5 ms·

Lots of resource from the demoscene, especially 1K, 4K and 64K intros - How a 64k intro is made [1] - in4k site creation of demoscene 1kb, 4kb and 8kb intros

by z303 3y ago

Lots of resource from the demoscene, especially 1K, 4K and 64K intros - How a 64k intro is made [1] - in4k site creation of demoscene 1kb, 4kb and 8kb intros [2] - SizeCoding.org is a wiki dedicated to the art of creating very tiny programs [3] [1] http://www.lofibucket.com/articles/64k_intro.html http://www.lofibucket.com/articles/64k_intro.html [2] https://in4k.github.io/wiki/about https://in4k.github.io/wiki/about [3] http://www.sizecoding.org/wiki/Main_Page http://www.sizecoding.org/wiki/Main_Page

GuB-42 3y ago
Came to say this. The main thing is to use a good packing tool. There are also templates to set up your project correctly, usually under Visual Studio. For 64k: kkcrunchy or squishy For 1-8k: crinkler, which is both a packer and a linker For 256b or less: not enough space for a packer, use 16-bit x86 assembly and DOS .COM files And of course, find a way to get interesting music and visuals with very little data, usually, it means maths.
- charcircuit 3y ago
  The main thing is arguably to use libraries or the OS as much as possible since code there doesn't typically count for demos.
  - GuB-42 3y ago
    For what I've seen, reusing built-in libraries or the OS is certainly one of the tools in a sizecoder toolbox, but it is not as important as I thought initially. First thing, you are usually not allowed to use libraries that are not included in a fresh install of the chosen OS. A fresh install will be done and only your executable which must be within the size limit will be copied to the "compo machine". Often, the only library functions being used are related to hardware access. A modern PC is not an Amiga, you can't just write at some address and expect the GPU to understand that it needs to set some pixel, you can't setup a DMA for your sound card to read some sound, you have to use some kind of libraries and drivers even if the only thing you want is show a dot on the screen. After setting up your display and sound, often, your code is doing all the work, with fonts being the only external asset typically used, if needed. There used to be more OS-related tricks. Like CAB-droppers for decompression, but now, you have context modeling based unpackers that are way better than the compression used in CAB, and take a few hundred bytes at most. Extremely slow, but we are talking 64k or less files here. For sound, you now have 4klang, a tiny soft synth that will generate code for interesting music in 1k or less, and that can interface with a DAW as a VST for composition. No need to mess with MIDI or whatever the OS has to offer besides "play wav".
- maksimur 3y ago
  What are the Linux versions of these? UPX doesn't pack binaries smaller than 40k.

by z303 3y ago

GuB-42 3y ago

Came to say this. The main thing is to use a good packing tool. There are also templates to set up your project correctly, usually under Visual Studio. For 64k: kkcrunchy or squishy For 1-8k: crinkler, which is both a packer and a linker For 256b or less: not enough space for a packer, use 16-bit x86 assembly and DOS .COM files And of course, find a way to get interesting music and visuals with very little data, usually, it means maths.

charcircuit 3y ago
The main thing is arguably to use libraries or the OS as much as possible since code there doesn't typically count for demos.
- GuB-42 3y ago
  For what I've seen, reusing built-in libraries or the OS is certainly one of the tools in a sizecoder toolbox, but it is not as important as I thought initially. First thing, you are usually not allowed to use libraries that are not included in a fresh install of the chosen OS. A fresh install will be done and only your executable which must be within the size limit will be copied to the "compo machine". Often, the only library functions being used are related to hardware access. A modern PC is not an Amiga, you can't just write at some address and expect the GPU to understand that it needs to set some pixel, you can't setup a DMA for your sound card to read some sound, you have to use some kind of libraries and drivers even if the only thing you want is show a dot on the screen. After setting up your display and sound, often, your code is doing all the work, with fonts being the only external asset typically used, if needed. There used to be more OS-related tricks. Like CAB-droppers for decompression, but now, you have context modeling based unpackers that are way better than the compression used in CAB, and take a few hundred bytes at most. Extremely slow, but we are talking 64k or less files here. For sound, you now have 4klang, a tiny soft synth that will generate code for interesting music in 1k or less, and that can interface with a DAW as a VST for composition. No need to mess with MIDI or whatever the OS has to offer besides "play wav".
maksimur 3y ago
What are the Linux versions of these? UPX doesn't pack binaries smaller than 40k.