In article <MDBBJLBFBICIIEIHFBMEMECLDBAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
Richard, How would the rotation and shear of the zoom box be higher quality using texture mapping support in the graphics card than the way Fractint does this now?
Higher quality in the sense that supersampling and antialiasing techniques can be brought to bear on fractals. Higher speed in the sense that the texel data doesn't need to be recomputed because you sheared the image or rotated the image.
With Fractint's current rotation and shear algorithms, don't the locations of the points in the complex plane that get calculated correspond one-to-one with each pixel on the display?
Yes, which is why its so slow to create a rotation animation in fractint today.
With texture mapping support in the graphics card a number of texels (texture pixels) contribute to a final rendered rotated/sheared pixel.
Yes.
It seems to me that having to calculate these additional texels for the texture map -- to insure adequate coverage of the rotated/sheared output pixels it maps to -- could be very burdensome for slow-calculating fractals and/or older computers.
It needn't be any more burdensome than at present because for a shear you can always compute the portion of the texture that needs to be computed, since a shear is an invertible transformation and you're not showing portions of the texture outside the parallelogram. As for old computers, if you want to use old computers with fractint, then use an old release. The current code doesn't take advantage of current computers, never mind the computers that are coming out in the next few years. Use old code for old computers, not new code.
Also, if the person computing the fractal does not have texture mapping hardware in their graphics card the implementation in software could be prohibitively slow on top of the fractal and texture application calculations.
Again, use an old version of fractint for old computers. Texture mapping is standard on all computers for the past 5 years at least, including even cards that are builtin to motherboards. Remember that fractint hasn't had a major release since 1999 when 20.0 came out. That's like 12-16 generations of graphics cards behind the current era; graphics cards have been doubling performance faster than Moore's law of a doubling every 18 months.
I have an idea for a sampling algorithm that maximizes the amount of reuse for each redraw...
You may be making some assumptions about how people use Fractint that need to be carefully validated. While some people may in fact use Fractint in a way that your algorithm would help the efficiency of their use of Fractint, others might serially calculate different fractals -- say, from different formulas or using the same formula with different parameters -- or calculate zooms into a fractal at very different locations for each zoom.
I realize that I haven't gone into the details of the algorithm here, but it would be something that you "opt into", not something that's forced upon you. At any rate, you're correct that attempts at reusing what was computed for one fractal type don't lend any speedups when you always change fractal types for every image. Its an algorithm that speeds up panning and zooming and would be something you could turn off if you weren't interested in panning and zooming.
While your disk storage method may be of benefit to a subset of Fractint user's it probably would not be useful to those with older machines with smaller hard drives -- unless your disk algorithm could be turned off and/or have its cache flushed.
Again, please remember what I'm doing -- bringing fractint into the modern world of current machines. Old versions of fractint will still be around for older machines with limited disk storage or memory. But in going forward, these are not the target audience. That may mean that some people will grumble that the newest features are not available on their older machines, and they will be right. But fractint has languished enough in the 16-bit DOS world and you haven't gotten any significant new features since 1999 anyway. The DOS code is dead. It won't be resurrected. Older machines will not be catered to by new code. If you want to use old machines, use old releases of fractint. They work just fine.
Another item adding to the age-old problem of insufficient computational power may be that today's processors might be faster, but it appears to me that people's desire to fill higher resolution screens with ever more detailed fractals has seriously taken the edge off these CPU speed gains. (My claim here needs to be validated by Fractint users.)
But the existing code is optimized for a machine that doesn't exist anymore unless you dig one out of your corporate IT boneyard. There are many avenues of optimization that are open to us now that we are unshackled from the memory constraints of DOS and catering to 8088/8087, 80286/80287, 80386/80387 CPU/FPU combinations. The current code doesn't even attempt to maximize the use of your cache or attempt to employ MMX/SSE/SSE2 instructions where it might help. The current code hasn't even been *profiled* on a modern operating environment, never mind tuned for it. Someone reported to me -- it might even have been you -- that the current C implementation actually benchmarked faster than the old DOS assembly implementation. That doesn't surprise me since the 16-bit instruction path used by DOS fractint is the *slow* path on modern CPUs. The code emitted by optimizing C compilers has gotten much better and is 32-bit and is the fast path on modern CPUs. So arguments about what is faster or slower have to be based on measurements and not on feelings about the old DOS code.
But people regularly use 200 MHz CPUs to run Fractint on.
Those people should probably stick to old versions of fractint, then. We're moving forward, not back.
Your proposed methods appear to be of potential value to those with current hardware, but do we want to leave the that portion of the Fractint user base behind that has not or cannot update their computers to include texture mapping hardware and large hard drives?
They're not left behind; they can use old versions of fractint.
Or would two versions of Fractint be needed -- one for computers with modern hardware features and another one for older computers?
Ain't gonna happen. Simply being, there isn't anyone to do the work. Not much has really happened at all since version 20.0 and that was in 1999. Where are you going to find people to do the work to cater to those old machines? I'm afraid if you want to cling to your old machine, you'll have to cling to an old version of fractint.
One of the premises of Fractint is that of getting the most function out of limited capacity hardware.
Only out of necessity. To my mind, the premise of fractint is being able to compute as many fractal types as possible with efficiency.
Do we want to abandon this philosophy?
DOS is dead. I'm moving the code forward, not back. Old releases of fractint will still work. If you want to keep an old machine computing fractals, then use an old version of fractint. Making the code base cater to old machines is the very thing that has held back fractint developing for the past 8 years. I'm not going back to that. I repeat what I said before: its time to evolve or die. -- "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/>