In article <000001c2e4f3$1d0fb630$017ba8c0@snoopy>, "Florian Kolbe" <flo@fkolbe.de> writes:
MAJOR TASK: would be to move the original 'fractint for DOS' code into d_fract. Anyone interested?
I'm fuzzy on d_fract.c; d_dos.c would probably be a better name for it since its a 'DOS driver', not a 'fract driver'.
The driver approach is nice - but the code still has too much control over the program flow for my taste.
Yes, the DOS code is polling-based for the I/O. All windowing systems are event driven. The way that xfractint got around this was that whenever the fractint code would poll, xfractint would poke at the message queue. Its ugly and its a hack, but it (mostly) works. I agree that its distasteful to my sensibilities, however this was "round 1 of code rehabilitation" and wasn't intended to eliminate every wart in the source base. I think its best to get the display driver stuff working again both under X11, 'disk' and under Win32 before tackling the control flow issue. Always try and keep the code working with as small a change as possible. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net>