Some questions about tilemaps performance/features

Michoko

Hi,

I started a puzzle game in Unity, but I'd like to see if I can actually do it in AIR instead (as I want to invest more time into this platform, and I don't really trust Unity any longer).

Basically, the game is a match 3 game with endless vertical scrolling. In Unity, I use tilemaps to represent 3 layers, displayed on top of each other: the background, and intermediate layer of "destructible blocks" that disappear when I do matches over them, and finally the last layer with regular match 3 pieces.

So I'd like to know more about Starling's tilemaps (basically MeshBatches). Here are a few questions:

Is it easy to edit a tile at runtime in a MeshBatch, and actually make it fully transparent when it is destroyed (for my destructible layer). I suppose it's the purpose of AddMeshAt(), but I can't find much information about this, nor any tutorial about large tilemaps modification/animation.
How big can a tilemap be? If it's very large, does it impact performance significantly, or is there some kind of object cullling that prevents off-screen tiles to be drawn?
If big tilemaps are not an option, what do you guys do to scroll over a large area? Tile recycling?

Any insights or tips would be greatly appreciated, as the feasibility of my project heavily depends on my ability to display blocks in a pretty large world you can scroll over. Thank you so much!

UnderwaterBird

Hi,
MeshBatch is more of a optimization technique, it's like a DisplayObjectContainer but for objects that most of the time will remain static (will not move, rotate, scale), so AddMeshAt should be the same as AddChildAt - only for setting a Z-order (order of drawing of objects), nothing else, as far as I understand. It has nothing to do with tilemaps directly, it can just be used to optimize performance, tilemap performance as well.

As a best example - Starlings TextField with a bitmap font is a MeshBatch itself and its letters are Meshes (Bitmaps). You can do most of things with TextFields, but when the're not changed during frame, they do not redraw, so using less calculations/resources each frame they do not change. The same with MeshBatches, as TextField is a MeshBatch.

As far as I remember, I'd used large in size MeshBatches with a height or width of several thousands of pixels with thousands of meshed (children), where each mesh (Image/MovieClip) was relatively small, and it worked fine (as long as using Texture Atlases the right way) and noticeably improved FPS. I've used them in mobile games on iOS/Android.

There were only few issues I remember:
1) in the process of creation of thousands of images, game freezes, so I would advice you not to create or erase everything in one frame, but create and destroy/dispose smaller chunks during runtime.
For ex. it's rather better to create thousands of data-only objects of where an what object will be, but create graphics for them only when they will be drawn in the near future. You will greatly save CPU time (in the time of loading, by redistributing calculations to the frames throughout gameplay) and RAM and will avoid small freezes when level/game loads. The best practice is to Dispose objects after (if no longer needed) or remove them from parent (and add via AddChild again when needed). A bit worse is to just toggle their visibility as object will still exist in the loop and eat some small CPU time. But even without those optimizations, GPU should draw only visible objects, it should be more of a RAM/CPU issue.

2) a single MeshBatch has a max number of children, so before adding Mesh to it, always check with if (CanAddMesh(xxx)). If MeshBatch is full, just create a new one.

3) there are many potential problems with redrawing MeshBatches on iOS while app is minimized, as iOS does not allow drawing while app is inactive, so you might have troubles/headaches with them when app will be minimized. Be very aware on async calls (calls to server) which will have callbacks/responces that will redraw your meshbatches, as when callback is triggered when an app is minimized, and that callback draws/redraws some MeshBatches, you will have an exception. Use Starling Juggler delay calls where you can, not setInterval/setTimeout.
For DisplayObjectContainers, it seems that Starling itself resolves this issue.

HaimSh

UnderwaterBird Your third point is incorrect, MeshBatch is the same
as Mesh and the same as Image, that problem is not with MeshBatch.

For a match 3 game, if you make sure to remove/make invisible tiles outside the view you can just
use Image, it not going to make any performance difference.

To animate MeshBatch you just change the texture/alpha of the Image/Mesh you add to the MeshBatch
and call AddMeshAt to the same index.

Michoko

Thank you UnderwaterBird and HaimSh for your thoughtful replies, it's quite useful.

So I'm just curious: is it actually possible to make a top-down action / adventure game (like a Zelda for example) with Starling? In the Starling handbook, Daniel explains that to make such a game, a MeshBatch containing all the tiles of the game world would work, but I suppose that without culling, drawing such a giant batch without handling some kind of visibility would be very taxing (especially on mobile)? Or does the GPU automatically discard geometry which is not inside the display port?

UnderwaterBird

HaimSh
I would argue with that, my friend. I debugged those kind of exceptions and code flow was quite clear there. Ancestry was avoided by is/as keyword and MeshBatches have separate drawing process.

By the way, in my experience GPU culling of Starling was in real world scenarios very effective on low-end mobile devices, would be interesting to hear your experience on that, how much does your fork improved that.
Perhaps, it would be possible to ask Daniel to merge your improvements to Starling?

HaimSh

Michoko Of course its possible, Zelda is a very old game.
For Zelda like game you would want culling.
Letting the GPU handle the culling will result on poor performance in low end mobile devices.
The problem with GPU culling is that that is has bigger fillrate, vertex cpu transform and bigger batches.
MeshBatch is indeed meant to be used for that kind of job.
If you want extra performance you can use my fork of Starling
https://github.com/HaimZik/Starling-Framework
and my fork of PDParticleSystem
https://github.com/HaimZik/Starling-Extension-Particle-System#starling-extension-particle-system

UnderwaterBird

Michoko
As far as I know, GPU should skip any noteable calculations when the graphics is fully outside of the screen (if not even a transparent pixel on the screen), so I would assume GPU will be fine, otherwise those thousands of objects would have destroyed those slow mobile devices I'd tested on. Starling is greatly optimized in GPU drawing.

So you should still do good without any custom optimizations in the drawing process, MeshBatch + TextureAtlas should be very fast.

What I've supposed is that it's good to be aware of your CPU as well, if you plan a ton of objects.
What might be resource heavy is instantly creating tens of thousands of new objects, as ActionScript is relatively slow.
If you instantly create several thousands of objects with some starting logic in them, you might use 100% of you CPU in that frame and that will freeze your game for that duration. And if you freeze your game for several seconds, especially on low-end Android devices, expect ANR and bad statistics, that might affect your game popularity as Google has some standards on how often ANR should occur.
As long as CPU calculations in a single frame are less then several seconds, you should be fine.
And yeah, a lot of objects might use significant amount of RAM, which iOS devices does not have that much.

But directly answering your questions - performance should be fine. I did not play Zelda, though, so I'm guessing your ambitions on objects count.

HaimSh

It might not be relevant to nowadays low end devices.
Batching will still cost a lot performance, being the biggest bottleneck of Starling due to ByteArray being slow
and lack of float32 in AS3, my fork help with that for batches with VertexData that has over 2000 bytes( easier to reach than is seem due to bytes needed for UV and color), it is hugely faster than vanilla Starling.
The Particle System fork is also more efficient at initializing new ParticleSystem
Say a MeshBatch with x=20 for every frame during the batching process Starling will copy the ByteAray to another ByteArray call ReadFloat for every vertex, transform it write it using WriteFloat.
Starling does that even when x and y are zero, so not culling is a bad idea, it could change if Starling will be GPU bottlenecked , which can happen when Harman is done implementing the ByteArray improvement I suggested .
https://github.com/airsdk/Adobe-Runtime-Support/issues/1773
I have unpublished code that skip the transform step if the transform matrix of the Mesh and all its parents is identity matrix,. To be useable you can pre transform and use viewPort, but even with that there is the cost to copy ByteArray to another ByteArray and the cost to resize ByteArray.