File :-(, x, )
Anonymous
Hi /gif/
I just made this
>> Anonymous
Funkylicious.
>> Anonymous
Fairly neat.
>> Grimmer
Nice fractals... what program did you use?
>> Anonymous
OP here
I programmed a tool to create Mandelbrot fractals and zooms to learn vb6... I added more features like Julia-sets, palettes etc. and ported the calculation-code to c++ because it's about 40times faster.
I rendered the frames with my program and composed them with ulead gif-animator 5

It's a bunch of 300Julia-sets around the point -0.1,0 with the radius 0.66
>> Anonymous
>>739692
You might try to add some multithreading and inline assembly (especially to the complex math part) of your C code.
With some optimization you should be able to generate stuff like that .gif in realtime (30 fps) at high resolutions (1 megapixel) on a desktop Core2Duo, which is pretty damn awesome.

(Fractals are a cool way of learning high-speed optimizations and fast multi-threading, given the fact that they're mostly complex math and are easily parallelizeable.)
>> Anonymous
>>739698
s/might/should/
>> Anonymous
>>739698
Whoa wait. I've never programmed anything before (just scripting like msl&au3) so I think it's a good start for now. But as soon as I know more, I might try some optimization.
The prog needs 110ms for the mandelbrot-set in 640x480 with 100 iterations on an Athlon 3700+. Do you know any programs I could compare with?

For those who are interested, here is the program:
http://rapidshare.com/files/55165754/mandelbrot.rar.html
>> Anonymous
lol, grammar nazis.
>> Anonymous
>>739702

Think you can upload the source?
>> Anonymous
>>739709
Here is the source:
http://rapidshare.com/files/55169173/mandelbrotsource.rar.html

Not a perfect code and many workarounds, but as I said, my first program.
>> Anonymous
>>739702
Dunno, all the desktop fractal software seems to be kinda bloaty and focuses on usability (a nice GUI interface etc.) than speed.

I just excavated my old code and ran it,
640x480 julia set with 90 iterations takes about 50ms on a Dual-Core opteron.

One problem with my code was overhead - Setting up the threads and reserving the POSIX shared memory objects (which I used for inter-process data sharing) takes some time, so the multi-thread implementation is actually slower than a single-thread implementation for small pictures like this 640x480 example.

Multi-threading really pays of for larger images though - a 10000x10000 image (100 megapixels) takes only about 10 seconds (200 times as long as the 640x480 did), even though it's more than 325 times large in size - a 60% increase in efficiency.

The other problem is storing the results - You can't parallelize I/O on most systems and image compression is mostly single-CPU, too. So saving the results in PNG format actually took longer than calculating them.

PS.: I would put my old fractal stuff online but it's mostly undocumented and half-finished so it wouldn't help much. Oh, and it has no guy either.

PPS: Of course the performance depends on fractal parameters. Depending on what parameters i choose for the set it can become up to 5 times faster, the examples above were pretty much worst-case (The whole computed area consists of points that require the full 90 iterations to be run).
(in b4 over 9000 spelling errors, g2g now)
>> Anonymous
Really good animated Fractal!
>> Anonymous
     File :-(, x)
>> Anonymous
     File :-(, x)
last one
>> Anonymous
how can gimp get any more annoying
>> sage sage
Fractals are fucking gay you idiots. There is nothing interesting about them at all. Fuck you all, and die.