Tilemap implementation

There's no "feature request" forum so I will just leave this here..

Looking at the blog post about C2 tilemaps I was wondering how the rendering of tilemaps is actually performed. Turns out that the implementation is not as optimized as it could be. If your tilemap looks like a checkerboard then each individual tile is rendered like an individual sprite. If there are rectangular regions of identical tiles those will get optimized and only be rendered as a larger block. Of course having large identical regions defeats the purpose of a tilemap and you could be using a tiled background object instead.

Suggested change for the C2 developers: upload the entire tilemap texture sheet as a single texture instead of as individual tile textures. For the tilemap create a single mesh (tristrip with degenerate triangles, and duplicated vertices) and modify the UV coordinates so that the relevant subimage from the tilemap texture is addressed.

In my retro gamer I have a 30x20 tilemap on screen. C2 currently creates around 300 individual draw calls for those tiles. With the above changes that number would go down to 1. Of course the GPU now has to do extra work but if your CPU utilization is reduced by two orders of magnitude that should be a worthwhile trade-off.

I am not sure, but wouldn't that cause to render the tilemap as one big picture, and thus increasing the chance that it goes over the maximal size of the availiable max texture size?

Size of the final tilemap object does not matter. Size of the individual tiles in the tile sheet does matter. E.g. on iPad the tile sheet must not exceed 2048 or 4096 pixels.

The WebGL renderer more or less already does that, but with fewer vertices since it can turn repeating areas in to a single quad. Seamless mode actually turns it back in to a tile-by-tile render, but this is extremely fast even on mobile devices. Your suggestion also raises some fairly thorny new performance pitfalls: when editing the tilemap at runtime it now needs to involve the GPU - either a full or partial mesh rebuild and associated GPU upload. Also it means it has to switch between buffers at runtime during rendering whereas currently tilemap rendering re-uses the highly optimised sprite-batch rendering which allows it to throw tiles in the same vertex buffer as sprites and all the other game content.

It's already really fast anyway - reducing something that takes maybe 1% of the CPU time to 0.5% is just a waste of time, especially if the improvement does not carry over to the canvas2d renderer, and especially if it has other pitfalls. As the tilemap blog post noted, using customised shaders is probably the ultimate fastest way, but good engineering is always a tradeoff and the current system is both simple and already very fast.

"The WebGL renderer more or less already does that, but with fewer vertices since it can turn repeating areas in to a single quad."

Right. But if I have repeating areas I might as well use a Tiled Background object. I would expect tilemaps to show variety instead of identical tiles next to each other. At that point the current implementation performs no better than rendering individual sprites, right ?

"when editing the tilemap at runtime it now needs to involve the GPU - either a full or partial mesh rebuild and associated GPU upload."

The same issue exists with your current implementation too I would assume. You need to recalculate the larger quads and upload those.

"Also it means it has to switch between buffers"

You mean switching between vertex buffers for sprites & tilemaps? Currently for every tile in a (non-trivial) tilemap you switch textures, which means OpenGL will do its notoriously slow texture state validation. That is worse than VB switching I'd think.

"improvement does not carry over to the canvas2d renderer"

True. I am mostly concerned about how construct2 runs on current mobile devices, and seeing warnings pop up for every single tile in the iPad OpenGL profiler is not a great sign.

Well, you can use tiled backgrounds if you like, but the editing experience is usually a lot more difficult than using tilemaps, and tilemaps should not perform worse than tiled backgrounds.

What I want to avoid is having to upload a potentially very large mesh for a very large tilemap object if tiles are modified. Right now that has very little impact since it's only dealing with a mesh for the visible on-screen tiles.

Could someone give me a .capx tested on mobile phone ( should test it on a low device, as 512 ram, no graphic card supported ) which make tilemaps faster than sprites + tile-background ? I made a lot of builds, but tilemaps 30-40 fps . Tile-background + sprites : 50-60 fps to show a same result screen.