09.25.08
Tile Storage
Sometimes the simplest solutions are the best….
Since the beginning, the GTE API has required that tiles be created via a call to GTENewTile() and then bound to a tile index via the GTESetTile() function. Originally, tile bitmap were compiled into executable code for very fast blitting into the graphics buffer. Over time, the design of GTE evolved and tiles needed to be used in many different graphics contexts. At first, I would compile different versions for each type of graphics buffer, but this became quite complex and made it hard to change the structure of the various internal buffers.
About a year ago, I switched the GTENewTile function to just return an aligned bitmap of the tile data plus a mask. The data is aligned and packed in such a way that it is efficient to copy under different circumstances, but it is just data, no code. Unfortunately, the user is stuck with managing up to several hundred memory Handles; one for each tile. This is slow, error-prone and probably not good for the performance of the Memory Manager.
As such, I’ve decided to simplify the interface and just allocate a static block of memory within GTE for tile storage. Rather than binding a tile object to a tile index, one just has to copy the tile data into the appropriate location in the tile buffer. Basically, the GTENewTile and GTESetTile functions are being merged into a single function.
Aside from freeing the tool set user from managing their own memory, it can also make tile management much easier since swapping out a complete tile set just requires a memory copy, and full tile sets are easily saved and loaded from disk since they’re just a 64K block of memory.
Faster code and simpler code. I like it when things work out like that.