This project has moved and is read-only. For the latest updates, please go here.

Performance question - Using farseer in platformer

May 19, 2010 at 7:53 AM

Hello all!


First off, I've been working with the farseer enginge for some time now, and wow. Awsesome physics made so simple, it's a delight to work with it. Thanks!


Then to my question. I'm making a retro - platformer thingy game, using Farseer as my main engine. The levels in the platformer consists of ~60x40 px blocks, wich all have their own body and geometry in the game. A complete level will, roughly, consist of 300- 2000 of these blocks. 


Are there anyone who has done something similar, and could tell me if this will be a huge drag or not? Is there any tweaks I should implement early in the development stages to boost performance? 

And what kind of collision detection should I use for the ground and/or player/enemies?


If I've made myself unclear, don't hesitate to ask =)



May 19, 2010 at 8:01 AM

Will all of these blocks be arranged in a grid pattern, or can they be freely placed? Do all of these blocks need to be reactive to physics, i.e. pushing, falling... or will they mostly be static? The best major tweak I can think of is to only enable the blocks that are on screen or within a certain distance to the player. That way it shouldn't really matter how many blocks there are, since only a handful will be in the physics simulation.

May 19, 2010 at 8:16 AM

Well, all my groundblocks will be static rectangles, aligned in a grid. Just used to walk on. 

The problem I think about when talking about disabling some blocks, are how  to prevent the other things that move around in the level, from falling down? 


Thanks for the reply.

May 19, 2010 at 8:30 AM

Well you would probably want to disable those things as well. If they are enemies that just walk back and forth on a platform this shouldn't be a problem. But if they need to persist and chase you across long distances or something then it may be a problem. You could perhaps enable the  blocks around these people as well once they have been activated. An enemy toward the end of the level doesn't even need to exist until the player gets there.

For the static blocks you might want to do something that creates a large rectangle around all of the small blocks in a group. So, instead of having 10 60x40 rectangle bodies next to each other, you can have one 600x40 rectangle body.

May 19, 2010 at 8:45 AM
Edited May 19, 2010 at 9:44 AM

Hmm, this has given me something to think about. So in disabling, one could just implement something that disables everything outside a certain range of the player? 

And about the blocks, that's a pretty good idea. It may be a bit tricky to implement, since all the lengths will be dynamic, and I want to draw the tiles repeated across the platform. 

What are hardest on the simulator, bodies or geoms?


And, does the simulatorView have some sort of FPS-printout, or do I have to calculate it myselves?



May 19, 2010 at 1:19 PM

I've managed to make the wider bodies and geoms, based on the grid. Next step is disabling those outside of the viewRect =)

Thanks radnemos =)


Any others have some thoughts or tips?

May 20, 2010 at 1:02 AM

Another idea is to have areas, where instead of activating items separately, you activate only the areas that are nearest the player, and all the items inside it.

The main advantage of this is in situations where disabling half the bodies could cause problems, such as a physics based contraption or an area swarming with monsters. 

May 20, 2010 at 9:14 AM

Interesting idea. You are thinking about dynamically making areas when the map loads, right?

If so, one solution is to make areas the same size as the viewport (maybe plus a little bit) and align them in a grid. 

At one specific time, only the four areas that are adjacent to the player (or the viewport) is active. 

This is a very good idea for the static tiles! But how about the enemies, wich should be able to move from one area to another?

I could update the specific enemy's area based on the current position, but I think that would be a lot of calculations pr tick. 


I will definitely give this a try! 

Btw, I'm planning on upgrading to FP3 when it releases. Should I wait a week with implementing this, or is this kind of functionality basically the same in the new version?


Thanks for taking the time RobertDodd, I'm sure you got your hands full these days =)