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

Farseer with Tile Engine

Topics: Developer Forum
Aug 21, 2008 at 4:30 AM
If I want to implement a 2D side scrolling tile engine do I need to make each tile a farseer object?  That seems very inefficient.  Any thoughts?
Aug 21, 2008 at 9:53 AM
No, only the objects you want to take part in the physics simulation.

That means, any object that should be able to collide with something else, needs to be a 'Farseer object'.

For a 2D side scrolling game, that might include the player character, enemies, the ground, perhaps some pickups and perhaps some weapons (Grenades?).
Aug 21, 2008 at 4:17 PM
So can the farseer bodies and geometries react with a tile engine?  I'm not sure i understand how that would work if the actual tiles are not farseer objects.
Aug 21, 2008 at 8:38 PM
The only reason why you would want every tile to be a farseer element is because of the collision detection. If the game is seen from the top, there really is no reason for using farseer as it only is for games that require physics.

I would recommend that you use boundingbox for collisiondetection instead. It's fast and simple.
Aug 21, 2008 at 9:27 PM
I guess ultimately my question is:

How does this guy integrate the farseer engine into the tile engine?
Aug 22, 2008 at 5:57 PM
Oh... sorry.

Did not read the part where it said side scroll game. My bad.

Well then... Yes, create every title as a farseer object. Static objects like the most of them in the game you linked to, is relative lightweight since they don't change position. (like the wall)

There are several methods of optimizing performance in a physics engine. One is only activating the farseer objects nearby the player. Another is pause the physics calculations of objects coming to rest. (This is being implemented by another here on the forums Look here for info).

If it still proves to be to much for your computer to handle, you can still use boundingbox for collision detection in all static objects (walls)
Aug 22, 2008 at 6:45 PM
Edited Aug 22, 2008 at 8:56 PM
genbox - excellent!  Thanks for your implementation tips - they are very helpful.

In terms of performance would the following ideas be advisable?

1. Use one large polygon to create the ground.

2. Instead of using square tiles I could use large rectangle tiles and small square tiles where needed.
Aug 22, 2008 at 11:29 PM
1) Yes, it would be better performance wise to create a large object for the ground and walls.
2) Yes, the bigger you can make the size of the objects, the better. It simplifies the work the engine has to do.

I'm happy to be of assistance. Don't hesitate to ask if you got any problems with the physics.
Aug 25, 2008 at 2:17 PM
Edited Aug 25, 2008 at 2:18 PM
If the game is seen from the top, there really is no reason for using farseer as it only is for games that require physics.

So a game viewed from the top doesn't need any physics? My game is viewed from the top and of course it requieres physics. Physics don't change just because your view is different.

Did not read the part where it said side scroll game. My bad.

The first sentance I responded to wasn't a mistake?

1) Yes, it would be better performance wise to create a large object for the ground and walls.


2) Yes, the bigger you can make the size of the objects, the better. It simplifies the work the engine has to do.

What? Why? I've checked that a long time ago and it's better to use many small objects. It's even more important to use small objects now, because if you don't then you won't get any performance boost out of dp2208's improvements.

Colliding with a small object is faster then with a large object because a smaller object has less vertices. Also, with a smaller object the collisions are more detailed because you can't set the collisiongrid size too small for a large object - it ends in a slowdown.

AFAIK -.- ... I'd like to hear from Jeff :).
Aug 25, 2008 at 2:30 PM
Edited Aug 25, 2008 at 2:37 PM
When I said that a top-down game does not really use physics, it of course depends on the type of game. I've seen a lot of top-down games that uses physics, and a lot of them could be without as it just adds more complexity to the game.
A role-playing game does not need physics (I have seen some with), I've even seen a chess game with complicated collision detection based on a large grid instead of just checking if one characters position is equal to the other. (center based position)

The physics engine is 2 parts: Collision detection and dynamics. You can use them separate.
If you want your object to react to force, torque and gravity and you don't need collision detect. Then you can do that.

When I was thinking of performance, I was thinking of all the iterations the engine make on it's elements. A triangle is also just 3 vertices no matter how large it is. I have not tested it in any way and I might be wrong.

I would like to see some performance tests of farseer if you can provide some. It would be nice to see how it handles geometries differently
Aug 25, 2008 at 2:37 PM
Edited Aug 25, 2008 at 2:37 PM
I think I've got to create some farseer testing videos now ;D ...

I'll post again when they are up.

Since I'm at work you'll have to wait a bit.

Aug 25, 2008 at 2:38 PM
Thanks :)

Could you include dp2208's performance enhancements in one of them? I have not had the time to play with it yet.
Aug 25, 2008 at 2:40 PM
I'd love to, where can I download the code?
Aug 25, 2008 at 2:44 PM
Download here

Unfortunately I'm not yet done with the refactoring of Farseer as I created a bug in the collision detection system by mistake.
More info here

But a new version of Farseer will soon be out, and we all get to play with the new and polished Farseer :)

Aug 25, 2008 at 2:53 PM
The other thread says it doesn't work with XNA?
Aug 25, 2008 at 2:59 PM
The first link I gave contains the master build of the Farseer engine. It should just need a little tweaking and then it will work with XNA. The current source code check-in (not a release) does not work with XNA. It does not work at all right now :)

Try it out and see what happens. If you have any problems with the build. Please contact me and I will try to get it fixed.
Aug 25, 2008 at 3:12 PM
Ok, I'll check it out.
Thanks :).
Aug 25, 2008 at 4:10 PM
sickbattery - Thanks for putting together some performance tests!  That should really help me and others.  I look forward to seeing your results.
Aug 25, 2008 at 8:32 PM
Ok guys I have to disappoint you for today. I got a little bit drunk because some stupid f***ing girls are pissing me the f*** off -.- ... I'll code and create the videos as soon as possible. I've already got some ideas and I'll test with Vista and XP 'cuz I've both installed.

Uhm, yeah ... give me max two days then there will be some stuff online on youtube and vimeo.
Aug 25, 2008 at 8:43 PM
Edited Aug 27, 2008 at 4:10 PM
It's okay. No rush.

I tell you what, I upload the current release of the source control for you. It's a stable version now and includes the improvements that dp2208 made. This way you do me a favor. You will test the release and harvest the performance of the new and polished Farseer engine. This version of the engine also works with XNA 3.0 ;)

Tell those girls to get lost, you have important things to do ;)

EDIT: The source code that contains the dp2208 improvements and a XNA 3.0 release can be found here:

Please keep us posted on your progress.
Aug 27, 2008 at 2:37 PM
It's okay. No rush.

You mean it :)? How about saturday evening? *joking
I don't know how far I'll get this today.

I'll try to sneak out of the office as soon as possible, but I was late -.- ...
Although we have flexitime my chef stresses me anyway if I use it.
... maybe because I'm so often late.

Nobody knows ;).
Aug 27, 2008 at 6:40 PM
Ok, I'm working on it. I'll have to modify my BigTexture2D class, that might become time consuming.
I hope I can put up some stuff today.
Aug 27, 2008 at 6:47 PM
I look forward to your findings!
Aug 27, 2008 at 11:08 PM
Edited Aug 28, 2008 at 1:45 PM
Stop that! Don't put me under pressure ;D ...

However my BigTexture2D isn't ready yet -.- ... The good thing about all this is that I'm finally working on my game again. Well, the engine. I want to use BigTexture2D for levels in my game. I'll probably release the code, too. If you want to have it?

Tell those girls to get lost, you have important things to do ;)

Yeah. ... but I have to deal with that, to get them to foxtrot uniform charlie kilo with me ¬.¬ ... u know?

Aug 27, 2008 at 11:14 PM
" I want to use BigTexture2D for levels in my game. I'll probably release the code, too. If you want to have it?"

What is BigTexture2D?
Aug 28, 2008 at 2:01 PM
Edited Aug 28, 2008 at 9:23 PM
It's a big 2d texture class :). - Now that's a stupid answer ^^ ... shoot me. (I'm just so happy... I bought this )

It's a class that makes it possible to load very big textures. 4096x4096? 8192x8192? Whatever the windows image loader (GDI+) can load ... (how awful, I can't remember it's limits -.- ...). It can splitt that texture by a variable side length. For example 128 or 256 or 123, whatever you like. It aslo draws the texture, so you don't have to put the parts together on your own. ... and now I'm trying to implement farseer collisions into it.

Basically you can create a level with one large texture and simply load it. Collision data will be generated automatically.

Collision data will be generated automatically.
Hmm. I'll have to release my Vertices.CreatePolygon() function aswell ... but it's a bit dirty ... ... not so well written. I wanted to rewrite it before I put it online.

6pm and I'm still at work ... I'm at 7pm at home, at 8pm I'm done with the new case ...

It's 22.20pm I look like this: (tired - very healthy)
And all I can think of is this: (beer and pizza - very healthy, too)

^^ ... you have jobs, too. You'll understand the delay oO. Right?
Aug 31, 2008 at 5:01 PM
Ok. I'm testing (50%) and creating the vids (25%).
I'm sure I can upload them today.

My first thoughts were way too complicated. It's easier then I thought.

I don't want to spoil, but you might get results - no one would ever thought of :P ...
Aug 31, 2008 at 5:31 PM
Testing: Done.
Videos: 33%
Aug 31, 2008 at 10:59 PM
Edited Sep 1, 2008 at 11:15 AM

I guess I'll have to explain a lot. That's because I was tired - once again - when I made this. Ask your questions ...
Aug 31, 2008 at 11:17 PM
Edited Aug 31, 2008 at 11:33 PM
I'm sure I can upload them today.

Now, that was close oO ...

So the question is answerd now ...

When I was thinking of performance, I was thinking of all the iterations the engine make on it's elements. A triangle is also just 3 vertices no matter how large it is. I have not tested it in any way and I might be wrong.

512x512px with some complexity will slow the engine down on collisions. Take a look at my level it's not really complex.
Aug 31, 2008 at 11:42 PM
I can conclude one thing from the video: You are insane. :D

Guitar Hero 3... hahaha.

Oh well, I will have a closer look at the video and the new additions when I get the time.
Sep 1, 2008 at 11:13 AM
Yeah ... GH III is the best ;D. Did you like my Nintendo shirt ^^? I've put it on to make all the Microsoft-Fanboys angry, hehe. But don't get me wrong I bought Vista a month ago :). I just dislike preconceptions, which doesn't mean that I don't have any. I'm just saying that I don't like'em (at least question them) :).

Uhm. PhysicsSimulator.InactivityController.Enabled is by default set to false and all I had to do was to set it to true, right? Or is there more to do to turn it off or on completely? I really wonder that the engine is so slow even if the InactivityController is turned off o.O ...
Sep 1, 2008 at 1:07 PM
I have not had the time to have a closer look at it, but there is also another feature called Scaling that is disabled by default.
The inactivity controller is also disabled by default.

The version you descripe as "new" in the video, is that the source control version?
Sep 1, 2008 at 2:08 PM
It's the one you told me to use.
Sep 1, 2008 at 2:09 PM
Just found that out :)

There is some major problem with it. I'm stress testing the source control version, and something is very wrong. I will find it and fix it, then you can test the inactivitycontroller properly.
Sep 2, 2008 at 4:02 PM
I have not had the time to test it properly, but I think this version does the trick:
Download here

There must have been some GC problems or compiler optimizations missing. I don't know. It's hard to troubleshoot such problems when almost every file in the project is changed from one changeset to the other.
One thing is universally true: It was my fault that the engine was very slow. Sorry about that. I have no Guitar Hero... I think that is the problem.

Try it out and tell us your results :)
Sep 2, 2008 at 4:15 PM
Thanks for creating the videos!!  You're awesome and so is Guitar Hero 3!

Just to clarify,

If I'm creating a tile based engine the tiles should be around 256x256?

Is it better to create rectangles or can i create sloped terrain without majorly effecting the FPS?

Sep 5, 2008 at 3:31 PM
Edited Sep 5, 2008 at 3:42 PM
I'll try create a new video this weekend :).

256px textures seem to have the best size/complexity-ratio in my demo. You should write code that is flexible and test the results. My BigTexture2D (which loads big textures, splits them and creates the collision data) is configurable. I can set the splitsize as I like to.

But probably a size between 128px and 256px is the best choice.

Using small textures is bad and using large textures is bad, too. That's because with small textures you have meny objects that have to be pre-checkt for collisions and with big textures you have a complex polygon with meny vertices. You'll have to find out what's the best ratio for your game because it depends on the complexity of the objects you are using.

So, we were both right xD ...
Sep 5, 2008 at 10:59 PM
Thanks a lot sickbattery. I know it's hard for you to let go of GH more than 5 minutes at the time. :) Really appreciate it.
Sep 10, 2008 at 8:53 PM
Didn't play GH ... didn't have any time. I've got to tell you, I hate women ^^ ... (no, not really)

But today I'll be early in bed so there is a very good chance that I'll make a new video tomorow. It's not that hard anymore. I'll just switch the engines and the demo will stay the same, so ... I think I can asure you that there will be a new testing vid online tomorrow.

I hope you still want to have it oO. Sorry for making you wait - again ¬_¬ ...
Sep 11, 2008 at 8:11 AM
@sickbattery - No problem, I do still want the new video. Would be nice to see if I fixed the performance bug.
Sep 11, 2008 at 8:34 PM
Edited Sep 11, 2008 at 8:46 PM
Ok. I'm not going to make a new video because I would consist of two screenshots xD ...

I'v used the 256px textures and the result is that the old engine is still faster. 

You improved the performance from ~75fps to:
OFF 105fps
IC 102fps
SCALING 103fps
IC + SCALING 105fps

... but OLD is 120fps.

Well, it's ok that scaling and the inactivity controller steal some cpu time but off should match the old engines performance... I think. Edit: Also the old engine doesn't jitter at all im my test.
Sep 11, 2008 at 9:48 PM
One thing is very true. The Farseer code is very fragile :)

I've just testet the code myself and it seems that you are right. In my test farseer runs at ~170 in and ~121 in 2.0
I removed all readonly and const keywords that I've put in the 2.0 code and the issue was gone.

Not both are at ~170 FPS (without scaling and stuff)

Could you try it out sickbattery? do a search&replace for "readonly" and "const" and replace it with "" (nothing).
There is one place where const is necessary, and that is in CollisionHelper.cs, so undo the replacing in that file.

If that is not going to work correctly, then I will have to be more conservative when changing code.
Sep 12, 2008 at 10:42 AM
Will do :).