Newest addition is tinytiled.h. Here is a Reddit thread
talking about the lib. The idea of the lib is to implement the minimum necessary to parse a JSON exported map file from the Tiled map editor (link
). Tiled is a very high quality map editor and I really do recommend using it for your game if your game uses tiles.
tinytiled loads up and parses the JSON maps, and has features to let users explicitly control memory allocation, crt usage, and file handling. tinytiled has already been used (to my knowledge) by two other devs as a drop-in replacement for whatever they were using prior. They were kind enough to provide some really valuable feedback:
Next for me is to hook up tinytiled to a WIP header called tinyspritebatch.h
. tinyspritebatch implements a 2D sprite batching API which performs run-time texture atlasing for draw-call optimization. The advantage here is all complexity of texture atlases are hidden behind high quality API, leaving image assets on-disk as-is. This makes it really easy to have the game itself load up images however it likes, instead of dealing with complicated atlases. For example, during development images can be stored on-disk as separate images, making loading logic trivial. Once release ready, the art can be zipped up into an archive and interfaced from a file-handling API (thus avoiding the run-time overhead of dealing with many file privileges for opening/closing files).
My main motivation for tinyspritebatch is to make hotloading files really trivial, that way I can hotload art and animations trivially without dealing with complicated texture atlases.
I actually started a thread on tigsource about tinyspritebatch here, with pretty pictures: https://forums.tigsource.com/index.php?topic=63197.0
The overall design I have in mind, is a design to deal with file paths, file loading/unloading, hotloading of assets, and sprite batching all together. It took quite a while to come up with this design, and in the end I had quite a bit of help from Mattias Gustavsson (a member here on these forums). After discussing with him, I came up with this design:
- Use Mattias's assetsys.h for dealing with file paths, file loading/unloading, and for interfacing with zip archives (as if the archives were typical directories)
- tinyspritebatch.h deals with draw call optimization by hiding texture atlases behind a run-time API. This way assetsys, and the game itself, does not need to know about texture atlases whatsoever
- Create a header called tinyhotload.h, which wraps assetsys.h and provides hotload/hotswapping functionality. This is critical for a particular kind of development style that relies on super fast iteration time. Like images, audio, scripts, shaders, animations, tile levels, or any other kind of assets.
I've collaborated with Mattias in creating tinyhotload.h, but do not yet have it in a good releasable state quite yet. First I need to use tinypsritebatch some more and iterate on it, and test out how all the pieces work together. Then once I wrap my head around how it all fits in detail, I can comfortably release tinyhotload.h.
In the meantime if anyone happens to come by with any thoughts or suggestions, please do let me know :)