DIY Mandelbrot

Squagnut

There's a gnu in my squat
Messages
15,749
Reaction score
481
Location
Cumbria
I'm sure there are folk on here who can easily do the sums and code for a Mandelbrot generator. I've used plenty of fractal progs but I'm crap at making that sort of thing, but I like to use a bit of bloodymindedness and I wanted to make one. Against this is the fact that the only computer language I ever knew is BASIC, which I messed about with on BBC micros years ago. But the interwebs has the goods! There's a free (trial) version of BBC Basic for Windows out there, and I stumbled across a printout of a Mandelbrot generator program from this old page. Yay, I now had the tricky part done (done for me, that is. Heh, I know the maths, just not how to implement it).

It's not a great prog, but (after OCRing and correcting the code - I'll post it here if anyone's interested) it does give a result which is recognisably a Mandelbrot:

Mandelbrot-0.gif


So I tweaked the parameters and reset the page size (the prog was asking to be hacked) and got a thing that looks like this:

Mandelbrot-02.gif


which shows a bit more promise. More tweaking and finally beginning to understand what the hell I'm doing and getting some idea of what imaginary, real and complex numbers are, and I found I could zoom in and navigate a bit about the Mandelbrot set.

Mandelbrot-03.gif


The prog still needs working on before it's an easy tool rather than a lot of tweaking variables in the code, but there's stuff like this to be had, which sort of boggles my mind considering it's a very short and simple piece of code which does the work, and the trial version of basic is a very limited software environment (apologies for outsize images):

Mandelbrot-07.gif


Mandelbrot-05.gif


Mandelbrot-08.gif


So, erm ... just thought I'd share.
 
really like that last pic :Smile3:
 
good work, you might want to look into python which is supposedly a very easy language to pick up and also free.

Hmm - I've heard of Python. I'll think about it, but I like the challenge of doing stuff on simple/old kit and software. I suspect I'm too long in the tooth to be bothered with learning coding properly.

really like that last pic :Smile3:

Yes, it's my favourite one so far. It took three hours to draw! That's because there's a lot of black in it. The black that is the base colour - i.e. in the centre of the Mandelbrot shape, rather than the black that appears in the swirly bits - depicts points which are in the Mandelbrot Set, and these take longer to compute than the coloury bits. More black = longer to draw.

But it's not a spectator sport! I'll happily share the code I'm using and what I know about it so far if folk want to make their own.
 
Hmm - I've heard of Python. I'll think about it, but I like the challenge of doing stuff on simple/old kit and software. I suspect I'm too long in the tooth to be bothered with learning coding properly.

well if you know basic you already understand the concepts of coding, just some syntax you'll have to learn. again i've just been told python is simple, it may confuse the shit out of you. i'm currently trying to learn django which uses python and learning that is confusing me plenty.
 
I'll happily share the code I'm using and what I know about it so far if folk want to make their own.

yes please phil I'd like to port it to c# and have a play with it, maybe something animated
 
Funny you should post this. I've been thinking about making a zoomable mandelbrot generator in C++.
I've been a bit distracted by MatLab and the possibilities it seems to present. I dont quite understand it well enough yet but give me a few weeks and I should have some interesting images to bring back here.

As long as you understand complex numbers (and how to handle them in various languages), the equation 'Z=Z*Z+C' and how to check if / when it runs off to infinity it shouldn't be to difficult to do in any language.
 
Okeydokey - I gave a link to a page with the code in the first post, and that, minus line numbers, looks more or less like this:

rem MANDELBROT
mode 1
rem MAXIMUM X AND Y PICTURE COORDINATES
MAX%=200 : rem MAX%<700
vdu 23,1,0;0;0;0; : rem Disable cursor
vdu19,2,2,0,0,0 : rem GREEN for YELLOW
rem define DISPLAY WINDOW AT CENTRE OF SCREEN
vdu24,640-MAX%/2;512-MAX%/2;640+MAX%/2;512+MAX%/2;
vdu29,640-MAX%/2;512-MAX%/2;
rem DEFINE TEXT DISPLAY AT BOTTOM OF SCREEN
vdu28,0,31,39,28 . . .
rem DEFINE ANGLE AT BOTTOM LEFT. ANGLE=AngleR+AngleIi
AngleR=-2 : AngleI=-1.25
rem LENGTH of SIDE IN COMPLEX SURFACE
Side=2.5
rem DISTANCE BETWEEN TWO POINTS IN COMPLEX SURFACE
Distance=Side/MAX%
T=time

rem CALCULATION
for Y%=0 to MAX% step 4
for X%=0 to MAX% step 4
rem C=CR+CIi
CR=X%*Distance+AngleR : CI=Y%*Distance+AngleI
rem Z=ZR+ZIi. Start value for Z equals C
ZR=CR : ZI=CI
Iteration%=0
rem Z=Z^2+C where Z^2=ZR^2-ZI^2+(2*ZR*ZI)i
repeat
A=ZR^2 : B=ZI^2 : Length=sqr(A+B) : ZI=2*ZR*ZI+CI : ZR=A-B+CR
Iteration%=Iteration%+1
until Length>2 or Iteration%>(16-1) : rem: set this to: (n*16)-1
gcol0,Iteration%mod4
plot X%,Y%
next
cls
print"TlME" (time-T)/100" S"
next
C&P that into basic and you get the first image I posted.

The variables AngleR and AngleI mark the bottom-left origin of the actual image, in terms of their coordinates in the Mandelbrot set's own internal logic. There is more than one origin to consider! I think that to find the origin, set Angle(x) to -2.5 and Side to 5. This gives a square, and quartering it intersects at 0,0 on the real and imaginary axes - it looks like this:

Origin2.gif


... while the other origin is at the bottom-left of the square, in the computer's internal logic. But someone please correct me if I'm wrong, tho' this is what happens on the same scale with Angle(x) set to 0:

Origin.gif


Side is an important variable too - the lower Side is, the more magnification - some of the OP pix had Side set to 0.000001 or so. But hack at will - I'd love to see it translated to C. And I want it animated! But I can't find a simple palette cycling thingybob. That was bloody easy on the Amiga! Blah. If you need it, the BBCBasic4Windows manual is here.

Obviously, under the Rem Calculation bit, there's the gubbins that does the Z=Z²+C magic and sets the colours (the GCOL statement). I would post the code I'm using now, but it's all geared to BB4W, so if you're not using that (I just like BBC BASIC, ok? It's my comfort zone) then there's probably not much point in posting it, but there should be enough here to adapt it all from (first things to do are take away the "step 4" line in the for...next loops, and increase MAX% to make it all bigger...). Hell, if I can do it then I'm sure someone who actually knows what they're doing can.

Wow, Seye - a zoomable Mandelbrot generator? Would that be as resource-hungry as it sounds? Or have I misunderstood? Cuz they take silly time to draw, but I guess a language not as high-level as what I'm using would be way speedier.

Related cake-oriented fact: "Mandelbrot" is German for almond bread, so these too are mandelbrots:


Looks good, tho' I doubt they have fractal properties. Not that I look for that in a cake (I felt this thread was heavy on the maths and psychedelia and light on cake. I hope this imbalance has now been redressed).

As long as you understand complex numbers (and how to handle them in various languages), the equation 'Z=Z*Z+C' and how to check if / when it runs off to infinity it shouldn't be to difficult to do in any language.

Heheh, I'm unashamedly doing baby steps here, but I have some understanding of complex numbers (the Wiki page I linked to presents complex numbers and how to use them in a pretty accessible way. I was very taken with why i was invented - as a way to force a solution to x²+1=0). Certainly it helps to develop this prog - anyone can drag a mouse, but seeing the Mandelbrot set in terms of numbers rather than (or as well as) pretty patterns is educational/interesting/fun enough.

Of course, the aim is to make it zoomable. Ho hum. More bloodymindedness needed.
 

Attachments

  • img_8221.JPG
    img_8221.JPG
    38.1 KB · Views: 6
Complex numbers are a wonderful thing. When they are first explained to you it makes no sense at all but as soon as you start using them they become infinitely valuable. It all feels a bit like this at first though...
e_to_the_pi_times_i.png


Making the generator zoomable could be really resource intensive unless you define the resolution of the image as a variable (in the same way google maps does). That way you can zoom around to find something that looks interesting and then increase the resolution of the image to get the detail. Of course some of the most beautiful detail is in parts that would look black at low resolution so it will always be a bit hit and miss.

If it was redone in any C variant you would have access to the full modern hex colour pallete. I'm not sure what exists in basic (the last time I wrote in basic was on a C64) but even Pascal (pre delphi) only had 16 built in colours including black and white. It shouldn't be too hard to generate a calculation that links the colour of a pixel to the number in hex that equates to a colour. That would give smooth changes in colour at boundaries.

One of my modules next semester involves coding simulations of complex feedback systems in MatLab. We start by coding fractals (of all kinds) so I should have plenty to bring to this discussion shortly. I might have a go at doing it in C++ before christmas. I have very little else to do.

If you want to know anything abut the maths feel free to ask. That is something that I can definitely help with. My world view has become so maths based (due to learning so much of it) I'm half expecting everything to dissolve and be replaced by falling monochrome numbers at some point.
 
That's really cool, great job!
+1 for complex numbers being fucking cool. I learnt a load of complex analysis at uni but never tried to actually render anything- fractals or otherwise. Knowing shit all programming doesn't help!

Quick question- obviously choosing more starting points increases the resolution, but how much difference does changing the threshold for checking divergence make?
i.e. for the purposes of rendering if you count a point as "in the set" if it's modulus stays below 2 after ten iterations of z -> z^2 + c, will that result in a significantly less detailed image than checking up to a hundred iterations? Or, past a certain point, is resolution the only important factor here?
 
I guess Seye will have to help you with that one, Majikthise, as long as he hasn't been overwhelmed by the lack of spoons. You know shit all programming? Welcome to my world! I have the script for a mandy engine but I don't yet understand how it works (probably because there are a buncha variables in there and I'm the sort who has to plod through it/use it to understand it. I learned how to, e.g. plot a circle using sines and cosines, first by just copying a script and seeing it work, and then learning about the maths of it afterwards. Luckily I'm under no pressure to learn or produce anything). But if you want to have a pop at programming, you could d/l the Basic I've linked to and mess about with it. There are a zillion reasons not to bother with Basic, but it's still the language that introduced a truckload of people to coding, on Vic20, C64, BBC Micro, Acorn Atom, the Speccy, and so on.

Seye, yep, xkcd has got it exactly. Like I say, I'm shit at sums but I fucking have a go!

Also, I've thought of a target prog to aim for, one which involves zooming but isn't simply "1) draw a mandy set --> 2) zoom in on selected rectangle and draw its contents --> 3) repeat step 2". I'll start on it later.

Yes, I can see the benefits of liberating myself from Basic ( I guess that speed is what'll get me away from it), but it's still fun.

Oh yeh, I did this one last night - a low zoom level but sweet stuff all the same:

AutoMandy06.jpg
 
Also, I've thought of a target prog to aim for, one which involves zooming but isn't simply "1) draw a mandy set --> 2) zoom in on selected rectangle and draw its contents --> 3) repeat step 2". I'll start on it later.

Small and not-giving-much-away update - this project is lots of fun and lots of late nights, and I've had to find some inventive ways to do what I want to do, but there should be something to see here soon.

I think I know a good deal more about all this than I did when I started. Yay.
 
Quick question- obviously choosing more starting points increases the resolution, but how much difference does changing the threshold for checking divergence make?
i.e. for the purposes of rendering if you count a point as "in the set" if it's modulus stays below 2 after ten iterations of z -> z^2 + c, will that result in a significantly less detailed image than checking up to a hundred iterations? Or, past a certain point, is resolution the only important factor here?

I think I can have a pop at this now, but I tend to think in different terms - i.e. I think of what determines the boundary of it printing black? In that prog, it's the variable Iteration%, which can be set low or high - low results in a very simple (but not necessarily quick to draw) graph, while high has more detail. Due to how BB4W works, it has to be in lumps of (n*16)-1 in this prog. In principle, Iteration% or its equivalent in any other prog can go on to infinity, as all it does is keep on cycling through the palette with each multiple of 16 (or equivalent - I gather it's possible to set a 128-colour palette on BB4W, and this will be part of my current project eventually, but I actually quite like the colours it has).
 
If it was redone in any C variant you would have access to the full modern hex colour palette.

Its really not that simple. The big problem arises from the fact that most graphics cards are implemented differently (unsurprisingly). This then requires either writing code specific to each card or using a hardware abstraction layer (such as DirectX, SDL or whatever). C itself does not provide any libraries for accessing video for exactly this reason. Of course it doesn't stop a HAL being written in C. C itself only provides "console" access. If you want more you start needing to use intermediate libraries.

For example there are multiple different encodings for a frame buffer. The simplest is a linear frame buffer where you can define white as 0xFFFFFFFF. However this obviously takes up a lot of space. Thus compression is brought in. At this point you want to compress 8x8 or 16x16 or whatever blocks. This means that the frame buffer then gets swizzled for better cache locality. Equally it is not unusual for different colour components to be held in different memory planes (This allows for far more flexibility in write performance) and again this complicates matters.

Naturally this reliance on other libraries massively increases the learning complexity as you are suddenly in the position of havign to learn a different library on different platforms. Even when you use a cross-platform library, such as SDL or OpenGL, the code you write will not necessarily be optimal as different platforms make different assumptions. e.g Writing linearly to a swizzled frame buffer will have shit performance as somewhere along the line swizzling has to occur.

Anyway I know I'm being pedantic but as someone who has worked on a multitude of platforms I can't let that one go :Wink3:
 
So here's what I have so far (I'm posting a link to save time/bandwidth, as it's a 480x480 7meg animated gif): Clicky

So me little prog (which is still v buggy and not quite right in many ways) is all animated now and can scroll in any direction, zoom, and add colour depth as it zooms (this is still quite primitive - atm it adds 16 levels every 16 frames, when it should be governed by magnification). It involves drawing and saving a huge number of bitmap images (this one has 256 frames, taking about 168 meg, each frame taking several minutes to plot), and I didn't assemble the animation using basic.

Ok, it's crap but it's fun crap.
 
cracking stuff squagnut. This could be quite a fun way for me to brush up on my coding. The penultimate pic in your first post is my fav. The way those tendrils spiral down into that oily, undulating depth....
 
Time to necrobump this thread!

In the years between starting this thread and now, I've learned a good deal about how to do stuff on computers. I'm still not a proper programmer and probably never will be, and my learning has been stumbling in the dark until I get it right.

As Seye suggested, it would be good to be able to access more colours. It turns out this is quite easy, and I now have several ways to set up my own colour palettes. It would also be good to be able to produce fractal images that are outsize, i.e. larger than the display area on the monitor. This is trickier, but I worked out how to make a block-by-block mosaic that can be stitched together in Photoshop.

Here's a few more recent images.





 
Back
Top