Rich wrote:
The more I think about where I want to take FractInt, the more convinced I've become that its future is more OpenGL than SetPixel/GetPixel style graphics.
There is no question that the post processing 3D function in fractint should be replaced with something better. I wrote that code and I am proud of it, but since it was written from first principles and has limited capabilities, I have no problem replacing it. However, I have some questions. The fundamental function of fractint is to produce 2D pixel arrays. Besides the afor-mentioned 3D function that is really a post process (e.g. it acts on regular 2D images) there are a few other "3D" functions such as the julibrot (greyscale distance rendering) and red/blue 3D orbits. But with these possibleexceptions, fundamentally fractint writes to a pixel buffer, and needs access to already-written pixels to do things like solid guessing and boundary tracing. If you think just of 2D fractals, what is the fastest/most effective way of writing and reading pixels? Can opengl write and display 2D fractals efficiently? How does it compare to other pixel rendering methods in terms of speed? The other concern is just getting the literal port done, working, and debugged, and releasing someone that would compete in the fractint fanatics hearts and minds with the DOS version. But if opengl has effective pixel reading and writing, moving to it could be sooner rather than later. But I would still suggest post-poning the rewrite of 3D for a second stage after the literal port. A final thought is I am not sure the 3D post processing function even deserves to be in the program, but 3D fractals that are directly generated by orbits, only in 3-space like julibrots and 3D orbit fractals really do belong. The reason is that other specialized programs (e.g. POVRay) do the post processing much better than fractint. Tim