What is the difference in cost between adding multiple tiles or adding multiple tiles inside Tile Containers and than added to the tilemap?
If I have different tilset between the sprites in game and the ground and I can’t fit both in one tileset, should I create 2 separate tilemaps, find a way to switch between tilesets with one tilemap, or do tilemap for the sprites and draw quads for the ground?
Would pooling for tiles be worth it, or is the cost for creating and deleting tiles minimal?
What is the difference in cost between adding multiple tiles or adding multiple tiles inside Tile Containers and than added to the tilemap?
In the current haxelib version of openfl (8.9.1) there is a small loophole in logic that adds a lot of overhead to tilecontainers. If you have a really deep and complex tree you will notice some slowdown. Otherwise, the performance hit is the one that comes from the applying the parent transformation to his children, for the ease of use it brings I consider that performance hit negligible.
If I have different tilset between the sprites in game and the ground and I can’t fit both in one tileset, should I create 2 separate tilemaps, find a way to switch between tilesets with one tilemap,
My general advice would be to set each tile “tileset” to the correct one and that allows you to mix and match tilesets in one Tilemap. Now, keep in mind that the batched render renders from back to front and it will have to flush (stop batching) as soon as it needs to change the tileset.
Would pooling for tiles be worth it, or is the cost for creating and deleting tiles minimal?
Technicallyyyy a tile is a super duper simple structure that is really cheap to make from scratch when needed. That being said, if you add some logic to it (say, you extend Tile to make Enemy) you might want to pool it. (For pooling, Lime has the ObjectPool that works reaaaaally good)
Now, something important to keep in mind: Tilemap will cull (not render) any tiles outside his boundaries. (negative x and y, and x and y above his own width and height). It doesn’t know where your stage starts or ends so it will not cull what is “outside the screen”. To make this I advice to have a Tilemap the exact size of your stage and then have a tilecontainer called “tileStage” and add all your tiles there. That should allow you to migrate from the DisplayList to the Tilemap somewhat seamlessly.
Hey, thanks so much for all of the advice this has helped me a ton. I’m just not quite understanding the last piece of advice. On why adding a tilecontainer to the top of the hierarchy helps. I’ve read through the tilemap source code and it seems to be made up of a tile container called __group. Let me know, and the ObjectPool is quite magical by the way, thanks!
Yeah, I phrased it poorly because my mind was onto something.
In case you need to “scroll your screen”, don’t move the Tilemap, create a new container to be the root of your list and move that. The advice was only in case you need to scroll your screen but my mind jumped ahead
The generic advice for this would be: Don’t make a tilemap larger than your visible stage (or place your tilemap in a way that parts of it end up outside the visible stage). Doing so is a bad idea. Make it smaller if you need to, but making it bigger is just a waste of processing resources.
