"Chris Aernoudt" <[EMAIL PROTECTED]> wrote
> - --Ok, here goes
> - --I've got some other scripts attached to be able to do a clickzoom, but
> that's not important to the drawing
Just commenting out the 'setPixel' line, I can see that the script itself is
very slow. At first I thought you could optimise a lot of the basic stuff like
fax = fcx+fx*fscale
fay = fcy+fy*fscale
...by putting this into lookup tables, but in fact, the problem is iterating
through all the coordinates.
I optimised the innermost while loop as much as I could by cutting down on
the squaring, and (re)moving a few redundancies. In fact, the logic for
choosing pixels in my version is slightly different, but does not take it
away from the central idea of drawing the mandelbrot set.
I figured that if your palette index were going above the maximum (255), it
would be set to 0 anyway, so I leave the loop at that point. In your
version, you use 'and' so you are continuing to look for the palette index
even when it will certainly be set to zero.
<snip>
fa1 = fax
fb1 = fay
lp = 0
fa1_squared = (fa1*fa1)
fb1_squared = (fb1*fb1)
repeat while (fa1_squared+fb1_squared <= fLimit)
if (lp <= 255) then
lp = lp+1
else
lp = 0
exit repeat
end if
fa1_squared = (fa1*fa1)
fb1_squared = (fb1*fb1)
fa2 = fa1_squared-fb1_squared+fax
fb2 = 2*fa1*fb1+fay
fa1=fa2
fb1=fb2
end repeat
</snip>
Actually, the key factor influencing how many iterations you get in the
innermost loop is (of course) fLimit and the number of colors you are using.
If you can go down to (say) a 32 color palette you will get much better
performance, not because 32 colors are faster to draw, but because you only
have 32 possible maximum iterations for the inner while loop.
BTW, I tried using lookup tables for the values fax and fay, which you
certainly are recalculating too often, but the effect on performance was
negligible. (A matter of half a second or so, which surprised me quite a bit).
In any case, Director is absolutely the wrong tool to handle this kind of
fast number crunching. Even programs compiled from C (which would be the
best tool for handling the while loop) take a noticeable amount of time to
draw a 320x200 mandelbrot set with a decent set of colors.
Unless anyone has a smart way to optimise the loops further, the best ploy,
then, is to code the innermost while loop in C, then wrap it in an Xtra. I
suppose that's out of the question, but at least we have established that
it's not setPixel() that is the culprit.
You can see why this is always going to be slow in lingo by running this code:
on test
t = the ticks
repeat with x = -160 to 159
repeat with y = -100 to 100
repeat with p = 1 to 255
-- nothing at all in here!
end repeat
end repeat
end repeat
put the ticks - t
end
You'll notice that this code takes a comparable time to execute as the
mandelbrot code, and it's not even doing anything! There are simply too many
pixels (64000) to do this quickly. Another way to improve the speed is to
double all the pixels (i.e. draw it at half size and scale the bitmap member
on screen). That will make an enormous difference.
Incidentally I'm all at sea when it comes to this kind of mathematics, so
even though it's interesting to play with, I don't really know what the
mandelbrot algorithm really is, or what it represents, beyond vague notions
of 'chaos theory' that I have gleaned from TV documentaries.
Thanks for letting us pick over your code!
--
_____________
Brennan
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
