Posted October 03, 2020 by Khonsu Labs
#devtober
Short update tonight, as I had several real-life fun obligations that prevented me from spending as much time on the project today. But in the spirit of Devtober, I did get some work done.
I worked part-time on expanding my SpriteSheet support from yesterday inside of Kludgine. I haven’t pushed the code yet, I’ll hopefully reach a point where I’m happy with it tomorrow. Here’s the problems I’ve been solving:
My coffee-sipping, Twitch-watching morning was spent typing out large enums representing all of the tiles within the sprite sheets I wanted to use. I noticed something, however. The base tile size is 16x16, but in one file, the tiles were 8x8. My TileMap code only supports a single tile size, and I couldn’t see myself changing that. However, I really needed these “border” tiles.
So, I invented a concept I’m really not sure if I’ll like or not, but it fits really nicely. Essentially, the structure SpriteSource (the source rectangle and a handle to the texture it comes from) has been expanded to offer a mechanism for multiple source and destination rectangles. This means I can stitch four 8x8 tiles into a single 16x16 tile.
I haven’t tested this code yet, but I’ve started creating the code that creates new “joined” sprites.
It’s going to be necessary to have my procedural generator use multiple source sprite sheets. However, I wanted each sheet to have its own enum of tiles, which means I needed some mechanism of creating a collection of multiple sheets.
I created a simple type SpriteMap that makes it easy to create an enum representing all of the sheets you’re wanting to use, and adding those sheets to the map. SpriteMap and SpriteSheet both implement SpriteCollection, which will be how the generator gets the tiles.
I don’t have an algorithm fully determined, but my general idea is:
Tomorrow I’ll hopefully reach a point where I can show off some generated rooms, or if I’m super productive, dungeons!