WINFRACT 32bit/true colour progress
Hi Team, Just a progress report on the weekend WINFRACT 32bit/true colour activities. All .c files including the 24 bit and WINFRACT files can now be compiled with no errors or serious warnings. I only have 512 undefined modules / variables at link time. Hopefully I can fix most of these in a week or so. Then comes the hard part, checking all the functionality. Especially the difference between the WINFRACT GUI from 18.21 and that of 2FRACTINT v20.2.4. Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- ----- Original Message -----
From pdeleeuw <pdeleeuw@bigpond.com> Date Tue, 09 Apr 2002 08:50:51 +1000 To fractdev@mailman.xmission.com Subject 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 ----------------------------------------------------------
participants (1)
-
pdeleeuw