Tiles hierarchy


#1

Hi,
I am refreshing a few projects with Tilemaps, and I am completely stuck because I realized that I can’t use hierarchy structures for Tiles: what can I do to imitate the DisplayObjects hierarchy?

@singmajesty : you were talking about TileContainer… are you still working on it?

Thanks


[HTML5 - canvas/webgl - Lime 5.6.0 - OpenFl 6.2.0] Animations not working in iOS
#2

Currently Tilemap is flat (similar to Bitmap), so any logical heirarchy will have to be done outside of the official API. However, if there’s demand for a TileContainer, we could potentially discuss an API and path to building one out


#3

Well, this is terribly limitating, it is difficult for me to think of a single project I made that doesn’t use hierarchy :thinking:

I tried to convert Spritesheets to Tilesheets to fix the problems with the animations I mentioned here .


#4

well, hierarchy is possible, but it currently must be custom. For example, code that used Flash copyPixels had to have it’s own concept of hierarchy to determine which pixels to copy where. It’s sort of the same idea


#5

Yes, I know, everything is possible, but I don’t know where to start from to implement it and avoid to be fired at the same time :persevere:


#6

I’ve just bumped into this. I was assuming that tiles would work just like other DisplayObjects (addChlid interface) so I wrote a class to pack all graphics including SVG renders into on bitmap and want to use Tiles (make bitmap -> Tileset -> Tilemap -> Tile) to render them. Obviously this can’t be done without a hierarchy.

Tilesets/Tilemaps/Tiles are basically only useful at the moment if you want to render a world. I have a lot of SVG graphics that I wish to render, some have multiple instances and others I want to animate (which means a whole lot more of them). But at the moment Tilemaps are not-useful for this. :frowning:


#7

You can use multiple Tilemap objects, so Sprite > (Tilemap, Tilemap, Tilemap), etc :slight_smile:


#8

Isn’t it heavy to elaborate? I ideally prefer to put multiple tiles on a single tilemap, not a single tile on multiple tilemaps.


#9

For me, this sounds usable. But just to be sure. Do multiple Tilemaps on the same Tileset have any disadvantages on rendering? To be concrete, if you have 10 DisplayObjectContainers each containing 8 Sprites all having 5 Tilemaps. When using one Tileset Is this from a rendering standpoint faster then using Bitmaps? And then the same question if you are using multiple Tilesets? (I’m rendering SVG to bitmaps on runtime and it will depend on the users VRAM and screen-resolution how much Tilesets there will be created)

If you are just iterating over the Tilemaps when there found in a DisplayObjectContainer:

// Pseudo Code
var set = map.getTileSet();
for (tile in map) {
    // Render
    set.render(tile); // :D
}

Then I don’t see much use for them performance wise in sprites unless the texture bindings are not changed if the Tileset does not change… Otherwise it might even be overkill/overhead in comparison to Bitmaps or cacheAsBitmap.

If I would make a estimate of the amount of single bitmap frames my game objects will have. Then it will be close to: 244 frames. Less then one quarter (50) of this will always be on screen and some are duplicates. The rest are for animating. The Tile infrastructure seemed like the best way for rendering this. But it might be overkill on the example scenario of 10 Containers -> 8 Sprites -> 5 Tilemaps (Unknown amount of Tilesets)

The source images are SVG’s. I use them because there are so many resolutions out there these days and this way I can support them all. Any advice how to best render this from a performance standpoint would be highly appreciated. I personally don’t care if its Bitmaps, cacheAsBitmap or Tiles, as long as its the fastest way.

Thanx!


#10

Maybe you can forget “hierarchy” and think “ordering”. So before the rendering, you can arrange the order of your tiles.

For example:

Container
  z-index
  tiles:Array<Tile>

then you loop all Container and order them by z-index, then you Tile.addTile() each frame.


#11

The real problem comes when hierarchy involves transformations.


#12

Oh I know what you mean. I had the same problem but fortunately I had already everything in my Spriter Engine.
Yes, maybe a TileContainer would be great after all :slight_smile: If you don’t have many “containers” maybe you can use many Tilemap for now.


#13

Thanks for all the replies. And an other problem that occurs is when using multiple Tilesets. If for example you have 3 each heaving its own Tilemap. Then when you add the Tilemaps (addChild) then they have a z-ordering themselves. The tiles will be subjected to this.

My development system has a MAX_TEXTURE_SIZE of 16384 which is already a lot, especially compared to mobile devices. And my system cant store all frames (244+) in one texture at 1080p. So on 4K this will result in a lot more Tilesets.

So as is, this is not very useful for my situation!

I’m probably just going to use cacheAsBitmap unless somebody can tell me that normal Bitmaps are faster.


#14

Okay, I’ll think about whether we should do a TileContainer or not, you can structure your own hierarchy, or using multiple Tilemaps does increase the number of draw calls, but still less so than using different Bitmaps


#15

Yeah, and no need for copyPixels :wink:


#16

A last question that I have is: Do Tilemaps share Tilesets?

var ts:Tileset   = new Tileset(/* some bitmap */, /* some array */);
var mapA:Tilemap = new Tilemap(/* width */, /* height */, ts, /* smoothing */);
var mapB:Tilemap = new Tilemap(/* width */, /* height */, ts, /* smoothing */);
var mapC:Tilemap = new Tilemap(/* width */, /* height */, ts, /* smoothing */);

Do all 3 tilemaps share the Tileset in VRAM - in which case there is only one in VRAM - , or does every instance upload a own copy - in which case there are 3 in VRAM - of the Tileset?

They probably share the Tileset but I would like to know for sure due to optimizations of my own code.


#17

Using one Tileset instance with multiple Tilemap objects will still share the same GL texture :slight_smile:


#18

Thanx a lot for verifying that! :smile: