farbrausch demo tools open source
category: code [glöplog]
Preacher:
Almost all animations are done in vertex shaders (sin/cos). This allows me to run the demo once every 10-20 mins and just play with the shaders by reloading on the fly. Some other more complex animations (the tiger running) are just multiple instances stored in a big .obj. The particles are the same - in "the butterfly effect" for example, all logic and movement (for all parts) is done in a shader.
The supporting code is trivial - nothing that can't be done in a day from scratch. There is just code for loading a mesh (you can do this now through assimp - although it is a bit slower for objs), shaders/FBO manipulation and that's all.
The look of total chaos is justified since, these days, I only have 2-3 weeks a year for making demos and so every minute saved is precious.
Almost all animations are done in vertex shaders (sin/cos). This allows me to run the demo once every 10-20 mins and just play with the shaders by reloading on the fly. Some other more complex animations (the tiger running) are just multiple instances stored in a big .obj. The particles are the same - in "the butterfly effect" for example, all logic and movement (for all parts) is done in a shader.
The supporting code is trivial - nothing that can't be done in a day from scratch. There is just code for loading a mesh (you can do this now through assimp - although it is a bit slower for objs), shaders/FBO manipulation and that's all.
The look of total chaos is justified since, these days, I only have 2-3 weeks a year for making demos and so every minute saved is precious.
navis demomaking ways keep amazing me :D
Quote:
navis: i know its good to protect your fx etc, but it was still a bit mean of you to run the file through a code obfuscator before uploading it
*drumroll*
plek knows his shit
Quote:
#define BALLS_LICK_AMOUNT 0.0005f
Navis: cool, thanks for the info. I might want to reconsider some of my demomaking ways...
I'm also amused by "the Navis method", in a positive way.
sag: ^_^, but today's shader terror obliterates my sse2 implementation anyway :)
And now back to more important matters.
sag: ^_^, but today's shader terror obliterates my sse2 implementation anyway :)
Quote:
camera.fieldOfView = PI / 35; // gaia's nasty homo trick
And now back to more important matters.
very illuminating. wow.
And maybe moderately hope-inducing.
(among them, hoping for more code drops in this thread)
Actually laughed out loud at "(which I'm going to use for the next 30 years regardless of any advancements in technology! \o/)"
Now I'm wondering what the code for the spoof in the 64K compo at Revision looks like. Seriously that was so spot on I almost fell out of my chair.
And maybe moderately hope-inducing.
(among them, hoping for more code drops in this thread)
Actually laughed out loud at "(which I'm going to use for the next 30 years regardless of any advancements in technology! \o/)"
Now I'm wondering what the code for the spoof in the 64K compo at Revision looks like. Seriously that was so spot on I almost fell out of my chair.
Guys, you are real angels! :3
Great. But it does inspire me to write my own tool-set.
For everyone that is using vim and want to make the navis code indented just select everything and press =%
meaty: You asked for it, more code. God, this is nasty code. A 10 year old software rendered demo ;-)
Oh, and of course: I already released a bunch of demo-sources a while ago.
For everyone that is using emacs and want to make the navis code indented just select everything and press TAB
SCNR. :-)
SCNR. :-)
@kusma: did you release any GBA stuff? :3
Quote:
God, this is nasty code. A 10 year old software rendered demo ;-)
nasty? come on, just admit it: navis won. that ship has sailed. this contest is over. time to move on.
there's no shame in retreating if someone brings a nuke to a knife fight!
Someone's gotta have an H-bomb somewhere on an old HD.
Graga: Nope.
ryg: Oh, sure. That's not where I was going with that comment :)
ryg: Oh, sure. That's not where I was going with that comment :)
I find it fascinating that V2's FM waveform is actually sin(at + saw(bt)). Non-antialiased. If I read the source right, that is :-)
Yeah, thought about some oversampling (2x should do in theory) but tried it and it simply was good enough :)
That's basically the whole design principle:
algo = cheapest_possible;
while (sound(algo)==shit) improve(algo);
:)
That's basically the whole design principle:
algo = cheapest_possible;
while (sound(algo)==shit) improve(algo);
:)
Yeah, I saw more surprised it was sin-of-saw and not sin-of-sin.
Sesse, actually it's sin(at+last_output). If you need sin-of-sin, set the preceding osc to sin. Less code, more flexibility :)
kb: Then I misread the source (it looked like you were doing a sawtooth by letting the register wrap around, then shift it to the right a bit, and OR in some bits to convert fixedpoint-to-float).
Sesse: The osc counter is a 32bit integer value that can wrap around and I use some int2float hackery because on the target platform (Pentium2) this was actually faster than fild and scale. The code does something like (minus optimisations and ring modulation)
for (idx=0; idx<fame; idx++, counter+=freq)
buffer[idx] = gain*sin(i2norm(counter)*2*pi + maxfm*buffer[idx]);
Same for the other oscs - at the beginning a buffer is cleared and the osc code either adds, ringmods or FMs in place. :)
for (idx=0; idx<fame; idx++, counter+=freq)
buffer[idx] = gain*sin(i2norm(counter)*2*pi + maxfm*buffer[idx]);
Same for the other oscs - at the beginning a buffer is cleared and the osc code either adds, ringmods or FMs in place. :)