Compose images, improve performance

[mariogarranz]

I'm developing a game where I have lots (more than 100) composed objects permanently in the screen, tiles with different types which are made of a backdround tile image and an icon.

 

After making lots of performance tests to increase FPS, I have noticed that the major bottleneck is in "drawImage". Reducing the canvas size does not increase FPS, but reducing the number of visible elements really does.


To reduce the number of drawing calls, I want to use some sort of buffer, composing the images so on the rest of the game loops they only produce one draw call. I was thinking of using RedererTexture or BitmapData. Is there any advantage on using one over the other?

And also, given that these elements are in essence canvas objects, won't it hurt performance having one for each tile?

[lewster32]

All display objects in newer versions of Phaser have a cacheAsBitmap property (provided by pixi) which renders the contents of the object to a single flat texture (using a RenderTexture internally) so yeah, you can just do group.cacheAsBitmap = true and the rendering will speed up at the cost of some memory to hold this newly composed texture.

[mariogarranz]

Thanks a lot lewster! That sounds very interesting.

I will make some tests with this function to see if it helps.

[mariogarranz]

I was making lot of tests with the cacheAsBitmap option and I only got visible perfomance improvements when I created very big groups of tiles and cached them into a single bitmap (say, for exmaple, 90 out of 110 elements being treated as a single element and the 20 other elements staying independent).

 

 

Using cacheAsBitmap for every single tile did not improve performance at all. I tried creating "pre-rendered" images, having a single texture for every possible tile type, and then performance almost doubled. Now for every different tile background I will have to add "n" different textures again, so texture atlas will be bigger, but it seems to work a lot better than trying to do the pre-rendering on cache.

[lewster32]

Yeah this is ostensibly what cacheAsBitmap is for - to compose many elements (or single complex ones, like Graphics objects) down into a single texture, trading more memory usage for far fewer draw calls.

 

There's also SpriteBatch which you can try, however that turns off a lot of useful stuff to keep it as fast as possible.

[mariogarranz]

Thanks lewster.


I've been moving forward with the cacheAsBitmap, caching the whole board while it's not animating, and trying to move object out of the cached group whenever they need to be animated.

The thing is aparently, when a group has cacheAsBitmap set to true, it's children lose their inherited coordinates, and that happens also for children inside groups that are inside cached groups. See this example:

 

 

- General group

   - Group1

      - Tile1

      - Tile2

   - Group2

      - Tile3

      - Tile4

 

 

If I enable cacheAsBitmap in the General group, then Tile1...Tile4 will have their coordinate inheritance removed, even if you change Group1 coordinates to fix the change, it won't make any effect.

Is there an easy way I can keep tracking input event on these elements? Having them being positioned at a different place than they are being drawn makes it very difficult.

[lewster32]

Not as far as I know I'm afraid - cacheAsBitmap's expected behaviour is to flatten the whole tree below the object you select, and this means losing positioning, input and everything else as it stands. I imagine it wouldn't be too hard to put this functionality back in if the input is separated from the display logic a bit more, but I guess your best option right now is to have invisible sprites positioned in the same place above the flattened objects you want to interact with, and use them for your input tests.