Re: [Fractdev] Allegro port
Hi Tim, We are getting close.
One trick is to do what both Winfract and Xfractint did, and write windows versions of the screen writing and reading routines.
These routines already exist in MANPWin and just need a cleanup. I think that using the #ifdef WIN32 we can fix most problems in the header files. I have again attached the latest build report from MSVC++v4 after defining XFRACT and modifyng 2 header files (also in attached zip file).
My original idea was to create a fRAc chunk that had subchunks for each data item. The iteration count could be in it's own chunk, or we could add some other similar items. In order to work on this we need to get PNG working in all the versions. This means getting out from under the DOS version which can never have PNG, as near as I can tell, due to memory limitations. I'll start looking into this.
I don't like the additional chunk as the PNG files size will be huge, even if compressed. Another view is to use my algorithm for generating true colour palettes and to surch for and remove duplicates and only save the lookup table. We need only thensave a WORD or DWORD per max iteration. This can be a processing overload for smaller machines. Comments? Regards, Paul de. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ----------------------------------------------------------
I don't like the additional chunk as the PNG files size will be huge, even if compressed.
Of course size is a consideration. But there is very little overhead to a chunk. And LIBPNG contains everything needed to define and implement compressed chunks, as you know. That might help a lot.
Another view is to use my algorithm for generating true colour palettes and to such for and remove duplicates and only save the lookup table.
We can certainly define a palette compression scheme similar to the one Fractint uses now for PAR files. We can also leave holes in the palette and have fractint interpolate through the holes, but that would require saving an index as well. Finally, palettes could be specified algorithmically via something like the formula parser. I don't think these issues are a hold-up, though you might disagree. We could define some simple temporary thing that is not optimized for space, and refine it later. The biggest obstacle from Jonathan and my points of view has been an adequate port to a flat memory model with reasonable performance and with preservation of the current feature set, which if overcome would let us retire the medium model version. If we fix those things and the license, we can probably attract new developers. And of course an even bigger obstacle is that I haven't helped Jonathan for about five years :-) Tim
Confused, I wrote:
We can certainly define a palette compression scheme ...
Of course, PHD was talking about saving the iteration count, not a palette. But of course you have to also save (by some means) the algorithm used to translate iterations (or maybe the last complex orbit point) to colors if you want to be able to reproduce the image from the PNG file. Tim
In article <3CB21E28.7578.975A0@localhost>, Tim Wegner <twegner@swbell.net> writes:
[...] But of course you have to also save (by some means) the algorithm used to translate iterations (or maybe the last complex orbit point) to colors if you want to be able to reproduce the image from the PNG file.
Isn't that captured in the parameters? -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>
participants (3)
-
pdeleeuw -
Rich -
Tim Wegner