[Solved] sonic style platorm game question

Aug 29, 2012 at 11:22 AM

Hey guys,

I want to ask anyone who might know about a the practicality of a usage scenario I have in mind for fse.

I've long had an idea to make a sonic the hedgehog styled platformer game, and I'd like to use a physics engine like fse to do it. One aspect of this would be the ability to have long sprawling game levels. I gather this would cause performance issues and memory usage issues if I were to load it all into an fse world in one go.. But I've wondered would I experience performance issues if I loaded level objects only as the entered the camera viewport and then unloaded the objects as they left it. Keep in mind I want to be able to maintain a smooth 60fps frame rate. I know this should technically work, but I'm worried is there a big performance penalty for removing bodies from the world like this? I'm also concerned about creating a lit of garbage, would there be a lot of work in creating an object pool I can use to recycle objects I've removed from the world?

Many thanks

Brian

Sep 10, 2012 at 7:19 PM

Static objects actually do not take up much resources.

So give it a try without optimization and it might still work for you. However remeber to simplify your shapes to save as many verticies as possible.

Sep 15, 2012 at 9:26 PM

I have actually run into performance issues loading all the static objects for a level at the start. There is certainly some major optimisation I can do regarding the number of shapes, but I would like to implement some sort of add/remove on the fly. or perhaps keep a cache and move them about to where needed?

Does anyone know the most efficient way to do this? Ill most likely stay with all-preloaded static shapes, but any ideas people have would be interesting?

I assume that the major issue with adding on the fly is the recalculation of the space partioning tree. as such i imagine that moving shapes about (teleporting) is almost as costly as creating and deleting on the fly.

I am loading about 2 to 3 thousands static shapes currently on a Windows Phone game and I'm getting some slow down.

Sep 28, 2012 at 9:28 AM
AlzPatz wrote:

I have actually run into performance issues loading all the static objects for a level at the start. There is certainly some major optimisation I can do regarding the number of shapes, but I would like to implement some sort of add/remove on the fly. or perhaps keep a cache and move them about to where needed?

Does anyone know the most efficient way to do this? Ill most likely stay with all-preloaded static shapes, but any ideas people have would be interesting?

I assume that the major issue with adding on the fly is the recalculation of the space partioning tree. as such i imagine that moving shapes about (teleporting) is almost as costly as creating and deleting on the fly.

I am loading about 2 to 3 thousands static shapes currently on a Windows Phone game and I'm getting some slow down.


hmm, that's not terribly encouraging. From research I've done I believe the best way to make game worlds like these performant would be to use multi-SAP broadphase instead of just SAP. I had a look at seeing could I implement this myself, but the work seems too over my head/time consuming for me personally. I might be faster using a c++ library that already supports multi-SAP, but I would love to stay in c# land.

Anyone have any ideas how difficult implementing this work in farseer would be? Would anyone else find the ability to have large sprawling worlds useful?

Nov 9, 2012 at 12:33 PM

Hi - Sorry to bump this. But does anyone have any advice for creating large levels of static bodies. I load them all and get poor performance. What is the best way to dynamically load? Should it be possible to turn bodies off and on with reasonably low level of slow down?

 

Thank you

Coordinator
Nov 9, 2012 at 1:35 PM

Loading large worlds is a scenario that I never optimized Farseer Physics Engine for. I actually have slowed it down when trying to simplify the engine, and making it easier to use. But don't worry, there are things you can do. First I will explain why it takes some time to create large worlds (only applies to FPE 3.x).

Problems

Body Creation
The main reason it takes quite some time to create a large static world, is the fact that the broad phase worst case scenario is creating a large amount of static bodies, in a systematic pattern. Creating a world of 10000 bodies will take a large amount of time, even on a fast PC. This is due to the way the dynamic tree behaves when you insert a large amount of bodies.

Body Positioning
The second reason is the fact that positioning bodies actually makes the broadphase check for collisions. It has to do this, or bodies will sort of transport in the world, and this will cause all sort of weird behaviors. The solution to this, is to call Body.SetTransformIgnoreContacts() to move the body into the correct position once it has been created. Using the BodyFactory will not work, as it calls the Position property instead of SetTransformIgnoreContacts.

---

Note: The good new is that I've fixed both of those issues in Farseer Physics Engine 3.5. With that being said, there is no way for me to optimize for every possible scenario that can happen, and creating large static worlds will probably always take some time compared to a lot of other scenarios.

-----

Solutions

Polygons With Too Many Vertices

Keep the number of vertices as low as possible on polygons. The default limit is 8, if you create more vertices than 8, it will slow down the engine on each collision. Never use polygons as a way to build the terrain, use edges instead. Static edges will have CCD enabled, so you won't have problems with tunneling issues. Most times you would like a concave, smooth colliding terrain - and those 2, you can't get with polygons, but you can with chained edges.

One Body, Multiple Fixtures
If you create a large world, try to keep the number of bodies to a minimum. You only need a single body for the whole world, but you can have multiple fixtures. Simply use the BodyFactory.CreateEdge() to create a body with a single edge attached. Then use FixtureFactory.AttachEdge() to attach multiple edges to that body. This will speed up the engine as it does not have to keep track of multiple bodies.

Load Your World With as Much Static Data as Possible
This point makes good sense, but no one ever does it. Because of the powers of Farseer Physics, you have the ability to trace a texture, triangulate it to convex shapes, stitch them together and make complex polygons. However, this procedure is really slow, and there is no need to do more than once. Do all the calculations you need, triangulate all the shapes and trace the textures, but save the results for later! Calling all those algorithms while in-game will cause problems and slow downs, simply do it once and save the results on the hard drive, and use it multiple times.

Remember to Turn Off Debugging
This not only applies to the build configuration. Remember to always test with release builds, as they depict the real performance. But also remember to turn off debugging in Farseer. You can do this inside Settings.cs, and you simply set the EnableDiagnostics to false, and you will have a bit more performance.

Nov 9, 2012 at 1:56 PM

Thanks GenBox - as always, super useful thank you.

I had been using a level editor and the marching squares to create thes static level polygons. I was then loading them as polygons (not edges) and using one body per small polygon!! So there are obvious optimisations there!

Ill also check debug.

Thanks!

Coordinator
Nov 11, 2012 at 8:43 PM

I forgot to answer the original question. Sorry about that.

If you create a large world and have performance problems, then you can use a view AABB that loads and unloads objects. However, try disabling and enabling the objects first; disabling an object will actually take it out of the simulation.

Otherwise object pools are the right way to do it. This way you can misuse the memory a bit, but get better performance on the CPU.