TileMap performance and crash on even small amount of tiles, why?

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

TileMap performance and crash on even small amount of tiles, why?

(9 posts) (4 voices)

Started 1 year ago by Ozden79
Latest reply from Lev

Tags:

Ozden79
Member

Hello There,

This is Özden Irmak from Klik! Games who successfully released 2 games on AppStore in the past months using another programming language and now moved into Objective-C after the 4.0 TOS. I was already following Cocos2D since it always seemed a good effort for a solid 2D framework for building IPhone games. Now, for our next game, "FastBall 2", I decided to use it. It's pretty nice overall, though some low level things are hidden but that's the case of having a framework right :).

In our game, tilemaps are the core of the game and I see some serious problems with it so wanted to understand the reasons of it.

1) I've read in some topics that TileMaps always draw all their elements, even when they are out of the screen which doesn't need to be drawn, why? This is something the first rule of graphical drawing optimization, "don't draw anything that doesn't need to be". In that case, even breaking a big tilemap into some small pieces won't work unless you make them very very small. Is there any technical reason that it has been done so?

2) I'm trying to load a tilemap with a size of 250x25 and it crashes, but if I use 250x20 it seems ok. Is there such a small limit in tilemap size? In the docs, this part is pretty vague so I could not understand the amount should I stick.

For the 2 issues above, without any magical trick, I could get healthy results with my own coding before in the other language I mentioned. All the drawings were counting the current position of my tilemap so I was only drawing the needed items within the screen bounds and tilemap is more or less a simple array pointing to an image resource to be drawn and could be populated without a big memory impact to cause any crash.

I would be glad if anybody could enlighten me in these matters...

Thanks in advance...

Özden

Posted 1 year ago #
toadkick
Member

I've been wondering about this myself a lot lately. A recent profile using Shark showed that simply rendering one layer of a TMX map (200x20, at 32px per tile) was taking up 13% (!) of my processing time. I am making a game where the main character can move very fast on some levels, and as such, I actually need a map at least twice as wide to have enough room for my character to move fast for a sustained period of time.

I spent a couple of hours looking into the implementation for TMX layers, but since the actually drawing is done as a huge batch of triangles by the superclass (CCSpriteSheet) there's really no good way as far as I can tell to refactor the code to draw only the tiles that are visible/relevant.

As it is right now, using TMX maps is not really practical, even for just one layer, and I will likely end up having to completely write my own solution from scratch :(

Please note that I am not posting this as a complaint (other than this, I have been very impressed by Cocos2D!), but mainly to say that I perceive this feature (tile maps) to be one of the most important features of Cocos2D. Unfortunately is is almost unusable for many types of games due to the fact that maps need to be relatively small.

Mainly I was just hoping to do what I think Özden was trying to do and get a productive conversation about this going to see what would need to be done to get TMX maps to perform better.

Posted 1 year ago #
Ozden79
Member

Thanks for your comments and backing me up in this matter...

I really cannot understand why this topic does not get the attention it deserves as it's one of the core things that needs to be optimized. I know Cocos2D is an opensource effort so cannot blame to anybody for that either. But at least, I hope that it'll be priotirized in one of the following versions.

For now, I think our only solution is to try some tricks or implement something from ground up...

Posted 1 year ago #
patrickC
Member
```
A recent profile using Shark showed that simply rendering one layer of a TMX
map (200x20, at 32px per tile) was taking up 13% (!) of my processing time
```
If you think about it that's a pretty bold statement, a 200x20 map means you're rendering 4000 sprites, which ain't few.

Unfortunately the current TMXTileMap doesn't allow you to hide bits of maps "on the fly", but that would require re-building both the vertex and texture coordinate arrays at each hide/show of map portions, resulting in rather expensive computing times that I doubt would work well while trying to maintain a 60fps speed (unless perhaps async, I don't know?).

What I would suggest you do is split the large map into a number of smaller ones, and hide/show them as necessary.
That's what I did (1 year ago) with Mini Taxi and the older .tga tilemap class.
I was able to have a relatively large world (256x256 if I remember correctly [65,536 sprites]) and keep performance high.
Posted 1 year ago #
toadkick
Member

I am well aware of how many tiles are in my map, and my statement is not that bold. I figure with 32x32 tiles that it would take 150 of them to fill the screen, plus another 25 for the extra row/column you would need to account for the scrolling. I simply cannot see how only rendering 175 tiles per frame would not be a significant performance improvement over rendering 4000 tiles per frame.

Now, realistically, 4000 are not really being rendered every frame. Depending on how densely populated the layer is with tiles (most of the tiles in the foreground layer will actually end up being blank tiles that don't need to be drawn), far less will actually need to be rendered. In my test map, currently there are about 550 tiles that are not blank in my map (it is indeed pretty sparse), and the actually amount visible at any one time are usually somewhere between 50 and 100. Even still, you can't honestly tell me with a straight face that only rendering the visible tiles would not yield a significant performance increase.

I have seen the suggestion to split up my map into several smaller maps elsewhere, and show/hide them as necessary, but the time spent splitting up the maps by hand and writing the code to organize them and show/hide them would be better spent just writing a system where such tedious work is not necessary imho.

(edit:grammar)

Posted 1 year ago #
patrickC
Member

Didn't mean to stir up any emotions ;)

I see what you mean and of course being able to hide/not-render the tiles that aren't visible on screen would be a huge performance improvement.

As I see it though, and I may be wrong, the performance increase that is gained by batching a draw call, therefore constructing a vertex array, means that if you want to constantly hide/show tiles you would need to reconstruct the array each time (again, I think).

Depending on how you do it and how big the vertex array is, it may or may not be do-able (performance wise).
The topic has been discussed sparsely over time and that's how I came to form this opinion, but then again riq or a more experienced person might want to chime in and prove me wrong :)

I still think the best way to deal with this is to split the tilemap into smaller chunks (can be easily done at run-time), and hiding/showing the mini tilemaps (again, pretty simple to implement).

Just my two cents as they say...

Posted 1 year ago #
toadkick
Member

Ha, no worries, my emotions have not been stirred...though I will admit I do have a tendency to come across passionately about things I guess.

You may be right about the performance implications of building the vertex array and texcoord array every frame, unfortunately the only way to know for sure is to implement it and see, at which point it would be a bitter pill to swallow if there was not a significant performance improvement. If you are not using scaling/zooming (or if you were but were able to provide a known upper and lower bound for the scale), you could probably get away with building the vertex array only once and using OpenGL to transform it into position, but so far I can't see getting around having to build the texcoord array each frame.

At any rate I'll admit that I had not previously put much thought into a run-time solution for breaking up the map into smaller chunks, and that may indeed be the best option at this point. I would still be interested in hearing from riq or someone else with some expertise on the matter though, as I do still think tilemaps are one of the most important features in a 2d engine :)

Thanks for the feedback patrickC!

Posted 1 year ago #
Ozden79
Member

Hello Patrick,

Could you please explain "split the tilemap into smaller chunks" a little bit more?

I had seen a suggestion on creating different areas of the tilemap on different layers so you can set their visibility to on/off when needed but that's a painfull process in the editor and more importantly, I think I'll still get a crash when I try to load a tilemap at start because all layers must be turned on at start.

Thanks in advance...

Posted 1 year ago #
Lev
Member

@Ozden79: What generation iphone / ipod are you working with?

For an isometric tilemap, my 3GS drops below 60 fps at about 10k tiles and starts rendering areas of the map black at about 17k tiles. At 17k tiles, I'm using 10mb of texture memory, 20mb of system memory, and 40% of the cpu. It doesn't seem like I should be topping out just yet. Does anyone know what the bottleneck is?

According to shark, half of the calls are memcopy from glBufferSubData_Exec. Im assuming this is copying crap into texture memory.

I could rewrite a bit of the tmxtiledmap code to parse the maps into smaller chunks placed in different layers, then, according to what's on screen, set them visible or invisible. This should cut down on the memcopy stuff the cpu is doing.

Even so, I'll run out of system memory at about 40k tiles, and that's not even really including any artwork. So it seems for a very large map I'd need to actually load and remove chunks of the map on the fly.

Has anyone tried this? Any show-stoppers I'm not thinking of?

Thanks,
Lev

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.