Cute Skunk wrote:
If DOS Fractint was moved to a linear memory model, then you could have the exact same source for every platform including DOS.
I'm not actually worried about supporting DOS. For nearly everyone here, the only interest in DOS is to run Fractint. Most folks here who are interested in DOS would be satisfied by a Windows version, or a Linux version.
Portability and DOS (med mem) seem to be mutually exclusive at this point. Which one is more important?
Clearly medium memory is no priority at all. The only reason to maintain it a bit longer is that the DOS version represents the full feature set, so any global changes that can also be done in the DOS version can be most easily be tested. Moving to a flat memory model is the most immediate single priority. As you pointed out, portability follows.
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..)
I don't quite see the point of switching between text and graphics, since the two-window Xfractint version avoids the problem altogether. Have you seen Winfract work? It works like Xfractint, with separate text and graphics screens, but it also has a GUI interface. If you really want a console version that cannot have two windows, why not do the simple, brute force thing and save the entire graphics image to large array in memory? This can be coded in a few min utes. Fractint's original tricks with video memory were due to severe memory constraints. Even fairly old machines no longer have limitations of memory that prevent saving the graphics screen.
I'm not sure how much faster hand optimizing the floating point code right now would be, compared to the cc output.
I am sure you are aware (don't mean to preach) that the rule about optimizing is only optimize if there is a demonstrable bottleneck.
From experience, I'd say we almost always saw significant benefit from carefully coding the inner fractal loop. The formula parser (a central feature of Fractint that must be preserved, and probably expanded) also benefited a lot from the assembler rewrite.
In any case, we can optimize later. The second rule of optimizing is get the algorithm right, then optimize. The third rule is all rules have exceptions (except this one). :-)
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?)
I'll work on this. We have one CVS repository now on one of Robin's machines but we aren't using it. I am just starting to get familiar with CVS and am sold on the advantages. We Stone Soupers are experts at using diff and patch, but CVS handles merging automagically. I want to look into using subversion instead of CVS. CVS does not have the notion of a multi-file patch (same reason Linux doesn't use CVS).
And also I've been wondering.. if Fractint no longer has any interger math in it... then is it really still fractINT?
My initial response is that we want to keep the names Fractint and Xfractint for historical reasons, even when the integer math is gone. The only reason not to call the new program fractint is if the integer version has continued life. But the reason I am so adamant that integer math be dropped is that: 1. There is no longer a performance advantage and 2. Artifacts due to integer math are just not reproducible on new platforms- integer math is necessarily not portable, unless one goes to GREAT lengths to analyze and emulate fractint's integer code (not a good idea IMHO). Tim