Understanding CPU usage

[Benjans]

Hi everyone,

 

I need your help to understand advanced behaviors in Phaser.

We're developing a big game with Phaser, we have many sprites, many layers and many animations. We have texts, and transparency too. Everything we need to make the game slow and with poor FPS

We want to optimize the game one step after another, and we want to understand, too, what is the most consuming task.

 

The game is currently running at 40 to 50 FPS on a desktop, with some minor slowdowns, but that is ok for us.

On a mobile phone, even with big hardware (iPhone 5s, Xperia Z1, HTC One M8), it runs at 2 to 10 FPS, unplayable.

The strange thing is that we tried to run the game on the iOS simulator, to profil it, and the result was exactly the same as on mobile.

In fact, on mobile and iOS simulator, the CPU usage is 120%.

On desktop browser, the usage is 30%.

 

We are totally sure that the problem is CPU usage because memory use and access are ok.

 

Do you have any idea, why this happens? Why the same code runs great on desktop, and not on mobile browser, even in a simulator?

Any help would be appreciated, cause we are lost

 

Thank you guys!

[Arcanorum]

Rendering tends to top the list for resource consumption. Think about how you can reduce amount of active sprites, consolidate layers, simplify animations.

 

Doing mass collision tests also takes it's toll. I haven't used Phaser's implementation of it yet, but quadtree partitioning is a smart way to go about reducing collision overheads.

 

As for the iOS simulator, I assume it is limiting how much of your hardware it will let you use, trying to replicate the actual device's spec, to achieve more realistic results. Would make sense, but IDK, I haven't used it.

[xerver]

Nearly done with a phaser debug module that may shed some light into issues like this. I recently encountered some CPU issues and wanted to take a closer look into which area was causing it so I started building this. Give me the weekend and I'll open source it.

[nuvorm]

@Benjans

sprite batching should be a good way to boost performance i guess.

I just posted a topic regarding an issue i have with sprie batching not updating the sprites body.

Maybe someone can shed some light into this.

@xerver that would be awesome.

[Benjans]

Hi everyone,

 

Thank you for your answers!

We're still investigating about it, we found several minor fixes (deactivating sprites with transparency, reducing number of "text fields", etc...).

 

@xerver would be awesome! When do you think we can check it?

[xerver]

Just open sourced it today: https://github.com/englercj/phaser-debug

 

It is pretty simple right now, hopefully will be extending it with more features as they are needed. Feel free to report any issues and contribute!

[Glaydur]

Just open sourced it today: https://github.com/englercj/phaser-debug

 

It is pretty simple right now, hopefully will be extending it with more features as they are needed. Feel free to report any issues and contribute!

Awesome! I'll try it out right now. Maybe you can make a yeoman generator for this and make a pull request to include it in the phaser-official generator

[San4er]

Just open sourced it today: https://github.com/englercj/phaser-debug

 

It is pretty simple right now, hopefully will be extending it with more features as they are needed. Feel free to report any issues and contribute!

It always shows 59-60fps while game.timer.fps shows 47-60 depending on performance.

[xerver]

The fps in debug is calculated on the time elapsed from the start of one game update to the next start of game update; not sure what else to say.

 

If you think something is wrong, then read this and then post here with a reproducible test case.

[pandavigoureux29]

Thanks for that. This should be really useful ( my game is slow on tablets and I don't know why ).

 

One question though : are "draws" referring to Draw Calls or is it just the number of sprite displayed at screen ?

[Benjans]

Thank you so much xerver! We'll try it today.

By the way the game I was talking about is online now: http://battleforparis.redbullbcone.com/#/

The "battle" part is made with Phaser, and we had problems with mobile version (we chose to deactivate some animations on mobile).

Sorry, there are still pieces of french texts here and there, but we are correcting it

[xerver]

Thanks for that. This should be really useful ( my game is slow on tablets and I don't know why ).

 

One question though : are "draws" referring to Draw Calls or is it just the number of sprite displayed at screen ?

 

That is the number of draw calls that are made each frame.

[pandavigoureux29]

Okay thanks.

As far as I know 40 is too much on a mobile device.

I should search for a way to reduce them ( 30 seems to be okay on my nexus7)

[valueerror]

draws N/A  on my game in the debug plugin..   am i doing something wrong?

 

edit: oh..  it was running in canvas mode ^^   

[valueerror]

sorry..  could someone please explain the meaning of "draws" ?   i've got 24 and when an emitter starts i got around 30 - it then goes back to 24..   removing the background gets me to 23 BUT removing all the objects (plants, signs, etc.)  changes nothing..

 

killing one or two sprites also changes nothing..  killing all sprites of the same type seems to reduce the number of draws..

 

so it is NOT the sheer number of sprites on the display ... right?  how can i reduce draws then if i would want to ..  

[pandavigoureux29]

As xerver said, "draws" refers to draw calls. 

 

From what I recall, a draw call is a call from the CPU to the GPU, sending data like vertices, transform matrices and textures, in order to draw on the screen every frame.

 

A sprite usually induces one draw call. But if two sprites share the same texture, they can "share" the draw call, then inducing only one draw call for two different sprites ( it's called Batching)

 

To reduce draw calls, you can use atlases, which can regroup mutliple textures of different sizes ( unlike spritesheets ), though this require some extra work, using a software like TexturePacker ( or a FREE one here ).

 

Another solution may be to regroup your assets with a similar size in a spritesheet, then making your own restrictive atlases. 

[gwinnell]

https://github.com/englercj/phaser-debug has come in really useful so far in my Phaser project. Big props to the developer!

 

I've recently been trying to modify the source to it so I can see the ".visible" property of objects/groups in the Scene panel. I can't for the life of me see where the Handlebar template values are being set though. Dang. Is something missing from the repository?