Performance tips for an isometric tile game

[foolmoron]

I've started working on an isometric tile-based game using this engine, so I'll probably be using this forum pretty often.

Right now I'm just wondering what the best practices are for getting the best performance out of this engine. It seems very fast so far, but are there any tricks to keeping a high FPS when there are a lot of tiles on screen (100 or more)? Is there anything that we should totally avoid doing for the sake of performance?

[a_bertrand]

Cubicverse usually shows 3000 sprites at around 20-30 FPS, so 100 sprites should be basically not an issue for the drawing. You could have other issues, like how you store your map, how you handle the logic etc.

[coolbloke1324]

I've started working on an isometric tile-based game using this engine, so I'll probably be using this forum pretty often.

Right now I'm just wondering what the best practices are for getting the best performance out of this engine. It seems very fast so far, but are there any tricks to keeping a high FPS when there are a lot of tiles on screen (100 or more)? Is there anything that we should totally avoid doing for the sake of performance?

Tiles are easily cached using the IgeTextureMap class so you can build up "background" or "floor" images from multiple tiles easily with the texure map and they will be output as a single image rather than rendering them over and over for each tile.

The complexity comes when we start to add lots of 3d-positioned isometric entities. These require the engine to depth sort them and lots of these can get slow quickly depending on how you handle them.

A few tips to start with:

1) Keep your scenegraph as simple as possible
2) Only keep items in the scenegraph if you need to draw them to the screen, unmount others if you can
3) If you have a wall object for instance, create one big wall rather than lots of individual entities that make up the wall in one direction. One object with single 3d bounds to check against is much better than tons of objects to depth sort.

[coolbloke1324]

Cubicverse usually shows 3000 sprites at around 20-30 FPS, so 100 sprites should be basically not an issue for the drawing. You could have other issues, like how you store your map, how you handle the logic etc.

I've only briefly looked at cubicverse but from the look of it I suspect it is "cheating" in regards to depth sorting, only allowing uniform cube shape entities so depth-sorting becomes very fast (depth = x + y + z). I could be wrong though!

[a_bertrand]

I must admit I have no clues what the Isogenic engine does. I just said that just the drawing of the sprite will not be an issue at 100 sprites.

For cubicverse, indeed the rendering is pretty simple, and the base blocks are just placed on a 3D grid. Objects on top of that are a bit more free, but again not overall complex. I don't need to do any depth sorting while rendering.

[foolmoron]

Texture maps look brilliant! Thanks for the tips.

And if depth sort 2 really improves performance, then I might try to only use cube entities to take advantage of that. I just tried it with what I have so far and it tripled my FPS with 400 sprites. I think my game could work with that limitation, anyways.

[coolbloke1324]

I must admit I have no clues what the Isogenic engine does. I just said that just the drawing of the sprite will not be an issue at 100 sprites.

For cubicverse, indeed the rendering is pretty simple, and the base blocks are just placed on a 3D grid. Objects on top of that are a bit more free, but again not overall complex. I don't need to do any depth sorting while rendering.

I don't need to do any depth sorting while rendering.

Is that because there are no moving entities or have you managed to do some other optimisation? Quite interested in any optimisations that can be made to isometric depth sorting

[coolbloke1324]

Texture maps look brilliant! Thanks for the tips.

And if depth sort 2 really improves performance, then I might try to only use cube entities to take advantage of that. I just tried it with what I have so far and it tripled my FPS with 400 sprites. I think my game could work with that limitation, anyways.

Depth sort mode 2 uses the basic depth = x + y + z calculation so it is the fastest. I am also working on some optimisations to the update pipeline such as detecting changes and only doing depth sorting against "changed" entities instead of the entire scene but it will be a long and complex process because the depth-sorting (using mode zero - full 3d bounds) has always been a bit of a mystery to me after I got it working, even though I wrote it!

It was one of those areas of the engine that I got working and decided if it's not broken... don't fix it... but now it is becoming a bottleneck so I need to figure out a way to handle it better. I'm leaning towards a binary tree structure.

[coolbloke1324]

I've started working on an isometric tile-based game using this engine, so I'll probably be using this forum pretty often.

Right now I'm just wondering what the best practices are for getting the best performance out of this engine. It seems very fast so far, but are there any tricks to keeping a high FPS when there are a lot of tiles on screen (100 or more)? Is there anything that we should totally avoid doing for the sake of performance?

Forgot to mention that during the render phase, scaling an image causes an FPS hit as well. If you size your images to the exact size you want to show them on screen then your rendering will run faster. It's not magic or anything, just that the canvas doesn't have to do any scaling of image data first so it's faster at blitting the pixels.

[foolmoron]

Forgot to mention that during the render phase, scaling an image causes an FPS hit as well. If you size your images to the exact size you want to show them on screen then your rendering will run faster. It's not magic or anything, just that the canvas doesn't have to do any scaling of image data first so it's faster at blitting the pixels.

I assumed that was the case. Does this apply to when you zoom the viewport as well?