I’ve been looking at techniques for creating large scrolling worlds with physics. I think one problem at the moment is that physics objects need to be tied into display objects, but adding display objects even if they are not visible can slow down the system. really I think we want to be able to move around a logical physical world but only render display objects in the camera view.
This is discussed here:
http://www.box2d.org/forum/viewtopic.php?f=3&t=4710&start=0
They use a big sensor rect to determine the viewport in a physical sense. Any objects colliding with the this sensor can then be rendererd as visual display objects
I’m not sure if this is the best method, but in my scroll tests for example creating a large world of invisible display objects up front does not lead to good performance eg here:
http://developer.anscamobile.com/forum/2010/12/11/another-scrolling-performance-test
as a solution to this
http://developer.anscamobile.com/forum/2010/11/22/scrolling-large-non-tiled-world-objects
I’m not even using physics at that point but it shows that creating more than say 10 screens of invisible objects can lead to performance issues. really we only want to create the positions of the physical objects logically and only render a small number of items that are on screen. Presumably the “game edition” sprite engine could be used to quickly “blit” these graphics to the positions of the logical box2d objects
I dont know how well the box2d implementation performs with large worlds, but i thought there were some “broad phase” calculations so that remote offscreen objects were not tested in the physics steps.
(Is the solution to not create a large box2d world in advance? but just add physical items dynamically around the current viewport, based on positional data, and cull them in an optimized manner rather than a realistic manner… ie kill the object if it leaves a radius bigger than 2 screens, rather than track it permanently?)
[import]uid: 6645 topic_id: 4490 reply_id: 304490[/import]