On Wed, 6 Nov 2002, Jonathan Osuch wrote:
Cute Skunk wrote:
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.
I'm considering going through and labeling all of the random constants in the code like this: #define VID_DISK 11 #define VID_CUSTOM 19 #define VID_VESA 27 #define VID_CGA 13 ... #define CALC_NONE -1 #define CALC_CHANGE 0 #define CALC_ACTIVE 1 #define CALC_RESUME 2 #define CALC_NORESUME 3 #define CALC_COMPLETE 4 ... And so on, and so on.. I'm also thinking of taking all of the global variables that are all over the place and sticking them into neat little structs, and probabily making them not even be global anymore. At the very least I want to put all of the math stuff all by itself so that a new UI core could be dropped onto it easilly without having to touch anything inside the fractal code. And people could write new fractal stuff without having to worry about what's happening to their globals elsewhere in the program.
I have most of the work done porting the formula paser to nasm. I prefer nasm because of its availability on various platforms.
Coolness.
- 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.
I'm not /that/ familiar with the medium memory model. Is it that there isn't enough room for the PNG code itself, or enough memory for the encoder/decoder to work in? As I understand PNG it's basically just a zlib stream decoder with some chunks for palette and image resolutions. So should have low overhead. (tangent: The fractint stuff put into GIF comments now could be placed directly into a fINT (or apropreatly named) chunk)