Mandel Machine

[Botond Kósa]

Thanks, so for some reason the palette saved is always the default one. I should have found it while testing, maybe it was too late at night (or early in the morning )
Scrolling speed will be faster in the next version.

[simon.snake]

Thanks, so for some reason the palette saved is always the default one. I should have found it while testing, maybe it was too late at night (or early in the morning )
Scrolling speed will be faster in the next version.

Thanks Botond, you are the man!

[simon.snake]

Lovely image but interesting glitch.  The only way I could save it was by grabbing the window.



I enclose the parameters:

www.needanother.co.uk/uploads/Polished Emerald.mmf

[SeryZone]

PNG saves too long. Botond, for saving PNG use GDI+. It saves All formats as fast. Dinkydau use my program. It very slow, but saves as fast. GDI+

[thegoatboy]

Any news on a 32 bit version?

[3dickulus]

Lovely image but interesting glitch.  The only way I could save it was by grabbing the window.

an interesting glitch indeed, here is that location rendered with SFT...

[Botond Kósa]

Lovely image but interesting glitch.  The only way I could save it was by grabbing the window.

<Quoted Image Removed>

I enclose the parameters:

www.needanother.co.uk/uploads/Polished Emerald.mmf

Thanks, this seems to be the result of the series approximation being too aggressive.

[Botond Kósa]

PNG saves too long. Botond, for saving PNG use GDI+. It saves All formats as fast. Dinkydau use my program. It very slow, but saves as fast. GDI+

I prefer to use Java libraries whenever possible and where performance isn't critical. I found a lib (http://objectplanet.com/pngencoder/) that saves png about 2x faster than the currently used standard lib, so that will be used in the next release.

I have never used GDI+ before. How much faster it is? Could you make a comparison between MM and your program for a large image (4000x3000)? If GDI+ is even faster than PngEncoder, I might use it in the future.

[Botond Kósa]

Any news on a 32 bit version?

It is in the backlog, but with low priority. I plan to implement unlimited zooming and Pauldebrot's ultimate glitch detection first.

[SeryZone]

Botond, It saves too fasts! Faster than libraries!

[Chillheimer]

It is in the backlog, but with low priority. I plan to implement unlimited zooming and Pauldebrot's ultimate glitch detection first.

what about a movie maker?
the true fascination of pertubation method is that you can make movies in reasonable time.. I'm really missing that in mandelmachine..

[Botond Kósa]

Movie maker is also coming, right after the improved glitch detection.

[SeryZone]

3840x2160, same location, same coloring (Histogram):
MM: saves frame for 1.735 sec
My program (GDI+): less than 0.514 sec (timer 'lie', because I press 'save' and close - program closes almost immediately)

But program written on delphi. Therefore - good news! fasm/java programms can save png faster!

P.s.
1) Yours
2) Mine [10.6 MB is 'very large' for hosting site]

[Kalles Fraktaler]

Thanks, this seems to be the result of the series approximation being too aggressive.

I don't think this is due to Series Approximation, KF skips 10288 iterations from SA (2 more than MM) and gives the attached result in a couple of minutes.

Also MM is renders this particular view much slower than KF, 5-10 minutes, so I think there is something else that is problematic with this view in MM.

Edit: KF 37 seconds with 7 references, MM 54 seconds, don't know the number of references. MM should be twice as fast as KF...

[Kalles Fraktaler]

an interesting glitch indeed, here is that location rendered with SFT...

Doesn't look anything like what's rendered in KF or MM.
I think there is a limit in SFT around e400-e450.
I think I had something similar scaling problem with my earlier 64-bit version of KF; in 32-bit I could scale to e600 but the very same code in 64-bit stopped working at e450. Someone suggested that 32-bit program use 80-bit floats in intermediate steps the background.

On my second attempt it did work also in 64-bit KF, zooming to e600 using scaled doubles.
I don't know why, and I'm not going to find out either