On Fri, 8 Nov 2002, Tim Wegner wrote:
Ok so to summerize, furutre directions:
(Ordered by priority)
Did you mean priority in imporatnace or in time?
By importance.
2. Be GPL
This can be done as we go. I can identify all the files that are already OK and those that need to be rewritten or the authors contacted. Maybe we need to make the files LGPL so the licenses can be mixed, then change to GPL when done.
I can see using the LGPL (lesser GPL) so that the GPL'ed code can be mixed with the non-GPL'ed code left over. But at the same time it could also allow a closed source commercial program to use Fractint, which is about the only explicit condition in Fractint's license now. ... or maybe not
3. Be multi-platform
Yes, but we can work on one platform first. There is, however, one huge advantage to multiplatform. More people can help. For example, Rich and Paul are interested in Windows. Jonathan and I can support either the DOS or X version.
If DOS Fractint was moved to a linear memory model, then you could have the exact same source for every platform including DOS. Portability and DOS (med mem) seem to be mutually exculusive at this point. Which one is more important?
4. real-mode DOS compatable (or should this be above 3.)
I think we start out making changes to Xfractint and Fractint in parallel. When we reach a dead end, we work in 32 bit version. However once there is a console version under Linux, how hard would it be to port that to a Windows console version?
Not very hard.. speaking of which.. I've rewritten the framebuffer code four times now and I still can't get it to switch back and forth between text and graphics mode in any predictable manner. Otherwise it works (well, Plasma broke again, which was weird because it used to work..) The way that the Xfractint version (that I'm building on) seems to work is that... it doesn't switch back and forth between text and graphics mode. I'm thinking I might have to resort to changing around some of the logic flow going through the menus for the console version. So far, I've only written stuff into unixscr.c, and at best I can get it to redraw when it should about 1/2 of the time. The three states currently are (text mode) "Press operation key, or blah...", (text mode) <blankness> and (graphics mode) <fractal> I can do some convoluted things to get this part to work, but then I can't switch back out of graphics mode, or something else unexpected happens. There's like several different paths through the code calling several different functions for whatever the current state should be, but they're all interdependant on each other. And I'm still not sure what I should call when switching VTs, because I really need something to redraw the screen baised on whether it was in text or graphics mode previously, but there isn't an easy way to tell. (The Xfract version doesn't do anything like this, and seems to have turned this sort of stuff off from the DOS version. I'm a little leary to start poking around all over the place turning DOS stuff back on because it might break the X version.) (but anyway..) A windows console version that looks and feels just like the X version would be easy to do, just drop the appropriate windows graphics calls into unixscr.c wherever something X related is, and it should work. (That's pretty much what the linux console version I wrote does.) You'd probably need ncurses, or equivalant, in your windows environment too. (Oh and there's the matter of path name seperators and such, but for Windows they're the same as for DOS)
One item not on your list would be to back port assembler into the 32 bit versions where a bottleneck can be identified. Thjis would be a lower priority.
I'm not sure how much faster hand optimizing the floating point code right now would be, compaired to the cc output. But, for things like using the MMX instructions to do 8 integer operations per clock cycle, that could be useful. I can see the KNI (or Streaming SIMD or whatever Intel calles it now) stuff being very useful too, although I don't have the hardware to work on it currently. Oh, and another thing... If this project is going to get big, do you think there should be a CVS server up somewhere. (Maybe a project on sourceforge.net?) And also I've been wondering.. if Fractint no longer has any interger math in it... then is it really still fractINT?