Run american fuzzy lop to generate GIF files with the necessary extensions.

Check for compatibility with DOS FRACTINT.

Can it also fuzz parameter files?

legalize[CodePlex]

Take a look at Frame.c. The mouse code works much better now. It does have a problem with not moving far enough, but it at least moves in the right directions.

Take a look at TrackZoom() in mathtool.c (in the win directory). We really should be setting the position of the zoom box (or whatever) to the position of the cursor, instead of adjusting the position of the zoom box as we move the cursor. I think WinFract
only moves the zoom box when the left mouse button is pressed while the cursor is inside the zoom box.

Do you recall what is driving the size of KEYBUFMAX? It is defined in two places (frame.h and wintext.h) as 80. The way the mouse is currently set up, we look for a delta of 8 pixels, and if we have it, we then move the cursor 1 pixel. This accounts for the
slow movement when using the mouse.

When I change the code to move the cursor the correct number of pixels (8 or greater keystrokes), then the buffer overflows (the assertion in frame_add_key_press() is false, which dumps us out).

The image structures used in GIF data blocks use fixed size fields to be compatible with files written out by FRACTINT. Change the types of the fields in the structures to reflect their compatibility size.

Metadata for PNG will be written out as a JSON text comment instead of a machine-specific binary representation. This will allow for bignums in the values.

Do some kind of screen scrape or something to move all the issues from codeplex over to here.

legalize[CodePlex]
with the disk video modes, the tab screen doesn't get cleared

legalize[CodePlex]
If you start with the default Mandelbrot with maxit=150, and open the palette editor using 'e', when you scroll around the image with the cursor key you get some palette entries that exceed 255. Theoretically, with maxit=150, you shouldn't see any palette
entries that exceed 150.

I know, truecolor doesn't care about palettes, but for some features to work, the simulation of a palette has to be accurate. As an aside, to avoid this problem, Xfractint currently doesn't show the palette editor when you are using a truecolor mode.

If there is a problem with the getcolor() routine returning a value in the appropriate range, this will also confuse boundary tracing.

legalize[CodePlex]
with the disk video modes, the tab screen doesn't get cleared

legalize[CodePlex]
For backwards compatibility, we need to try to match up the new key stroke mapping to video modes to make them similar to the old key stroke mapping. For example, SF5, SF6, and SF7, should NOT be disk video modes and they should correspond to 640x480,
800x600, and 1024x768, respectively. There may be others that are needed, but these three are critical.

There are PARs that break because they require a specific video resolution. The music ones, for example. I know, it doesn't matter now, but it will later. And, it's far easier to change it now.

I got fairly far building this, but not far enough :/

$ make
Scanning dependencies of target hc
[  1%] Building CXX object CMakeFiles/hc.dir/hc/hc.cpp.o
[  2%] Building CXX object CMakeFiles/hc.dir/hc/helpcom.cpp.o
[  4%] Building CXX object CMakeFiles/hc.dir/unix/unix.cpp.o
Linking CXX executable hc
[  4%] Built target hc
[  5%] Generating ../headers/helpdefs.h, ../home/fractint.hlp
HC - FRACTINT Help Compiler.

Compiling: help.src
Making hot-links.
Paginating online help.
Paginating document.
Writing: helpdefs.h
   Note: FRACTINT must be re-compiled.
Writing: fractint.hlp
Scanning dependencies of target id
[  7%] Building CXX object CMakeFiles/id.dir/common/3d.cpp.o
[  8%] Building CXX object CMakeFiles/id.dir/common/line3d.cpp.o
[ 10%] Building CXX object CMakeFiles/id.dir/common/plot3d.cpp.o
[ 11%] Building CXX object CMakeFiles/id.dir/common/calcfrac.cpp.o
[ 12%] Building CXX object CMakeFiles/id.dir/common/calcmand.cpp.o
[ 14%] Building CXX object CMakeFiles/id.dir/common/calmanfp.cpp.o
[ 15%] Building CXX object CMakeFiles/id.dir/common/fracsuba.cpp.o
[ 17%] Building CXX object CMakeFiles/id.dir/common/fracsubr.cpp.o
[ 18%] Building CXX object CMakeFiles/id.dir/common/fractalb.cpp.o
[ 20%] Building CXX object CMakeFiles/id.dir/common/fractalp.cpp.o
[ 21%] Building CXX object CMakeFiles/id.dir/common/fractals.cpp.o
[ 22%] Building CXX object CMakeFiles/id.dir/common/frasetup.cpp.o
[ 24%] Building CXX object CMakeFiles/id.dir/common/soi.cpp.o
[ 25%] Building CXX object CMakeFiles/id.dir/common/soi1.cpp.o
[ 27%] Building CXX object CMakeFiles/id.dir/common/testpt.cpp.o
[ 28%] Building CXX object CMakeFiles/id.dir/common/ant.cpp.o
[ 30%] Building CXX object CMakeFiles/id.dir/common/jb.cpp.o
[ 31%] Building CXX object CMakeFiles/id.dir/common/lorenz.cpp.o
[ 32%] Building CXX object CMakeFiles/id.dir/common/lsys.cpp.o
[ 34%] Building CXX object CMakeFiles/id.dir/common/lsysf.cpp.o
[ 35%] Building CXX object CMakeFiles/id.dir/common/miscfrac.cpp.o
[ 37%] Building CXX object CMakeFiles/id.dir/common/cmdfiles.cpp.o
[ 38%] Building CXX object CMakeFiles/id.dir/common/decoder.cpp.o
[ 40%] Building CXX object CMakeFiles/id.dir/common/diskvid.cpp.o
[ 41%] Building CXX object CMakeFiles/id.dir/common/editpal.cpp.o
[ 42%] Building CXX object CMakeFiles/id.dir/common/encoder.cpp.o
[ 44%] Building CXX object CMakeFiles/id.dir/common/evolve.cpp.o
[ 45%] Building CXX object CMakeFiles/id.dir/common/gifview.cpp.o
[ 47%] Building CXX object CMakeFiles/id.dir/common/loadfdos.cpp.o
[ 48%] Building CXX object CMakeFiles/id.dir/common/loadfile.cpp.o
[ 50%] Building CXX object CMakeFiles/id.dir/common/loadmap.cpp.o
[ 51%] Building CXX object CMakeFiles/id.dir/common/parser.cpp.o
[ 52%] Building CXX object CMakeFiles/id.dir/common/parserfp.cpp.o
[ 54%] Building CXX object CMakeFiles/id.dir/common/rotate.cpp.o
[ 55%] Building CXX object CMakeFiles/id.dir/common/slideshw.cpp.o
[ 57%] Building CXX object CMakeFiles/id.dir/common/stereo.cpp.o
[ 58%] Building CXX object CMakeFiles/id.dir/common/bigflt.cpp.o
[ 60%] Building CXX object CMakeFiles/id.dir/common/biginit.cpp.o
[ 61%] Building CXX object CMakeFiles/id.dir/common/bignum.cpp.o
[ 62%] Building CXX object CMakeFiles/id.dir/common/bignumc.cpp.o
[ 64%] Building CXX object CMakeFiles/id.dir/common/fpu087.cpp.o
[ 65%] Building CXX object CMakeFiles/id.dir/common/hcmplx.cpp.o
[ 67%] Building CXX object CMakeFiles/id.dir/common/mpmath_c.cpp.o
[ 68%] Building CXX object CMakeFiles/id.dir/common/drivers.cpp.o
[ 70%] Building CXX object CMakeFiles/id.dir/common/memory.cpp.o
[ 71%] Building CXX object CMakeFiles/id.dir/common/fractint.cpp.o
[ 72%] Building CXX object CMakeFiles/id.dir/common/framain2.cpp.o
[ 74%] Building CXX object CMakeFiles/id.dir/common/help.cpp.o
[ 75%] Building CXX object CMakeFiles/id.dir/hc/helpcom.cpp.o
[ 77%] Building CXX object CMakeFiles/id.dir/common/intro.cpp.o
[ 78%] Building CXX object CMakeFiles/id.dir/common/jiim.cpp.o
[ 80%] Building CXX object CMakeFiles/id.dir/common/miscovl.cpp.o
[ 81%] Building CXX object CMakeFiles/id.dir/common/miscres.cpp.o
[ 82%] Building CXX object CMakeFiles/id.dir/common/prompts1.cpp.o
[ 84%] Building CXX object CMakeFiles/id.dir/common/prompts2.cpp.o
[ 85%] Building CXX object CMakeFiles/id.dir/common/realdos.cpp.o
[ 87%] Building CXX object CMakeFiles/id.dir/common/zoom.cpp.o
[ 88%] Building CXX object CMakeFiles/id.dir/unix/d_x11.cpp.o
/home/stu/projects/external/iterated-dynamics/unix/d_x11.cpp: In function ‘void x11_buzzer(Driver*, buzzer_codes)’:
/home/stu/projects/external/iterated-dynamics/unix/d_x11.cpp:2876:45: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘buzzer_codes’ [-Werror=format=]
     fprintf(stderr, "x11_buzzer(%d)\n", kind);
                                             ^
cc1plus: all warnings being treated as errors
CMakeFiles/id.dir/build.make:1381: recipe for target 'CMakeFiles/id.dir/unix/d_x11.cpp.o' failed
make[2]: *** [CMakeFiles/id.dir/unix/d_x11.cpp.o] Error 1
CMakeFiles/Makefile2:95: recipe for target 'CMakeFiles/id.dir/all' failed
make[1]: *** [CMakeFiles/id.dir/all] Error 2
Makefile:75: recipe for target 'all' failed
make: *** [all] Error 2

24365 Segmentation fault: 11 Debug/hc /c

legalize[CodePlex]

Take a look at Frame.c. The mouse code works much better now. It does have a problem with not moving far enough, but it at least moves in the right directions.

Take a look at TrackZoom() in mathtool.c (in the win directory). We really should be setting the position of the zoom box (or whatever) to the position of the cursor, instead of adjusting the position of the zoom box as we move the cursor. I think WinFract
only moves the zoom box when the left mouse button is pressed while the cursor is inside the zoom box.

Do you recall what is driving the size of KEYBUFMAX? It is defined in two places (frame.h and wintext.h) as 80. The way the mouse is currently set up, we look for a delta of 8 pixels, and if we have it, we then move the cursor 1 pixel. This accounts for the
slow movement when using the mouse.

When I change the code to move the cursor the correct number of pixels (8 or greater keystrokes), then the buffer overflows (the assertion in frame_add_key_press() is false, which dumps us out).

Albrechtx[CodePlex]
Hi Richard,

maybe you have read my mails about multifractals.
As preliminary versions run well with fractint for
windows I wonder, if it is possible to increase
the size of the internal buffer, as I get a
quotBuffer overrunquot error if I try to load
multifractal_10.

Sincerely, Albrecht

Create a markdown file in the top-level that describes how to contribute, similar to the contributing guide for exercism.

The codeplex project had GPL v2, this one could have GPL v3.

The readme is stale. Merge contents from fractint/fractsrc.doc and existing readme files into a single ReadMe.md

Use shields.io tags in README for build status, etc.

Thought I'd check in and see how things are going, but didn't manage to compile.. this time it's toupper causing an issue.

This is on Ubuntu 20.04 on x86_64.

make -j8
[  2%] Built target helpcom
[  4%] Building CXX object unix/CMakeFiles/os_hc.dir/unix.cpp.o
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp: In function ‘int stricmp(const char*, const char*)’:
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp:68:29: error: ‘tolower’ is not a member of ‘std’
   68 |         const int c1 = std::tolower(*s1++);
      |                             ^~~~~~~
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp:69:29: error: ‘tolower’ is not a member of ‘std’
   69 |         const int c2 = std::tolower(*s2++);
      |                             ^~~~~~~
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp: In function ‘int strnicmp(const char*, const char*, int)’:
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp:99:29: error: ‘tolower’ is not a member of ‘std’
   99 |         const int c1 = std::tolower(*s1++);
      |                             ^~~~~~~
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp:100:29: error: ‘tolower’ is not a member of ‘std’
  100 |         const int c2 = std::tolower(*s2++);
      |                             ^~~~~~~
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp: In function ‘char* strlwr(char*)’:
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp:134:22: error: ‘tolower’ is not a member of ‘std’
  134 |         *sptr = std::tolower(*sptr);
      |                      ^~~~~~~
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp: In function ‘char* strupr(char*)’:
/home/stu/projects/external/iterated-dynamics/unix/unix.cpp:158:22: error: ‘toupper’ is not a member of ‘std’; did you mean ‘tuple’?
  158 |         *sptr = std::toupper(*sptr);
      |                      ^~~~~~~
      |                      tuple
make[2]: *** [unix/CMakeFiles/os_hc.dir/build.make:63: unix/CMakeFiles/os_hc.dir/unix.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:201: unix/CMakeFiles/os_hc.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

This parameter describes the video mode on exit. This is no longer relevant.

legalize[CodePlex]
From: [email protected] Anyone who has seen my deep zoom viddies has noticed the occasional jerk frames. I do not know what causes this, but it seems that fractint reads the
PAR file wrong and scrambles the numbers for some reason. Thus with off-parameters or coordinates the image(s) are a bit distorted or off center.

Now, attempting a zoom animation of Muth FOTD 3_15_07 I have encountered this again, only the error occurs in the magnification number - the first time I have seen this! I need someone to verify that I am not hallucinating. Attached are PARS for 3 images in
the sequence.

You clearly see the mag factors are 1.35e+12, 1.37e+12, and 1.40e+12 respectively. The first and last render correctly, but the middle one ends up with a mag factor of 6.88e11 !

Why is this and where does the number come from? It is totally reproduceable too!

You dont have to render the entire image (they take awhile). Just a couple lines then hit TAB key to see the numbers.

A clue might be that this only occurs in the last third of the sequence - beyond e12. There are so many messed up frames an otherwize awesome zoom is not now good for posting!

Whoever solves the mystery gets a free DVD!

Enhance the help compiler to output an HTML version of the help and use this to populate the github pages branch.

• single HTML page with entire text document
• multiple HTML pages with one page per printed page in text document
• page number cross-links become HTML links

Hal9009[CodePlex]
Every fractal rendered by Fractint for Windows beta 5 is too wide in the X direction

by a factor of 1.3333...

Thus, a reduction of the quotX Magnification Factorquot (ltzgt, ltF6gt) of 0.75 must be entered

for every fractal to have its aspect ratio be correct. Note that even the Mandelbrot

set initially calculated by default has had its quotX Magnification Factorquot set to 0.75

in order to have its appearance correct.

I attempt to calculate every one of Jim Muth's FOTD fractals with beta 5 (except
Mandelbrot-BC3 images) and this aspect ratio problem has been present
for every fractal calculated.

An apparent side effect of the above problem is that when one rotates an image (with the

aspect ratio set correctly) 90 degrees (without resizing it), is that the aspect ratio

of the rotated image becomes incorrect and must be corrected by again setting an
quotX Magnification Factorquot of 0.75.

Also, the dotted quotzoom boxquot rectangle aspect ratio appears to be incorrect during and after

rotations. (This is more noticable when the quotzoom boxquot is smaller than its full size.)

Try rotating the default Mandelbrot set 90 degrees to see the resulting aspect ratio

error in the fractal that's created:

ltPageUpgt
ltctrlgt+ltKeypad+gt
ltctrlgt+ltKeypad+gt
ltctrlgt+ltKeypad+gt
etc., ... until your rotate the zoom box 90 degrees.
ltEntergt

Hal Lane

Things that need changing:

• Iterated Dynamics, not FRACTINT
• Primary author is Richard Thomson
• Move Tim Wegner and Johnathan Osuch to scrolling list

Albrechtx[CodePlex]
Hi Richard,

maybe you have read my mails about multifractals.
As preliminary versions run well with fractint for
windows I wonder, if it is possible to increase
the size of the internal buffer, as I get a
quotBuffer overrunquot error if I try to load
multifractal_10.

Sincerely, Albrecht

Hal9009[CodePlex]
Every fractal rendered by Fractint for Windows beta 5 is too wide in the X direction by a factor of 1.3333...

Thus, a reduction of the "X Magnification Factor" (z, F6) of 0.75 must be entered for every fractal to have its aspect ratio be correct. Note that even the Mandelbrot set initially calculated by default has had its "X Magnification Factor" set to 0.75 in order to have its appearance correct.

I attempt to calculate every one of Jim Muth's FOTD fractals with beta 5 (except Mandelbrot-BC3 images) and this aspect ratio problem has been present for every fractal calculated.

An apparent side effect of the above problem is that when one rotates an image (with the aspect ratio set correctly) 90 degrees (without resizing it), is that the aspect ratio of the rotated image becomes incorrect and must be corrected by again setting an "X Magnification Factor" of 0.75.

Also, the dotted "zoom box" rectangle aspect ratio appears to be incorrect during and after rotations. (This is more noticeable when the "zoom box" is smaller than its full size.)

Try rotating the default Mandelbrot set 90 degrees to see the resulting aspect ratio error in the fractal that's created:

PageUp
Ctrl-+ Keypad +
Ctrl-+ Keypad +
etc., ... until your rotate the zoom box 90 degrees.

Hal Lane

legalize[CodePlex]
The attached formula doesn't render properly compared to DOS fractint.

legalize[CodePlex]
If you start with the default Mandelbrot with maxit=150, and open the palette editor using 'e', when you scroll around the image with the cursor key you get some palette entries that exceed 255. Theoretically, with maxit=150, you shouldn't see any palette
entries that exceed 150.

I know, truecolor doesn't care about palettes, but for some features to work, the simulation of a palette has to be accurate. As an aside, to avoid this problem, Xfractint currently doesn't show the palette editor when you are using a truecolor mode.

If there is a problem with the getcolor() routine returning a value in the appropriate range, this will also confuse boundary tracing.

syntopia blog

Include what you use keeps you honest about making sure you include the headers for the things you use and aren't obtaining the declarations accidentally via transitive inclusion.

legalize[CodePlex]
Jim's FOTD for 12-08-07 'Straight Forward' was a bit late appearing on Lee's

site so I thought I'd have a look at it, (a rating of 9 tends to make the
wait more painful!)

In Fractint for Windows it looks nothing like the posted image so I used the
DOS version to check that I hadn't screwed the par. That resulted in the
same image as Lee posted.

Simon_Snake[CodePlex]
In the formula parser, using fn1(xx) and setting the function to ident gives different results on the dos fractint compared to beta 5. It is as if the parser is treating the parameter as just x, not xx.

This can be demonstrated here:

http://www.fractalforums.com/index.php?topic=11980.0

"Disk Video" was implemented to render arbitrarily large images from a parameter set in a non-interactive manner. Replace "disk video" with a console-based offline rendering utility that does the same thing.

This probably isn't feasible until the UI and rendering code is more cleanly separated.

Features:

• By default, it doesn't print anything, but command-line switches enable increasing verbosity for very long renderings.
• Ctrl+C (SIGINT on unix) interrupts the rendering, but saves the state in the image file for later resuming.
• Partially completed image file can be resumed.

The CMakeLists.txt needs to run the resource compiler and link the resources into the Win32 executable.

Simon_Snake[CodePlex]
In the formula parser, using fn1(xx) and setting the function to ident gives different results on the dos fractint compared to beta 5. It is as if the parser is treating the parameter as just x, not xx.

This can be demonstrated here:

http://www.fractalforums.com/index.php?topic=11980.0

legalize[CodePlex]
For backwards compatibility, we need to try to match up the new key stroke mapping to video modes to make them similar to the old key stroke mapping. For example, SF5, SF6, and SF7, should NOT be disk video modes and they should correspond to 640x480,
800x600, and 1024x768, respectively. There may be others that are needed, but these three are critical.

There are PARs that break because they require a specific video resolution. The music ones, for example. I know, it doesn't matter now, but it will later. And, it's far easier to change it now.

The XFRACT conditionally compiled endianness swapping (e.g. decode_evolver_info) assumes that unix machines are the ones that need the swapping. With linux distributions on x86, this is not the case. The condition should be replaced with a compile-time test that checks endianness and sets whether or not to call the decoder code.

We can build on macOS using github runners; add a macOS build to ensure that things still work as expected there (shouldn't be any different from linux).

It wasn't clear in the Readme how to compile on a Mac/Linux machine.

legalize[CodePlex]
Jim's FOTD for 12-08-07 'Straight Forward' was a bit late appearing on Lee's

site so I thought I'd have a look at it, (a rating of 9 tends to make the
wait more painful!)

In Fractint for Windows it looks nothing like the posted image so I used the
DOS version to check that I hadn't screwed the par. That resulted in the
same image as Lee posted.

legalize[CodePlex]
The attached formula doesn't render properly compared to DOS fractint.

legalize[CodePlex]
From: [email protected] Anyone who has seen my deep zoom viddies has noticed the occasional jerk frames. I do not know what causes this, but it seems that fractint reads the
PAR file wrong and scrambles the numbers for some reason. Thus with off-parameters or coordinates the image(s) are a bit distorted or off center.

Now, attempting a zoom animation of Muth FOTD 3_15_07 I have encountered this again, only the error occurs in the magnification number - the first time I have seen this! I need someone to verify that I am not hallucinating. Attached are PARS for 3 images in
the sequence.

You clearly see the mag factors are 1.35e+12, 1.37e+12, and 1.40e+12 respectively. The first and last render correctly, but the middle one ends up with a mag factor of 6.88e11 !

Why is this and where does the number come from? It is totally reproduceable too!

You dont have to render the entire image (they take awhile). Just a couple lines then hit TAB key to see the numbers.

A clue might be that this only occurs in the last third of the sequence - beyond e12. There are so many messed up frames an otherwize awesome zoom is not now good for posting!

Whoever solves the mystery gets a free DVD!

Hal9009[CodePlex]
Richard, I've discovered one reason why certain of Jim Muth's
FOTDs do not render in Fractint for Windows beta 5 -- and
a temporary workaround for this particular problem.

E.g.: Jim's original PAR file for his FOTD for Aug 5, 2013
(pasted below) has one of its parameters specified as:

/1000000000000/

The fractal renders as an all black screen with this
original parameter specification.

When I change the format of the value (not the
numerical value itself) to:

/1.0e+012/

then the fractal is rendered as expected, and appears
like the image on Jim's web page:
http://www.crosscanpuzzles.com/Aug13/080513.html

My workaround is included below as a parameter set named: Anti-Minibrot-2

START PARAMETER FILE======================================= 

Anti-Minibrot { ; time=0:01:30.00 F130805.PAR 
; F130805.PAR Fails to be rendered in Fint4WinB5 
reset=2004 type=formula formulafile=basicer.frm 
formulaname=FinDivBrot-2 function=recip passes=1 
center-mag=+0.3007751526060126/-0.0201684395807311\ 
/2.544126e+010/1/47.5/0 params=5/1000000000000/0/0 
float=y maxiter=1500 inside=0 periodicity=6 
colors=000bf_ZgZUhYQiXLjWHkVClU8mT4nW5kY5i_5gb5ed\ 
5bf5i6Zk6Xm6Up6Sr6Qt6Oq8Mn9LlAJiCIfDGdEFaFDZHCXIA\ 
UJ9RK7PM6MN4JO3HP2GU9GYFGaMGeSGiZGmdGqkGuqGywEqoI9\ 
8CihAa8VU6NM4FF277LMGIIDFFBCC9996664332yHnlDcAUO\ 
6KC3Ay0Js0Hn0Fi0Ed0C_0BV09P07K06F04A03501tUVSFFnXU\ 
jURfSPcPN_NLWLJTIHPGFLECIBAE98A767443225Yg4Vd4Ta4R\ 
Z3PX3NU3LR2JO2HM2EJ1CG1AD18B0680450223Sf2MY1GP1BH0\ 
58aKtYVSHFQ3pK2eF1VA1L50AwUcrRnPYjNVeLSaJPYHMUFK\ 
PCHLAEH8BC68845422SeLVRELI7A9ovKkrIhnHejGbgFZcDW_\ 
CTXBQTAMP8JM7GI6DE59B3672331lqNW_FGI7uSppQllOhhMdd\ 
KIYXGUTEQOCMKAIG8FC6B847zzztt0ee0SS0EE0EoKCgHAE\ 
8TB6M84E52728gA7c96_86X75T64P54M53I42E32B2171030MC\ 
WKATI9QG8NE7KC6HA5E84B638425212D8BB799688566454343\ 
22111bjfZfbWbZTZWQVSMRPJNLGJHDFE9BA677333r1Aj08b07\ 
V05N04F02701Gunjo0mVdDkmBfhAac9XZ7SU6OP5JK3EF29A14\ 
5W0CS0AP09M08J07G06C04903 } 

Anti-Minibrot-2 { ;t=1:30 F130805.PAR Fixd: Fint4WinB5 
; F130805.PAR 
; 
; This fix repairs an all black image in 
; Fractint for Windows beta 5 (Iterated Dynamics) 
; 
; quotFixquot: changed parameter format from: 
; /1000000000000/ to: /1.0e+012/ 
; 
reset=2004 type=formula formulafile=basicer.frm 
formulaname=FinDivBrot-2 function=recip passes=1 
center-mag=+0.3007751526060126/-0.0201684395807311\ 
/2.544126e+010/1/47.5/0 params=5/1.0e+012/0/0 
float=y maxiter=1500 inside=0 periodicity=6 
colors=000bf_ZgZUhYQiXLjWHkVClU8mT4nW5kY5i_5gb5ed\ 
5bf5i6Zk6Xm6Up6Sr6Qt6Oq8Mn9LlAJiCIfDGdEFaFDZHCXIA\ 
UJ9RK7PM6MN4JO3HP2GU9GYFGaMGeSGiZGmdGqkGuqGywEqoI9\ 
8CihAa8VU6NM4FF277LMGIIDFFBCC9996664332yHnlDcAUO\ 
6KC3Ay0Js0Hn0Fi0Ed0C_0BV09P07K06F04A03501tUVSFFnXU\ 
jURfSPcPN_NLWLJTIHPGFLECIBAE98A767443225Yg4Vd4Ta4R\ 
Z3PX3NU3LR2JO2HM2EJ1CG1AD18B0680450223Sf2MY1GP1BH0\ 
58aKtYVSHFQ3pK2eF1VA1L50AwUcrRnPYjNVeLSaJPYHMUFK\ 
PCHLAEH8BC68845422SeLVRELI7A9ovKkrIhnHejGbgFZcDW_\ 
CTXBQTAMP8JM7GI6DE59B3672331lqNW_FGI7uSppQllOhhMdd\ 
KIYXGUTEQOCMKAIG8FC6B847zzztt0ee0SS0EE0EoKCgHAE\ 
8TB6M84E52728gA7c96_86X75T64P54M53I42E32B2171030MC\ 
WKATI9QG8NE7KC6HA5E84B638425212D8BB799688566454343\ 
22111bjfZfbWbZTZWQVSMRPJNLGJHDFE9BA677333r1Aj08b07\ 
V05N04F02701Gunjo0mVdDkmBfhAac9XZ7SU6OP5JK3EF29A14\ 
5W0CS0AP09M08J07G06C04903 } 

frm:FinDivBrot-2 { ; Jim Muth 
z=(0,0), c=pixel, a=-(real(p1)-2), 
esc=(real(p2)+16), b=imag(p1): 
z=(b)(zz*fn1(z^(a)+b))+c 
|z| lt esc } 

END PARAMETER FILE=========================================