On Thu, 7 Nov 2002, Tim Wegner wrote: [...]
Fractint copes with this truly horrible limitation by the following means. [...] All this has been accomplished artfully and debugged thoroughly, and is very robust, but you have to be careful or the DOS version will break if you add anything major. But when we bust out of this prison, [...] Adding PNG support to Xfractint is very easy. I did it once in an afternoon. But adding PNG support to Fractint is utterly impossible, at least inside a monolithic program. Once I got as far as getting a Fractint executable to compile with PNG support, but it failed at runtime. The memory demands are far too great, much more than GIF. If you look at the GIF decoder and encoder, they just re-use a couple of the afore-mentioned arrays.
I'm starting to look through the GIF code right now. I'll write a inflate/deflate routine that uses memory in the same way as the LZW stuff does now. (dstack and stuff or decoderline1? (I'll figure it out))
I am deeply committed to adding PNG support, but we can't do it until we are ready to leave DOS (or more accurately, the medium memory model) behind. (If we converted the DOS version over to djgpp and ran it in a console, we could add PNG easily.)
That would require the user to have at least a 386 I think.
I suggest we divide your various projects up and implement them in phases, doing the ones that can be backported to DOS first. I know you are enthgusiastic about PNG, but I believe things will work out better if it is added after we are free of the medium model.
(comments below)
Consolidating the various global variables into some carefully designed structures is a good place to start. This should be possible to backport into the DOS version.
For performance reasons I'd leave some variables global to reduce calling overhead, but alot of them arn't critical like that. I mostly go tinto this code clean-up mindset when I was tring to change the keyboard input handling a bit and wasn't sure if I should modify getakey(), xgetkey(1), getkey(), getkeyint(1), getkeyint(block), keypressed(), etc. etc. (xgetkey is the answer mostly) And just dropping the framebuffer code into where the Xlib stuff is now in xfractint gives you a fractint that goes into graphics mode once the first time, and then never goes back into text mode again until you exit. I had to write a kludgy redraw screen thing to switch back and forth. I'm not sure if there is a proper function that is being used for this already in the DOS version (because I know it does it there, but the setvideotext(), setforgraphics(), setfortext(), savecurses(), stackscreen(), etc. etc. don't seem to do what I think they do)
BTW, there is a free Watcom compiler that still supports the medium memory model. Jonathan and I use the last DOS Microsoft compiler. It is probably possible to port Fractint to Watcom with little trouble, and then if you (and others) have a Windows or a DOS environment you could compiler Fractint yourself and test your changes.
I think I'm going to have to setup a DOS development enviroment for the near future.
Of course it is also possible to fork the project and leave DOS behind immediately. Paul de Leeuw has done this with Manpwin. His [...] My bias (and I think Jonathan's also) is to be protective of the Fractint feature set, and not embark on a course which abandons a lot of functionality. What is so remarkable about Xfractint is that it shares sources with Fractint, and we could maintain it long after the original author left, and it preserves nearly the whole feature set.
Ironically, one hope for not abandoning our DOS/Windows user base might be to backport Xfractint to djgpp! I know Jonathan has worked on this with some success.
(see below)
An alternative approach (which I suggest with some trepidation) would be this. Folks don't scream, last time I made a suggestion like this there was an alarmist reaction on the fractint list :-) This is a brainstorm idea not a decision!!
1. Consolidate the current version and make a LAST DOS fractint version. Which, of course, doesn't rule out continued maintinence at the glacial pace we have been maintaining it recently :-)
Or perhaps, a last real-mode DOS version.
2. Starting with the Xfractint Float only version, begin a radical transformation that would be evolutionary in that at each step it would preserve the feature set.
Do stuff like:
a. relicense the code - which means re-write all the parts by people we can't contact. If there are no other proposals I suggest GPL. I think this is closer to the original fractint license than BSD - we wouldn't want people to take our code and make a closed-source program. The current license forbids using the code for a commercial fractal program. But I wouldn't care if someone made an open source commercial program out of Fractint.
Politics.. fun fun. GPL sounds good, but figuring out who has to ok what code to relicense will probabily be more work than reimplmenting stuff from scratch. I'm not that sure really what else would need to be done to relicense the code if we couldn't get OKs from everyone ever involved with it. The best time to do this would probabily be at the next radical change for fractint. (which is what you said so I don't know why I repeat it here) Also this brings to mind making a fractal library out of the math core of fractint, so that you can use it from GIMP or something. (Or easilly write a new UI for fractint)
b. Undo all the array re-use and make the memory management something reasonable (I would favor writing our own malloc and free that would do bookkeepping to avoid memory leaks. This is fairly easy.)
*nodnod*
c. Separate the GUI from the underlying engine as Rich suggested a long time ago. But beware, some features, such as orbits and inverse julia windows, assume a frame buffer and will take some creative disentangling.
Indeed. I'm still becoming familiar with the code currently.
d. Separate GUI projects could be done on different platforms. Maybe this could be merged in with manpwin on Windows. Or ...
d'. Make a portable GUI using WxWindows. Then we could target many platforms with ONE source base. I am not opposed to option d., but I personally prefer d'. I am personally willing (even enthusiastic) about learning ONE GUI development environment, so without knowing anything about it, I prefer WxWindows. :-)
Lately I've been thinking that what may be easiest for everyone involved might be to make a GPL fork from the current Fractint, port it to Windows/ *nix/MacOs, and then port it back to real-mode DOS. Or, try to keep as much code as possible the same between the two versions, so that core features could be easilly put into both at once. This second option may be more work (tring to keep the same code base).
e. Add the much delayed missing features. These are: True color support, PNG support, and a carefully designed fRAc chunk for storing fractal data.
I think these should be done before a complete fork, otherwise I fear that they won't make it back into a DOS version. Makeing parts of the current version into more of a self-contained black-box will also help greatly when the time comes to branch the code. (Unless we do a complete rewrite/translation) Ok so to summerize, furutre directions: (Ordered by priority) 1. Retain /all/ current features 2. Be GPL 3. Be multi-platform 4. real-mode DOS compatable (or should this be above 3.) 4. Then new features(?)