Mandelbrot Madness!

Version 2.0 -- FAQ

[Return to Index]

What different versions of MM! are available?

For detailed information about different versions of MM!, see the version history on the Introduction page. Roughly, version 1.x was the initial Win32 release written in Visual C++ with limited functionality. Version 2.x is a complete redesign of the application based primarily on the Java version of the program, Mandelbrot Madness JAVA! Version 2.x is written in .NET 2.0 C# and brings the Windows branch of development in line with version 4.x of the Java branch.

What's changed between version 1.0 and 2.0?

Virtually everything. Version 1.0 hadn't been updated since 1999, meaning a lot of advancements in both programming technology and my personal programming skills have been made. After Version 1.0 of MM! was released, I concentrated more heavily on the Java branch of development, eventually taking MMJ! all the way to version 4.0. MMJ! 4.0 was far more advanced than MM! 1.0. When the opportunity to develop on Windows opened again, I decided to bring the Windows branch up to speed with the Java branch. Among the new improvements are:

How does this version compare with Mandelbrot Madness JAVA!?

Version 2.0 of MM! is almost identical in features to version 4.0 of MMJ! The only features MMJ! has that MM! doesn't are Java specific and thus non-applicable to a Windows application. Meanwhile, MM! actually has a few new features not yet implemented in its Java counterpart:

How do I upgrade to the latest version?

There isn't an "upgrade" option, per se. The MM! 1.0 installer was pretty rudimentary. Your best bet will be to completely uninstall MM! 1.0 and install MM! 2.x from scratch. Since 1.0 did not support parameter files and didn't have configuration options, you don't need to worry about preserving any settings.

"Upgrading" from Mandelbrot Madness JAVA! is similarly simple. MM! and MMJ! use totally different configuration schemes, so you don't need to worry about preserving your settings. (You'll have to reconfigure MM! anyway.) You should first manually back up all your parameter and image files if you want to keep them around. MM! can read parameter files written by all versions of MMJ!, so don't throw them out. Once you've backed up your files, uninstall MMJ! and install MM! Or, if you want to, you can keep both installed side by side; they won't interfere with each other.

Why is MM! at version 2.x, while some of the other files are at version 1.x?

Because these are the first released versions of those files. The MMCommon library is completely new, as is the mmbatch command-line program. (The batch mode in Mandelbrot Madness JAVA! was built into the same executable.) PaletteBuilder has no real functional changes from the last Java version, so I felt rather silly calling version 2.0. Thus everything but the main app has a lower version number. The whole system is usually packaged as a unit, so as long as you install it all from the same installer, you should have nothing to worry about.

What's with the high final number in the version string (i.e. "2.x.x.[bigger_number]")?

The final number is the SVN revision number, and is more for my purposes than yours. You may even see the revision be different for different parts of the program (the main app, the MMCommon library, etc.), even though they should be part of the same Visual Studio solution. In officially released copies of the program, you only need to worry about the first two numbers in the version string, the major and minor version numbers.

How do I install MM!?

Simply download the MM! installer and run it. It's that simple. (You can also take the added step of verifying the GnuPG signature of the installer if you want to verify its authenticity.) Note that "batch" mode support is considered optional and must be explicitly chosen during installation. If you're not comfortable working from the command line or otherwise don't need batch rendering or conversion, then you can safely skip batch mode support and stick to the GUI application. Batch mode requires you to install the application as an Administrator, because it modifies the system PATH environment variable.

Non-Windows users are in for a bit more work, as there is no standard installer for other platforms. Simply download the binary archive and extract it to the location where you want to store it. This is considered an advanced topic and is left as an exercise to the reader.

I'm running a non-Windows operating system. Can I run MM!?

In theory, yes. Using a .NET 2.0 compatible framework, you should be able to run MM! virtually anywhere. However, as of this writing, MM! is untested under any other platform other than Microsoft's official .NET Framework 2.0 on Windows. Initial tests using Mono under Fedora Core 5 failed as this version of Mono does not support much of .NET 2.0. Hopefully we'll be able to test it more thoroughly before we release it, but other platforms (i.e. other than 32bit Windows and Linux) will most likely remain untested. The only place we foresee possible problems is that MM! searches the Windows registry to find the user's default image editor. We have no idea how other .NET implementations will react to this code.

How do I run MM! in batch mode?

Technically, MM! is only a graphical (GUI) application with a point-and-click interface. However, it also includes a command-line (i.e. console) application that lets you perform certain tasks in "batch" mode, similar to the batch mode in MMJ! For more information on the batch mode, see here.

What's the deal with the multiple version of MMJ files?

Unfortunately, this involves a little bit of history with the Java version of MM! MMJ! 2.0 introduced the MMJ file format for saving parameters. Unfortunately, this version of the program did not allow zooming in Julia sets, and the MMJ format did not anticipate this feature. When Julia zooming was added in MMJ! 3.0, the MMJ file format had to be restructured to allow for the additional information. These "Version 2" MMJ files could not be read by MMJ! 2.x, so a conversion utility was added to MMJ! to allow users of the newer versions share files with users of the older versions.

This version of MM! can read both "versions" of the MMJ file format. By default, it writes the newer "version 2" file that allows Julia zooming. For backward compatibility, we have kept the conversion utility so you can convert "version 2" MMJ files to the "version 1" format. We don't anticipate much use from this feature, but we like to keep it around, just in case. More information can be found here.

If we have MMJ files, what are MOB files for?

The MOB file is an alternate form of parameter file. It combines all the information of the .MMJ parameter file and the .PAL palette file into one compressed binary file. This had advantages and disadvantages, but it is the recommended format for sharing parameter files between folks using MMJ! versions 3.1 and up and MM! versions 2.0 and up.

If we have these other parameter files, what are MM XML files for?

The MM XML file format is making its debut with this version of MM! This powerful XML-based format combines many of the advantages of the MOB format, including inline palette information, without being tied to a single technology platform (like Java for MOB). It also includes new featrues such as comments, compression, and prerendering information unsupported by the older formats. We strongly recommend the use of this format over all the others, but the conversion utility will let you move back and forth between the different parameter file formats with relative ease.

Why don't you just save parameter information in the image files like FractInt does?

Well, for one thing, this isn't FractInt. :) Actually, I thought about it. It would be a great way to combine saving the image information and parameters in one compact unit. Unfortunately, .NET doesn't have the capability (that I know of) to read and write the extra textual blocks of the GIF98a or PNG specifications which would be needed to store such information. And saving the parameters and the palettes by themselves, without the image, takes up much less space.

If you've never used FractInt, consider it highly recommended. It has also been ported to several different platforms. Personally, I find MM! a lot easier to use, but FractInt is much more versatile and can handle many more fractals than just the Mandelbrot and Julia sets.

MMJ! runs incredibly slow! How can I speed it up?

Fractal generation is historically a slow process. It requires a lot of repeated calculations and a good deal of memory, especially when rendering large images. Many of us who have joined the computer world only recently don't fully appreciate the old days, where generating a fractal was an overnight exercise (if not over several days!). The only thing I can suggest is be patient. You can speed up part of your process by creating small resolution "preview" images at low iteration rates, then "upping" these values when you come across something you want a better look at. Having a Windows Solitaire session (or similar time-wasting mechanism) open at the same time might help the boredom somewhat. A faster processor and more RAM is the only permanent cure, as the rendering algorithm is fairly efficient.

Why can't MM! find the PAL file associated with my MMJ file?

The .MMJ parameter file does not save any sort of path information associated with a .PAL palette file when it stores the palette file's name. This is because different platforms delimit paths differently, and storing a path may cause shared .MMJ files to work improperly on other platforms. Therefore, when MM! opens a .MMJ file, it assumes that if a .PAL file is specified it will be in the Palette Files folder as specified in the Options menu. If it can't find the palette, make sure the palette files is in the Palette Files folder, or change this setting to the folder that contains the file.

The command line "batch" program will assume the PAL file will be in the same path as the parameter file. If it cannot find the palette file, try moving the .PAL file in the same directory as the .MMJ file.

Another possibility is that you didn't save the palette with the parameters. See the next question.

One alternative to avoid the missing palette file situation is to use MOB or MM XML files instead, since these files store both the parameters and palette in the same file.

MM! says that no palette was specified in my parameter file!

MM! does three things with palettes when you save a parameter file. If you use the internal Rainbow or Grey Scale palettes, they will not be saved to disk; a flag will be specified in the parameter file and the proper palette will be restored when it is loaded again. If you loaded a palette from a file, the palette's file name is saved, so MM! will attempt to load that file when the parameter file is opened again. Lastly, if you created a custom color scale palette, you will be given an opportunity to save it to a .PAL file. If you choose not to, MM! will record that no palette was saved. If you load this parameter file later, MM! will see this and default to the Rainbow palette.

Another possibility is that your palette file is somewhere that MM! can't find it. See the previous question.

Help! I don't have a command line! How do I run the command-line utilities?

You're in luck. All the command-line utilities are now available through the Tools menu. So, if you're on a non-Windows box without a command prompt or just don't feel comfortable typing in options and file names, you can use the GUI to perform all of these tasks. Only the batch mode is not available through the GUI.

Can PaletteBuilder read/write the palettes in MOB or MM XML files?

PaletteBuilder can read the palette from a MOB or MM XML file, however it cannot write back to it. Since MOB and MM XML files contain all the information to recreate an individual image, overwriting the palette in a MOB or MM XML would alter those parameters. It is our opinion that this would be a different image and it should have its own separate MOB or MM XML file. If you load a palette from a MOB or MM XML file, saving back to the same file name (the Save menu option) will be disabled. You can always save the file to a new PAL file (the Save As option), then load this new palette into MM! where the new image can be rendered. You can then save the new palette and parameters to a different MOB or MM XML file if you wish.

Why is the "My Image Editor" button and menu item grayed out?

By default, each time MM! starts it searches the Windows registry to see if there is a preferred application defined to edit PNG files. If this can't be found, it looks for a program that can open (not necessarily edit) PNG files. If neither of these can be found, MM! assumes no image editor installed and grays out the "My Image Editor" button and menu item. Fortunately, you can override this behavior by going to the Options menu and choosing Other Options. This will open the Options dialog box. In the Helper Apps tab, you can turn off this detection and even specify your preferred image editor yourself.

How do I make MM! default to the same or different directories for all my image and parameter files?

Go to Options, then Folders. You will see a tear-away menu with three items, each corresponding to a specific folder. Each one will let you set the default directory for MM! to look for that type of file. This way, you can keep your user files out of the program directory, or even separate parameter files from palette files from image files. The organization is up to you. There is also a fourth option that will let you set all three defaults to the same location, if you'd prefer to keep them all together.

Why does it take so long the first time I go to save or load a MOB file?

The reasons behind this delay are technical and complicated, so we'll give you the shortest version we can. The MOB file format has its roots in the Java versions of Mandelbrot Madness! and are tightly tied to Java's way of doing things. This implementation is not native to the .NET platform on which this version of MM! is based, so we have to jump through a few hoops to get it to work properly. The first time you load or save a MOB file, several extra library files have to be loaded, causing a noticeable delay. Fortunately, after these libraries are loaded they will stay in memory, making subsequent MOB file operations go more quickly.

Why do I occasionally get warnings about loading a file with a "high-color palette"?

The High-Color palette was an experimental palette that I tried to introduce in Mandelbrot Madness JAVA! 4.0. This palette attempted to go beyond our usually very limited 256-color barrier to introduce 16-bit, 65,536-color images. However, this palette didn't turn out nearly as well as I had hoped and I eventually decided to abandon it. For completeness, I have implemented the High-Color palette and this version of MM! will open and render files that include it, but it cannot be selected from the user interface for new fractals.

Where can I view the latest version of this FAQ?

It's quite possible that this FAQ has changed dramatically since you downloaded this distribution. Fortunately, you can always find the latest version of this FAQ at I will try to keep this up-to-date, even when the FAQ in the distribution may not be.


[Return to README]

Last updated March 19, 2007.
© Copyright 2007, Jeffrey T. Darlington. All rights reserved.