Cute Skunk wrote:
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.
Take a look at the Allegro port in the experimental code section of the developer's web site. It is at patch 3, although I seem to have put patch 4 into my source. Just haven't uploaded it. This code is what Rich is talking about.
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)
That's a good idea. We are running into just that problem with patch 5. We had to put in a bunch of instances of "if (dotmode==28)". Easier said than done, of course.
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)
I have most of the work done porting the formula paser to nasm. I prefer nasm because of its availability on various platforms.
- 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.
This can't be done with the medium memory model based C code used for the DOS Fractint.
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?
No, the Xfractint code uses memory.c, also. Jonathan