Skunky wrote:
These files are slightly different.. but they differ in the same sort of ways as DOS 20.0 differs from DOS 20.2..
3d.c cmdfiles.c encoder.c fractint.c fractsrc.doc loadfdos.c printer.c read.me zoom.c biginit.c cmplx.h evolve.c fractint.h helpdefs.h miscovl.c prompts2.c realdos.c
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.
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. 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.
By the way, is there anyone 'officially' in charge of the 'official' version of fractint, like how Linus or Alan are in charge of the Linux kernel.
Jonathan Osuch and myself.
I don't know if I would need to OK big changes in the structure of fractint's source code with anyone.
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. We do welcome you. Let's hear more about what you want to do. 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.) 2. The medium memory programming model. Once we get off this we can drastically revise (and simplify) memory allocation. The assembler is no longer much of an entanglement since Xfractint solved that long ago, and recently Jonathan has ported some assembler to linux. For me preserving the feature set and targetting multiple platforms (primarily Windows, Linux/BSD and the Mac) are a high value to hold. 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. Tim