In article <48E5E022.8000709@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Actually, I think it is. Unlock dear old DOS Fractint, it happily renders in a graphical window on my Linux desktop - [...]
Umm... if you're running DOS fractint in a window on your desktop, that has nothing to do with how fractint is treating your system, it has to do with how you're emulating DOS in a window on linux. Inside the DOS code it doesn't do anything fancier than treat the graphics card as a dumb frame buffer with support for colormaps and color cycling (which is just manipulating the CLUT). It isn't using any part of the graphics pipeline available in modern cards other than the frame buffer. The vast majority of the circuitry on your graphics card is idle when driven by fractint.
using the card as a "dumb frame buffer". It's rendering graphics to an image window managed by the X video system, which is just another chunk of system memory.
...which is still just a dumb frame buffer approach. Even xfractint doesn't use windowing in any way other than a dumb frame buffer. If you look at the code you'll find that all the access is dumb frame buffer style and the code goes through contortions to get that to work with the X window system in a window.
True, but DOS fractint is *also* using the slow compatability path on the CPU.
True. It still calculates far more numbers than it makes video accesses.
DOS fractint is using the 16-bit instructions. It is not using 32-bit math instructions, nor is it using SSE, SSE2, or even MMX/MMX2 instructions to accelerate things. I think somewhere there is a chunk of Pentium assembly code for the inner loop of the M-set, but that's probably about it. In xfractint, its compiled on gcc so you'd be getting 32-bit integer math instructions, although lots of the code assumes "int" is 16-bits and "long" is 32-bits, so the algorithms don't necessarily take advantage of the 32-bitness of gcc.
Very true! Someone just needs to factor Fractint into two parts - a back-end processing engine (platform independent, compile and run on any hardware including a GPU, the supercomputer down the street or a render farm of commodity PC hardware) and a standard, documented API for accessing the processing engine.
Its more complicated than that; the code is a mess. -- "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/>