Tile rendering strategies for mobile HTML5

[Jon Goikolea]

I'm building a very simple platformer using tiles and I wonder which way would be the best to render the map when the target is obviously a mobile device. As far as I know there are 3 main strategies:

 

1. Render game as it comes just simply checking which tiles should be in the screen in every single frame and draw the pertinent tiles. Straight forward, but the scene need to be recomposed every frame.
2. Draw map chunks to invisible canvas layers and work with those chunks. This method seems to be flexible enough to offer good results but the question is how big should be those chunks, and how affects that in memory and performance terms.
3. Draw the whole level in a single canvas layer and just scroll it. Is there any limit here with the size?

 

[Chris]

I am currently building a tilebased rendering engine and have gone with approach 1 so far.

I am getting ~60 fps on my iPhone 4s in a 800x600px canvas, rendering 32x32px tiles.

I havent tried a fullscreen canvas yet.

[rich]

You can't use approach 3 unless the map is very very small. Canvas has memory/dimension limits you will hit fast.

 

I am using approach 1 in Phaser for a few reasons:

 

1) I've not yet seen any significant slow down. So long as the tilemap image stays in memory it renders really fast.

2) I have a multiple camera system and would have needed a hidden canvas per camera, which would start to consume memory.

3) I believe that when we get WebGL support in mobile approach 1 is by far the fastest and easiest to implement there.

4) Drawing the tiles each frame allows for some fun effects to be added easily without re-rendering whole canvas.

[Jon Goikolea]

Thanks, I will try the first approach in a platformer game and see what I get. Good to hear you got nice results, I tend to undestimate HTML5's capabilities

By the way, I'm using this article on the subject if anyone is interested.

[Ezelia]

I also use the first aproach for platformer games .

one optimisation you can do here is the use of object pooling, this will reduce garbage collections and avoid some game slowdowns

 

objects pooling is endependent from rendering strategy, it's a good practice in general when you have to allow lot of objects frequently.

[tcaud]

I've honestly found HTML 4 (not 5!) to be the fastest technique for rendering tile maps. It's actually faster to use IMG elements than to draw on a canvas. Bizarre I know, but in my tests the times are half for IMGs what they are for canvas draws.

 

Particularly when using setTimeout(0) to draw tiles (one line per timeout). And that is the fastest way to prerender the canvas. At 128x128 tiles it takes about 6 seconds to blit a map full of blank tiles. At 256x256 it rises to 45 seconds. For 512x512 it's 4 1/2 mintues. The times are double (or worse) for Canvas blits. (test system is Pentium 4 3.0ghz, 2 gb RAM, 128-meg accelerator). The memory costs for the 512x512 map were 180 megs.

 

The advantage of prerendering the map is that you just have to reposition the canvas in a clipped DIV to scroll it. Excellent performance.

 

But it does seem like the performance of Canvas is particularly hideous when dealing with many .draws in succession. It might have something to do with Firefox (my game maker, Gamestar GCS, is an addon exclusive to Firefox because Chrome doesn't allow native file access at all), but I can't be sure because I can't test it in Chrome. Well actually I probably could... maybe I'll do that later.

 

If I were to guess why the rendering is so slow, I'd say the browsers handle memory allocation very sloppily, and waste a lot of time shifting memory around.

 

Blitting the map as it scrolls might provide faster graphics, but Gamestar GCS does realtime editing so it's not much of an option for use in the editor itself and besides it seems I have sound playback issues with HTML 5 in general on this machine that, paradoxically, can run Doom 3 just dandy.

 

I particularly dislike that setAnimationFrame ALWAYS sucks up half the CPU. No good excuse for that. SetTimeout sucked it all up, but that just shows setAnimationFrame can do better. We should lobby the browser vendors to improve their programming.