- Fractdev - mailman.xmission.com

I've run across what appears to be 2 problems with the 20.99.8 Fractint for Windows
by Hal Lane 02 May '08

02 May '08

I've run across what appears to be two problems with the ver 20.99.8 Fractint for Windows, one known, one perhaps new: - Calculating Jim Muth's FoTD for 8/4/8 gives a black screen using the "Run saved command set" command. - Completion of the image at 640x480 is essentially instantaneous per the <tab> command, instead of the 7 1/2 minutes described by Jim. - After calculating the FoTD for 8/4/8 and: - Choosing fractal "Type" "mandel" and - Accepting the default parms - An incorrect default Mandelbrot image is drawn. - The problem appears to be that the "Outside" parm on the "X" screen is left as "fmod" from the previous calculation of the FoTD using the "Run saved command set" command. - Changing "Outside" to "iter" draws the correct default Mandelbrot image. The first problem appears to be of the following type: Author: Richard Date: 2008-02-18 09:11 -500 Subject: Re: [Fractdev] <Richard> Lex & yacc for formula parser? > > ...I wouldn't mind fixing the bug that > > causes some formulas to render incorrectly in the near term. The second problem may be a newly uncovered problem. Calculating the FoTD for 8/4/8 with DOS Fractint ver 20.04.4 gives the correct image. - Hal Lane ######################### # hallane(a)earthlink.net # #########################

5 13

shift by negative bits
by Richard 12 Apr '08

12 Apr '08

in unix/fpu087.c, RegSftFloat: long RegSftFloat(x, Shift) long x; int Shift; { float f; f = em2float(x); if (Shift>0) { f *= (1<<Shift); } else { f /= (1<<Shift); } return float2em(f); } When Shift is negative, it divides by 1 left-shifted by a negative number of bits. Shouldn't this be 1 << -Shift instead? -- "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/>

2 2

save_stack() called without calling restore_stack()
by Richard 09 Apr '08

09 Apr '08

This looks like a bug to me. fractalb.c, ComplexPower_bf: _BFCMPLX *ComplexPower_bf(_BFCMPLX *t, _BFCMPLX *xx, _BFCMPLX *yy) { _BFCMPLX tmp; bf_t e2x, siny, cosy; int saved; saved = save_stack(); e2x = alloc_stack(rbflength+2); siny = alloc_stack(rbflength+2); cosy = alloc_stack(rbflength+2); tmp.x = alloc_stack(rbflength+2); tmp.y = alloc_stack(rbflength+2); /* 0 raised to anything is 0 */ if (is_bf_zero(xx->x) && is_bf_zero(xx->y)) { clear_bf(t->x); clear_bf(t->y); return(t); } cmplxlog_bf(t, xx); cplxmul_bf(&tmp, t, yy); exp_bf(e2x,tmp.x); sincos_bf(siny,cosy,tmp.y); mult_bf(t->x, e2x, cosy); mult_bf(t->y, e2x, siny); restore_stack(saved); return(t); } When the 'if' is taken above, restore_stack() is not called and bignum memory stack is leaked. This structure is repeated again in ComplexPower_bn. -- "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/>

2 2

<Richard>I don't understand usage of some of the new FRACTINT.CFG file
by Hal Lane 20 Feb '08

20 Feb '08

Richard, These are minor items in Fractint for Windows beta 5, but are possibly features that are behaving differently than intended. In the FRACTINT.CFG file, when I tried to add the phrase: square pixels (as a comment to the F2, F3, etc. lines) between the pair of commas in: 256,,gdi in some of the rows, as follows: 256,square pixels,gdi I was trying to follow the 'instructions' of the column headings: |clr| comments | driver When I do the above the comment phrase: square pixels does *not* appear in Fractint for Windows beta 5's screen that lists resolution choices brought up by the <del> key. Is this a problem? <---<< The comments from the DOS FRACTINT.CFG file are listed in DOS Fractint's list of resolutions screen. I also noticed that you list the order of columns in the Fractint for Windows list of resolutions screen as: .colr.driver......comment... with the order of the driver and comment reversed from the FRACTINT.CFG file. This may or may not be as you intended it. Interestingly, when I added a couple of Win32 Disk Video lines that ended like this: 19, 2048, 1536,256,(1024x768*2),disk and this: 19, 4096, 3072,256,(1024x768*2),disk the list of resolutions *did* show the: (1024x768*2) So, the comment feature of the FRACTINT.CFG file works for some lines and not for others. Note: the two lines (above) had no key associated with them. (Their definition lines started with leading spaces and a leading comma.) These above added disk resolutions create the intended files OK - with the correct resolutions. Its great to still be able to add arbitrary resolutions. I sometimes calculate images at higher resolutions than I want for the final image. I then 'downsample' the higher resolution image with bicubic sampling to get a more anti-aliased version for the final image. I realize that this methodology can be problematical when applied to fractals, but has worked well for the particular fractals I have used it on. Also, I found that the line in FRACTINT.CFG defining: F9 ... 1280, 960,256, does *not* appear in the Fractint for Windows screen that lists resolution choices when I am using 1280x1024. It *does* appear when I increase my screen resolution to 1600x1200. You apparently interrogate the current screen resolution to see if it will support each Win32 GDI Video resolution in the FRACTINT.CFG file plus its containing window border. Very nice. I note that there are also at least two resolutions shown - 480 x 360 (disk & video) and 1500 x 1125 (disk) - in the Fractint for Windows resolutions screen table that are *not* in the FRACTINT.CFG file. I guess I don't know where the 480 x 360 and 1500 x 1125 pixel resolutions come from or why some comments in the FRACTINT.CFG file appear and others don't. - Hal Lane ######################### # hallane(a)earthlink.net # #########################

2 1

Re: New substantially improved version
by Jonathan Osuch 20 Feb '08

20 Feb '08

Jean-Pierre, > > 1) I left out your popup window (in encoder.c) because I do not want to > > check for NCURSES in the common directory. I like the idea and there > > may be a way to do this strictly from the code in the unix directory. > > Don't know if this is doable - but let me think about it ! We can code texttempmsg() and stopmsg() as popup windows in Xfractint, and then #ifndef XFRACT out the versions in realdos.c. Jonathan

3 5

<Richard> Q's re Fractint for Windows
by Hal Lane 18 Feb '08

18 Feb '08

Richard, > > Is the latest [beta] still: FractIntSetup-21.00.beta5.msi ? > Yes Thanks for the confirmation. I just installed this and I am very impressed with its behavior. Thanks for all your work! I really agree with your approach of keeping the DOS user interface and restructuring the fractal code for Windows as the first step towards a full migration of DOS Fractint to Windows. I was surprised (looking in Task Manager) at how little of my CPU was being used (and how it varied between fractals) when calculating some of the parm file fractals included in your distribution. [Its certainly pleasant not to have the DOS keyboard read routines not continuously sniffing at my fingers in your Windows beta!] What currently determines how much of the CPU is given to the calculation of a fractal? <---<< > I won't release another version until I've fixed a bug in the formula > rendering that keeps giving a light red screen for certain formulas. When I took a quick look at the formula parser some time ago, I was pretty intimidated. The parser looked like an ad hoc design approach, rather than an automatically generated parser, like lex and yacc. I guess if the formula parser code is still the original code, that something like the changed #includes and/or data typing and it passing must be the source of the problem. The fact that the bug in the formula rendering keeps giving a consistent symptom (a light red screen) should hopefully help in the eventual diagnosis of the problem. You may want to delete or update Jonathan's ReadMe.txt file in your next beta since it describes the DOS version. I note that you changed the keys that encode different screen resolutions from the original encodings. So far that has only impacted my SSTOOLS.INI file. It could also affect .BAT files that include a screen resolution change. I guess I'm working my way around to asking whether it could be useful to have the keys that encode screen resolutions be the same as the default DOS encodings... Do you have a web page where you collect the issues/bugs that people report or that you are working on -- beyond the items listed in the BUGS.txt file included in your distribution? I don't want to report any items that have already been reported, or reported and fixed like: <---<< > <\> or <h> or <ctrl-h> just redraws the current image Fixed in beta 6 - Hal Lane ######################### # hallane(a)earthlink.net <mailto:hallane@earthlink.net> # ######################### > -----Original Message----- > From: fractdev-bounces(a)mailman.xmission.com > [mailto:fractdev-bounces@mailman.xmission.com]On Behalf Of Richard > Sent: Saturday, February 16, 2008 8:40 PM > To: Fractint developer's list > Subject: Re: [Fractdev] What is the latest version of Richard's > 'Fractint forWindows'? > > In article <MDBBJLBFBICIIEIHFBMEAECNDFAA.hallane(a)earthlink.net>, > "Hal Lane" <hallane(a)earthlink.net> writes: > > > Is the latest still: FractIntSetup-21.00.beta5.msi ? > > Yes > > I won't release another version until I've fixed a bug in the formula > rendering that keeps giving a light red screen for certain formulas. > --

2 3

What is the latest version of Richard's 'Fractint for Windows'?
by Hal Lane 16 Feb '08

16 Feb '08

What is the latest version of Richard's 'Fractint for Windows'? On 2007-05-10 Richard posted to [Fractdev]: "Yes, beta 5 is the most current." Is the latest still: FractIntSetup-21.00.beta5.msi ? If not, what is the latest version and where can I get it? Thanks, - Hal Lane ######################### # hallane(a)earthlink.net # #########################

2 1

Image artifacts due to precision problems
by Hal Lane 25 Jan '08

25 Jan '08

************************************************* Jim Muth in his "FOTD -- January 24, 2008" text says: >some of the images appear so unlikely that I >cannot shake the impression that they are >artifacts of mathematical imprecision rather >than true fractals. My question is: Can one determine if a fractal's features are precision problem artifacts by computing the fractal twice -- with two different values of the number of arbitrary precision digits -- and then comparing the two images? <---<< My hypothesis is that if you compare the two images calculated in the above manner and they are the same, then problems of precision are not the cause of a fractal's unusual features. Is this the case? <---<< If this method does correctly determine whether an image has artifacts or not, is adding the following items to an image's parameter file a valid way to exactly set the number of digits of precision used in a calculation? 1st image calc: --------------- MATHTOLERANCE=-1/-1 BFDIGITS=14 2nd image calc: --------------- MATHTOLERANCE=-1/-1 BFDIGITS=15 I cannot find the email sent to me that tells how to compare two images. Here is what appears to work -- please correct me if I am wrong: To compare two images that are in files: - Run FRACTINT *without* the command line parameter debug=50 - Load the first image from its file using <r> - Type <g> and then: debug=50 - Load the second image from its file. (Note that the File List selection page title is now: "Select File for 3D Overlay") - The image on the screen is the difference between the two images. Identical pixels in the two images are shown as color zero. Different pixels are shown as non-zero. - If this 'difference image' has any non-zero pixels the two images are different. Is the above procedure to compare two images in files correct? <---<< It appears that the color map of the images is used to display the difference pixels. If there are extremely dim color map values in the image one could be fooled into thinking that there were no differences between two images when in fact there were if the difference pixels that were displayed happened to use dim color map values. If this is a problem for a particular image one could get around it by loading a garish color map, say, a color map of 15 bright colors and black like: GOODEGA.MAP This makes all non-zero pixels be easily visible against a black background. I calculated a default Mandelbrot image at 640 x 480 using both the default integer math and then putting float=yes in my SSTOOLS.INI file. (I had forgotten to do this when installing FRACTINT onto my recent computer.) I was surprised to see a significant number of differences between the integer and float images. I constructed a color map that would allow me to see the difference image pixel values as follows: 0 0 0 This file shows the pixel values 127 0 0 1-6 as distinct recognizable 255 0 0 colors. All other pixel values are 0 127 0 dim gray, except for pixel value 0 255 0 zero which is black. 0 0 255 - HHL 1/24/08 0 0 127 64 64 64 64 64 64 64 64 64 . . . 64 64 64 The difference image showed a few dozen pixels with values of 1 - 6 and a few hundred dim gray pixel values with values somewhere in the range of 7 - 255. All other pixels were black. Is it likely that I did this comparison and analysis incorrectly, or is this difference between integer and float expected? <---<< Does anyone know if the pixel values of the difference image represent the absolute value of the difference between the pixel values of the two compared images as I am conjecturing they do? <---<< Also, am I correct in assuming that arbitrary precision works for formula file fractals? <---<< - Hal Lane ######################### # hallane(a)earthlink.net # ######################### *************************************************

2 1

Re: [Fractint] Fractint version 20.4 patch 7
by Lee H. Skinner 15 Dec '07

15 Dec '07

Jonathan, I had something weird happen. I was generating a 1600x1200 image (Disk video mode, passes=1) in a Windows XP batch file, and doing an automatic save every 10 minutes. After about 40 minutes, I noticed that it did the fourth automatic save after line #1195. A few seconds later, when it finished, the file was completely gone! (I've never seen this happen in DOS.) I suspect it has something to do with the timing and buffering in Windows - the deleting of the old file after line 1195 not being executed by Windows until after the file was saved again at the end of the fractal's generation a few seconds later. But occasionally, when running a batch job, I've noticed that one of the images was missing, and I had to regenerate that image again. This could have resulted from similar behavior when an automatic save was done just before the image would normally complete. Lee

3 5

Visual C++ 2008 Express released
by Richard 20 Nov '07

20 Nov '07

<http://www.microsoft.com/express/download/> The 2008 C++ includes everything needed to build Win32 applications, so you don't need to download the Platform SDK separately anymore. -- "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/>

2 2