Kalles Fraktaler 2.7.8 available

[Kalles Fraktaler]

http://www.chillheimer.de/kallesfraktaler/

I have just uploaded a small update, which is only a small bug-fix regarding the bug described by plynch27

...
2. The general zoom sequence render routine fails to continue behaving robotically when it gets to magnifications under 1e10
...
About the second complaint, though, basically, when it finishes calculating the first frame that has a magnification of less than 1e10 ─ i.e. the first frame whose magnification has a single-digit exponent ─ it will, under some conditions, read "R: 5000% and, after that, under all conditions, get caught in an infinite loop before ever drawing to the screen. Sometimes, calling the zoom sequence render routine again without cancelling the render will cause the program to draw the last image to the screen before getting caught in another loop.

Thanks for reporting this.
The issue I tried to solve is described by stardust4ever in this thread:
http://www.fractalforums.com/images-showcase-(rate-my-fractal)/00019-1-14e382-wip/

For me it seems that the easiest way to render a zoom sequence is to begin at the end and render frames "backwards" by zooming out. By doing so, one need to keep track of as little as possible, I think.
But, as I have noticed, the central point that I use as reference has a deep connection in a magic way, which is illustrated by stardust4ever's glitch-issues.
An attempt of a more scientific explanation: The reference and delta orbits collide before what the series approximation give as possible to approximate with the same low threshold that is effective for other locations.
The result is the same kind of patterned glitches that we had so big problems with before Pauldelbrot's glitch detection method.

My solution, and this may be interesting for all of you that are doing perturbation/series approximation renderers, is to put the reference point a bit away from the center. This is inspired by hapf that managed to render Dinkydau's Flake with 3 (manual?) references only. In my implementation I reuse the already rendered pixels in the center from the previous rendered frame, so it should not be visible. Of course it is many times, but hopefully it will only be necessary to add one or two extra references and in sparse areas, where the reference orbit usually is not as high as near the final minibrot.
And I think it is a reasonable prize to pay since stardust4ever's glitches must be solved by re-rendereding the whole frame manually, either with no approximation or by selecting a new main reference a bit away from the center.

The source is also updated. Please remember, if you aren't using Visual Studio, use it mainly as a reference.