Making of: "Turtles all the way down"
category: code [glöplog]
http://geidav.wordpress.com/
Uh, sorry the full link is this one: Making of: "Turtles all the way down"
Very nice writeup. Thank you!
thx for the writeup to this kickass 64k
Thanks, well worth the read!
What all the others said!
Very interesting reading, nice one :)
Love the article and enjoyed the demo & concept
cool writeup!
I really like this making-of!
thumb-up!
thumb-up!
it's kind of weird reading as a c64 coder that at some point you ran out even of virtual memory, so unused mem stuff had to be released. on the other hand all that crazy stuff to fit into 64k. size coding is getting really stupid.
Well, with procedural content creation and compression you can generate a lot of data from an executable file of just 64k. Just think of fr-08: .the .product, which generated content which would be worth more than 1 GB if it were stored as raw images.
For the actual making-of report, thumbs up! Quite a good read.
For the actual making-of report, thumbs up! Quite a good read.
nice, thanks!
very nice article. Always cool to get a behind-the-scenes look, thanks. :D
Oswald: the thing is, when you're coding something, there's usually three ways of doing something (as you probably know very well)
1) You can expand in disk space / data size and precalculate / bake a lot of your data. (Animations, AO maps, but also lookup tables on smaller platforms.) This works if you don't have much memory or enough CPU power but you have enough storage to read from disk.
2) You can opt to just do stuff on the fly; keeps the data small and relatively little memory overhead, but of course hits the CPU rather hard. This is essentially the 4k + raymarch method where the shaders are typically slow but with little cost on size or memory, or the realtime synths.
3) You can expand in memory when your effect is too slow to do on the fly (typically, generating things can be like that) and you're limited in size, meaning you store little code+data and generate most of your data in memory during loading. This is basically your high-end 64k content, or your 4k music method.
So I suppose when you start coding you usually want to find your sweet spot on the memory-cpu-storage triangle. I would assume this is true to smaller platforms as well, not only PC.
1) You can expand in disk space / data size and precalculate / bake a lot of your data. (Animations, AO maps, but also lookup tables on smaller platforms.) This works if you don't have much memory or enough CPU power but you have enough storage to read from disk.
2) You can opt to just do stuff on the fly; keeps the data small and relatively little memory overhead, but of course hits the CPU rather hard. This is essentially the 4k + raymarch method where the shaders are typically slow but with little cost on size or memory, or the realtime synths.
3) You can expand in memory when your effect is too slow to do on the fly (typically, generating things can be like that) and you're limited in size, meaning you store little code+data and generate most of your data in memory during loading. This is basically your high-end 64k content, or your 4k music method.
So I suppose when you start coding you usually want to find your sweet spot on the memory-cpu-storage triangle. I would assume this is true to smaller platforms as well, not only PC.
Gargaj, you've summed it up very well.
Thing is this intro didnt run out of memory because it struggled for performance, simply the authors threated the memory as a limitless resource. and left all old scene data in memory. In the light of that the 64kb artifical limit suddenly felt to me pretty meaningless.
There's the 254 byte raycaster just released for c64, it's a coding achievment, but its entertaining value is 0, and the code is horribly ugly. For me the beauty is in fast code producing nice effects (limited HW amiga/8bits), on the PC I dont have a feel on how hard something is to do, so I am on thin ice and possibly wrong most of the time when judging.
Sorry for the hijack :)
Thing is this intro didnt run out of memory because it struggled for performance, simply the authors threated the memory as a limitless resource. and left all old scene data in memory. In the light of that the 64kb artifical limit suddenly felt to me pretty meaningless.
There's the 254 byte raycaster just released for c64, it's a coding achievment, but its entertaining value is 0, and the code is horribly ugly. For me the beauty is in fast code producing nice effects (limited HW amiga/8bits), on the PC I dont have a feel on how hard something is to do, so I am on thin ice and possibly wrong most of the time when judging.
Sorry for the hijack :)
Oswald: I think you misunderstood me in the making-of. It's not that we didn't care about memory management. As long as we had enough of it, all the data was kept in memory for a simple reason: faster turn-around times. Why not using that huge amount of memory if you have it?
When talking about coding achievements one has to be careful: optimizing the shit out of a few lines of assembly code on the C64 vs. handling all the complexity coming with modern computers and 3D APIs is not directly comparable. Though, as long as you're doing state-of-the-art stuff for sure both is challenging. You're just fighting with different problems. I prefer the latter :).
When talking about coding achievements one has to be careful: optimizing the shit out of a few lines of assembly code on the C64 vs. handling all the complexity coming with modern computers and 3D APIs is not directly comparable. Though, as long as you're doing state-of-the-art stuff for sure both is challenging. You're just fighting with different problems. I prefer the latter :).
Quote:
In the light of that the 64kb artifical limit suddenly felt to me pretty meaningless.
We passed that station a long time ago.
Nice summary Gargaj, thanks.
I don't get the meaninglessness of the 64k limit that Oswald and Shifter talk about. It seems pretty meaningful to me. Can someone explain their POV?
BTW, Brain Control: One way to use the padsynth algorithm to generate good percussion (at least for sounds that are metallic in nature), is to randomly offset the position of the harmonics in your spectrum, and have nice wide harmonics. This gives the perceptual effect of random resonance frequencies in the spectrum, which is perfect for metallic type sounds. Of course you need some filters and envelopes on top of that, to not just have metallic noise. I believe Punqtured uses that technique a lot. Hope that helps :)
I don't get the meaninglessness of the 64k limit that Oswald and Shifter talk about. It seems pretty meaningful to me. Can someone explain their POV?
BTW, Brain Control: One way to use the padsynth algorithm to generate good percussion (at least for sounds that are metallic in nature), is to randomly offset the position of the harmonics in your spectrum, and have nice wide harmonics. This gives the perceptual effect of random resonance frequencies in the spectrum, which is perfect for metallic type sounds. Of course you need some filters and envelopes on top of that, to not just have metallic noise. I believe Punqtured uses that technique a lot. Hope that helps :)
Hunta, I like to read up on how stuff is done on the PC, so I enjoyed to read the making of this cool 64k too, sorry if I sounded like an ass. It's not against you or this intro, I understand there's lot of hard work behind this. Most PC stuff is very complex to achieve, and that really puts me off to try myself in this area. C64 is cosily primitive :) Maybe I'll try a basic raymarcher some day, I really love that technique.
Quote:
I believe Punqtured uses that technique a lot
I sure do ;)
I always release the source track for my releases, and here, you can download the synth
I tried to gather a list of the entries I could remember - would only work if you're using Renoise, ofcourse. The .xrns should be in the archives in the links below.
Phor Phanden - 32k executable music at Revision 2013
Sir Truck does the Baumgartner - 32k executable music at Kindergarden 2012
An LFO alone does not a dubstep make - 32k executable music at Revision 2012
Our Drums Can Beat Your Moms' - 64k intro at Solskogen 2012
It recently came to my attention - 32k executable music at TRSAC 2012
Propaganda 5 - 64k intro at TRSAC 2012
Funciton - Streaming music at Function 2011 (it's a 32k exe, but there was only streaming compo)
Gouden Eeuw - 32k executable music at Outline 2011
In Response - 32k executable music at Kindergarden 2011
Ultra Happy Lullaby - 32k executable music at TRSAC 2011
Wobble The Fuck - 64k intro at TRSAC 2011
Some from 2011 might be from a different version of the synth, thus causing it to sound really strange ;)
I'm thinking they could probably figure it out with less than 11 examples :-)
Quote:
There's the 254 byte raycaster just released for c64, it's a coding achievment, but its entertaining value is 0, and the code is horribly ugly. For me the beauty is in fast code producing nice effects (limited HW amiga/8bits), on the PC I dont have a feel on how hard something is to do, so I am on thin ice and possibly wrong most of the time when judging.
Oswald, could you please elaborate what is so "horribly ugly" in such a 254 byte code?
And do you honestly think that you have a feel on how hard it is to code something like that in 254 bytes?
Are you sure you are on thick ice when judging something you self-claimedly lack the skills for? (size coding)
Did I commit a crime by releasing a raycaster in 254 bytes for C64 just to prove it is possible to do it? Is the scene not about breaking the limits and seeing what is possible and proving yourself if you can do it or not? Maybe I should have asked your permission first to take a challenge, whether it is suitable for your appreciation criteria or not?
Finally; I had thought it was okay what you wrote in CSDb under the product's release page. But talking about my product in completely irrelevant places is way too over the fair line, especially when everybody else so far disagreed with you, by providing their feedback in commentary, vote or social-likes form. (And this last point is probably where your rage against such a small release arises).
I apologize for hijacking this thread, but this was said here, and probably should have been replied here.
I have examined your source code, and I liked some parts, fex. where you used the kernal rom very cleverly. then some parts I did not understand :)
I have told its an achievement, (I know it was NOT easy!), and also told: for me beauty is in fast and clean code.
Size coding is not about fast,clean and nice code, its about horribly ugly code :). It boils down to tastes, and I am not a fan of size coding. Especially on c64, the CPU can not compensate with horsepower for the small size. On a PC you could easily have 320x200 resolution, just because the cpu is that much faster.
For me the coding on the c64 is about pushing the effects faster and faster and making them nice. and my observation is that the cleaner and simpler you can do it the faster it gets. Size coding is the opposite, the uglyer the code the smaller. ;)
Sorry for hurting your feelings. It's just my opinion without the intent of harming you.
I have told its an achievement, (I know it was NOT easy!), and also told: for me beauty is in fast and clean code.
Size coding is not about fast,clean and nice code, its about horribly ugly code :). It boils down to tastes, and I am not a fan of size coding. Especially on c64, the CPU can not compensate with horsepower for the small size. On a PC you could easily have 320x200 resolution, just because the cpu is that much faster.
For me the coding on the c64 is about pushing the effects faster and faster and making them nice. and my observation is that the cleaner and simpler you can do it the faster it gets. Size coding is the opposite, the uglyer the code the smaller. ;)
Sorry for hurting your feelings. It's just my opinion without the intent of harming you.
and i am not a fan of c64 with always the same effects over and over again (whether or not they're 0.001ms faster than all the 10000 times i've seen them before) :P
