In article <MDBBJLBFBICIIEIHFBMEGEMFCNAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
Thank you all for your comments about Fractint and Windows and your efforts on Fractint's behalf. [...]
I think all of us share your thoughts re: Fractint. What I did was work from an XFractint code base. First, I printed out the *entire* source code to fractint and studied it. The printout is about 4 inches thick when printed double-sided! Maybe I'm "oldschool" by working from a printout but for me it has always been the best way to understand a very large body of code because you can spread everything out on the table, couch, chairs, etc. to get it all within your visual field of view. After studying everything, I identified the points where the calculating code called back to the user-interface code. Since the code originates before "event style" programming, it tends to be things like "check if a key was pressed" and so-on. What XFractint did was hook in the event processing in these functions. So when you checked if a key was pressed, the XEvent queue would be processed. It ends up that the polling style I/O code of the DOS world ends up being called often enough that your events are processed in a timely fashion. After identifying all these sorts of UI callbacks and various system type functions having to do with timers and things like that, I refactored them all into a structure of function pointers. The current "device" was a global variable pointing to one of these filled out structures. When you called the global function that said "check for a key pressed", it just called through the global structure pointer into the member function. Kind of like a poor-man's object method call. The member function then had access to its internal device data that it needed for that device. I had everything refactored and compiling, but I got pulled in other directions before I had a chance to get everything debugged. I still believe that this is the right way to go in that it maximally preserves the existing code base, but still moves us in the right direction. I keep hoping that someone will drive this effort towards completion, but if noone else does, then I will come back to it when my book is finished, which is looking sooner rather than later at this point, although I've been working on it for about 6 years now :-). I still have a soft spot in my heart for fractint and if noone else does it, then I will eventually move it to a modern UI platform! I still think it could be preserved to work under dos DPMI style environment as well. I would ultimately like to refactor the whole polling UI business out of the code and move it to a real event processing architecture, but for the moment, I think its more expedient to hack in the event processing into the polling code the way XFractint does it. If you want to see my effort at refactoring the UI code, I still have it around somewhere. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html>