On Tue, 5 Nov 2002, Tim Wegner wrote:
Files with the same name are identical in the same version of fractint and xfractint. What may be confusing is that we have both a traditional and a float only version (the latter with the integer math removed). While we haven't quite decided to stop maintaining the traditional version, the integer math clearly has no future.
Yes, that is it exactly. (And I was wondering that about the float-only version) The interger only code might still be useful for legacy systems (The DOS port and *nix on a 386 or 486SX and any other old platform that someone wants to port to) But it would be easiest for the core to be float-only, and then let indivuduals porting to legacy platforms put the integer code back in.
Anyway, I was going to merge these two branches back together if no one minds. (There will be one code base and you just specify something at compile time to get one version or the other out)
I'm not sure what you mean needs to be merged. There is no point in having an Xfractint version of the traditional code, since the integer mode doesn't work in Xfractint anyway, although we still have such a version.
Ok I wasn't aware of the foating point change (why the integer stuff was going away) when I wrote that last message; Or aware of all the changes between the two code branches, I diff'ed them to try to get an idea.
All future work should be based on the float-only version. If you look at www.fractint.org, you will find two versions of fractint and two versions of Xfractint at revision 20.2 patch 4. The corresponding versions (traditional or float only) share identical files. It would be possible to have the files for both fractint and xfractint in a single directory with different make files.
I only found frasrcfo20.2.04.zip and xfract20.2.04.zip, hence the confusion. I'll work off the floating point version from now on. Placeing the regular fractint and xfractint together and using different make files was what I was thinking of. In the future the windows/mac/beos/palm/whatever port would be handled in the same way.
There are a lot of issues you would need to understand in order to enable changes to backport to the current DOS version. At a certain point (the sooner the better) we want to cut free of the DOS limitations, but attempts to do so inevitably reduce the feature set.
This was my big worry, and why I didn't want to just start changing stuff. I want to try to maintain DOS compatability as it is now. But the easiest way I think to do this is a rewrite of the main loop that behaves from the user's point of view just like it does now, but internally it may be radically different. (This is mostly for developers' benifit) I think what I would do is have something like the startvideomode(), writevideo(), readvideopalette(), type of stuff that is there now, but.. moreso. There's still alot of "if (dotmode==11)" stuff scattered all over the place, which I want to package up into a generic video object so that the main code doesn't care what's physically going on. (This will also make it easier to write code to draw on multiple windows/screens at once or to scroll around a very large fractal) Oh I also want to seperate the sxdots,sydots from the video driver, so that you can change them independantly in the UI, but this will break DOS compatability. It will make it easier though to resize windows with no special exceptions. For the linux framebuffer version I'm pulling the video modes out of /etc/fb.modes, which can be almost anything (I have "352x240-158Hz" in mine for example), but it's always the same video driver. In the DOS version stuff is hard coded to certain specific drivers in the list, irregardless of sxdots,sydots, and colors.
We do welcome you. Let's hear more about what you want to do.
Once I have have fractint running on the Linux console (which it mostly does now except for some palette stuff and keyboard funkyness, the /cleanest/ way to fix this would probabily break DOS compatibilty which was why I was asking.) Then I'll start adding stuff, here's my TODO list: - rewriting x86 assembly from DOS version to assemble with as or nasm (Keeping the C source too of corse for non-x86 platforms) - MMX, 3DNow and SIMD assembly code (I can only use MMX and 3DNow with the proccesor I have now) - Maybe seeing if I can compile my framebuffer version for the ARM to run on my roomate's Sharp Zaurus - Browseing .zip files as directories. I've already written code to do this in Java, I just need to port it to C. (It's so cool, it's a recursive IO stream, so you can read zipfiles within zipfiles within zipfiles just like they were sitting in a normal directory) - PNG support, I might change the format for how the parameters get stored in the comments since this is a clean break from the GIF stuff. I'm not sure if anything should be done with the alpha channel yet or not. - Related to PNG... 24-bit color and reorganization of global variables.. this would bump up the version number. - PBM output for batchmode, maybe. New palette tricks (cycle R, G, B seperately), glancing at the wish list, someone mentioned the ability to produce animations natively. (Output as animated GIF or FLI?) Various other user bells and whistles. - um.. anything else I said yesterday.
The main legacy entanglements are these:
1. DOS-based video using the frame buffer, and exploiting a VGA characteristic that leaves most of video memory unchanged when changing between graphics and text modes. (Xfractint avoids this by making the graphics screen separate from the text screens.)
I've kinda been considering making the core of fractint just think that it's always using diskmode, and then having the device specific stuff just suck stuff out of diskmode memory.. but I'm worried that it'll break DOS compatability (with people who have no EMS/XMS or just 2M or RAM or somehting (like I used to)) Experimenting with something like this this morning it can be slow at times, but I think I can rewrite it to leave most of the stuff in the framebuffer memory. A side effect of doing this though is that if you do have enough memory, it would be possible to implement an undo feature by keeping around some of your old buffers. (You could just keep a table of all the old parameters too, but there's no recalc this way. (no more, arrg I just wiped out a pic that took 48 hours, etc. etc.)) There may be some kinda of effect you could do if you had more than one image to work with as well, etc. Insted of just storing the image in memory, you could actally store the iteration counts, and then have an engine which renders the picture off of that. That way you can turn log palettes on and off without needing to recalculate everything, maybe switch between real and imaginary for the outside points in realtime, etc. etc. (real and imag maybe not, but you could set some of the outside colors without needing to start over)
2. The medium memory programming model. Once we get off this we can drastically revise (and simplify) memory allocation.
I havn't looked in memory.c yet, I'm guessing that it's only /needed/ by DOS?
The assembler is no longer much of an entanglement since Xfractint solved that long ago, and recently Jonathan has ported some assembler to linux.
Yes, the Xfractint code made many things much more portable, most of the hard work for porting has already been done by the Xfractint maintainers.
For me preserving the feature set and targetting multiple platforms (primarily Windows, Linux/BSD and the Mac) are a high value to hold.
I think, Windows, *nix, and Mac maintainability/compatibility will be easier to achive between the three of them than between any one of them and DOS.
We need to begin migrating the files to another license, and there should be an understanding that all the sources and any new contributions will end up being licensed under GPL (or another open source license). We made need to make them LGPL at first until the whole program can be made GPL.
I was wondering about that too... and how the code would be migrated to a new license... Anyway, thanks for the info.