In article <23576011.1184357720510.JavaMail.root@web01sl>, Paul <pdeleeuw@bigpond.com> writes:
The first step would be to completely separate the fractal code from the screen rendering code so that the developer can choose what method of rendering is done.
This is already done with the driver that I introduced. However, you'll find that although this does impose a layer of abstraction, that lots of the code is tightly coupled to the idea of "a pixel is an index into a color lookup table".
My difficulty with fractint code has been the interdependence of fractal code and screen code.
Its getting better, but there is still some coupling.
I am also concerned with converting fractint to something that needs hardware that is only 5 years old.
We're back to "evolve or die" on this one. If people want to use old hardware, there is nothing stopping them from using an old version of FractInt! We're looking forward now, not backward. This obsession with supporting ancient hardware is holding back FractInt from evolving into better code that takes advantage of current hardware. Frankly, supporting old hardware is nowhere on my agenda. Use the DOS FractInt if you have old hardware. It still works and will continue to work on that old hardware. I want to turn the equation around. I don't want us to say "we need to keep the code looking backwards because users have old hardware"; I want users to say "I will buy new hardware because of the cool things FractInt is doing". Consider 5 year old NVidia cards. That would be cards introduced before July of 2002: GeForce 4 MX 460, 440, 420 and earlier generations: <http://en.wikipedia.org/wiki/Comparison_of_NVIDIA_Graphics_Processing_Units> These cards are available on ebay for $10 or less! This is hardly an expense that's crushing anyone's wallet. Of course you will need a machine with an AGP slot, preferably 4x or 8x. But guess what! Because that system configuration is also 5 years old, I can find systems for $200 or less on ebay as well! So we're talking about $200 to have a 5 year old machine. Hell, if you ask around I bet you can find someone who will *give* you a 5 year old machine with an AGP slot. These cards have screaming texture capabilities, alpha blending, stencil buffer support, large memories for textures and 3D models and so-on. They only have shader model 1.x support, but that still gives you lots of interesting things you could do with fractals. Treating these cards as "get pixel, set pixel" type cards is like buying a high end Cadillac just to store your golf clubs in the trunk. What a waste! FractInt should have the ability to leverage your graphics card to the MAXIMUM IT CAN ACHIEVE, degrading gracefully on weaker cards within reason. A 5-year card window is more than most game studios would tolerate and since the DOS version of FractInt supports these older configurations just fine, I see absolutely no reason why the modernization effort of the current code base must be held back because some people want to use old hardware.
If we can generate fractal libraries that can be linked into any platform, th at would be the first task.
Separating rendering from presentation is a good idea, but the existing code was never created with this separation in mind and its a rough refactoring. The main reason that people want to separate rendering from presentation is to put a more modern UI onto FractInt. I have a feeling that most of this desire will disappear once FractInt is moved to wxWidgets and an updated UI (i.e. real dialogs and not emulated CGA screens). The only other reason I can think of for separating the rendering from presentation is to create networked rendering where no presentation is needed. This is a worthwhile goal, but one that is much farther away on the roadmap. To me the roadmap looks like this: - Refactor polling input to event-driven input - Remove 0-63 color channel limitation - Create CGA screen control for wxWidgets - Refactor to wxWidgets application (X11 and Mac "port" comes for free here) - Refactor rendering to OpenGL - Refactor UI to wxWidgets native dialogs/controls - Enhancements (coloring formulas, RGBA support, PNG support, etc.) Its roughly in order of how I'll work, although PNG support might come earlier than this indicates. There's also some stuff I've probably not put on that list that should be there. -- "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/>