In article <AANLkTimfg44Qvp5Ynp36-KsBgrRP2p0wP_HESBbVEFB5@mail.gmail.com>, Mihai Dobrescu <msdobrescu@gmail.com> writes:

In my case, it doesn't work on Windows 7 64 bit.

My fork works on Win7 64-bit. Download from here: <http://iteratedynamics.codeplex.com/> -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Paul,

The "open source" was much easier to obtain from 20.04.04 backwards, since one could get the whole .ZIP or .TAR file in a single download. After that, it was split up into its smallest pieces so that you were limited in the options available for downloading the complete source code.

"They" say it was handled this way for support reasons, but I believe it was more about keeping people from having an easy access to the code. Otherwise "they" would still offer a recent .ZIP file version.

Why are you reluctant to use an SVN client to download the complete source code from the SVN repository? What am I missing? Jonathan

Mike,

Thanks for all the suggestions on getting the latest version of the code. When I read there was some tool that help manage the source I guessed that it was not available on a Mac. I kept downloading things until I found a tar.gz file that decompressed into xfractint-20.04p9 so I think I now have the latest source. I don't care which platform it is for since I am only using it to figure out algorithms. Unfortunately, this code looks exactly the same in the area I am having a problem with.

Do a Google search for "mac svn client". The Wikipedia page that compares svn clients includes KDEsvn, Qsvn, Subcommander svnX, WebSVN, and xcode (included with OS X 10.5).

I have been trying to figure out how outside=tdis works. The documentation is vague on outside=tdis and trying to guess the algorithm by comparing images has proven futile. I looked in detail at the code in calcfrac.c and this is what I see. It looks very simple. I pasted together the relevant parts so it is easy to see all together. ... I don't think I implemented anything wrong here. The image I get has a color index that changes much faster than the correct image. Its not off by a fixed number or a ratio or any other good clue as to what is wrong. I was hoping someone here might have an idea of something outside this code that could affect the results. If not, no worries, I will just keep looking.

That's all the right code. How are you determining the bailout? We use the following, or something similar (from fractals.c): int near fpMODbailout(void) { tempsqrx=sqr(new.x); tempsqry=sqr(new.y); magnitude = tempsqrx + tempsqry; if(magnitude >= rqlim) return(1); old = new; return(0); } Where rqlim normally defaults to 4. Jonathan

Mike,

Could there be some difference in the color mapping (like forcing logmap or something) that is forced when tdis is in effect?

There is this section of code in calcfrac.c: /* eliminate negative colors & wrap arounds */ if ((coloriter <= 0 || coloriter > maxit) && outside!=FMOD) { if (save_release < 1961) coloriter = 0; else coloriter = 1; } Then further manipulations occur at plot_pixel: I don't see how any of this could cause what you are seeing. Changes in the iteration count are dependent upon when the bailout occurs for outside pixels. So, if the bailout is occurring in the correct place based upon other outside= options, then there must be an error in how totaldist is being calculated. Is new getting set before the bailout is detected or after? When is old getting set? Jonathan

Mike,

Fracton's code is different and doesn't have new and old as such. I think it does exactly the same thing though. I will just post the code since it is only a few lines. You can scroll back a few messages to see the FractInt equivalent.

double totalDistance;

// Complex numbers

complex lastZ;

complex z;

This means lastZ and z are structures.

lastZ = z; // tdis initialization

I believe this make the structure lastZ point to the structure z. This is different than using: lastZ.r = z.r; lastZ.i = z.i; which moves the contents of z to lastZ, but leaves the pointers pointing to separate structures. Jonathan

I had to know for absolutely sure so I wrote a little test case and used the debugger to check it. typedef struct complexStruct { double r; double i; } complex; complex a,b; complex *pa,*pb; a.r = 1.0; // Initialize the members a.i = 2.0; b.r = 0.0; b.i = 0.0; pa = &a; // Get a pointer to a and b pb = &b; b = a; // Copy a to b pa = &a; // Get a pointer to a and b and verify with debugger. There is no address change. pb = &b; a.r = 0.0; // Just for fun, change a and make sure b doesn't change in debugger a.i = 0.0; // If a and b were the same address now both would change and they don't This verifies that b = a; copies the members instead of setting b's pointer to a's pointer. -- Mike Frazier www.fracton.org

I know there is a reason we

used separate assignments in Fractint.

Maybe they were passed as pointers at some point and the style was maintained. Not sure. I think what I need to do next is to find some low iteration test image that I can check by hand and look at the differences. I really appreciate you looking at stuff. That eliminated a lot of possibilites. -- Mike Frazier www.fracton.org

On Sun, Sep 12, 2010 at 5:24 PM, Jonathan Osuch <osuchj@avalon.net> wrote:

Mike,

...

----- Stuff here to calculate the initial z -----

lastZ = z; // tdis initialization

totalDistance = 0.0;

One other minor problem is that old is not the current value of z (or new for Fractint), it is the value at the start of the iteration that ends with bailing out.

The only time FractInt uses old is to first initialize the lastz. Isn't old at that point the initial value of z before the first iteration? The value of old at the end of iterations isnt used. -- Mike Frazier www.fracton.org

I finally found the problem with the outside=tdis bug in Fracton. Just like the cheesy "who done it" where the true villain isn't visible until the end, there was nothing wrong in the code I posted. The problem was FractInt doesn't use the last z for the tdis calculation when it bails out. In Fracton I did use it. That made a huge difference because the last value is usually one of the biggest. Now all of the FOTD images using outside=tdis work perfectly. Thanks to all who gave assistance. I was stuck thinking I was missing some code. Once that was eliminated, it was only a matter of time before I found the problem. -- Mike Frazier www.fracton.org

You can install the command-line version with macport. That's what

I've used in the past and it works fine.

Good tip. Thanks for the info. -- Mike Frazier www.fracton.org