Welcome to Fractal Forums

Fractal Software => Fractal Programs => Topic started by: recursiveidentity on March 16, 2017, 09:42:05 PM




Title: Fastest mandelbrot software? Perturbation method?
Post by: recursiveidentity on March 16, 2017, 09:42:05 PM
Hi, I've been using Kalles for a while, and see I think that maybe there will not be a version 3... What other software is out there right now that takes advantage of the perturbation method? Or which software in general is the fastest for making regular old Mandelbrot zooms down to about e500 or so? I don't need anything fancy. I was taking a look at Mandel Machine, but it also appears to be not under development any more and also requires an old Java version... Thanks!


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: simon.snake on March 17, 2017, 11:21:54 PM
Prior to Kalles Fraktaler and Mandel Machine my old favourite was Fractal eXtreme.

This is still being updated (less so these days maybe but who knows).

It is pretty impressive, multi document based, is free to use up to 100 'zooms', can be extended with plugin formulas (some programming knowledge required) and doesn't slow down your PC while drawing each fractal as it is modest in CPU usage etc. and only costs a nominal amount to register.  The author, Bruce Dawson is on the forum I think.

It's not all rosy though - it only supports one colour palette at a time for all open windows, doesn't use Perturbation, was written over 15 years ago and still feels like it was.

I hoped Bruce would add more features (e.g. perturbation, etc.) and drag it into the 21st Century but updates have been few and far between over the last few years.

Still, worth a try so you can make your own mind up.  There is a 64-bit version too.  It's easy to find on the web.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: Dinkydau on March 18, 2017, 04:21:19 AM
Mandel Machine is so fast it's worth to make java somehow work and learn how to avoid the bugs. In terms of speed I'd say it's the true successor to Fractal eXtreme. Kalles Fraktaler has more useful features and I'm using it for exploring a lot now, but I can definitely recommend using Mandel Machine for making final renders.

The most computationally intensive render I did with Fractal eXtreme took 30 days (http://dinkydauset.deviantart.com/art/Evolution-of-S-shapes-433465344). It was like a big project. I had my computer running 24/7.

Now with Mandel Machine, same resolution, default settings: 8,5 minutes including glitch correction. It's nothing. You can almost start the render, make a sandwich and it's done.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: recursiveidentity on March 18, 2017, 03:45:40 PM
Thanks for the replies. I actually bought Fractal Extreme years ago and really do like it, it's just way too slow on my old machine. I've now been spoiled by Kalles.. :)

I still use Kalles, I just wondered what else was out there... I will give Mandel Machine another go and get Java working to see what I think.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: Kalles Fraktaler on March 18, 2017, 04:17:31 PM
The source of mandel machine is publicly available.
It seems the core functionality is implemented in a native dll written in assembler, and the ui in java.
The choice of java is causing problems for many that cannot use MM, including me since a year back or so.
One with time and knowledge could perhaps attempt to write a C++ ui that access the dll, that would be an awesome thing to do


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: recursiveidentity on March 18, 2017, 06:30:23 PM
The source of mandel machine is publicly available.
It seems the core functionality is implemented in a native dll written in assembler, and the ui in java.
The choice of java is causing problems for many that cannot use MM, including me since a year back or so.
One with time and knowledge could perhaps attempt to write a C++ ui that access the dll, that would be an awesome thing to do

Wish I had the time/skill... I am a programmer, but not up to that task I'm afraid.  Wish we could get a bounty going or something for a nice full fledged open source cutting edge program, similar to how blender has has so much success.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: recursiveidentity on March 18, 2017, 09:43:50 PM
Also, I wonder if it would be easy to take the existing Java code and just recompile it for 1.8. There may not even be anything broken and it just needs to be built, but that's probably wishful thinking...


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: 3dickulus on March 18, 2017, 10:17:21 PM
I managed to convert SuperFractalThing from java to C++ for a 10X speedup and that was a handful, but after having a look at MMs java code I don't think I want to tackle that one. A better idea might be to use the asm core library in a C++ program ???


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: Kalles Fraktaler on March 18, 2017, 10:19:12 PM
I managed to convert SuperFractalThing from java to C++ for a 10X speedup and that was a handful, but after having a look at MMs java code I don't think I want to tackle that one. A better idea might be to use the asm core library in a C++ program ???
Yes, that is exactly what I meant. :)


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: 3dickulus on March 18, 2017, 10:34:21 PM
yes, of course.  :embarrass:  SFT was 100% java, MMs gui to C++ would still be a big job though.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: recursiveidentity on March 18, 2017, 11:58:29 PM
So since the core is in ASM, does that mean the front end programming doesn't have much impact to performance? Would it have to be C++? I would think any front end would work as long as it stays out of the way...


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: 3dickulus on March 19, 2017, 02:57:08 AM
yep, any language that can use the library would work.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: Kalles Fraktaler on March 19, 2017, 03:56:54 PM
yep, any language that can use the library would work.
Maybe we can work togehter on this?
The source of the dll is availabe and consist of only 3 files:
mm_WorkerThread.h
mm64.cpp
mm64core.asm

The definition "JNIEXPORT" indicates exported functions, I assume simliar to "__declspec(dllexport)"
There are only 12 exported functions:
1. Java_mm_WorkerThread_getItNative_164a
2. Java_mm_WorkerThread_getItNative_164b
3. Java_mm_WorkerThread_getItNativeEx
4. Java_mm_WorkerThread_getCPUid
5. Java_mm_WorkerThread_getIterationsPTnativeF
6. Java_mm_WorkerThread_getIterationsPTnativeD
7. Java_mm_WorkerThread_getIterationsPTnativeEx
8. Java_mm_WorkerThread_setOrbit
9. Java_mm_WorkerThread_freeOrbit
10. Java_mm_WorkerThread_initRefOrbCoeffsEx
11. Java_mm_WorkerThread_doAuxIterationEx
12. Java_mm_WorkerThread_getIterationsDnative

So, what do they do and how are they called?
If you have converted SuperFractalThing to C++, I assume you have knowledge in Java?
Can you debug MM and see how to use these 12 functions?

If we want to convert this to a C++ project, there is no need to compile the files as a DLL project, and the first parameter of each function, JNIEnv, needs to be implemented.
The jclass parameter is never used so it can be ignored.

I don't have access to Java's SDK, but I was able to compile the code by adding the following piece of code in the top of mm_WorkerThread.h, that defines the used datatypes and implements JNIEnv (although always return NULL):
Code:
#define JNIEXPORT __declspec(dllexport)
#define JNICALL
#define jclass void *
#define jint int
#define jdoubleArray double *
#define jfloatArray float *
#define jdouble double
#define jlong __int64
#define jlongArray __int64 *
#define jboolean bool

#define JNI_TRUE 1
#define JNI_ABORT -1

class JNIEnv
{
public:
double *GetPrimitiveArrayCritical(jdoubleArray dbla, jboolean isCopy)
{
return NULL;
}
jlongArray GetPrimitiveArrayCritical(jlongArray jzx,jboolean isCopy)
{
return NULL;
}
void ReleasePrimitiveArrayCritical(jdoubleArray dbla, jdouble* xyzbailout, jint i)
{
}
void ReleasePrimitiveArrayCritical(jlongArray dbla, jlong* xyzbailout, jint i)
{
}
void ReleaseFloatArrayElements(jfloatArray orbxyFref, float * orbxyF,jint i)
{
}
void DeleteGlobalRef(jfloatArray orbxyFref)
{
}
void DeleteGlobalRef(jdoubleArray orbxyFref)
{
}
void DeleteGlobalRef(jlongArray orbxyFref)
{
}
void ReleaseDoubleArrayElements(jdoubleArray orbxyDref, double *orbxyD, jint i)
{
}
void ReleaseLongArrayElements(jlongArray orbxyEref, __int64 *orbxyE, jint i)
{
}
double *GetDoubleArrayElements(jdoubleArray orbxyDref,jint i)
{
return NULL;
}
float *GetFloatArrayElements(jfloatArray orbxyFref,jint i)
{
return NULL;
}
__int64 *GetLongArrayElements(jlongArray orbxyEref,jint i)
{
return NULL;
}
jfloatArray NewGlobalRef(jfloatArray orbitXYF)
{
return NULL;
}
jlongArray NewGlobalRef(jlongArray orbitXYE)
{
return NULL;
}
jdoubleArray NewGlobalRef(jdoubleArray orbitXYD)
{
return NULL;
}
};

Now since I don't have knowledge in Java I don't understand the difference between e.g. GetPrimitiveArrayCritical and GetDoubleArrayElements and NewGlobalRef, which all seems to return arrays of the 3 different datatypes __int64, double and float.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: recursiveidentity on March 19, 2017, 05:21:44 PM
Awesome, I am willing to help however I can. Testing if nothing else...


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: 3dickulus on March 19, 2017, 07:33:51 PM
ok will have a look at it... I am not a java programmer, the SFT conversion was done based entirely on the similarity between java and C, the hardest part was figuring out which things were pointers because of dynamic typing.
I am also working on linux so no DLLs only .so or static .a(lib) files, the asm part is not very big and could be compiled into the prog or linked as static lib instead of using it as an external dynamic library and for cross platform compat I would want to use Qt for the gui part.

you're definitely on the right track, mm_WorkerThread.h is machine generated and should be re-generated based on the target platform but in a pinch modifying manually should work too.

the java code will just be a map for re-creating the interface, must pay attention to work flow and threading implementation.

The first thing I would do is to hardcode some working settings and just get it to render an image in a simple "hello world" window...


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: 3dickulus on March 19, 2017, 11:38:43 PM
java files "between" gui and mm64core..

iterArray/ *
math/ *
util/itercodec/ *
util/offHeapArrays/ *
WorkerThread *

...about 30 java files

ControlTread.class and ControlThreadStatus.class might be of interest as well as the Computation and Rendering classes in gui/toolbox/

maybe more, not sure if I will be able to get this all into my tiny brain  :alien:


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: recursiveidentity on March 20, 2017, 12:39:25 AM
What languages do you know? I'm a .net programmer for my day job, so that's what I know best, but would think C# to Java would not be so difficult... And I know my way around the syntax and can read Java and C++... Know a little bit about memory management...


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: Dinkydau on March 20, 2017, 02:14:12 AM
Would it help if the latest Mandel Machine source code was released instead of that of the 1.3.10 version? Zoom depth was increased and bugs were fixed since then. I asked Botond Kosa for the latest source code a few weeks ago because I had some plans to add features to the program, because nowadays I'm copy-pasting coordinates between it and Kalles Fraktaler all the time. It seems he has disappeared completely and he might return, or not, it's unclear. They were just some relatively simple ideas, but I like to see more people seem to agree that because of the highly efficient core functionality, Mandel Machine is worth building upon and I will be interested to follow the events.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: Kalles Fraktaler on March 20, 2017, 09:25:02 AM
java files "between" gui and mm64core..

iterArray/ *
math/ *
util/itercodec/ *
util/offHeapArrays/ *
WorkerThread *

...about 30 java files

ControlTread.class and ControlThreadStatus.class might be of interest as well as the Computation and Rendering classes in gui/toolbox/

maybe more, not sure if I will be able to get this all into my tiny brain  :alien:
I think a way forward is to try to understand what the 12 exported functions does?
1.Java_mm_WorkerThread_getItNative_164a?
2. Java_mm_WorkerThread_getItNative_164b?
3.Java_mm_WorkerThread_getItNativeEx?
4.Java_mm_WorkerThread_getCPUidI think this is checking the capabilities of the CPU
5.Java_mm_WorkerThread_getIterationsPTnativeFMaybe this is the mandebrot iteration loop for a specific datatype, could it be per pixel?
6.Java_mm_WorkerThread_getIterationsPTnativeDMaybe this is the mandebrot iteration loop for a specific datatype, could it be per pixel?
7.Java_mm_WorkerThread_getIterationsPTnativeExMaybe this is the mandebrot iteration loop for a specific datatype, could it be per pixel?
8.Java_mm_WorkerThread_setOrbitSeems to have something to do with the refreence
9.Java_mm_WorkerThread_freeOrbitSeems to be release of the reference
10.Java_mm_WorkerThread_initRefOrbCoeffsExMay be the calculation of Series Approximation
11.Java_mm_WorkerThread_doAuxIterationEx?
12.Java_mm_WorkerThread_getIterationsDnativeMaybe this is the mandebrot iteration loop for a specific datatype, could it be per pixel?


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: 3dickulus on March 21, 2017, 02:15:49 AM
I agree, need to study the calls from the java flow to see what's going on

for me, the way forward is trying to compile but gcc doesn't like intel asm syntax, there is an option, .intel_syntax noprefix for the assembler that can be set for specific pieces of code but has to switch back using .att_syntax so that the compiler doesn't use it for other things...

roughly 32000 lines of java code total, if I can compile the asm on my linux machine maybe I will jump into the java and try to figure it out but if I can't compile it I probably won't dig much further and will leave it to the windows coders.


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: claude on March 21, 2017, 08:53:03 AM
if I can compile the asm on my linux machine

I recall Botond mentioning that the ABI of Windows and Linux is different, so chances are the ASM entry points would need massaging to fit...


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: _revers_ on March 21, 2017, 11:39:11 AM
Also, I wonder if it would be easy to take the existing Java code and just recompile it for 1.8. There may not even be anything broken and it just needs to be built, but that's probably wishful thinking...

The sources aren't broken at all. I'm able to import them (mm_v1.3.10_src_java.zip (http://web.t-online.hu/kbotond/mandelmachine/src/mm_v1.3.10_src_java.zip)) to Eclipse IDE (http://www.eclipse.org) and run/debug the Mandel Machine.

To make possible development of the Mandel Machine in Eclipse one needs to do few steps, though:

1. The Mandel Machine uses restricted Java API. To be able to compile it in Eclipse one needs to change the access rules from Error to Warning. (http://stackoverflow.com/questions/25222811/access-restriction-the-type-application-is-not-api-restriction-on-required-l)

(http://www.bankfotek.pl/thumb/2066514.jpeg) (http://www.bankfotek.pl/view/2066514)

2. The Mandel Machine has dependencies to oracle.jdeveloper.layout package. The easiest way to acquire the package is to download MM binaries (http://web.t-online.hu/kbotond/mandelmachine/download/Mandel_Machine_1.3.15_x64.7z), extract file mm.jar (for example using 7zip) and copy folder "oracle" to the Eclipse's project "lib" folder (it needs to be created). Also it is good idea to copy all native libs and configuration files to the main project's directory:

(http://www.bankfotek.pl/thumb/2066515.jpeg) (http://www.bankfotek.pl/view/2066515)

Next you need to add the lib folder to the projects libriaries search path: RMB on the project -> Properties -> Java Build Path -> Libraries -> Add class folder and select "lib".

(http://www.bankfotek.pl/thumb/2066516.jpeg) (http://www.bankfotek.pl/view/2066516)

3. Finally you can run the app by RMB on mm/AppWindow.java file -> Run As -> Java Application

(http://www.bankfotek.pl/thumb/2066517.jpeg) (http://www.bankfotek.pl/view/2066517)

And voilą, you are ready for development of the Mandel Machine :)

(http://bankfotek.pl/thumb/2066513.jpeg) (http://bankfotek.pl/view/2066513)


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: _revers_ on March 21, 2017, 03:43:20 PM
In case of the newest sources, there is possibility to decompile Java classes from the latest Mandel Machine version. Produced code is very readable (even local variables have original names), though would require some fixes to compile.

But the question is: would the author mind if you would use his decompiled source code?
I wonder what was the reason to not publish the source code of five newest releases. Maybe there was one...


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: 3dickulus on March 22, 2017, 01:58:19 AM
@claude gcc prefers AT&T syntax and compiles libraries a little differently so not just ASM entry points but the src/dst order is reversed and register names need % prefix and a number of other things.

@_revers_ Thanks for the eclipse tutorial ;) that will help to get others to look at this

the last code version on the MM site is v1.3.15 - 2015.06.16 (http://web.t-online.hu/kbotond/mandelmachine/download/Mandel_Machine_1.3.15_x64.7z) almost 2yrs ago, I'm certainly impressed with Botond's work but oracle, intel syntax and java all together makes the coding part of my brain overheat  :tongue1:


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: recursiveidentity on March 27, 2017, 03:19:23 AM
I'm going to download Eclipse and play around with this for fun... Also, I assume from the direction this thread went that there aren't really any other programs out there right now that use perturbation?


Title: Re: Fastest mandelbrot software? Perturbation method?
Post by: Dinkydau on August 02, 2017, 04:19:11 AM
Edit: Before you read this post: I have already managed to solve the problems myself. I will make a later post on how to I compiled the full Mandel Machine when I understand better why it worked this time and when I'm more confident that it actually works well.

The definition "JNIEXPORT" indicates exported functions, I assume simliar to "__declspec(dllexport)"
There are only 12 exported functions:
1. Java_mm_WorkerThread_getItNative_164a
2. Java_mm_WorkerThread_getItNative_164b
3. Java_mm_WorkerThread_getItNativeEx
4. Java_mm_WorkerThread_getCPUid
5. Java_mm_WorkerThread_getIterationsPTnativeF
6. Java_mm_WorkerThread_getIterationsPTnativeD
7. Java_mm_WorkerThread_getIterationsPTnativeEx
8. Java_mm_WorkerThread_setOrbit
9. Java_mm_WorkerThread_freeOrbit
10. Java_mm_WorkerThread_initRefOrbCoeffsEx
11. Java_mm_WorkerThread_doAuxIterationEx
12. Java_mm_WorkerThread_getIterationsDnative

So, what do they do and how are they called?
I spent my time today reading about how java works, to understand more about how Mandel Machine works. According to some sites, functions from a dll should be declared with the keyword native in java. There are more functions in the java code with this keyword. All of them are declared in WorkerThread.java:
Code:
private static native int getItNative03_32(double[] iterArray, int index, int[] zxzy, int maxIterations, double bailout, final double lnlnbailout);	
private static native int getItNative04_32(double[] iterArray, int index, int[] zxzy, int maxIterations, double bailout, final double lnlnbailout);
... it goes from 3 through 35
private static native int getItNative34_32(double[] iterArray, int index, int[] zxzy, int maxIterations, double bailout, final double lnlnbailout);
private static native int getItNative35_32(double[] iterArray, int index, int[] zxzy, int maxIterations, double bailout, final double lnlnbailout);

private static native void getItNative_64a(long[] zxzy, int minIterations, int maxIterations, double bailout, int fracs);
public static native void getItNative_64b(long[] zxzy, int maxIterations, double bailout, int fracs, double[] refOrbXYD, long[] refOrbXYE, int refOrbLength2, double mul, double glitchAbsThreshold, boolean extended);
private static native int getItNativeEx(double[] zxzyb, int minIterations, int maxIterations, boolean computeDE);
public static native void setOrbit(float[] referenceOrbitF, double[] referenceOrbitD, long[] referenceOrbitE);
public static native void freeOrbit();
public static native void initRefOrbCoeffsEx(long[] coeffsEx, int serApproxTerms, int coeffsScaleMode);
public static native void doAuxIterationEx(long[] coeffsEx, int serApproxTerms, int coeffsScaleMode, double[] refOrbXYs);
private static native void getIterationsDnative(int minIterations, int maxIterations, long zxzyb4Ptr, int pixels, int simdMode, boolean computeDE);
private static native void getIterationsPTnativeF(long minIterations, int orbitLength, long dxdyb4Ptr, int scale, int pixels, int simdMode);
private static native void getIterationsPTnativeD(long minIterations, int orbitLength, double[] dxdyb4, int scale, int pixels, int simdMode, boolean ignore);
private static native void getIterationsPTnativeEx(long minIterations, int orbitLength, double[] dxdyb, boolean ignore, boolean extendedReference);
public static native void getCPUid(long resultsPtr);
The remaining functions are declared in mm64.cpp and exist in mm64core.asm, so they must be the functions written in assembly language.

The source of the dll is availabe and consist of only 3 files:
mm_WorkerThread.h
mm64.cpp
mm64core.asm

...

I was able to compile the code by adding the following piece of code in the top of mm_WorkerThread.h, that defines the used datatypes and implements JNIEnv (although always return NULL):
Code:
#define JNIEXPORT __declspec(dllexport)
#define JNICALL
#define jclass void *
#define jint int
#define jdoubleArray double *
#define jfloatArray float *
#define jdouble double
#define jlong __int64
#define jlongArray __int64 *
#define jboolean bool

#define JNI_TRUE 1
#define JNI_ABORT -1

class JNIEnv
{
public:
double *GetPrimitiveArrayCritical(jdoubleArray dbla, jboolean isCopy)
{
return NULL;
}
jlongArray GetPrimitiveArrayCritical(jlongArray jzx,jboolean isCopy)
{
return NULL;
}
void ReleasePrimitiveArrayCritical(jdoubleArray dbla, jdouble* xyzbailout, jint i)
{
}
void ReleasePrimitiveArrayCritical(jlongArray dbla, jlong* xyzbailout, jint i)
{
}
void ReleaseFloatArrayElements(jfloatArray orbxyFref, float * orbxyF,jint i)
{
}
void DeleteGlobalRef(jfloatArray orbxyFref)
{
}
void DeleteGlobalRef(jdoubleArray orbxyFref)
{
}
void DeleteGlobalRef(jlongArray orbxyFref)
{
}
void ReleaseDoubleArrayElements(jdoubleArray orbxyDref, double *orbxyD, jint i)
{
}
void ReleaseLongArrayElements(jlongArray orbxyEref, __int64 *orbxyE, jint i)
{
}
double *GetDoubleArrayElements(jdoubleArray orbxyDref,jint i)
{
return NULL;
}
float *GetFloatArrayElements(jfloatArray orbxyFref,jint i)
{
return NULL;
}
__int64 *GetLongArrayElements(jlongArray orbxyEref,jint i)
{
return NULL;
}
jfloatArray NewGlobalRef(jfloatArray orbitXYF)
{
return NULL;
}
jlongArray NewGlobalRef(jlongArray orbitXYE)
{
return NULL;
}
jdoubleArray NewGlobalRef(jdoubleArray orbitXYD)
{
return NULL;
}
};
How do you do this? I tried using g++ from the commandline in cygwin64 to compile mm64.cpp. It fails (collect2: error: ld returned 1 exit status), so I inserted your piece of code, which changes the error to a lot of these:

Code:
mm_WorkerThread.h:4:14: error: declaration does not declare anything [-fpermissive]
 #define jint int
              ^
I googled the error, did some things without understanding what I was doing, which made this specific error go away and lead to another error, and another... So I can't get this compiled. Apparently it didn't normally work for you either (without the extra code). Do you have an idea why? I would assume the source code as shared by Botond Kosa be complete and we shouldn't need to change anything.

I tried to find the reference to the file containing the assembly language, because that's what the dll is really about, and couldn't find it. It makes me wonder how this code was supposed to be used.

Edit:
Apparently, this is how a c file with functions in assembly language should be compiled. Taken from an example from the JWasm assembler:
Code:
gcc -c mixed1c.c 
jwasm -coff mixed132.asm
gcc mixed1c.o mixed132.obj -o mixed1c.exe

JWasm is not the correct assembler for Mandel Machine's source code - it's just where I found the example. I have now found out the right one is probably ml64, an executable included in some microsoft software packages including Visual Studio. It's very hard to find otherwise. I downloaded Visual Studio 2013 (several gigabytes) and installed it in a virtual machine only to copy the ml64.exe that's just 500 kB. Using that and assuming c++ should be compiled the same way as c, this is what I did:
Code:
ml64 /c mm64core.asm
g++ -c mm64.cpp
g++ mm64.o mm64core.obj -o mm64.dll
This assembles mm64core.asm to mm64core.obj, compiles mm64.cpp to mm64.o and links the two files to form mm64.dll.

This generates a dll. That's a good sign. Unfortunately the dll makes Mandel Machine crash, so I'm still not doing something right. (Mandel Machine can start succesfully when it doesn't need to use the dll: for example when a parameter file with iteration data is last loaded.)


The sources aren't broken at all. I'm able to import them (mm_v1.3.10_src_java.zip (http://web.t-online.hu/kbotond/mandelmachine/src/mm_v1.3.10_src_java.zip)) to Eclipse IDE (http://www.eclipse.org) and run/debug the Mandel Machine.
This works. Thanks.

There is still a problem which I'm not sure what's causing it. I used mm64.dll from version 1.3.10 because the source code is for that version. The application crashes when zooming to exactly 1951 zooms or more. (Using the latest mm64.dll from version 1.3.15 doesn't allow zooming beyond 43 zooms.)
Edit: Ignore this. Parameter files with higher magnifications can be loaded succesfully and I can continue zooming without problems so it's probably just a bug.