Whatsdat?

[Antoni]

Click on the thumbnails to enlarge.

Those images were saved from my work-in-progress Mandelbrot viewer. Download mandel.zip

At the moment the program should compile in Win, Linux and DOS

Use:

Code: Select all

mdb x y width

goes directly to a point
you can call it without parameters to get the full view.
When the coordinates appear on the top of the image, the drawing is finished.
At this moment you can:
-select a new zone to zoom dragging with left mouse button
-go to the previous image with a right-click
-press S to save the current image with the name yymmddhhmmss.bmp

I plan to implement a incremental drawing in a thread and a dialog to choose coloring options. This will make it unportable....

Any suggestions?

[rdc]

Very cool. I love Mandelbrot programs. :)

[Dr_D]

Cooool. I really like the third one. The only bad thing is that they remind me of Jark. I miss his work.

[counting_pine]

Really nice. I particularly like the third screenshot. Sadly, I wasn't able to produce it though.
I think you should use PNG instead of JPG for the screenshots. In this case the PNG will probably be larger (unless you select a very simple area) but I don't think JPEG does them justice.

[Antoni]

c.p. You can't reproduce the third thumbnail because it was made with different rendering adjustements, mainly a b/w coloring of the outside of the set. I plan to add a dialog to allow the user to adjust this kind of thing.

Dr D. In fact every idea in my code is from http://www.mrob.com/pub/muency.html
(the best source, with the dullest images!)
Jark used that source too...

[relsoft]

wooooo!!! Looking great!!!!

[Cajaka]

Your screen shots look great, they are much better then the Mandelbrot I made. Great job!

I am not sure if this is what you are referring to by:

incremental drawing in a thread

With my program I tried splitting up the calculations into separate threads, each thread doing a separate chunk of the screen. I ran into a problem with the program freezing most of the time it was ran. to fix it I used code to prevent threads from doing pset as the same time. It ended up not have that much of a performance gain (with or with out the fix). Granted this was my first program to use threads so I may have done something wrong.

Suggestions:
1. Record the zooms done by the user as an animation, with the way your program works it should not be to hard.

2. Screen saver mode: either randomly zoom in or replay a user zoom.

3. Offer different color shifts for the palate. like from color1 -> color2

* 4. Offer the use of the GMP It allows for the user to zoom in further at the cost of some speed.

* 5. If you really want to be adventurous, you could try a making it a small scale distributed computing project out of it.

* I am willing to help with either of these if you need it.

[Sisophon2001]

If you are looking for speed, I made a Mandelbrot/Julia set viewer in FreeBASIC not so long ago. It developed from code D.J.Peters posted, except I changed to SSE assembly routines that I found during an internet search, to make it was fast as possible, increased to 800x600 and used full color. It uses single precision instead of doubles to lever the benefits of SSE. It needs a P III Processor or better to see the speed benefits of SSE.

The code is on my web site if you want to check it out. You are welcome to use anything you find useful.

the code is on this site, as the bottom of the windows programs page.

http://www.freewebs.com/weekendcode/

Garvan

[Antoni]

cajaka:
My plan is to have only two threads, one that calculates and another one for the user interface.
For incremental calculations I mean to calculate up to 100 iteratoins, display what has diverged, then calculate 100 iterations more with what's not diverged. It would give an image fast and refine it indefinitely
while the user is watching, until he chooses another area. This requires a lot of memory to keep all intermediate variables.

Sisophon:
My big problem is my mandelbroot loop is calculating the derivatives at the same time, because some of the coloring is based in a distance estimator (see Munafo's site). I once submitted my code to DJ Peters, he told me the floating point stack is not big enough to keep all the variables I need, so any conversion to assembler would require some not-so fast loads and saves to memory.
I'll check your program...

[Cajaka]

Have you considered a divide and conquer method? You could split the screen into smaller chunks 5X5 or so. Calculate the top right most point in each chunk then move on. It would reduce the number of floating point variables you would need to handle and give the user a bit of a preview of what is to come.

[Antoni]

Yes, divde and conquer is an option too.
In any case I will save all the results of my calculations to an array. When I implement the user controls for the coloring method, I don't want to have to wait for a full recalculation every time I try a set of colors.

[relsoft]

Now if you could do this in realtime and do a fractal zoom like Art of Demomaking did, it would roxxors!!!

[Antoni]

Rel:

My aim is image quality, that's always opposite to speed.
I'm increasing the number of iterations with the zoom factor, and doing more calculations (derivatives) ineach iterations. Can you imagine a zoomer doing that?
D.J Peters coded a very fast fractal zoomer in FB, with an assembler inner loop..

BTW: Did you sorted out hte Fortune's algorithm for the realtime cells demo? ;D

[relsoft]

Nope, didn't get the play with it really. :*(

Link to the fractal zoomer of DJ? No SSE though. this comp does not support SSE2

[Antoni]

The source is listed in this forum, just do a search. And no SSE, it's all floating point.