Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Cool to read the writeup and some of the things you encountered. Here's a couple tips that might be useful for using the GBDK toolchain:

> never render empty sprites and use up a vital sprite slot

Yes, png2asset operating in "metasprite" mode (the default, i.e. without "-map") will accomplish that. It treats tile regions with no pixels set as empty space and skips over them, so that when the metasprite frame is loaded into the OAM no sprite slots will be used for empty tiles. It is typically used with *_metasprite_*() functions which will update all the needed sprite entries at once.

> loading a whole new set of data + rewriting the bg map every animation frame

For multiple background images (or sprites) that share a common tileset the -source_tileset option for png2asset might be useful. It allows generating tilemaps that don't require reloading the tile if the shared tile data is already in place (or only reloading the tiledata that is unique and not shared).

There is also the gb\hblank_copy demo which demonstrates a way to load vram data faster for background animations that don't have tearing. It can be for tilemaps or tile data.

Hope these help if you work on a GBDK project again.

Thank you for taking a look! I would like to revisit the Gameboy / GBA at some point, probably the next time a Jam rolls around. I'll take a look at the metasprite code again. I did take a look at the hblank example so maybe I can verify it helps with the example repo I put in my post.