Beta Mandelbrot Set Generator For Pandora


Hello all,

Been flying around for the past week so I wasn't able to read/respond.
Thank you all for the great ideas, I think I'll go with the box drawing method, forgot all about it... ;)

Hopefully I'll have something to show later on today...
 
That will work as long as there isn't a small detail in the box, and it gets blocked out because it doesn't touch any of the corners / edges.
That's part of the issue of drawing fractals, is that there's details everywhere. You have to check for them.
 
lulzfish said:
That will work as long as there isn't a small detail in the box, and it gets blocked out because it doesn't touch any of the corners / edges.
That's part of the issue of drawing fractals, is that there's details everywhere. You have to check for them.
Well, the Mandelbrot set is contiguous so the box method can only miss any details if you have an algorithm with horrible aliasing.
 
Last edited by a moderator:
Hello all,

Been playing around with the box idea, I think it's the jet-lag, but I got lost somewhere along the way...
Anyway, just had an epiphany about it, but I have to get some sleep... It'll have to wait till my head clears.

Thanks.
 
lulzfish said:
That will work as long as there isn't a small detail in the box, and it gets blocked out because it doesn't touch any of the corners / edges.
That's part of the issue of drawing fractals, is that there's details everywhere. You have to check for them.
Once you get into the detail of the set there aren't any boundaries that are wholly within any bounding box because that boundary exists around the whole of the set.

Errm? ... Contiguous!

It will fail if a lobe enters and leaves the box between points that you are checking, detail which results in a blocky appeance to lobes. Easy to spot and fixed with more points checked upto the entire perimeter of the box.
 
Last edited by a moderator:
Hello guys, I need your help.
I'm using SDL events for the mouse operations for the zoom box, my problem is that if I press the mouse during the drawing of the image (can get long when you increase the number of iterations and zoom in), the behavior at the end of the drawing is unexpected, it looks like the events are queued but the mouse position isn't, so when it is finally read from the queue, the mouse position being sent for both the start and end of the mouse press is the same and is equal to where the mouse is at the end of the drawing.
How do I flush the event queue so that no keys or mouse actions are kept at the end of drawing?
I tried using SDLPeepEvents but must have been doing something wrong because it didn't work.

Any ideas?
 
Oh and a quick updated version...
Sorry only the win32 version for now, still need to finish getting my Linux back together after buying a new computer (old one died).

Some updates on the drawing method, I like this one better as it gives you more to look at sooner.
Still haven't cracked the whole square drawing thing, it partially works but I still need to figure out why it only partially works and when it does, why it works slower than the current method.

Keys are mostly the same with some minor changes:
mouse left click + drag = Draws zoom box, zooms after button is released
mouse right click = zoom out to previous zoom (also restores max iterations from previous zoom level)
mouse middle click = center
Numpad + = increase iterations by 20
CTRL + = increase iterations by 100
SHIFT + = increase iterations by 500
ALT + = increase iterations by 2000
Numpad * = multiplies the current number of iterations by 2 (up to 50000)
Numpad - = decrease iterations by 20
CTRL - = decrease iterations by 100
SHIFT - = decrease iterations by 500
ALT - = decrease iterations by 2000
Numpad / = divides the current number of iterations by 2 (with a minimum of 100)
s = save BMP file (With x and y start and end values as well as number of iterations in the filename)
r = reset all (goes back to initial zoom and iterations (100 iterations)
c = toggle color palette

Feel free to criticize, that's why I'm posting it, but go easy... ;)
 
Have you tried reading the queue until no messages are waiting (but save the previous one!!)
Then the last message received has the correct mouse position and you ignored all others.

Either that or break out the drawing loop if a message arrives - means having to check the message queue regularly


I'm not in a position to DL at the mo, but I'll check it out later
Cheers!
 
I thought about having a separate thread to deal with the SDL event loop and use event handlers to deal with the different events...
However, my main concern is that it would complicate the logic of the whole thing if I do.

If I understand your suggestion correctly, you mean that when I get out of the drawing loop, next time I read events go through the entire queue and only read the last one, wouldn't that cause problems when I'm not drawing? things like dropped motion events when the mouse moves quickly?

Thanks!
 
gp32rich, thanks! it worked like a charm...
I just added an empty while loop:
Code:
while(SDL_PollEvent(&event))
{}

At the end of every draw cycle. I figured there is no event I care about which happened during the drawing and since I only start looking at the mouse motion events after a button press event, I'm clear with regards to that.

Here's an updated version with this fix as well as a fix for the * and / not re-drawing the set

Enjoy...
 
Love the drawing routine! Looks cool fading in.


But whenever/wherever I try to zoom it just goes black? Well, once ir twice it went orange :/
Ah! Because I was runing straight from the zip it may have been something about creating stdout & stderr


Extract it and it's fine!!

An idea: If I click have it zoom on the mouse (like the early version?) If I drag then zoom area.


Great work!
 
Thanks for the kind words! it is appreciated.

As for the click vs. drag, sounds simple enough, could simply be done by comparing the start and end position of the zoom box... I like it!
I'll do that tonight.

:)
This is what I like about community development, you can get feedback from your users instantaneously without having to send people to the field or have them fill in surveys or countless other ways which make the input garbled...
 
There you go...
Click to zoom the old way, click+drag for the zoom box.
Both cases right click goes back to previous zoom level, up to 100 zooms, which should be more than enough given the limitation on zoom depth imposed by doubles... I'll need to conditionally go to floats beyond a certain zoom level...

Anyway, I fixed a bunch of bugs along the way, let me know if you find anything strange or unexpected!

Thanks...
 
Well, feels like I'm doing it mainly for myself (I'm having loads of fun writing it), so here goes... ;)

I've added a new feature, when you place the mouse anywhere on the Mandelbrot set and press j, the Julia set would be drawn for that place in the Mandelbrot set.
It currently uses the same maximum number of iterations (might remove that later and cap it at a fixed value) and the same coloring scheme.

s for saving a screen shot works for it as well (see attached picture).
Use r to reset back to the Mandelbrot set.

Enjoy...
 
Looking really cool! I do like the idea you have for how to choose between julia sets, I hadn't thought about that. I've been messing with your source code off and on, though it's the really early version. I add gradiants and made zooming in and out more efficient(1/4 of the pixels dont need to be recalculated. Unfortunatly I ran out of time and won't have any to spare for a few months. so I figured I can post what I have if you want to look at it.
 
wow! just took a look at your EXE. Throught the way it looked while calculating the mandelbrot was absolutly awesome! It looks like you do a certain number of iterations max per pass. Something to point out though, is if you increase or decrease the number of iterations then you only need to recalculate the pixels that are not at max iterations. After seeing you had just included an exe I realized that's a lot less work than having to compile and everything, so here's an exe of my work, along with an Image I made messing around with it. The controls are about the same as yours except that G goes into gradiant editor, where A adds a new node, D deletes the selected node, Left click selects nodes and right click deletes them. Hope you have some fun with it, it was my first time making a gradiant so i can't guarantee that it was done right. :p
 
Wow man, nice work!
I really love the whole gradient idea with the gradient editor being a perfect addition, solves the need to come up with color schemes myself, let the user do it... ;)

I hope you don't mind, I intend to take the code you sent and combine yours with mine to include all the cool stuff we both added into one application.
OK with you?

Thanks!
 
Took a look at your code, incredible, I was just looking at it last night thinking of converting it to C++, Guess you just made that part all the more easier... ;)

Thanks!
 
Yes! feel free to use any of my code however you wish. Sorry it isn't commented so well.
 
Back
Top