[xy]_{min,max} sure, but [xy]_3rd?
What is the purpose of the XXX_3rd variables? They seem related to one of the corners of the complex plane where the fractal is computed, but I don't see anything that explains its relation or purpose to the min/max variables. "3rd" doesn't convey any meaning. -- "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/>
What is the purpose of the XXX_3rd variables?
Rich asked: I'll have to study the code to remember the exact definition, but it's related to the fact that the zoom box can be rotated. It's probably a coordinate of what was the upper right corner of the zoom box before it was rotated. (It is sufficient to specify three corners of the zoom box to gain full generality, which includes non- rectangular zoom boxes.) I am sure some of the fractal artists will howl at any loss of functionality, but I think rectangular zoom boxes that may be rotated are sufficiently generalized - not sure we need non-rectangular parallelograms. I am sure there are some places in the code where this is made clear. Let me add that generality of zoom boxes also complicates calculations related to automatic transitions from one kind of precision to another. Tim
In article <463BADA1.29644.CE8F26@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
I am sure some of the fractal artists will howl at any loss of functionality, but I think rectangular zoom boxes that may be rotated are sufficiently generalized - not sure we need non-rectangular parallelograms.
I've always envisioned that the samples should always be on a rectangular grid aligned with the coordinate axes of the complex plane. Any distortion or rotation should be done by a display process and not by the sampling process. However, it'll be a while before that sort of notion can be introduced intro fractint. I suspected that's what the "3rd" was for; I'll try to pin it down specifically as I continue to push global state and functions into member variables and methods on objects. -- "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/>
Tim, Richard, I advise you *not* to remove the ability to use parallelogram zoom boxes. Not only does it allow each axis to be rotated independently, but it also allows each axis to be stretched independently. There are some fractal types which desperately need these features in order to bring the details into view, and if I recall correctly, Jim Muth's explorations sometimes venture into this territory. Since this keeps the mapping transformation of pixels to complex numbers still as a linear matrix, I don't think this will simplify it all that much to remove it (you need a full linear matrix in order to accomodate rotation anyway). Move the other stuff (e.g. inversion) into a separate bit. Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/
Damien wrote:
I advise you *not* to remove the ability to use parallelogram zoom > boxes. Not only does it allow each axis to be rotated independently, but it also allows each axis to be stretched independently. There are some fractal types which desperately need these features in order to bring the details into view, and if I recall correctly, Jim Muth's explorations sometimes venture into this territory.
The convincing part of that argument is that Jim (or other fractal artists) use skewed zoom boxes. I didn't mean to be suggesting that Rich take skewing out (though I guess I should be careful expressing my opinions lest they be interpreted as policy) - just to say that *for me* I never saw the value of skewing zoom boxes. The complication is not mathematical (see my other message that should exhaust that subject) but it's more in the GUI implementation of the zoom box. But that's certainly not insuperable. My more serious suggestion at this point is let's not take out any features without a lot of discussion. My earlier less serious comment about howling fractal aratists was really saying the same thing - we shouldn't ignore howling fractal artists :-) Tim
In article <463C4D61.14443.2FE00A@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
My more serious suggestion at this point is let's not take out any features without a lot of discussion.
No worries there, I'm not trying to remove any features -- just the opposite, I'm trying to preserve as many features as possible. In fact, the way things are going, the X11 version will gain lots of features that it blew off before. -- "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/>
In article <200705050836310171.691B44CD@mandy.fractalus.com>, "Damien M. Jones" <dmj@fractalus.com> writes:
I advise you *not* to remove the ability to use parallelogram zoom boxes.
I guess what I was saying is that in my mind I'd like to move the code to separate sampling from display. By this I mean that you always sample on an axis-aligned grid, but that you then have a separate piece of code that's saying "oh, I'm viewing a parallelogram, that means that my mapping from pixels to computed samples isn't 1:1". Think of it like texture mapping. Your texture is always defined in a rectangular sample grid. Using the texture coordinates you can stretch and rotate it anyway you want. I have other reasons why I want to introduce the rectangular sample grid as the underlying sampling mechanism, but since I'm so far off from implementing that, I'm not going to talk about that right now. -- "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/>
Richard wrote:
I've always envisioned that the samples should always be on a rectangular grid aligned with the coordinate axes of the complex plane. Any distortion or rotation should be done by a display process and not by the sampling process. ... Think of it like texture mapping. Your texture is always defined in a rectangular sample grid. Using the texture coordinates you can stretch and rotate it anyway you want.
But when you change the order to sampling / rotation, you don't get the same (pixel-by-pixel) picture, do you? Think of it like of doing inversion. If you reorder actions to sampling / inversion, you get a *very* sparse image. /charlie/
In article <1910.2573-9011-346628596-1178452362@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
Richard wrote:
I've always envisioned that the samples should always be on a rectangular grid aligned with the coordinate axes of the complex plane. Any distortion or rotation should be done by a display process and not by the sampling process. ... Think of it like texture mapping. Your texture is always defined in a rectangular sample grid. Using the texture coordinates you can stretch and rotate it anyway you want.
But when you change the order to sampling / rotation, you don't get the same (pixel-by-pixel) picture, do you?
That's true, you might not get the same pixel exact picture, but that's because the parallelogram-based sampling is introducing the distortion into the sampling. Rendering fractals is essentially texture mapping, just that the texels are computed procedurally instead of done by an artist in a paint program. If you drive sampling of a source texture from the screen space coordinates of a distorted quadrilateral (i.e. a parallelogram or quadrilateral rotated with respect to the texture), then you introduce aliasing between screen space and texture space. With textures they solve this with mipmapping and bilinear filtering and using texture coordinates to drive sampling of the texture. Tilt the quadrilateral in perspective and you need homogeneous texture coordinates in order to undo the perspective distortion. Fractint currently always samples directly from screen space, probably because of its limited memory heritage. However if you sample the fractal in a non-distorted space, then you can create mipmaps and do all the same distortion eliminating tricks that texture mapping uses.
Think of it like of doing inversion. If you reorder actions to sampling / inversion, you get a *very* sparse image.
Inversion is something completely different. First, for a parallelogram or rotated zoom box, this is a linear transformation (although a parallelogram represents a shear transformation, its still representable by a matrix). An inversion is a non-linear transformation and doesn't preserve areas or angles. Still, even an inversion transformation is analytical enough that you can define the source region that corresponds to the screen space region of a pixel. You can then appropriately sample the corresponding source region (i.e. the complex plane) so that you can filter it to obtain the appropriate screen space "iteration". (It wouldn't really be a single iteration then, but an average of all the iterations in the source region that correspond to the screen pixel.) Whether or not this would be feasible or reasonable to do is an interesting question. The point is though, that just because an image is "different" from whatever fractint renders right now, doesn't mean that the new image is "wrong". Fractint does all kinds of stuff all over the place that can introduce small errors in the resulting image in deference to speed. For instance, the symmetry speedups introduce small errors when pixels don't exactly straddle the axes. I don't hear anyone complaining about that. Solid guessing also introduces errors in plenty of fractal types. Alternate algorithms generate different images of the same fractal -- the DEM algorithm was created specifically to highlight the dendritic filaments of the M-set that don't show up in typical escape time algorithms because the filaments are thinner than a pixel. Even the idea that a pixel only represents a single sample in the complex plane introduces aliasing and errors. -- "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/>
Richard, Charlie, Thanks for the instructive comments on sampling and mapping relevant to Fractint. Richard, I especially liked your observations about symmetry speedups and solid guessing, and 'different' and 'wrong' images. I know that in the past there has sometimes been a great outcry when a pixel was changed in an image due to a code change. I always followed these sometimes heated discussions since I was interested in 'correct' images. But I have come to see that many of the passionate comments were uninformed. In chaotic areas of fractal images even the change of the sample point by an astoundingly small amount in the complex plane will change the calculation sufficiently to get a different pixel displayed. Writing the code that creates fractal images on a screen is almost more of an 'engineering task' than a 'pure mathematics task' in the sense that the task is complete when it is done within a reasonable, specified error tolerance -- instead of when the task is done 'perfectly.' - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces+hallane=earthlink.net@mailman.xmission.com [mailto:fractdev-bounces+hallane=earthlink.net@mailman.xmission.com]On Behalf Of Richard Sent: Sunday, May 06, 2007 10:21 AM To: Fractint developer's list Subject: Re: Re: [Fractdev] [xy]_{min,max} sure, but [xy]_3rd?
In article <1910.2573-9011-346628596-1178452362@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
Richard wrote:
I've always envisioned that the samples should always be on a rectangular grid aligned with the coordinate axes of the complex plane. Any distortion or rotation should be done by a display process and not by the sampling process. ... Think of it like texture mapping. Your texture is always defined in a rectangular sample grid. Using the texture coordinates you can stretch and rotate it anyway you want.
But when you change the order to sampling / rotation, you don't get the same (pixel-by-pixel) picture, do you?
That's true, you might not get the same pixel exact picture, but that's because the parallelogram-based sampling is introducing the distortion into the sampling. Rendering fractals is essentially texture mapping, just that the texels are computed procedurally instead of done by an artist in a paint program.
If you drive sampling of a source texture from the screen space coordinates of a distorted quadrilateral (i.e. a parallelogram or quadrilateral rotated with respect to the texture), then you introduce aliasing between screen space and texture space. With textures they solve this with mipmapping and bilinear filtering and using texture coordinates to drive sampling of the texture. Tilt the quadrilateral in perspective and you need homogeneous texture coordinates in order to undo the perspective distortion.
Fractint currently always samples directly from screen space, probably because of its limited memory heritage.
However if you sample the fractal in a non-distorted space, then you can create mipmaps and do all the same distortion eliminating tricks that texture mapping uses.
Think of it like of doing inversion. If you reorder actions to sampling / inversion, you get a *very* sparse image.
Inversion is something completely different. First, for a parallelogram or rotated zoom box, this is a linear transformation (although a parallelogram represents a shear transformation, its still representable by a matrix). An inversion is a non-linear transformation and doesn't preserve areas or angles.
Still, even an inversion transformation is analytical enough that you can define the source region that corresponds to the screen space region of a pixel. You can then appropriately sample the corresponding source region (i.e. the complex plane) so that you can filter it to obtain the appropriate screen space "iteration". (It wouldn't really be a single iteration then, but an average of all the iterations in the source region that correspond to the screen pixel.)
Whether or not this would be feasible or reasonable to do is an interesting question.
The point is though, that just because an image is "different" from whatever fractint renders right now, doesn't mean that the new image is "wrong". Fractint does all kinds of stuff all over the place that can introduce small errors in the resulting image in deference to speed. For instance, the symmetry speedups introduce small errors when pixels don't exactly straddle the axes. I don't hear anyone complaining about that. Solid guessing also introduces errors in plenty of fractal types. Alternate algorithms generate different images of the same fractal -- the DEM algorithm was created specifically to highlight the dendritic filaments of the M-set that don't show up in typical escape time algorithms because the filaments are thinner than a pixel.
Even the idea that a pixel only represents a single sample in the complex plane introduces aliasing and errors. -- "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/>
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.4/790 - Release Date: 5/5/07 10:34 AM
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.5/791 - Release Date: 5/6/07 9:07 AM
In article <MDBBJLBFBICIIEIHFBMEKEBODBAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
I know that in the past there has sometimes been a great outcry when a pixel was changed in an image due to a code change.
The desire to satisfy the "old image" requests has resulted in a *lot* of crufty code workarounds in the code as well.
In chaotic areas of fractal images even the change of the sample point by an astoundingly small amount in the complex plane will change the calculation sufficiently to get a different pixel displayed.
Yep. Fractals are just one big aliasing problem because you always have some chaotic portion where the image is undersampled. You can brute force resolve the chaos down to some smoother seas of noise by supersampling and then downfiltering. I've done this plenty of times. It gives you smooth edges on the escape time boundaries and resolves the chaos to the best that an image of your final resolution can show. But it will always be an approximation to the underlying "true" fractal.
Writing the code that creates fractal images on a screen is almost more of an 'engineering task' than a 'pure mathematics task' in the sense that the task is complete when it is done within a reasonable, specified error tolerance -- instead of when the task is done 'perfectly.'
I have an idea for a storage scheme that stores the iterations at infinite resolution of detail (limited only by disk space) that I want to implement some day. Its about as close as you can come to the 'perfect' rendering of a fractal, IMO. This scheme would require a separation of sampling and display to work properly. However, once you separation sampling from display, then you can do things like rotate the sampled image around in a circle arbitrarily fast, since you're just displaying a texture-mapped quadrilateral in that case. No need to recompute the texture at all, which is how fractint would do it now. Even XaoS recomputes a bunch of stuff more often than it needs to because it only keeps around in memory a single buffer at a single zoom factor. The killer thing is that the more you animation by zooming in and out, or rotating around, the worse it gets both for fractint and for XaoS. -- "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/>
Rich, a silly question: why should be the sampling area aligned with axes? transformations of a sampling area save a lot of computations: otherwise you would have to sample and compute the whole area of a bounding box of a stretched / skewed / rotated zoom box.. transformations of a computed image result into interpolations, blurring the originally 'incorrect'/'imperfect' image even more the chain is: transform coords > sample > compute > transform pixels > render what Fractint does: transform coords > sample > compute > visualise what real-time rendering layer would add: loop {transform pixels > render} so, even if you plan to substitute the plain visualisation with a real-time rendering layer, the coords transformation is still needed for efficiency and versatility.. /charlie/
In article <1916.2579-2544-586195160-1178561760@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
a silly question: why should be the sampling area aligned with axes?
It doesn't have to be; currently fractint doesn't do this. But I have an idea for a sampling algorithm that maximizes the amount of reuse for each redraw during panning and zooming and that idea depends on an axis-aligned sampling grid. It would also be possible to store the itarations on your hard drive through this method so that you could browse your favorite fractal type and store as much iteration data as you wanted on your hard drive, up to the capacity of the drive. The other reason (and one more likely to be implemented sooner) that you might want to do this is to reduce "display fractal" to "display texture-mapped quadrilateral". In that case, any parallelogram or rotation would just be a shear to the quadrilateral or a rotation of the quadrilateral, respectively. Your samples would still be axis-aligned and stored in the texture that way. Basically with texture mapping support in the graphics card, rotation and shear of the fractal zoom box are trivial operations and higher-quality than what you get with fractint right now. -- "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/>
In article <E1HlozH-0005aJ-00@xmission.xmission.com>, Richard <legalize@xmission.com> writes:
The other reason (and one more likely to be implemented sooner) that you might want to do this is to reduce "display fractal" to "display texture-mapped quadrilateral". In that case, any parallelogram or rotation would just be a shear to the quadrilateral or a rotation of the quadrilateral, respectively.
More accurately, the shear might be done through the way the texture coordinates are placed on the corners of the quadrilateral. -- "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/>
############################################################ Richard said:
Basically with texture mapping support in the graphics card, rotation and shear of the fractal zoom box are trivial operations and higher-quality than what you get with fractint right now.
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? 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? With texture mapping support in the graphics card a number of texels (texture pixels) contribute to a final rendered rotated/sheared pixel. 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. 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. [Brief overviews of texture mapping and texture filtering are here: http://en.wikipedia.org/wiki/Texture_mapping and here: http://en.wikipedia.org/wiki/Texture_filtering ]
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.
It would also be possible to store the iterations on your hard drive through this method so that you could browse your favorite fractal type and store as much iteration data as you wanted on your hard drive, up to the capacity of the drive.
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. Similarly, going to texture mapping might be effective for those with texture mapping hardware in their graphics cards, but not for those without this hardware. 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.) So, for example, changing from calculating an 800 x 600 fractal to calculating a 1600 x 1200 current screen resolution fractal requires four times as many pixels -- making a 2 GHz CPU appear four times 'slower' -- like a 500 MHz CPU calculating the 800 x 600 pixel fractal. But people regularly use 200 MHz CPUs to run Fractint on. And it looks like the last decade's CPU speed gains are not going to be happening in the future -- witness Intel's falling back to providing two CPU's on a chip instead of a single faster CPU as its last offering. 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? Or would two versions of Fractint be needed -- one for computers with modern hardware features and another one for older computers? One of the premises of Fractint is that of getting the most function out of limited capacity hardware. Do we want to abandon this philosophy? - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # ######################### ############################################################ No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.6/795 - Release Date: 5/9/07 3:07 PM
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/>
Richard said:
Someone reported to me -- it might even have been you -- that the current C implementation actually benchmarked faster than the old DOS assembly implementation.
It was not me. But I'm pleased to learn that C compilers, CPUs and FPUs are so good now. Thanks for your detailed comments on my email. It is always great to have motivations, reasons, ramifications, etc. of major decisions about program changes clarified so that any adjustments needed in the philosophy of the changes can be made earlier, rather than later. Also, others may not be aware of all of your reasoning behind the particular changes you are making and proposing. Thanks for all the great work you have done getting the beta out there. (Is beta 5 the most current?) Would you please republish the link for the latest beta (to [Fractint]) to help more people try it -- and give you more feedback... - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # ######################### No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.6/795 - Release Date: 5/9/07 3:07 PM
In article <MDBBJLBFBICIIEIHFBMEOECMDBAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
It was not me. But I'm pleased to learn that C compilers, CPUs and FPUs are so good now.
Its mostly that the 16-bit instructions are the slow path in CPUs these days and the new code is compiled 32-bit.
Thanks for your detailed comments on my email.
I'm happy to explain what motivates me: modernization. I know that people will always want to run fractint on old boxes, but a new version of fractint doesn't take away the old versions, which are more appropriate for old hardware.
Thanks for all the great work you have done getting the beta out there. (Is beta 5 the most current?)
Yes, beta 5 is the most current. There is a two-fold motivation here: move the code forward to a Win32 environment, and restructure the existing code base so that its easier for other programmers to contribute. The former is easier than the latter. Lately I've been working on the latter.
Would you please republish the link for the latest beta (to [Fractint]) to help more people try it -- and give you more feedback...
I recently posted it to sci.fractals and I posted it to the fractint list. I can repost to the fractint list. Is there somewhere else I should also post it? There is an article about it on my blog as well. -- "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/>
Richard wrote:
Is there somewhere else I should also post it [The link to the Fractint for Windows beta]?
You could post the beta link at [Philofractal] also.
There is an article about it on my blog as well.
You should explicitly include the link to your blog in the text body of your beta announcement postings -- mentioning its Fractint content -- in addition to having it in your signature. I didn't notice the link or know that it had extensive comments about Fractint until you just sent me your last email... I just read your blog entry on Fractint. An enjoyable and informative read. I also enjoyed your blog entry: ÂWorking Effectively with Legacy Code by Michael C. Feathers I worked with a large legacy code base in the past and once had a supreme challenge in understanding thousands of uncommented lines of spaghetti Fortran. I eventually was able to get my head around it enough to make the needed mods. - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces+hallane=earthlink.net@mailman.xmission.com [mailto:fractdev-bounces+hallane=earthlink.net@mailman.xmission.com]On Behalf Of Richard Sent: Thursday, May 10, 2007 9:13 PM To: Fractint developer's list Subject: Re: [Fractdev] <Richard>Thanks for the comments
In article <MDBBJLBFBICIIEIHFBMEOECMDBAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
It was not me. But I'm pleased to learn that C compilers, CPUs and FPUs are so good now.
Its mostly that the 16-bit instructions are the slow path in CPUs these days and the new code is compiled 32-bit.
Thanks for your detailed comments on my email.
I'm happy to explain what motivates me: modernization.
I know that people will always want to run fractint on old boxes, but a new version of fractint doesn't take away the old versions, which are more appropriate for old hardware.
Thanks for all the great work you have done getting the beta out there. (Is beta 5 the most current?)
Yes, beta 5 is the most current. There is a two-fold motivation here: move the code forward to a Win32 environment, and restructure the existing code base so that its easier for other programmers to contribute. The former is easier than the latter. Lately I've been working on the latter.
Would you please republish the link for the latest beta (to [Fractint]) to help more people try it -- and give you more feedback...
I recently posted it to sci.fractals and I posted it to the fractint list. I can repost to the fractint list. Is there somewhere else I should also post it? There is an article about it on my blog as well. -- "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/>
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.8/797 - Release Date: 5/10/07 5:10 PM
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.8/797 - Release Date: 5/10/07 5:10 PM
In article <MDBBJLBFBICIIEIHFBMEIEDFDBAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
Richard wrote:
Is there somewhere else I should also post it [The link to the Fractint for Windows beta]?
You could post the beta link at [Philofractal] also.
What's the subscription address/URL for it? -- "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/>
Richard wrote:
What's the subscription address/URL for it [Philofractal]?
To subscribe to/unsubscribe from the list, send a message to: <philofractal-subscribe@lists.fractalus.com> <philofractal-unsubscribe@lists.fractalus.com> Posting address: philofractal@lists.fractalus.com For additional commands, info and a FAQ e-mail: <philofractal-help@lists.fractalus.com> <philofractal-info@lists.fractalus.com> <philofractal-faq@lists.fractalus.com> There may be no interface to a web site containing an archive of previous posts. I did not see a way to access the archive other than sending email requests to the automated list attendant as detailed in the help information: To get messages 123 through 145 (a maximum of 100 per request), mail: <philofractal-get.123_145@lists.fractalus.com> To get an index with subject and author for messages 123-456, mail: <philofractal-index.123_456@lists.fractalus.com> Here is a potentially useful excerpt from the response I received from sending a help request to: philofractal-help@lists.fractalus.com: If you need to get in touch with the human owner of this list, please send a message to: <philofractal-owner@lists.fractalus.com> Please include a FORWARDED list message with ALL HEADERS intact to make it easier to help you. - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # ######################### No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.8/797 - Release Date: 5/10/07 5:10 PM
Thanks Hal. -- "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/>
Hal, - There may be no interface to a web site containing an - archive of previous posts. I did not see a way - to access the archive other than sending email requests - to the automated list attendant as detailed in the - help information: There is currently no web interface, although one is being developed. Exposing the list messages to the web is actually easy (and I had a prototype of this working a couple of years ago). The tricky part is if access to the list messages needs to be limited to list members. Since not all the lists I run are public (e.g. beta-testing lists) that was an important requirement, and the project fell by the wayside until this spring. Damien M. Jones dmj@fractalus.com http://www.fractalus.com/gallery/ http://www.damienmjones.com/
What's the charter for this list? I'd seen people posting to it occasionally, but I don't know what the subject area or target audience is supposed to be. -- "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/>
Richard wrote:
What's the charter for this list? I'd seen people posting to it occasionally, but I don't know what the subject area or target audience is supposed to be.
Mary Tupper (Xylen) was the originator of the Philofractal List. (It has been many years since she last posted.) The following was taken from a discussion about the Charter back during the latter part of January, 1999: Gedeon Peteri wrote:
I joined this list because my curiosity was aroused. Since "promoting agendas" and, conversely, "debunking" those of other's, as well as engaging in argumentation, belong to the essence of philosophy, I was wondering what will be accomplished here if such activities are prohibited by the charter.
Yes, you are right Gedeon. Technically "promoting agendas", "debunking", and "argumentation" are all part of philosophy, but I don't want people to get overly emotional and angry about the posts. I prefer the term 'discussion' to 'arguing' because arguing has angry emotional connotations. By restricting "promoting agendas" I am referring to people who will post statements like "Concept X is the only true way, and anybody who doesn't believe in X is a fool." As long as people are willing to discuss both the pro's and cons of a concept, there is no problem. Similarly with "debunking": "As long as you believe in Concept X, you are the fool" contribute nothing to a discussion. The whole point of this list is promote discussion and logical arguments about fractal philosophy. Since this group can spend months discussing the rules for a contest, ;) I'm sure there will be much discussion on this matter as well. Xylen Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
Richard wrote:
"Hal Lane" <hallane@earthlink.net> writes:
Would you please republish the link for the latest beta (to [Fractint]) to help more people try it -- and give you more feedback...
I recently posted it to sci.fractals and I posted it to the fractint list. I can repost to the fractint list. Is there somewhere else I should also post it?
There are hundreds of fractal related Lists, Forums, Groups, etc... And I have already sent messages to at least two dozen of them. Do you require somebody to give you a listing of all those various places which could receive such a notice?? Plus, I copied the installation file to my software directory, where it has had around 2,000 individuals grab a copy so far. The problem is that there is no Text file, Help file, Dialog Window, or other such means of communication within the installation which lets people know what to do when they find an error or bug, or where to send that information to. It should be prominent either during the install process or upon each execution of the beta version. Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
In article <464765AD.5040103@Worldnet.att.net>, "Paul N. Lee" <Paul.N.Lee@Worldnet.att.net> writes:
There are hundreds of fractal related Lists, Forums, Groups, etc... And I have already sent messages to at least two dozen of them. Do you require somebody to give you a listing of all those various places which could receive such a notice??
No, I accept bug reports from anywhere :-)
Plus, I copied the installation file to my software directory, where it has had around 2,000 individuals grab a copy so far.
Cool!
The problem is that there is no Text file, Help file, Dialog Window, or other such means of communication within the installation which lets people know what to do when they find an error or bug, or where to send that information to. It should be prominent either during the install process or upon each execution of the beta version.
I think I have a shortcut installed to the current bugs .txt file, but I will add something for reporting bugs/feedback in the next beta. Right now the code is undergoing massive restructuring in order to facilitate further development. Part of the "release" process is not just the executable, but making the code accessible to other contributors. In order to do that, there's lots of plumbing changes needed under the covers. -- "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/>
Rich wrote:
I suspected that's what the "3rd" was for; I'll try to pin it down specifically ...
I was almost right - the "3rd" variables are the lower left corner, not upper right. There are some extensive comments in lorenz.c I wrote (with a contribution from Sylvie) that explain the relationship between the fractint pixel coordinates and the complex plane. Other places in the code to look at would be places that convert between corners and center-mag. I can look that up, but what is below should be definitive. This code was needed in lorenz because the transformation between pixels and complex plane had to happen each point. Let it not be said there are NO comments in the fractint code <grin!> Well - the options are - no comments, or long essays! Tim /* Conversion of complex plane to screen coordinates for rotating zoom box. Assume there is an affine transformation mapping complex zoom parallelogram to rectangular screen. We know this map must map parallelogram corners to screen corners, so we have following equations: a*xxmin+b*yymax+e == 0 (upper left) c*xxmin+d*yymax+f == 0 a*xx3rd+b*yy3rd+e == 0 (lower left) c*xx3rd+d*yy3rd+f == ydots-1 a*xxmax+b*yymin+e == xdots-1 (lower right) c*xxmax+d*yymin+f == ydots-1 First we must solve for a,b,c,d,e,f - (which we do once per image), then we just apply the transformation to each orbit value. */ /* Thanks to Sylvie Gallet for the following. The original code for setup_convert_to_screen() solved for coefficients of the complex-plane-to-screen transformation using a very straight- forward application of determinants to solve a set of simultaneous equations. The procedure was simple and general, but inefficient. The inefficiecy wasn't hurting anything because the routine was called only once per image, but it seemed positively sinful to use it because the code that follows is SO much more compact, at the expense of being less general. Here are Sylvie's notes. I have further optimized the code a slight bit. Tim Wegner July, 1996 Sylvie's notes, slightly edited follow: You don't need 3x3 determinants to solve these sets of equations because the unknowns e and f have the same coefficient: 1. First set of 3 equations: a*xxmin+b*yymax+e == 0 a*xx3rd+b*yy3rd+e == 0 a*xxmax+b*yymin+e == xdots-1 To make things easy to read, I just replace xxmin, xxmax, xx3rd by x1, x2, x3 (ditto for yy...) and xdots-1 by xd. a*x1 + b*y2 + e == 0 (1) a*x3 + b*y3 + e == 0 (2) a*x2 + b*y1 + e == xd (3) I subtract (1) to (2) and (3): a*x1 + b*y2 + e == 0 (1) a*(x3-x1) + b*(y3-y2) == 0 (2)-(1) a*(x2-x1) + b*(y1-y2) == xd (3)-(1) I just have to calculate a 2x2 determinant: det == (x3-x1)*(y1-y2) - (y3-y2)*(x2-x1) And the solution is: a = -xd*(y3-y2)/det b = xd*(x3-x1)/det e = - a*x1 - b*y2 The same technique can be applied to the second set of equations: c*xxmin+d*yymax+f == 0 c*xx3rd+d*yy3rd+f == ydots-1 c*xxmax+d*yymin+f == ydots-1 c*x1 + d*y2 + f == 0 (1) c*x3 + d*y3 + f == yd (2) c*x2 + d*y1 + f == yd (3) c*x1 + d*y2 + f == 0 (1) c*(x3-x2) + d*(y3-y1) == 0 (2)-(3) c*(x2-x1) + d*(y1-y2) == yd (3)-(1) det == (x3-x2)*(y1-y2) - (y3-y1)*(x2-x1) c = -yd*(y3-y1)/det d = yd*(x3-x2))det f = - c*x1 - d*y2 - Sylvie */
In article <463C4AA0.28836.251D57@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Let it not be said there are NO comments in the fractint code <grin!> Well - the options are - no comments, or long essays!
Comments that explain why the code does what it does are good. Comments that explain what the code is doing mean the code isn't clear enough on its own and indicate a need for refactoring. -- "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/>
participants (6)
-
charlie chernohorsky -
Damien M. Jones -
Hal Lane -
Paul N. Lee -
Richard -
Tim Wegner