more parsets that render improperly in xfractint
I'm not sure what the common denominator is here. I'm scraping through Roger's old parsets and rendering them in xfractint and a few of them have come up as black (or white) screens or get an error. Attached are the ones I've had problems with so far... 09-April [Fractint] Resampling,complexity compounded 18-April [Fractint] (no subject) 21-April [Fractint] Subject No Subject (fractal noise) and the Droste Effect 22-April [Fractint] Fmod Coloring 25-April [Fractint] A bug with bugs 06-May [Fractint] Techno! -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Here is what Fracton gets for this difficult set of par's: fract044 - Black Screen - Color indexes are between ~0-200, well below the log map cutoff fract081 - Black Screen - Max iteration for all pixels fract045 - Correct Image apr_21 - Correct Image - There is an error in the par. It is missing a } at the end. fract068 - Incorrect Image - Fracton sometimes draws incorrectly with outside=fmod fract163 - Incorrect Image - Image mostly white. Uses round which I never tested with an image before now -- Mike Frazier www.fracton.org
In article <AANLkTikU3dfrKtrxpnaSBjRf7ZgLr80aVivNZ82R-TbA@mail.gmail.com>, Mike Frazier <fractonorg@gmail.com> writes:
apr_21 - Correct Image - There is an error in the par. It is missing a } at the end.
D'oh! I should have caught that one, thanks! -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Rich,
Attached are the ones I've had problems with so far... 09-April [Fractint] Resampling,complexity compounded 18-April [Fractint] (no subject) 21-April [Fractint] Subject No Subject (fractal noise) and the Droste Effect 22-April [Fractint] Fmod Coloring 25-April [Fractint] A bug with bugs 06-May [Fractint] Techno!
09-April, both fract044 and fract081 seem correct on mine, but I haven't committed recent changes 18-April, fract031 broken, uses Cotanh - see below 21-April, fract045 is correct 22-April, apr_21.gif is correct, as Mike stated, uses Cotan - but see below 25-April, fract068 broken, uses Cotanh - see below 06-May, fract163 generates if run first, but doesn't look quite right I just ran across a problem with the ChkFloatDenom macro in parser.c while looking into the problem with fract031. The C code uses this in the Tan, Tanh, Cotan, Cotanh, and Recip functions. If the absolute value of the denominator is less than or equal to DBL_MIN, the overflow variable gets set and bailout occurs. The assembly code behaves differently in that overflow never gets set and the calculation just keeps going. I am curious as to how the C code can use doubles to determine that a value is less than DBL_MIN. Jonathan
I am curious as to how the C code can use doubles to
determine that a value is less than DBL_MIN.
*DBL_MIN* - the smallest positive normal double. I am pretty sure you can have de-normalized numbers that are smaller than this. That is the smallest normalized number. De-normalized numbers would still have the minimum exponent but would have more leading zeros in the mantissa. With 53 bits of mantissa in a double you can go about 1E-15 smaller than that number. I just ran into this when I added the arbitrary precision math to Fracton. Here is a page that has the definition for all those terms for IEEE floating point. http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPa... -- Mike Frazier www.fracton.org
In article <1284416480.1847.97.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:
09-April, both fract044 and fract081 seem correct on mine, but I haven't committed recent changes 18-April, fract031 broken, uses Cotanh - see below 21-April, fract045 is correct 22-April, apr_21.gif is correct, as Mike stated, uses Cotan - but see below 25-April, fract068 broken, uses Cotanh - see below 06-May, fract163 generates if run first, but doesn't look quite right
I get the same on the Windows port. I will try again in xfractint and see what I get. Its possible that my script failed and not xfractint. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
In article <E1OvLNV-0006MN-Qc@shell.xmission.com>, Richard <legalize@xmission.com> writes:
I get the same on the Windows port. I will try again in xfractint and see what I get. Its possible that my script failed and not xfractint.
OK, I get the two broken ones that use cotanh in the current xfractint code. So I guess the other errors were my script; I'll pump them through again and see if they succeed this time. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
In article <E1OvM4c-0002vy-0p@shell.xmission.com>, Richard <legalize@xmission.com> writes:
In article <E1OvLNV-0006MN-Qc@shell.xmission.com>, Richard <legalize@xmission.com> writes:
I get the same on the Windows port. I will try again in xfractint and see what I get. Its possible that my script failed and not xfractint.
OK, I get the two broken ones that use cotanh in the current xfractint code. So I guess the other errors were my script; I'll pump them through again and see if they succeed this time.
Hmm.... when I render at 800x600 for the 06-May fractal ("Techno!"), I get the correct result. When I render at 4800x3600 and downsample, then I get a white screen. I wonder if this formula is sensitive to resolution? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
techno1.gif GIF 1600x1200 correct techno2.gif GIF 3200x2400 wrong techno3.gif GIF 2400x1800 wrong techno4.gif GIF 2000x1500 correct techno5.gif GIF 2200x1648 wrong So at some point at resolution > 2000x1500 the image is rendered wrong. Narrowing it down by binary search seems to indicate that if the width is larger than 2048, then the image produced by this parset is always white. Is there some limitation with > 2048 in tesseral scanning? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Rich,
Narrowing it down by binary search seems to indicate that if the width is larger than 2048, then the image produced by this parset is always white.
Is there some limitation with > 2048 in tesseral scanning?
Yes!!! After 2048 passes=1 is forced. This has to do with fixed array sizes that were imposed under DOS. Once we get away from the DOS version, we can eliminate this limitation. Jonathan
In article <1284511088.1767.4.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:
Yes!!! After 2048 passes=1 is forced. This has to do with fixed array sizes that were imposed under DOS. Once we get away from the DOS version, we can eliminate this limitation.
OK, but the xfractint code base shouldn't be constrained by this. Where is the limit? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Rich,
Yes!!! After 2048 passes=1 is forced. This has to do with fixed array sizes that were imposed under DOS. Once we get away from the DOS version, we can eliminate this limitation.
OK, but the xfractint code base shouldn't be constrained by this. Where is the limit?
Do you mean which specific lines of code? Or, what is the numerical value of the limit? The numerical value is the same because the same sections of code are used for Fractint, Xfractint, and Winfract. This is a big project to fix because this specific array and its size are used to draw the image and save/restore the image (GIF encode/decode), to name a few places. The couple of times I've looked at fixing this I quickly got so far afield that I gave it up. I'll look at it again once I have my SDL port up and running. Jonathan
In article <1284677130.1750.8.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:
Do you mean which specific lines of code?
Yes. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
In article <1284678501.1750.12.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:
Rich,
Do you mean which specific lines of code?
Yes.
Start in fractint.h with line 57:
#define OLDMAXPIXELS 2048 /* Limit of some old fixed arrays */
Well yeah, I meant more where in the tesseral scan logic does it use this? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
participants (3)
-
Jonathan Osuch -
Mike Frazier -
Richard