Phaser Arcade Physics Circle Performance Questions

Phaser 3
1

Hello together!

I am currently experimenting with ways to improve the ArcadePhysics performance of my game, because that is the main bottleneck.
For this, I set up a new repo to collect some best practices.

My first experiment is in using Object Pools:
I create 200 circle-formed ArcadeSprites, add them to one group, then disable their bodies, then add collision for the group with itself.

The use case would be for example just collision between units and walls.
You can “see” it live here: https://luccahellriegel.github.io/Phaser3-Best-Practices/prod/game.html
The code can be found here in the function oneGroup here:
https://github.com/LuccaHellriegel/Phaser3-Best-Practices/blob/master/src/physics-perf.ts
The sprites are created here:
https://github.com/LuccaHellriegel/Phaser3-Best-Practices/blob/master/src/util.ts
(These 20 lines is all that is happening)

The CPU Usage jumps to 40-60% from just doing the above, when I just was expecting an increase in Heap Size because there aren’t any collisions happening. There are also some peaks that go up to 80%. They can be reduced a little by removing the collision, the rest of the performance does not improve, which leads me to believe that disabled objects are CPU intensive anyways.
For reference an empty phaser game is at 5-10% CPU Usage.

My current question is, is using an ArcadePhysics ObjectPool a known Anti-Pattern?
Or phrased differently: why does it cost so many additional CPU cycles to have disabled circle-formed sprites?
While preparing this post, I also found out that you can cut the 40-60% by 20+% by having the disabled sprites not be circle shaped. (So, commenting out sprite.setCircle(40). Increasing the size of the sprite with sprite.setSize(40,40) does not reduce the performance). So it really is something about circles
that is tripping up the physics engine, even if the body is disabled.

All the best,
Lucca

2

Phaser v3.23.0 will have some optimizations for colliding disabled bodies. For better performance use this.physics.world.disableBody() and this.physics.world.enableBody(), as those modify the search tree.

In that example all of the bodies are “colliding” in the search tree (because all sprites have identical positions), so some CPU will be spent looping through all those hits. I don’t know why circular bodies would be more expensive in that case, though.

Have you checked the profiler?

3

Thanks for the hint with the world-functions.
Actually, this was the one time I did not look a the profiler carefully enough (because for me usually the physics were the problem)…
image
As you can see, the CPU is occupied by what I assume are drawing the circle-shapes for the sprites,
because I am in debug-mode.
So deactivating the debug-mode or setting
(sprite as Phaser.Physics.Arcade.Sprite).body.debugShowBody = false;
put the CPU usage back in normal areas.
The difference that I observed remains however. This means that drawing the debug-body for circles is much more performance heavy than drawing the regular squares (this might be expected?).
Anyways, what I learned is, that I should deactivate the debug body of my pool objects.