Tileset Tile Dimensions

[Richard Kain]

I've been continuing to play around with Tilengine. During the course of my experimentation, I ran across a limitation. I don't think it is a bug, but I would like to know why the limitation exists, and whether or not it can be altered in a future release.

When designing tilesets for use with Tilengine, you have to make sure the dimensions of your tiles are a power-of-two. This limitation seems to be specific to the tile dimensions in the tilesets, and not the dimensions of the image file. The image file can be whatever, but if the tiles are not a power-of-two, the engine chokes. For instance, your individual tiles can be 8x8 pixels, and 16x32 pixels, and even 256x4 pixels. But they can't be 24x24, or 7x12, or even just 48x48. If either the width or the height is not a power-of-two, you're cruising for an engine crash.

I would imagine that this is related somehow to the performance of the tilemap rendering. I can work within these limitations for the time being. But it would free me up somewhat to be able to use non-power-of-two dimensions with tilesets and tilemaps, if it is possible. I'm in the process of cooking up some interesting uses for the tilemap structures to flesh out ways in which Tilengine can be used.

[megamarc]

Hi Richard!

You're right, the engine is built around power-of-two tile dimensions, as it uses bit shifts and masks wherever possible for improved rendering performance. I didn't considered arbitrary dimensions, because actual 2D video chips had this same design principle and limitation, and it's nearly a "de facto" standard across tiled engines. Where you can have arbitrary dimensions is in sprites but not in tileset/tilemap.

What kind of effect are you trying to achieve that would require this feature? Maybe it helps if I understand the motivation.

[Richard Kain]

I'm working on an example project that I intend to write a tutorial about. It's for using the tilemap and tileset structures in tilengine to render text. A lot of the games that I would like to make would involve a healthy amount of text, and using sprites for that amount of text would not be very good for performance. Coming up with a workable solution for text rendering led me to the idea of using a tilemap layer instead.

I wouldn't use the term "required." I was actually able to cook up a font graphic within the limitations currently in place. But I did have to go back and re-design the font graphic after I found out about the power-of-two thing. I had originally planned on making every letter 6 pixels tall by 12 pixels wide. I had to adjust them to be 8 pixels by 16 pixels instead. I'm interested in non-power-of-two tilemaps because it would give me greater control over text features like letter spacing and line spacing. With my current prototype, the line and letter spacing have to effectively be baked into the texture itself.

The prototype has been going well. I'm confident that I can cook up a system that at least approximates the kind of text rendering you see in games like Zelda, or the classic JRPGs. I even think I will be able to construct basic text boxes to go along with them.

[megamarc]

Hi again, thanks for the explanation, it helps to understand.

Most of classic games used a monospaced font where each glyph used the same number of tiles. Then it's super easy to render text, just update the tilemap layer containing text in realtime. That's exactly what the "Retropang" example does in the score area in the bottom of the screen:
https://www.youtube.com/watch?v=3x-RmMktoO0

You can download full source project here:
http://www.tilengine.org/downloads/RetroPang.zip

Advanced variable width text systems of that era, as the jrpg you mention, used a two step process. They use a contiguous range of tiles inside a tileset as a "virtual bitmap", that uses as many tiles as it is required to fill the rectangular textbox on the screen, and that textbox is a tilemap that maps to those tiles in the tieset. Then blitted by software the individual glyphs (not tiles!) to draw the text onto that "virtual bitmap" inside the tileset zone, creating tile data in realtime, that was reflected in the screen. In other words, those systems weren't able to do complex composition to the screen (there wasn't a framebuffer at all), but they could manipulate the tilemap memory as a virtual bitmap because that was just regular memory that could be modified at will.

A side effect of that is that in those games, you always see the text being constructed sequentially, even when you pressed the "skip" button: the text presentation accelerated but didn't show instantly: that was the CPU blitting the glyps by software. Those CPUs were meant to do small writes to registers, not to do expensive software blitting that couldn't be done fast enough.

I hope you catch the idea! And I look forward to see your work in progress