I’ve read about the crazy tricks developers did to fit games into the available space in the past, which brings me to wonder:
Are some of the techniques developed for 4k stuff useful for “real” projects? Is there any pressure to pack commercial games into a smaller size?
or is this more like code golf, where it’s a fun challenge, but most of the techniques used are undesirable and the constraints not really relevant to real projects?
Would a developer who did this sort of thing for fun find themselves applying techniques they learnt from it to their other projects and work?
As someone who has written a couple of 4k intros (my best work) and works professionally with computer graphics I feel qualified to answer this.
Mostly you just learn the boring stuff: how to scope a project, how linkers work, what assembly listings look like, how OpenGL fixed function state interacts with modern shaders, what kind of data compresses well and why. So actually pretty useful stuff but no means special.
Regarding commercial games, sure there’s a lot of pressure to pack the games into smaller size, but you have to understand there’s a world of difference between achieving maximum compression of a few kilobytes and streaming gigabytes of data off an SSD.
The Crinkler executable compressor was mentioned in the article and it’s a de facto demoscene tool for this size category. You can’t use it for files larger than a dozen kilobytes though because it’s so slow. Its decompression routine also takes hundreds of megs of RAM. In general, context modeling compressors simply can’t compete in speed with LZ-type algorithms because they have to squeeze the decompressed data bit-by-bit while LZ can just memcpy from already decompressed buffer.
So yeah, for a game you’re better off using zlib, LZ4, ZStandard, or a commercial middleware such as RAD Game Tools Oodle.
The design tricks I’ve learned however are something I find use for often. It’s good to know what colors look good together and how to pace a video.
A cool production and a neat writeup. I really liked the smooth water effect and investigating the generated code via assembly listings in the text was a good choice.
Using SIMD instructions to make the code smaller is an intriguing idea. Shame it didn’t end up in the final build since it would’ve been hilarious in its own way. Perhaps the CPU-side code be replaced with a compute shader pass? Of course that brings its own overheads.
I could read a million essays on demoscene code. It’s such a cool and unique constraint.
ryg’s Debris - Opening the Box is a series of articles on demo coding.
I’m particularly fond of Metaprogramming for Madmen.
I’ve read about the crazy tricks developers did to fit games into the available space in the past, which brings me to wonder:
Would a developer who did this sort of thing for fun find themselves applying techniques they learnt from it to their other projects and work?
As someone who has written a couple of 4k intros (my best work) and works professionally with computer graphics I feel qualified to answer this.
Mostly you just learn the boring stuff: how to scope a project, how linkers work, what assembly listings look like, how OpenGL fixed function state interacts with modern shaders, what kind of data compresses well and why. So actually pretty useful stuff but no means special.
Regarding commercial games, sure there’s a lot of pressure to pack the games into smaller size, but you have to understand there’s a world of difference between achieving maximum compression of a few kilobytes and streaming gigabytes of data off an SSD.
The Crinkler executable compressor was mentioned in the article and it’s a de facto demoscene tool for this size category. You can’t use it for files larger than a dozen kilobytes though because it’s so slow. Its decompression routine also takes hundreds of megs of RAM. In general, context modeling compressors simply can’t compete in speed with LZ-type algorithms because they have to squeeze the decompressed data bit-by-bit while LZ can just memcpy from already decompressed buffer.
So yeah, for a game you’re better off using zlib, LZ4, ZStandard, or a commercial middleware such as RAD Game Tools Oodle.
The design tricks I’ve learned however are something I find use for often. It’s good to know what colors look good together and how to pace a video.
A cool production and a neat writeup. I really liked the smooth water effect and investigating the generated code via assembly listings in the text was a good choice.
Using SIMD instructions to make the code smaller is an intriguing idea. Shame it didn’t end up in the final build since it would’ve been hilarious in its own way. Perhaps the CPU-side code be replaced with a compute shader pass? Of course that brings its own overheads.
There’s also a guide for Nim 4k intro coding.