In article <MDBBJLBFBICIIEIHFBMECEHFCOAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
I have always used the concept of enhancing code by adding incrementally to a working base.
That's what I'm trying to do; its just that you have to re-implement a collection of "base" routines on which everything else builds. For instance, at the moment I'm not talking about turning the 'x' parameters screen into a genuine Win32 dialog. I just implement the underlying functionality of an 80x25 "text mode" window. The routines in the implementation of the 'x' screen call other routines that switch from graphics to text and put text strings on the screen at a certain location. So the 'x' screen code just gets a function renaming change which doesn't introduce any bugs in the 'x' screen. Once you get the underlying functions working, then the 'x' screen works again.
Also, regression tests become applicable [...]
That would be a first for fractint! :-). I'm not aware of any test suite. Basically you render an image and look at it to see if it looks 'right'. I think the most pounding it gets is when a version is released into the while and people start playing with it and give feedback on crashes or incorrect renderings/behavior.
Fractint's built-in demo capability might be able to be used to do the regression testing -- perhaps with saved images automatically compared to reference images using a script.
That's a good idea! We could at least use that to generate a suite of baseline images from the existing code and then generate the same set from the driver code base and do a quick image compare.
With enough resources [changing all the code at once] can work. But, the locality of problems in the code in the new environment is not well characterized and this is what presents the greatest challenge. When working on a problem you have to keep dealing with 'everything' 'all the time' and this has not proven tractable to others in the past.
In this case, the bugs are all located in the driver implementation. We're not changing anything in the main code about how it does its work.
I don't have any understanding of how a MS GUI and event-driven Fractint would be compatible with any future UNIX GUI and event-driven versions. In other words, how close do MS windowing and event-driven paradigms map to X-Windows or other UNIX windowing systems? <---<<
They're all pretty much the same with minor differences. Ultimately it would be nice to see FractInt evolve into three distinct modules: a front end UI, a calculation engine, and a back-end exporter of images and/or 3D data. In a certain sense, the code is already like this in that the engine is relatively isolated from the UI code. The back end just saves GIF/PNG when you ask for an image to be saved, but ultimately it would be nice to save Lorenz plots as 3D models, etc. The front end could then be written in whatever way was 'native' to the platform. On X11 it would probably use Motif. On Win32 it would have real dialogs for parameter screens. On the Mac it would use the native toolbox. On the Amiga it would use Intuition. However, this is a long way from where we are right now, even if my driver abstraction was fully debugged. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>