I was so happy that Goerp had fun making his first TIC-80 thing (link to live version) that I wanted to try my hand at making it tiny. Especially since my earlier attempts at doing fireworks with sound in 256 bytes had failed.
256 bytes is a classic category in sizecoding, the demoscene discipline that focuses on programming tiny things. During livecoding sessions (called Byte Battles), the number of characters is counted. However, for regular competitions the size of the binary .tic file is what matters. The TIC-80 is a fantasy console that has a lot to offer in the way of making things small, and I’ll try to document my process here.
Running a packer
The TIC-80 internal file format consists of various chunks. By default, the source code is stored in a simple text chunk, but TIC-80 also supports a zlib compressed chunk which is perfect for sizecoding. People created various tools to help convert to this compressed format. What these tools do is take the LUA code from the uncompressed source, reorder it to make it optimal for packing, and then compress it into the compressed block.
Packing changes the rules, as things that would normally make your code smaller (like aliasing math.sin to s) might now actually make the output bigger. It’s now all about having “similar rows of characters” (handwaving) in your source that will compress away. As it can be a bit unpredictable what works best for compression it’s very important to regularly run a packer from the start.
What I do is I always have a custom little tool running that monitors the TIC-80 folder and compresses after any file change, using the quickest compression scheme from the Pactic tool . This allows me to keep an eye on the file size, while I can trust that doing a packing run with full compression on (this takes a while) will shave off another 5-10 bytes in the end.
The original .tic file clocks in at 2095 bytes. As you can see in the screenshot below, simply running our compressor brings that down to 347 bytes… Not bad!
Code optimizations
The code consistently used for i=1,count,1 do to enumerate sets. That last ,1 is optional, so it can be safely removed… however, that left us with a final size of 350! Oh now, we just lost three bytes. Yay compression and it’s mysterious ways.
Comparisons were done in if value==true and if value== false style, replacing those with a simple if value and if not value brought as back on track to 345 bytes.
Sound
To be figured out 😄
Final Compression
Ignoring the sound: pakkettic gets it down to 335 bytes rn.
Leave a Reply