07-19-2021, 10:48 AM
Hey Megamarc!
It's been a few years since I was championing Tilengine, and wishing I had a game idea that would need it.
Sadly, now that I am working on a 2D pixel art game, I decided not to use Tilengine! I've been thinking about it a lot, it's such a shame because I really liked the idea behind Tilengine. I thought I would describe the path I took, and get your thoughts on where Tilengine sits in all this.
I think the first reason I didn't start with Tilengine for my retro projects, is the most beaten path to getting Tilengine to run (that I know of) is to run it on top of SDL. However, I went with Unity for the cross platform support, that SDL doesn't have, even though it pained me to know I was using a 3D engine to draw 2D pixel graphics, and this was very evident in my frame rate testing on very low end hardware, compared to more true 2D engines like Godot. But it didn't matter - as long as it ran well enough, my ultimate goal was to be able to easily port to consoles like the Nintendo Switch, and Unity was the best at that, at the time.
Then I came across Kha (I think from the GamesFromScratch YouTube channel), and I decided to give it a solid go, because it rivals Unity for cross platform support, and it's a more "truer" 2D engine. Even better, it's 2D engine is designed to make the best use of modern GPUs. Each "drawImage" or "drawSubImage" function call actually sends a quad of 4 texture mapped verts to the GPU. Sequential draw calls using the same texture will be batched, to reduce overhead. And you can get more involved in this pipeline if you want, and change the way it works. It's meant to be used this way because it's more of a framework than an engine - a modern replacement for SDL. You can make other 2D or 3D engines with it, and it will always be using the GPU.
I then quickly learned shaders to implement my own paletted images, so now my sprite atlases have associated palettes, and each sprite instance (or rather, each drawImage call) has it's own palette index that it can use, meaning each sprite instance can have a different palette, but still use the same texture, and still be batched into the same draw call.
And I've already planned out how I'll do some per-layer scanline effects, by rendering the layer to a pixel buffer and sending that to the GPU where the shader will offset each row of pixels.
And then I finally realised, I was better off learning shaders to emulate old hardware effects. The experience is more relevant to the way modern hardware works, and everything has a GPU now, and the GPU seems like the right place to spend resources emulating old video game effects, leaving the CPU to actually run the game itself.
Although if we're talking about making games that look like SNES or Megadrive games, the extra effort is probably pretty minimal whether it's on the CPU or GPU. And it is likely very possible to implement Tilengine into Kha, and have it just draw a texture every frame. I guess it comes down to me feeling better about using Kha's GPU based drawing commands and getting involved and writing shaders to be part of that draw process, and knowing I'm learning relevant skills while making the best use of the actual hardware the game is running on.
Oh I also recently made a video on Kha over Unity or SDL https://www.youtube.com/watch?v=5A8v7dbkPRg
So yeah, after all the fantasizing I did about making a game using Tilengine, I felt like I needed to come back here and talk about what ended up happening, and see if you had any thoughts on all this.
It's been a few years since I was championing Tilengine, and wishing I had a game idea that would need it.
Sadly, now that I am working on a 2D pixel art game, I decided not to use Tilengine! I've been thinking about it a lot, it's such a shame because I really liked the idea behind Tilengine. I thought I would describe the path I took, and get your thoughts on where Tilengine sits in all this.
I think the first reason I didn't start with Tilengine for my retro projects, is the most beaten path to getting Tilengine to run (that I know of) is to run it on top of SDL. However, I went with Unity for the cross platform support, that SDL doesn't have, even though it pained me to know I was using a 3D engine to draw 2D pixel graphics, and this was very evident in my frame rate testing on very low end hardware, compared to more true 2D engines like Godot. But it didn't matter - as long as it ran well enough, my ultimate goal was to be able to easily port to consoles like the Nintendo Switch, and Unity was the best at that, at the time.
Then I came across Kha (I think from the GamesFromScratch YouTube channel), and I decided to give it a solid go, because it rivals Unity for cross platform support, and it's a more "truer" 2D engine. Even better, it's 2D engine is designed to make the best use of modern GPUs. Each "drawImage" or "drawSubImage" function call actually sends a quad of 4 texture mapped verts to the GPU. Sequential draw calls using the same texture will be batched, to reduce overhead. And you can get more involved in this pipeline if you want, and change the way it works. It's meant to be used this way because it's more of a framework than an engine - a modern replacement for SDL. You can make other 2D or 3D engines with it, and it will always be using the GPU.
I then quickly learned shaders to implement my own paletted images, so now my sprite atlases have associated palettes, and each sprite instance (or rather, each drawImage call) has it's own palette index that it can use, meaning each sprite instance can have a different palette, but still use the same texture, and still be batched into the same draw call.
And I've already planned out how I'll do some per-layer scanline effects, by rendering the layer to a pixel buffer and sending that to the GPU where the shader will offset each row of pixels.
And then I finally realised, I was better off learning shaders to emulate old hardware effects. The experience is more relevant to the way modern hardware works, and everything has a GPU now, and the GPU seems like the right place to spend resources emulating old video game effects, leaving the CPU to actually run the game itself.
Although if we're talking about making games that look like SNES or Megadrive games, the extra effort is probably pretty minimal whether it's on the CPU or GPU. And it is likely very possible to implement Tilengine into Kha, and have it just draw a texture every frame. I guess it comes down to me feeling better about using Kha's GPU based drawing commands and getting involved and writing shaders to be part of that draw process, and knowing I'm learning relevant skills while making the best use of the actual hardware the game is running on.
Oh I also recently made a video on Kha over Unity or SDL https://www.youtube.com/watch?v=5A8v7dbkPRg
So yeah, after all the fantasizing I did about making a game using Tilengine, I felt like I needed to come back here and talk about what ended up happening, and see if you had any thoughts on all this.