Elysian Shadows

Hello everyone!

I've recently started planning the tiling engine for a game i'm developing with some friends. Let me first give you an overview of where i'm going with this.

The "look and feel" of the terrain is planned to be in a Zelda style, such as in the masterpiece The Minish Cap, but with a couple of added features. First of all, i am thinking of implementing tiles that the player can move both under and over (more on that later). Secondly, i am going with a more "pokemon" kind of overworld, meaning that the map should be loaded on the fly as the player (or rather, the camera) moves around.

So now that you know what i'm looking to implement, let's move on to the details of the current design.

The map will be loaded in "chunks", containing a square of 16*16 or 32*32 tiles (that will depend on the tile size, meaning that if the tiles are 16*16 i'll probably go for 32*32 chunks). Think of a chunk as a small map, since it will function like that. That said, each chunk will contain layers in the following fashion: For the layer the player (or any other object for that matter) is currently on, the tiles on that same layer are the ground and the walls/static objects that have collision. The layers above that are stuff that are drawn above the player, such as roofs, overhanging bridges, treetops etc. Objects can change layers by moving through stairs etc.

This design handles both the features requires, but here now is an issue i'd like some advice on.

The rendering is going to be done in OpenGL mainly, by means of textured quads. These textures will be "constructed" by SDL. Now, something i ruled out early was to render each and every tile as an individual textured quad, due to obvious overhead from binding/unbinding all those textures every frame. The solution i have come to for the time being would be to do the actual tiling of each chunk (only 9 loaded each time btw) with SDL, thus reducing the amount of textures used per frame to 9 + any extra layers that some or all chunks may include. Here is the issue though: animated tiles (water etc). That would require rerendering any chunk textures that contain them + passing them to OpenGL. Of course, that would happen 3-4 times per second tops, so it's still better than doing the same thing every frame, but i'm worried about performance. What i'm looking for is some advice on whether this can be done in a better way, or if there is some way to improve this.

BTW looking forward to AiGD18

If your tiles are coming from a tile sheet then you can just check if the texture is already bound before binding a new one. That's the approach i'm using on the PSP and it improved the framerate from about 40fps to 60fps. It's actually limited to 60fps so who knows how big the actual increase is.

Personally, I wouldn't combine textures, or draw tiles as individual quads. I would work in layers, but with each layer having it's own, single tile sheet, then I'd construct each layer as a triangle list with custom UV coordinates depending on the tile at each location.

So if layer 1 is water, I would use a little tile sheet with a water animation, and offset the UV coordinates each time to scroll the water, as your tile sheet only needs to have water, it will be pretty small, and should be easy to animate. You'd only need to add quads where you need water. You might want some foamy bits where the water hits land, like quite a few 2D RPG's, that's doable with this technique of course.

Layer 2 might be ground tiles - so I would have lots of different ground tiles on a tile sheet, and set the UV coordinates to suit the required tile. Any layers more than that would probably work the same way until you get to objects.

Object layers might need to be drawn more than once, because characters can go behind and in front. I would try working out which tiles need to be drawn again because of characters - like draw all the object tiles, draw all the characters and flag object tiles that are in front of characters, then draw those object tiles again.

The main benefit is that you can stick to 1 image per layer, so no need to change texture bindings. Also, a triangle/quad strip will be a lot more efficient than individual quads. For one thing, you'd be able to construct a whole level and just offset and update - rather than creating all those quads every loop, you can just create them when loading and redraw them every loop. I'm only going by my experience with iOS, but using a triangle strip instead of several quads gives a great performance boost - in fact it saved my project from the scrap heap and made it a smooth and fast engine.

Thanks a lot for the replies

The idea of binding the tilesheet and playing with the texture coordinates is actually very nice, i will look into it more and try to get a test program up and running. I will post any further issues i might have with this here, although i'm pretty busy this week and i won't work on the project that much. Thanks again for the advice and i'll keep you posted on the progress

Well, after giving it some thought, banging my head against the wall for not thinking of using UV manipulation and doing some research, i think i can safely say that using an indexed triangle/quad list is impossible to do without duplicate vertices (which negate the benefit), so i'm going to go with regular triangles/quads using a vertex array for performance, and for the textures i'll just do what Van-B suggested. I have tested this with a small number of quads and a single tile texture (too busy ). As soon as i have some time i'll test it with a reasonable amount of tiles/textures. In the meantime, any suggestions are welcome of course

I remember saying something about this in a previous thread a while back... Now note, I've never actually tried this myself, but I would think it should work (I haven't done much with OGL, been using SFML). But anyways, have a function that instead of rendering, stores each "tile" in an adaptive container, sorted by it's texture ID. Then have an loop through each texture ID, and render everything that uses that texture, then move on to the next texture ID.

XianForce wrote:I remember saying something about this in a previous thread a while back... Now note, I've never actually tried this myself, but I would think it should work (I haven't done much with OGL, been using SFML). But anyways, have a function that instead of rendering, stores each "tile" in an adaptive container, sorted by it's texture ID. Then have an loop through each texture ID, and render everything that uses that texture, then move on to the next texture ID.

If you're sticking to a texture not being used in more than one layer, then yea this would work. If not, you could run into z-layering issues.

MrDeathNote wrote:

XianForce wrote:I remember saying something about this in a previous thread a while back... Now note, I've never actually tried this myself, but I would think it should work (I haven't done much with OGL, been using SFML). But anyways, have a function that instead of rendering, stores each "tile" in an adaptive container, sorted by it's texture ID. Then have an loop through each texture ID, and render everything that uses that texture, then move on to the next texture ID.

If you're sticking to a texture not being used in more than one layer, then yea this would work. If not, you could run into z-layering issues.

You could sort them by z-index as well.

dandymcgee wrote:

MrDeathNote wrote:

XianForce wrote:I remember saying something about this in a previous thread a while back... Now note, I've never actually tried this myself, but I would think it should work (I haven't done much with OGL, been using SFML). But anyways, have a function that instead of rendering, stores each "tile" in an adaptive container, sorted by it's texture ID. Then have an loop through each texture ID, and render everything that uses that texture, then move on to the next texture ID.

If you're sticking to a texture not being used in more than one layer, then yea this would work. If not, you could run into z-layering issues.

You could sort them by z-index as well.

How would that help? You could have two textures used for layer 1 and the same two used for layer 2. Either way you sort that, you're going to get a z-layering problem.

Yeah, I wouldn't advise having more than one texture per layer - it turns a straightforward system into a nightmare. You'd be 'drawing' the tiles according to their texture, like drawing texture 1, then texture 2... but what if you have part of texture 1 in front of texture 2? - One layer, one texture, one draw call... it's the only sensible way. Things like items and characters might have to intercept this - because they could be in front or behind areas, but this is something you'll have to figure out - that would depend on your game engine and requirements. For a platform game, well you could just have 2 forground layers - on behind, and one in front of the player. I can imagine that this get's real tricky with Zelda style games and isometric viewpoints.