Tim,
Jonathan, how is the new job???
Same desk, same computer, same logon. The hope is added stability. I've never actually worked directly for a utility before. Some of the people I'm working with I've known for 20 years. I started working for this utility as a contractor in 1985. Yikes! IOW, great so far.
Winfract seems slow. This makes me think that it is only of historical interest, and won't be that usable even if we fix the problems. That doesn't mean I'm not willing to help bring Winfract and Fractint in synch if we can do it in a finite amount of time. It would be nice to have synched up versions of Fractint, Xfractint, and Winfract if it doesn't take too long.
Do you have pixel-by-pixel update set? If so, unset it!
Have you seen the program gnofract4d? The home page is http://gnofract4d.sourceforge.net. This is an amazing open source program written in python and C++ using GTK+. It parses both fractint and ultrafractal formula files to C, and then loads the C and runs. It runs only under Linux at present. I had no trouble installing it under Mandrake.
I've looked at it periodically. Not recently.
Given the existence of at least two, and maybe three outstanding fractal programs (Gnofract4d, Ultrafractal, and Xaos), as I find my interest picking up again I also find myself asking this question: what is a worthwhile goal for a further development of Fractint given the existence of those (each in their own way) more advanced programs?
This *is* a hobby, after all. The goal is to give you something to think about that isn't work related. Sadly, I can see the day where we have to leave the DOS code and only develop WinFract and Xfractint. Once we implement png support, for example.
The simplest answer to my question about a goal would be to extend fractint's life by porting to 32 bits as we have discussed. I still favor using WxWindows rather than Windows API so we could have an easy Linux port. I'm looking into various compiler choices. I figure I have enough in me to learn one new thing, maybe two, and I wonder if a good choice would be WxWindows and maybe C++ for a more literal port of Fractint (legacy code would remain in C).
What has occurred to me, which may be incorrect, is that to go to WxWindows will require a complete rewrite of the WinFract Windows code. This may not be a bad thing, but it does beg the question of whether or not we should start a WxWindows port from Rich's source (which is only slightly out of date). Something I would like to do, now that I've looked at the Windows source, is to rewrite the main loop in Xfractint in a similar fashion. Jonathan