PHD wrote:

I have been dogged by asm code myself and has slowed down my progress for a 32 bit WINFRACT.

If you are referring to the old Winfract, I understand. That used the medium model and called virtually all the same assembler as the DOS verson. If you are referring to my comments about Xfr4act, all the assembler was transwlated to C, but Jonathan redid a small bit of assembler using NASM. This should cause little problem, just a few unresolved references that can be cleared up by grabbing whatever C module has the same variables and functions. I'll look into making a way to chose between the assembler or C versions as Jonathan ports more of the assembler.

Once we get the #defines and the header files working, a couple of months and we will have 32 bit windows true colour FRACTINT.

It is very important to try to keep source compatability with the other versions. Otherwise you can't take advantage of work on the older versions. One trick is to do what both Winfract and Xfractint did, and write windows versions of the screen writing and reading routines. This immediately gives the whole DOS interface in the Windows version. Then you can add a Windows GUI interface at your leisure, and we can migrate toward the holy grail that Rich mentioned of a platform independent core with platform specific interfaces wrapped around.

The only other issue is the iteration -> RGB and back translation for storing pixel data and iteration count in the PNG files.

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. Tim