- 256b: They are nice because it's a good opportunity to spare some time on the old good assembly. I used to advocate assembly coding in the past but today there is no way I am doing it again, not on PC, not even in gamepark handhelds, maybe not even on GBA (although I am curious about the speed improvements on the good old slow GBA). I am too lazy. But in 256b intros you have to do it. And usually a simple intro can be coded in 1-3 evenings. Also good for small demo releases. Unfortunately my new Vista don't run the 256b intros anymore and dosbox is too slow for the good ones.
- 4kb: Also an opportunity to make a fast release if you are lazy to code a big 64k or demo although this time you don't need assembly. With the various frameworks around the web, you can have a simple empty template in 700bytes and start from there. The negative is when size is too restrictive and you end up writting coding in different ways, inlining your function in one big ugly pile of code and generally screwing things up. Just so the compiler and cruncher gives you 20 missing bytes to reach exactly 4096 and not be at 4116 or something. I don't like this. Also, in 256b you have an excuse for not having any music (even a very bad and ugly music is considered a must) but in 4ks it's an additional burden for me. Especially when I have only the gfx and it's already 500 bytes below the limit and I know I can't crunch enough without removing scenes.
- 64k: The best of the best, even if one needs to work harder to create them and there is no excuse for and not having a music or having a shitty one (although you can just play a nifty chip tune that sounds cool and fits into something like 10kbs or 20 there). The interesting thing there is that there is enough space if you love to do everything procedurally. This is the most interesting part of all those tiny intros in my opinion. In 4ks, even if you did stuff procedurally, you would be very soon sort of space, just by code. But in 64k, you code and code and code stuff and you still can't reach the limit. I haven't code enough of them, maybe just because they need more effort. I have produced 256b and 4ks which I like less than 64ks for the same reason. 64ks is something to check in the future.
- Source limitations: I haven't seen one in the demoscene but when I was into the quickbasic forums, there were those compos where you had to write stuff fitting in 3 lines of code without semicolons and one had to write bloated pieces of code or reduces all his variables into single letters. I don't like killing my code just for source code size. It makes no sense. But this is just supposed to be a fun or senseless enjoyful competition. Even if it doesn't appeal to me. Also, similar methods are used into squeezing shader code for 4k intros.
- Graphics limitations: I am mainly thinking of ASCII demos. Each year there is a competition going on and each year I am thinking of maybe entering but I am not even starting to code something. It's fun to watch them but I am not motivated enough to code something like that, because it's just like reducing the resolution into something like 80*50(???) and coding the same effects. (Actually I have a ridiculously slow raytracer that would run perfectly smooth in that res ;) Ok, maybe there is a challenge, trying to do things look cool with text (because it's not just the resolution, it's also the character and color you will choose to shade your graphics differently). Actually, some graphics limitation compos are interesting. There was one at DBF interactive forum where you had to either have blocky pixels or 4 colors only or both, and I even made three entries for it. Sometimes it's fun!
- Hardware limitations: This is just very interesting to me. Someone will say, what's the meaning of limiting yourself, like when you have a PC, why try to code a raytracer on the C64 or something? Remember, I said before about 256b/4ks, if my extremely tiny programm is 257 bytes, why bothering with 1 byte? It's still extremely tiny and fully procedural so it's getting boring and senseless to kill those few bytes. But there it makes sense. You don't have a hard drive with only 256b free. You have plenty more. If your intro is 300bytes it won't matter for me. Ok, it's only for fun and senseless competition here. But the same doesn't exactly apply on hardware. You have the CPC and you want to work on the CPC and there 4Mhz Z80 is just what you have. Of course you can do the code on the PC, but your focus is to code something for a specific hardware. There is no even point to code it for an emulator that overclocks the machine since you want it to run on the real thing you have home and watch it and be proud of it. Although sometimes it can become too restrictive too. 8bits are too slow and you better code assembly there and their video modes are pretty weird and unfriendly. Opensource handhelds are my favorite hardware limit because they have a middle point of power, not too lame, not too fast, most coming without 3d accelerator, so it's like having an old 486 with 320*240 pixels of glory :)
- Other limitations: Imagination! Try to make out your own limitations or rules for demos. Shortest scrolltext? Longest maybe? Use a fucked up restricted palette and try to make something good out of it? Make a demo where only additions is allowed and no mul no div no sine no nothing? Make a demo out of a specific simple effect or routine? I would like to hear such compos around. Or maybe create some weird unofficial random rules for a demo I'd like to make and try this out (E.g. throw a D&D dice and determine that I should make a small demo with only plasma, glow and shade bobs, using that specific palette of 32 colors, each part shouldn't be longer than 5 seconds and the music should be a mix between trip hop and polka :)
Friday, 4 December 2009
About demo limitations
What do I like and what I don't: