Blog post on saving flash space

I whipped together a blog post on what I’ve learned thus far in saving space, if anyone is interested.

http://www.mattgreer.org/articles/squeezing-the-arduboy-for-every-byte/

6 Likes

A great read! I’ll be keeping this close when I finish the tutorials and make my own venture into Arduboy game development.

1 Like

Venture huh??? That reminds me a good game I used to play that could be ported…

In ArduBoy2’s drawPlusMask() , the data must be interlaced: One byte of graphic data, one byte of mask data, one byte of graphic data…

It was done this way as it’s the only way to make the render speed CRAZY fast - which was the design goal. True, if you don’t need the speed you might be better served with separate render passes and simply reusing some of the simpler C drawing routines, as you’ve found.

Awesome writeup.

That makes sense. It’s good to have options and be able to pick speed or space depending on the situation.

Great article.

@Pharap keeps threatening to create an article on memory saving techniques - at a code level - and, if combined with a higher level design-focused document like this, would result in a nice manifesto for newbies.

For the first time I used ArdBitmap in a game - Mini Rogue - and must say I love it. Mirroring has saved me so much memory

Recently while playing with Rogue I replaced one of the SpritesB functions with the venerable old drawSlowly or whatever it’s called. Saved an easy 320 bytes. (a 50% reduction) If you don’t need speed you you can start making all sorts of interesting tradeoffs.

The other big thing is stick with 8-bit numbers. If you can build your WHOLE game with 8-bit math vs 16-bit you’ll achieve a huge amount of savings everywhere just because your’e working at the native unit of the processor. Using rogue as another example it uses long int for hunger (up to 65,000 hunger levels). Do we really need that much flexibility in hunger? What about 0 - 100 as a scale?

Or what about simulating larger numbers with smaller numbers… so store something with 8 bits and then when it comes time to show a status screen you do math (a single math operation, one time) to convert it into a larger value. You’d lose precision, but you could add some fake precision back with pseudo-random numbers if it was really needed.

I’m starting to believe if you really want to make some really epic games on this platform you should just give up on 16-bit math from the get go and design your game around 8-bit mechanics.