The cost of huge worlds and off-screen sprites?

[InsaneHero]

How CPU expensive is maintaining a large off-screen sprite list in PIXI/Phaser and will having a huge world cause any problems (45k wide and high)?

 

I've implemented a virtual camera to make a window into a huge box2d world, and I'm debating whether I should create/destroy sprites that are outside of the window, or just create them all at the start and leave them there.  Also if I go the latter route, would it make more sense to use the Phaser camera instead?

(The 'virtual camera' is an offset which is applied to all the sprites every frame, incurring a fairly significant cost if I precreate them all - but that is offset against the cost of calculating what should be created/destroyed... So I'm left with the unknown aspect of how much work these systems do to support sprites which are not currently visible and the huge world question).

 

I've just started to poke into the code to try to find my own answer, but if anyone knows this off the top of their heads it could save me a lot of time 

 

 

[sbat]

I've implemented a virtual camera to make a window into a huge box2d world, and I'm debating whether I should create/destroy sprites that are outside of the window, or just create them all at the start and leave them there.  

 

InsaneHero, pardon me please for slight offtopic. But are your experiment showing that "huge box2d world" is going to perform on its own? From what I heard in casual chats with devs, even relatively small box2d worlds (like less <100 bodies) are not always performing on par with their expectations on mobiles. Or you are targeting desktops only?

[InsaneHero]

So far I haven't done any testing on mobile.  My understanding of Box2D is that it partitions the world so it can discard the majority of potential collisions incredibly quickly (hash tables if I remember the old C version correctly)... given that my physics world is just two complex moving things, and one giant static poly shape, I'm hoping that the performance will be sufficient for mobile too.

Also, I can't really improve box2d so I'm watching every cycle in the rest of the implementation!

[rich]

Two suggestions:

 

1) I would use the 1.0.7 dev branch of phaser (in case you're not) as it has a much more optimised Sprite update loop and overall World/Camera handling.

 

2) Secondly you can use the Sprite camera cull property to stop it from being drawn outside of the camera. This means it will still get iterated upon in the display list loop but skipped for the actual render pass, which is the most expensive bit.

 

3) If you're using Box2D then using the 1.0.7-dev branch you should set the Sprite bodies to be null (sprite.body = null), then they won't try and do any of their own physics and more importantly won't insert themselves into the world quad tree either.

 

So I guess that's 3 things really