Here is a 1k prod of the 3D Mandelbrot fractal. This 1k demo has been coded in Direct3D 9 and has been shown to the Breakpoint 2010 demoparty.
Breakpoint 2010 was my second demoparty so far, and even though I was there just as a spectator, I showed my Mandelbulb implementation to a few people,
and they suggested I make a 4k demo out of it. Well, I might still finish that 4k eventually (with better performance, more accurate ambient occlusion,
blablabla…), but for now here is a 1k demo which raymarches a Mandelbulb and can get decent frame rates at good resolutions on a
fast computer. Since the final code was significantly smaller than 1k, I added some additional effects until I reached 1k (well, technically 1k=1000, so it’s really 1Ki or 1.024k, but whatever…).
You can download this prod HERE.
And here are some interesting tricks from the author to create very very small code (these tricks help hitchhikr‘s exe packer to produce a better compressed code):
- All variables should be just one letter
- Make everything lowercase. The shader in this demo contains not a single uppercase letter.
- All variables should be declared in one place
- Variables should be reused whenever possible in order to minimize the amount of variables which need to be declared (this shader uses 1 float2, 3 float4s and 10 floats)
- Since repetitive strings can be compressed better and some letter are more frequent than others, “1000” may compress better than “999”, or “z*z*z*z” may be
better than “pow(z,4)” - Use all features of c++ whenever possible, such as “o=d=1”, “while(z<400&&i++<11)" or "x=o-=log(b*b+u*u)*.15"
- DirectX has a few additional features which can be useful. “if(h<1)v=v.gbra" reorders the indices of v while being very compact.
- Truncate floats as much as possible, always ommit the leading zero and remove all unnecessary spaces and brackets.
- Macros are usually not worth it.
- At least on my machine the program would occasionally refuse to start at random. Adding “1*” or “0+” to some line might help.
- Some variables may require an initilization, but the exact value might be not so important. In that case, just initialize them in combination with some other variable (“o=b=a.y;”) or reuse them when you know what the last value will look like approximately.
I successfully tested this demo on my GeForce GT 240 (ForceWare 197.45 Win 7 64-bit) with an average FPS of 10…
You can’t see it ? No worry, just watch this video:
[youtube 1QoIPMm5Erw]
And sorry for the lack of bews this week, I’m a little tied up with some GPU dev and my next moving….
Super cool!
It runs around 15-20 fps on my single 5850 stock core i7 860. Didn’t check crossfire yet. I wonder though, is this gpu limited or cpu limited? Isn’t Mandelbrot something cpu related?
I may do a video for my Youtube channel of this.:D
I think this version relies on a highly optimized mandelbrot shader and then is GPU limited.
Damn i can’t get 4k or 1k demos run on my system.(Win 7 U x64,qx6700@3.44)
Just “Blah blah blah has stopped working”
T_T
Very cool.
To Romero : Unpack the zipfiles first before trying to run the demo. That helped me (-;
I.E. dont run the exe file directly from the winzip archieve, which windows might let u think is unpacked.
I don’t see the point of the first two “tricks”… How on earth declaring one letter variables (and lowercase) could help an exe packer do its job better?
Variable names do not appear in an exe once it is compiled.
I may be wrong, and the exe packer mentioned could act like a compiler. In that case, it would be a bad compiler if it cared about the length of the name of the variables.
It reminds me of my students who used to think that the less characters in their code, the faster it should run 🙂
Matumbo: Hint; Its about size…
I believe the tricks probably refer to the shader source code that is embedded in the exe.
(ie it probably compiles the shader at runtime)
@matumbo:
Shaders are held as *source* in the compiled exe and are then dynamically compiled by the shader system at run time. Thats why using small variables (few letters) helps. As for capitals v lower case, the compressors will work better because there is less difference between the binary representation of x and y than of x and Y and the compressor in questions works at the bit level.
Seriously, those students remind me of you, not the coder of this 1k.
I did not ever launched demoscenes right in archieves. And this does not help. I found elevated 4k intro with some “win7 fix” and it’s didn’t work too.
@jegx
You were right man. The demo is indeed gpu limited. It also supports crossfire!
I just fired up my OC settings, Core i7 860 @4.0Ghz and my 5850s at 1Ghz and the demo run at 60fps! Wow! Tremendous difference compared to one 5850 at stock.
It only dipped at 50s at the end of the demo. It is too short though. I would like to see a larger version of it. It seems to be good gpu test.
Awesome – Ran well on my Core i7 950 @3.07Ghz & my Nvidia GTS240 w/ 197.45 drivers.
To Psolord: How did you measure the FPS? I don’t recall seeing any indicators (unless I’m blind!).
One small unimportant note: My monitor’s native res is 1680×1050. At that res, only Mandelkern – 1680×1050.exe ran. I was able to run the others by lowering resolution first.
Perhaps it’s because I have 3 screens. 🙂
JR
Pingback: [3D Programming] GLSL Minifier: Pack Your GLSL Code Into a C Header - 3D Tech News, Pixel Hacking, Data Visualization and 3D Programming - Geeks3D.com
Pingback: Real-Time Rendering · Benoit Mandelbrot dies at 85
Why D3D? What’s wrong with OpenGL?