Mandelbrot Set Viewer - 3.0.0

It's a bit slow. I think the "abs" function in the calculation uses a square root (since z is complex). You can replace the test with the equivalent "if z*z > 4: break". Square roots are expensive, especially when done up to 255 for hundreds of thousands of points.

also: "Well now, let's try that again, shall we?"

Don't be condescending to the user, man!

Peter, that's because you have a netbook with a horrible processor ;-)
py_beginner, as the mailing list, if you haven't already.

Hi, I try to make the example for python 3.0.1 with pygame2, but I have problems with passing from pygame to pygame2. So if someone know how to do it or already did it please help me

It runs really slow on my computer. even the smallest setting takes a long time, then it crashes

As far as I know, PyGlet and PyGame are similar, but they use different backends for rendering. Also, the coding style required by PyGlet is very different than PyGame--this is one of the problems I'm having.

The rectangles are a nightmare. Hopefully, the next release will use shaders--programs on the GPU--giving realtime zooming and doing away the the rectangles altogether. I've been having issues with the tech. though--big ones. I've tried using PyGlet, PyOpenGL, and both together, but nothing seems to work.

The shading example I'm going from is written in PyGlet, so I'm trying to both implement algorithms, port code to PyGame/PyOpenGL, learn shading language, carry over previous features, and actually make it work.

I have a semi-working example in PyGlet, but it is nowhere near good enough--no zooming, rendering, etc, (though it is very fast).

Nice new release, but it doesn't appear to be any faster. Also if I try to zoom in from bottom to top it messes up. Might want to fix that ;-)

@effeemme:
I really don't think Pyglet and PyGame are similar. I've made a game with Pyglet and I had to do almost everything quite a bit differently.

Well, isn't pyglet almost the same library as pygame but with OpenGL rather than SDL? To keep this a pygame program I'd say using PyOpenGL would be better. Program's awesome by the way!

Version 3.0.0 released!
Shaders hopefully in next version.

To use shaders, I would need to either use PyGlet or PyOpenGL. That's an extra dependency which I would rather not deal with. Oh well. It must be done. Any preference to which?

I've made a lot of improvements here--minor stuff like polished text output, and some larger stuff--and have now come across a practical way to do this real-time. I'll work on implementing that A.S.A.P. The 2400x1600 screenshot there could be rendered in a few seconds at most...

Woot! This is cool. Might want to smooth out the coloring though...

Now is impressive! Good work!

Version 2.0.0 released!

Thanks! You can fix that error by using PyGame 1.8.

The rendered filed doesn't work with Eye of Gnome (eog) either. I examined the file, and it seems to be a tga (Targa) file. Nice app though!

Also, psyco doesn't seem to do much difference on my machine (but I haven't done any extensive tests).

Yes, but it can't zoom in forever. I assume it is in C or some related language. As you say, having a Python program that does it is good. For colours, I'll see about making other colors an option, but I like this monochromatic version too--except on CRT monitors.

have you looked at that fractal viewer yet?
it does realtime zooming with higher precision and has more than the mandelbrot set.
its still good to have a python program that does them though.

Luke, backwards compatibility for me means supporting people who do not have all of the same modules I do. Besides backwards compatibility, there are very few good reasons not to get another module. Short answer, a try/except is probably a good idea, but the real speed solution is to just download psyco in the first place.

Marcel, I think this is an interesting idea, but in the case of the window, it should only take a few seconds to load. If it take more than about 5 seconds, your window is too big. The external render is for when you really want to see something in good detail. It takes me about 10 zooms to get to Python's float limits, I think this screenshot was 5 or 6. That is 5 or 6 renders, so 5 or 6 outputs. If you zoom in to several separate images, reseting the view each time, that is a good deal of render status lines cluttering the console. The other thing is that this would slow the render down. When a high-res. screenshot is rendered, it actually takes more time because of the status reports. This minute delay would become noticeable with the relatively short rendering time for the normal view. Note that while rendering, the program does not update the screen or check for input--this, too, makes it faster.

Indeed, there are messages in the console when the program is saving a image to a file. I wanted to see these messages when the program is drawing the image on the window. This is what I called "render". Just a terminology confusion.

You should modify it to test for psyco, but I don't really see how that's backward compatibility. I don't know of any python distros where psyco is included by default. I know a lot of people who don't use it, actually.
As far as 1.8, you're right, I didn't install the update yet. I should have provided this information as well but I was in a hurry.
To Marcel, there are messages in the console. It even has a percentage of completion of the render.

this is nice
BUT:
it would look better with colours
and realtime zooming is nice and actually possible
look for a program called XaoS it displays fractals like this with infinite zoom (only limitation is that the thing will lose the pattern after a while unless you turn the iterations up which makes it render slower(ie only likited by number of iterations))
its a cool program and does colour YAY

Nice idea!
The images have some kind of pretty shading.
I just wished to view messages like "rendering..." and "render completed" in the console.

As far as backwards compatibility is concerned, I will modify it to test for Psyco.

However, the .png saving issue is probably caused by PyGame 1.7. The solution is to update to 1.8, but, (if you really don't want to do that for some reason), you can change the program to save as .tga

True, I should make backwards compatibility. I shall remember.
As for your error, I am confused myself. For me, it works fine. I also showed it to someone, and it didn't work, then to PyMike, which worked. Curious, that. I'll look into it further.

Also, on Windows, Photoshop, Paint and Image Preview were unable to open the generated PNG from a 300x200 screen to a 1200x800 destination.

I would suggest you modify your code as such:
try:
import psyco
psyco.full()
except ImportError: pass

The draw time is a bit long, perhaps because I don't have psyco. Pretty neat though.

Version 1.0.0 released!