Lots of sprites, improve performance

[mariogarranz]

I have a game with many sprites at the same time (around 100-200). Most of them are not even inside the screen, but I need them to be created just for game logic reasons. This logic is only applied on certain events, not in every update call.

Game resolution and the amount of graphics being drawn is almost the same as I've had for any other game I've developed before, but performance is way slower, specially in a "New iPad" with iOS 7.

I've tried everything, setting all sprites to invisible, disabling their bodies, etc. but even then performance is slow. If I reduce the number of sprites to 20 or so, performance is perfect, even though I am often just rendering 20 of them.

Disabling physics didn't solve the issue either.

Any idea on how can I improve the performance here?

[mariogarranz]

Just in case it helps understand better what I mean, the game is a bubble shooter where the board can go both up and down (not just down as in most bubble shooters) and you can shoot the bubble to the upper side of the screen where the board is not visible, which is the reason why I need sprites to be there even if they are not displayed and can't just use a recycling pool of bubbles when they are inside the screen.

[klg]

Hi mariogarranz,

 

I've almost the same situation as you do and haven't been able to figure out the solution. I'm not sure why there is no performance boost when I set visible or renderable property to false.

[ForgeableSum]

Have you tried switching the canvas renderer to webgl or 2d? webgl typically gives a performance boost but I suppose it depends on what you're doing. You can also try forcing 2D (by setting the rendered property to Phaser.CANVAS) instead of auto. 

 

Phaser should be able to handle 100-200 sprites easily, especially if there is nothing in the updates function. I would examine other factors. Just because the game is much faster with fewer sprites, doesn't necessarily mean the sprite # is the problem. There might be something else in the game affecting performance and increasing the sprite # puts you over the threshold of what the device can handle. 

 

What are you using for the environment, tiles? How many? I would examine all displayObject containers and check for large quantities of game objects, because that's the number 1 cause of memory leaks: too many objects. But 100-200 is not a lot. 

 

How does performance compare on PC? Can you send a link? It also might be worthwhile to run the Chrome javascript profiler - that will tell you exactly which processes are sucking up resources. 

[mariogarranz]

Have you tried switching the canvas renderer to webgl or 2d? webgl typically gives a performance boost but I suppose it depends on what you're doing. 

 

Phaser should be able to handle 100-200 sprites easily, especially if there is nothing in the updates function. I would examine other factors. Just because the game is much faster with fewer sprites, doesn't necessarily mean the sprite # is the problem. 

 

What are you using for the environment, tiles? How many? I would examine all displayObject containers and check for large quantities of game objects, because that's the number 1 cause of memory leaks: too many objects. But 100-200 is not a lot. 

 

Yeah I have tried both and different devices. WebGL is way faster, but even in WebGL I can see a clear performance boost when my board has 20 sprites to when it has 200 sprites, even if only 20 of them are renderable and have a body.

The game does mainly have just an image for background and then the sprites of this group, even removing the whole update logic performance stays the same, (I can see it when showing GUI dialogs with animations for example).

I did some profiling in the iPad, this is how it looks:

Purple is code execution time, red is drawing time. As you can see there is a fast switch between updating and drawing in the Menu state, but as soon as I enter the Game state, the time between draws goes up to 20 -25 times longer, taking 400ms in between each draw.

I can't profile any deeper with Safari (I think). In my PC it works fine with Chrome, I did some debugging too but saw nothing too conclusive.

[mariogarranz]

I have made different tests without any success.

 

Obejcts are not Sprites, but objects that extend the Sprite class, so I modified the whole class to use Sprite as a property rather than extend it without noticing any difference in performance. Completely disabling physics and collison checks didn't make a difference either.

These are the results of profiling the game in my computer with Chrome, both are visually the same, only in the first one I create all the sprites (about 350), and in the second one I just create the sprites that are inside the screen (around 100), which runs really smoother:








Any hint or idea would be very much appreciated because I'm absolutely lost right now.

[MichaelD]

I know its an unlikely factor but make sure to have nothing on the html part of the canvas element like border or background-color or any other css property.

 

Other than that, tweening animations are costly so try to reduce those as well if any.

 

In general canvas on tablets/mobile devices tends to suck badly. Also try to remove the objects that are not needed or setting them to alive = false.

 

Another long-shot but I have to say it, make sure the tablet is not on power-save mode, it really throttles the gpu and everything else...

[ZoomBox]

Have you tried to call .kill() on them where they're off screen ?

[spinnerbox]

You can try to group similar images as frames into one bigger image as spritesheet.

 

I am doing the same thing.  I have around 153 images and I grouped buttons into one big image. Then i use it as spritesheet, which saved me 30 different loads over network.

[mariogarranz]

Hey guys, thank you all very much for your responses.

@MichaelD:

I know it's something about the game itself, because I have made many other games that work on tablets and smartphones and they performed well, as this one does when I have less than 100 sprites created. About tweening, well, these performance issues happen even without animating, but I find tweening less expensive than physics and use it a lot. I guess I could make some improvements by recycling tweens (though Phaser Tween system is not very friendly with this idea AFAIK) but yet performance sucks even without any animation so that's definitely not the problem.


@ZoomBox

No, I didn't try that. I never use kill, just set exists and renderable to false, I'm not sure if there's a big difference between those, but I will look into it and give it a try. Thanks


@spinnerbox

Yeah, I already use atlases for these images, they are all inside one single atlas. But thanks for the tip

[stauzs]

If possible for your game - try to use Image instead of Sprite: http://phaser.io/docs/Phaser.Image.html/Phaser.Image.html
usually it significantly increases performance

[mariogarranz]

Thanks stauzs.

I use Images whenever I can. In this case, however, I need physics on them, which means they have to be Sprites I'm afraid.

[ZoomBox]

.kill() actually set renderable, visible and alive to false.

I believe it's the only thing it does.

[drhayes]

It's probably time to talk about how those Sprites are written code-wise. Are you using deep inheritance hierarchies? JS gets inefficient when traversing the prototype chain a lot. Do those Sprites start out as the same "class" but then each gets a bunch of custom properties added to them? That makes them what V8 (the JS engine in Chrome) calls "polymorphic types" which are much harder to optimize. I imagine other JS engines have similar heuristics around performance.

 

Do your sprites have lots of children? What do the sprites' textures look like, what size are they? Can you measure performance at 200, 500, 1000, 2000, etc., to get an idea of how quickly performance degrades, if there's some boundary?

[ForgeableSum]

I recommend trying out the Phaser Debug Module: http://www.html5gamedevs.com/topic/9243-phaser-debug-module/.

 

That will give you more granular info than Chrome's debugger.