FractInt for Windows (beta 5)

Download FractInt for Windows Beta 5

The legacy code I’ve been working on lately is FractInt.  FractInt’s most recent release is a source base that compiles in three ways: DOS (FRACTINT), Win16 (WinFract) and lunix/X11 (xfractint).  The DOS code has gone about as far as any DOS program should go, and then some.  The Win16 and X11 code has lagged behind the DOS code in some areas, mostly because people didn’t want to translate the 16-bit x86 assembly code for other environments.

In 1999, I studied the FractInt source base and suggested a set of changes that would move the DOS code into a Win32 environment more completely than the Win16 version had done.  The Win16 version had made native Windows dialogs for all the UI and while this was nice, because the DOS version was still alive the changes kept getting made there and they weren’t back-filled into the Win16 version.  The X11 version was a hybrid X11/curses program, which definately looked odd when you ran it.  So there were divergent UI methods, with some of the UI code falling behind the DOS code which always got all the changes.  In addition the X11 code also lagged behind the DOS code in functionality, but in ways that were different from the Win16 code.

FractInt is a large C program.  Not C++, but C.  It has a large quantity of global data and the code tends to be organized in weird ways in order to accomodate the 640K limit on an x86 segment and it uses an overlay approach to memory management.  The overlay model created incentives for weird aliasing of data and weird placement of functions and global data. So yeah, its a big piece of legacy code that has its fair share of warts and tumors that it has grown over the years.  (FractInt’s first release was in 1988, I believe.)

However, FractInt also has a lot of code that’s worth saving.  It computes over 150 fractal types, has a variety of image decomposition methods that can be applied to most fractal types, has a means of computing images on arbitrary formulas with its own builtin formula parser, supports arbitrary precision arithmetic on some fractal types, supports resuming of partially completed fractals, has lots of coloring options for inside and outside regions of fractal sets and many other useful features.

Since noone had acted on my partial implementation from 1999 to move FractInt forward and I recently completed a big multi-year personal project, I took on the task of finishing my partial implementation into a complete implementation for Win32.  (An updated xfractint release will come later.)  This is an implementation for Win32 that steals a trick that xfractint used to sneak a message loop into the polling I/O model currently in FRACTINT.  The code polls the keyboard often enough that sneaking the message loop into the keyboard processing works somewhat decently.  Along the way, a major restructuring of the entire code base has been done to remove all the DOS-isms: segments, near pointers, far pointers, interrupt calls to the BIOS and the 16-bit assembly language.  Furthermore, restructuring passes have been made on the source code to replace ‘magic numbers’ with symbolic names, naming global data and file scope data with prefixes to indicate their storage class, eliminating fallback code for systems with no FPU accelerator (386 and earlier) or even just 80287 FPU specific code, and sanitizing function names wherever possible.  There probably isn’t a single line of code in the entire source base that I haven’t touched in one way or another.  In ‘legacy code’ terms I did a hell of a lot of “Rename Method”, “Rename Variable” and “Rename Parameter” refactorings along with a few “Extract Method” refactorings along the way.

 Most of these changes have been refactorings because they are not intended to change the behavior of FractInt.  If they don’t make any difference to the end user, you might ask what good are they?  Well, as I read through the source code in an attempt to assimilate enough of it to introduce a driver abstraction, there were a number of barriers to understanding that were just an artifact resulting from the organic growth of fractint.  There’s too many globals to keep in your head.  When you’re looking at a piece of code in isolation, and it uses variables not defined in the local scope, you can’t easily tell if its accessing global data or file scope data.  Furthermore, knowing what that global data was for or what values were valid was often a question that could only be answered by searching the entire code base for where its used and reverse engineering back out the semantics of the variable in question.  So marking all global and file-scope data with a special prefix (g_ and s_, respectively) at least helps you know at a glance what kind of data any particular statement is manipulating.  Giving things clearer names helps other people to understand what the data is about.  Defining symbolic names for the valid values helps you see that this piece of data is treated like an enum with a set of specific values, that piece of data is treated as a set of bitflags with that set of flags, and this other piece of data is treated as an integer value.

The variable names, the style of programming that communicates through side-effects on globals and mostly the antiquated programming environment and the large source base all combined to create a giant set of barriers that intimidated most programmers from contributing to FractInt.  It was large.  It was hard to understand and hard to debug.  Reading the source code was sometimes just painful.  Monster functions that go on and on and on in a giant nested thicket of switch, if, and while statements.  Who wouldn’t be scared of this code?  Even if they weren’t scared of it, would they want to add code into a source base that was so strangled by 16-bit DOS memory constraints that by simply adding a function to a file they might break something?

So this release that’s currently at beta 5 will serve two purposes.  First, will be the port to Win32 bringing along as many of the DOS features as is possible.  The main things that will be missing compared to the DOS version are the integer fractal types written in assembly language.  Eventually we may get those back — there are a lot of RISC architectures out there that have screaming integer performance but not so good floating-point.  So integer math is still an important speedup technique on some architectures.  We just need the integer code converted from x86 assembly into C code so that it can be compiled for those architectures.

Second, the source code itself will be a little more presentable.  It still communicates through global variables, it still has a polling I/O model and there’s still the occasional Monster Function that goes on for too long, but its better now than it was before.  There’s too much work to “fix” everything at once, but I can give you an idea of where FractInt is headed:

  • Transition to C++ from C so that object-oriented methods can be used
  • Separation of the compute engine from the UI
  • Change to an event-driven I/O model from a polling I/O model
  • Native UI for Win32 and X11 platforms instead of emulating DOS text screens

You’ll notice that except for that last one, these sweeping changes to the code base aren’t even visible to the user.  Well, I might extend an existing fractal type or add a fractal type or two along the way, but most of these changes are needed to re-invigorate the FractInt infrastructure.  It needs the kind of organization that lends itself to more contributions from others in the Stone Soup Group tradition.

39 Responses to “FractInt for Windows (beta 5)”

  1. Alan Says:

    Any chance we could get a plain .zip version?


  2. legalize Says:

    The MSI package is the preferred way to install FractInt for Windows. It gives you shortcuts, an entry in Add/Remove Programs, etc. In the future this may be more important as INI files are deprecated in favor of the registry, prerequisites checked in the installer, etc.

    However, for any MSI file such as this one you can extract the embedded files by issuing the command “msiexec /a <path to msi file>” and select the target folder for the uncompressed files. This doesn’t install the product, but it does extract the compressed file payload.

    I cannot guarantee that I will fix any bugs you report if you don’t use the installer, however.


  3. Cees Says:

    Hi…great work!…far better performance of Fractint this way.
    So far I used a DOSshell (DosBox) emulation to use Fractint for DOS under win2000….very slow.

    I do not know if there is still action on this Fractint msi package, nor do I know if this is the right place for it, but I ran into a bug (I guess) with the TGA output.

    When tga output is selected in 3D params, the program renders the screen and then end after a short beep sound. The written .tga file only has the background color, the rest of the image is not written.
    Whatever I try, no result for TGA.

    I “need” this tga output to revive an old image I made back in 1993, called “Beauty”. I still have the .key file and edited it so this new windows-Fractint could read it well.
    I was trying to render the image again, in high res…to be able to get in on photopaper and frame it.

    Thanks for this Fractint-windows installer, great work!

    Highest regards,
    Cees van der Mark,
    The Netherlands.


  4. Rick Duim Says:

    This version is MUCH faster than any other windows implementation. Any chance this one will continued to be developed? Anyway, thanks for this version. I use it a lot, and have easily added high resolution video modes.


  5. jo Says:

    i invented a technique to accelerate l-systems
    (bypassing huge strings)


  6. legalize Says:

    OK, I’ll bite. What is your technique for accelerating L-systems?


  7. marcusbacus Says:

    I was really impressed with this new version. I am not a programmer so I can’t comment on specific details about it, but being a long time Fractint fan and also being a lot disappointed with its previous “Windows” versions I have to say that this was a fantastic improvement. I quit using Fractint since the Vista I think or even XP, and Winfract never interested me as it was slow and didn’t have some of the features I liked to use (I don’t remember seeing for example the evolution mode in WinFract). Recently I started to try it with DOSBox, but it wasn’t still “it”. This new version made me quite happy though, at least until a really “translated” Windows version can appear. It has some small bugs here and there, but that’s much better than not being able to use it at all.


  8. Sean Says:

    Excellent work, by far the best windows port ever.

    As a feature request though, something I have only seen on the acorn archimides port, a click & drag box to zoom


  9. marcusbacus Says:

    One of the few bugs I think I’ve noticed is when you use the boundary mode with the Evolution, it crashes quite often. Other than that, it’s quite a pleasure to work with, and the only thing I think it’s still missing would be the mouse support, it would make things much more productive. Whenever I need to rotate an image for example (mostly when it’s 90°) I just import the .par into UltraFractal and rotate it there, it’s actually simpler this way. I import a lot of my pars into UF (those that are compatible, at least) to render them in a better quality anyway, so it’s not a problem.


  10. Marcos Says:

    Much probably there is still some log file saved with these errors, but I’ve never bothered to look at it, although I remember a message saying a dump file was saved (when this happens the program closes). If it saves the errors sequentially in different files, I might have a couple of these files. If they are useful, I can post them somewhere and/or send you if you wish.
    What I do remember is that it crashes mostly (or only) if I’m not wrong if I’m using boundary or tesseral in the Evolution mode. With guessing and 1-2-3 passes it never crashed.


  11. Fractint and the new Windows versions | Mundo Fractal Says:

    […] is the ultimate fix for running Fractint in Windows. Get the Fractint 21 beta. It works without all that mess described […]


  12. Dave S. Says:

    Version 20.99 looks great but I have a problem with a buffer overflow. The program is then terminated. This happens when I type ‘v’ for view or try loading any of my saved fractal images. Sometimes the fractal will show but it is has the wrong aspect ratio and is stretched. Any ideas?


  13. Arte Fractal – Orbis Pictus Says:

    […] Consegui finalmente instalar o Fractint no Windows 7, uma solução simples que só agora fui conhecer. O link para esse feito é este aqui. […]


  14. Latest Inchiki News — forkword Says:

    […] the ‘iterated dynamics’ Fractint for windows beta by Richard Thompson, available at Legalize Adulthood. I spent many long hours with fractint on my old 386 and my 586. I’m looking forward to […]


  15. arnold mccall Says:

    You’ve saved my sanity. I’ve got XP with service pack 3 and I couldn’t get Winfract to go past an arbitary precision of 17. It’s a heap of shit if you ask me. Thanks.


  16. Michael Gonzales Says:

    You are AWESOME. I am a huge fan of Fractint, and it has always blown my mind that it never got formally updated past the Windows 98 era. Seriously, I have one old pentium p.c. and one old laptop, both with Windows 98 on them, for the sole purpose of being able to use Fractint. It seemed like a tragedy that the program might become a relic of another era of computing, but you have single-handedly kept the whole project alive? I can’t thank you enough…


  17. Tamara Katzenstein Says:

    Does Fractint works with a computer 64 bits?


    • legalize Says:

      Yes, although it is a 32-bit executable, not a 64-bit executable. Windows supports 32-bit executables on 64-bit operating systems.


      • Jay Litwyn Says:

        The author of “Undocumented Windows” said that mixed-mode code should be supported. He wuz talking about 16-bit code segments with 32-bit data segments (for example). I agree. Fractint iz very compact, and it can stay that way if you can mix address types and data types. Can you?


        • legalize Says:

          There’s no point in trying to retain anything from the 16-bit environment. When you use 16-bit instructions, you’re going through the legacy code path in the CPU which is the slowest path in the CPU.


          • Jay Litwyn Says:

            It haz been a long time since I studied instruction timings. I remember that the 486 featured integer operations that in 16 bits were often the same az in 32 bits, and that it had a five cycle, 32bit multiplier. That must’ve been a gargantuan circuit. 32=2^5 — exactly minimal time. My understanding of computer architecture says that if you minimize space, then you also reduce time, due to your cache getting more hits. I would not know where to look up the timings to prove that 16 bit operations occur in the same time az 32 bit operations, so I will take your word for it: 16 bit operations take longer than 32 bit operations.


  18. kreinsch Says:

    Any updates on the conversion to C++


  19. Jay Litwyn Says:

    I am very glad that someone iz making this project readable. It really should hav a place on the home page, even if it scales my old parameter files by an extra 4:3. Understanding how to make tesseral renderings in C and scalable iz a much more difficult issue. It can wait. An extra X-mag of 4:3 keeps me from using it.


    • legalize Says:

      This code is a fork of the code on We’ve gone our separate ways. I’m more interested in GPU based acceleration, portability and a modern code base. They are more interested in maintaining a 16-bit DOS application.


      • Jay Litwyn Says:

        I TRIED to get periodicity checking made into a non-default, because the poor rezults it sometimes yielded made me toss a lot of work. I do not _mind_ a GUI. I love the speed at which I can operate fractint with keys, though. Flip out to notepad with a copy of the old formula and a new name with a number at the end of it… There was something called “paste and go?” for fractint that did something like that. Beats me if it saved the formula. Readable code iz extremely nice. I hope the guys developing winfract take some tips or transfer to your project. GPU (SIMD?) and core-based acceleration are tricky. I would love to see that 2048 pixel square tesseral accelerated on my quad to 4096 pixels square. I do not think you want to fork your code on two decades of old parameters.


  20. sy2002 Says:

    Thank you *very much* for doing this amazing port. FractInt has been and still is one of the greatest fractal explorer ever – and thanks to you it will continue to live on.


  21. Joseph Thiebes Says:

    Hey I’ve been a fractint user since the early 90s but there has been a long gap in my use of the program since I didn’t have much luck with it on windows. This version works great! I just wanted to mention, this beta is now almost 7 years old and is not mentioned on the main fractint site. The latest developer version does not seem to work on Windows 7 but your beta does.


    • legalize Says:

      I have no control over the fractint developer’s site. They have the code for the beta 5 release, but they have chosen not to do anything with it. I forked to Iterated Dynamics but haven’t really had the energy or time to pursue another update. I would like to, but it’s a tough slog doing it alone. My gut feeling is that it’s bubbling closer to the top of my stack more than being pushed farther down, but I am not doing anything at the moment. Right now I have 3 proposed talks to C++ Now 2014 and I’m waiting to hear back on whether or not one or more of those talks will be accepted.


  22. clead Says:

    Very good work!
    I only don’t understand why for some fractals (for example, the Jim Muth’s Fractal of the Day April 17 1997, May 21 1997 and May 25 1997,, and the images don’t correspond to the one calculated by the original Fractint program (it seems that there are two kind of “layers” in the image and the Fractint for Windows can show only one of the two layers)
    Thanks to anyone who can solve this issue.


  23. Give Your Old Code Some New Love | Legalize Adulthood! Says:

    […] is more of a bug than a feature. Iterated Dynamics began as work in the FRACTINT tree to port the code base to Win32. I wanted to go further and embrace OpenGL and more GPU-oriented approaches to the application, but […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: