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

Performance improvements made

Topics: Developer Forum, Project Management Forum
Aug 6, 2008 at 1:40 PM
Edited Aug 6, 2008 at 1:42 PM

i wanted to show you a video of my "InactivityController":

I am planning to release it soon and wanted to know, if it could be added to the engine.

Aug 6, 2008 at 10:19 PM
Oh, ok.  Took me a minute to figure out what it was doing.  I guess when they're yellow and red that means they're having collision processing done on them.  Sounds good.  I haven't had too many performance issues out of Farseer but it never hurts to squeeze a little more performance out of it.
Aug 7, 2008 at 12:06 AM
It simply increases the number of possible bodies/geoms, when they are not all colliding at each other. I need this because my game will have big levels. The objects not affected by forces will then be deactivated. If you do the same, you can benefit from this method.

I noticed that the performance issues are caused due to the intense use of lists, that are managed and refilled in every update. May be its GC related. My method does not solve this problem. It simply doesn't appear anymore when using the engine the way i described.

The final solution would be to reorganize the structure of the engine.
And that is way too big for me ;)

I tried to manage the list in separate threads on different cores of the xbox but this is difficult because the current procedures of the colliders are all effecting its membervariables (counting stuff etc...).

May be crashlander could say something about this problem. Do you have a hint for me where to start?
Aug 7, 2008 at 8:42 AM
My solution was to simply remove geometries that are more than a couple of screens away and add them back in once they get close enough.  I keep their basic data in memory(position, scale, etc..) but the actual geoms and bodies are gone once they get too far out.  I managed to get fifty cells(roughly 50 square kilometers) of randomly generated terrain out of this.  And since they're not all being loaded during the same frame it's completely seamless.  The only drawback is if you have some AI that is a good distance away that you want running, you either have to simulate collision or accept that there won't be any collision.  Here's a video that shows some of it off:
Aug 7, 2008 at 7:18 PM
dp2208 - Very nice. What you have essentially done is creating resting bodies. Could you possibly release the source of the controller?
Nice illustation of the effect by the way. Did you extend the engine to do this?

Lemunde - It seems to work fine even if you remove the geoms some screens away. I think it depends on the game if this is a drawback or not. In a Top-down shooter you would not like every enemy in the level to come and attack you, so you could disable (or remove) the geometries.
Aug 7, 2008 at 11:58 PM

Yes, i will release the source when it is tested. But i did some changes to the engine as well.
Aug 8, 2008 at 5:00 PM

I got your email about your changes.  Sounds very interesting and yes it would be nice to get it into the engine.

Some questions:

Outside of your new controller, how extensive are the changes?  If someone decides to use a different controller will the code you added intefere?

Is there anything about your changes that are specific to the XBox version?  I'd want this to work in the Silverlight release as well.

If they aren't to complex then I could send you the "master" version of source and let you update it.  Would that work for you? I'd offer to implement the changes myself, but I'm short on time at the moment and you could probably do it much quicker.

Once you made the changes, I could do a release so others could use it.

As for the use of Lists. I'm open to suggestions, but I don't have the time for an extensive re-write.

Aug 8, 2008 at 5:23 PM
Edited Aug 8, 2008 at 5:25 PM
Outside of your new controller, how extensive are the changes? 

I fixed a bug, where the velocity were NaN, because of a length calculation of a Vector.Zero, added a feature to the default collider so that it ignores geoms that have got disabled bodies, changed the Vertice class to generate a geom of 8 vertices instead of 16 when creating a rectangle and added 3 new properties to the Body class. I think they are not extensive. The first two fixes would have been made sooner or later by you, wouldn't they? :)

If someone decides to use a different controller will the code you added intefere?

Yes. Controllers have to check if the bodies they are affecting are disabled and their "IsAutoIdle" property is set to true. If this is the case they have to enable these bodies at first.
I am not totally sure if this could cause problems with other controllers but if it does, the user has two options: to adjust their code or to simply not enable the "IsAutoIdle" property to these bodies (if the InactivityController is not activated it does not have an effect too, of course).

Is there anything about your changes that are specific to the XBox version?  I'd want this to work in the Silverlight release as well.

No, they are not Xbox specific. They only have got the biggest affect on performance on the Xbox.

Sure, i could do the changes and would say, that you offer the community to test it before it will be a new release. What would you say?
Aug 8, 2008 at 5:45 PM
Ok, I will try to get the code to you some time today...

Aug 8, 2008 at 7:09 PM
crashlander - I see that you don't use the onside source control (Team foundation). Does this mean that you don't have Farseer in a source control environment?
It would have been easier for dp2208 to just provide a diff patch of the changes for incorporation.

crashlander, dp2208 - It's very nice to see public collaboration between the author and community. Keep it up.
Aug 9, 2008 at 10:55 PM
I don't currently have farseer using formal source control.  Currently it gets backed up daily automatically to the mozi online backup service.
I may look into putting it up on codeplex source control system, but it's a bit complicated by the fact that I have two (actually 3 if you count the .Net 3.5 version) target platforms.  If I keep one version of on code plex it will probably be the Silverlight version since it is the version I'm actively developing with.

Have any suggestions on how to handle the source control under this scenerio?  
Aug 10, 2008 at 12:27 AM
Edited Aug 10, 2008 at 12:29 AM
Indeed I have.

Use SVN with the TortoiseSVN client. You will not find any better non-distributed source control out there. And TortoiseSVN make your life much easier.

Codeplex is about to support TortoiseSVN as a client to TFS. They will release a bridge software here on codeplex that makes it possible to do this.

As with the diffrent versions of farseer, SVN makes your life so much easier. You should be using branches and merge changes between the branches as they are being developed.

Here is a short tut on how it could be done:

1. Install SVN server on a seperate machine. You will be better off by downloading VisualSVN server and install it instead of the main SVN server since it's easier and have a buildin web server with a interface on port 8080. Download it from here:
If you don't have a seperate machine, there are several free hosting sites (including google). Or wait for codeplex to release the bridge software. (don't know the current state of the project)

2. Install TortoiseSVN on your development machine. This client will intergrate itself into the cascading menu (right click) in explorer. Just right click on a folder and you will have all the avaliable actions exposed to you.

3. Right click on a folder and "checkout" the SVN project (from codeplex or other hosting) by entering the url of the project.

4. Put all your mainstream files and folders into the newly checked out folder and commit the changes by right clicking again. (and select commit)

5. Create a branch of the project (right click, select branch/tag) and put it into a new folder called braches. This branch could be the SilverLight branch.

6. Whenever you make a change to the mainstream, just right click and select merge. Select the SilverLight branch and the changes will be merged between the 2 branches.

The final folder layout should be something like this:

-- /Trunk/ (This is the mainstream)
-- /Branches/SilverLight/
-- /Branches/XNA/
-- /Branches/Xbox/
-- /Documentation/
-- /Resources/

Hope this helps you. It certainly changed my development cycle some years ago.
Aug 10, 2008 at 1:23 AM
I've toyed around with TortoiseSVN before, but I've never taken the time to learn how to use it correctly.  I come from an MS development background so I'm more use to VSS and lately TFS.

When you say "Put all your mainstream files and folders into the newly checked out folder ..."  Do you mean just core source files that are common accross all platforms?  What goes in each branch, just the .csproj and other platform specific files?  Or does each branch have it's own "copy" of the source files in the trunk and the merge process syncs them up?

I usually keep the Silverlight version of the engine open as I work on my project so that I can easily make changes when I need to.  Then, when I decide it's time for a release I manually copy all the source files to the other projects and test them.

Under your scenario, what becomes my "working" copy of the engine.  Can I still work with the Silverlight version and propogate/merge changes to/with the other platforms?

Aug 10, 2008 at 2:05 AM
The /trunk/ folder holds the version that is common to all the branches. Each branch is a copy of the trunk, but is a folder by itself. Any changes you make to a branch will not be visible in the trunk, and the other way around. They are independend.

When you get an idea and want to implement it into the project. Then you can make the change to the trunk, and then merge the changes into each branch. It's just like when you copy your files manually, but it has some advantages:

1) They way SVN stores the files makes sure that it does not take up any space. When you branch a working copy of your source, you are essentialy copying the source files, but SVNs inner workings make sure to make links (like shortcuts in Windows). This keeps space usage at a low.

2) Each time you merge, branch or make any other change. It's completly reversible. All changes are kept in the repository as a revision. This ensures easy backtracking. And if you forgot what you have changed between 2 revisions, you just do a diff on the revisions and you will se only the changed files (and their content).

To anwser the question about making changes to Silverlight version and merge changes: Yes, indeed you can. If you prefeer to work with the Silverlight branch and merge your changes to the XNA version. Just untick the .csproj and other platform dependend files and merge.
Aug 10, 2008 at 5:42 PM
Ok, I will look into this.

Thanks for the info.
Aug 12, 2008 at 6:24 AM
Any word on what the current status is on this?

I'd like to get my hands on a copy of farseer that has these changes...

Aug 12, 2008 at 12:25 PM
I wanted to mention that removing things from memory like that is a really bad idea because it causes memory fragmentation and in the long run will affect performance and stability.  What you should do instead is retain the geometry and simply remove it from Farseer's grasp.  Store it in your own list of world-objects and add it back to the simulation as needed.  Unless Farseer is making copies of everything it uses, there will only ever be one instance of your geometry anyway, so it will never be destroyed, and you'll never have to worry about fragmentation.  There's an article on the XNA Creators Club that explains this in detail.
Aug 13, 2008 at 1:01 AM
I sent the source, but haven't heard back yet.
Aug 17, 2008 at 8:13 PM
Aug 18, 2008 at 7:44 AM

i successfully integrated my changes.
Let me first test it on the xbox again - on friday i am back at home and could send it to you on saturday.
Aug 19, 2008 at 8:24 PM
I added another "feature":
My version is now scalable. If the framerate drops the simulation will optionally get less accurate (it will get updated in greater intervals). This can help to avoid a temporary drop of the FPS.
Should i integrate this as well? :)
Aug 20, 2008 at 5:38 PM
Edited Aug 20, 2008 at 5:49 PM
Damn, this rocks!
I increased the FPS from 2 to 280 with 180 Bodies on my slow laptop by simply activating the Scaling mode and WITHOUT using the InacticityController.
You can specify the preferred and the maximum update interval and thats it - the rest is being done by the engine.
If the update takes longer than the preferred interval, it slows down a bit (in the worst case until it reaches the specified maximum) and later accelelerates again.

This works really great :)
Aug 20, 2008 at 6:50 PM
That sounds nice. How is this implemented? I seems that something like this should be in the game and not in the engine, but it could be considered if it's scalable over all platforms (silverlight, xna, xbox, zune, others) and have the ability of being turned off without any drawbacks.

What are the potential pitfalls of using something like this?
Aug 21, 2008 at 5:51 AM
You are right. This should normally be handled in the game. The problem is the option "IsFixedTimestep".
The scaling option has the effect that the engine isn't tied to this fixed timesteps anymore.
If you are using silverlight, you could simply use the engine as you did before.
But if you are using XNA, supplying a second parameter (elapsedRealTime) in the update method is all you need to fix the problem. I think this is very straight forward.
I tested it in a sample and this was all what made the difference between 2 FPS and >200. The rest is being done inside the engine.

What would you guys say? :)
Aug 21, 2008 at 8:00 AM
Amazing, maybe you can release new movie with these 180 bodies? ;)
Aug 21, 2008 at 9:59 AM
This is really great stuff, I look forward to play with this!
Aug 21, 2008 at 10:27 AM
I am currently building a sample application that shows how to use the new features. It will be the same as shown in my video. But i will capture a video of my quadcores performance too ;)

I forgot to answer your last question. There is no real pitfall. You only have to make sure, that you specify a "MaximumUpdateInterval", that is small enough to recognize all collisions.
For example: if you plan to calculate fired bullets of a players weapon, you should use a smaller MaximumUpdateInterval than if you are just calculating some big objects falling onto a floor.

As i said: give me time to celebrate my birthday on friday. On saturday i will finally test it on the xbox and send my work to crashlander.
The sample i mentioned should make it clear, how to set up the engine to use the new features. This should be less than 10 lines of code in total.
If you don't want to use the new features, you have to do nothing :)
Aug 21, 2008 at 5:01 PM
Edited Aug 21, 2008 at 5:08 PM
Ok. I look forward to have a look at it.

Happy birthday on friday.

EDIT: If you can make it scalable enough and want to see it's octo-core (8 cores) performance, give me a hint ;)
Aug 23, 2008 at 12:12 PM
The changes sound good.  My only concern, as genbox mentioned, is that

1.  It works the same accross all platforms.

2. The DEFAULT behavior is to act the same as it did before your changes (as much as it makes sense). With any new feature can come new un-intended bugs and possible un-expected behavior.  I'd like to minimize that.

Send me the code when you have it finished along with any notes you have on the changes so I know where to look for them.  I'll test it with my apps and I will release it for others to test prior to releasing it "officially".

Sound good?

Thanks again for this!
Aug 24, 2008 at 1:03 PM
You can download the code here:

The engine acts completely the same as before if you don't activate the InactivityController or Scaling.
Take a look at my included sample for how to set it up.

Search for "Daniel Pramel". I marked every change with a region.
btw: You should really use source control ;)
Aug 24, 2008 at 2:04 PM
@dp2208 - Thanks for the code. I will soon add it to source control so future work can be transactioned in diff files. ;)
I will have a look at the source, looking forward to see what you have accomplished.
Aug 24, 2008 at 4:03 PM
Edited Aug 24, 2008 at 4:03 PM
Thanks, Daniel.

One quick think I noticed is in the Inactivity controller


using Microsoft.Xna.Framework;

needs to be this:

#if (XNA)
using Microsoft.Xna.Framework;

otherwise the silverlight version will not compile.

Aug 24, 2008 at 4:05 PM
It's already fixed. :)
Aug 24, 2008 at 4:53 PM
Okay, thanks ;)
What do you say? Did this help you to improve performance or did this just help me?
Aug 24, 2008 at 6:40 PM
Scaling greatly improved speed! But the boxes in the demo are acting weird when there are many of them. Anyway: fantastic job ;)
Aug 24, 2008 at 7:06 PM
the boxes in the demo are acting weird when there are many of them
I think you should reduce the MaximumUpdateInterval or turn off the InactivityController. Just play around with the values.

Anyway: fantastic job ;)
thanks ;)
Aug 26, 2008 at 9:13 AM
Edited Aug 26, 2008 at 9:24 AM
Could anyone have a crack at porting this part over to BlitzMax version? Ill have a crack at it myself but chance of success is low since i only started BlitzMax like 1-2 months ago (Ill ask the developer of the BlitzMax version too)

I can open C#/XNA Code in notepad, right? I guess ill find out...

Edit: After looking at how much code there is i dont think i will try myself XD
Aug 26, 2008 at 9:30 AM
I have never used BlitzMax and don't know how it works. But because Faseer is a .net framework, it can be used by all applications/other frameworks that support .net. How do you currently use Farseer?

And yes, you can open C#/XNA code (XNA is ordinary C# code) in notepad or any other editor.
Aug 26, 2008 at 10:03 AM
btw: Will these changes i made be integrated into the next release of the engine?
I also wanted to ask if i could participate in the future development of the engine
Aug 26, 2008 at 10:23 AM
Yes, they are already integrated into the team foundation source control. I've only changed your code to use automatic properties, everything else is still as you left it.

I would be very happy to get some help with the future development of the engine. Any bugfixes, patches or improvements are welcome.
I'm currently in the progress of gathering ideas and concepts that will make it into the 2.0 version of the engine. So if you have any ideas, you are welcome to post it and we will have a look at it. :)

By the way, our open source soul invites everyone to come with ideas.
Aug 26, 2008 at 10:49 AM
Edited Aug 26, 2008 at 10:51 AM
I've only changed your code to use automatic properties

Isn't that part of .net 3.0? This means it can not be used by XNA 2.0 (which uses .net 2.0), doesn't it?

My post was intended to be a question if i could be added as a "developer" on this
project. This would make things easier because i then can check in sourcecode directly.
I simply don't know if crashlander wants that - as far as i know he is the only one who can add new entries to the "persons" page.
Aug 26, 2008 at 11:52 AM
Yes, indeed it is. The current source code checkin is using XNA 3.0 CTP and does not support XNA 2.0.

Are you sure that XNA 2.0 only supports .net 2.0? I've head it before from others, this makes me unsure.
I was sure that XNA 2.0 can use any dotnet version as it's just a managed library (wrapper) for directx.

I cant even test it, my Vista 64bit box will not install VS2005 for some reason.
Aug 26, 2008 at 12:05 PM
I was under the impression that XNA 2.0 only supports .Net 2.0  framework.

If you use features that were introduced Net 3.0, how would the compact framework on the XBox360 know about them?

Aug 26, 2008 at 12:09 PM
Hm, i don't want a discussion about it in this thread, but why should farseerphysics only support a XNA version that isn't released yet? This makes no sense for me :)
I don't know if XNA 2.0 can run with any other .net version than 2.0. But i am sure that the XBox version of it doesn't. You can't even run 30 CTP applications on the Xbox.
I think it is not the best solution to test it against XNA 3.0 CTP. It should support the most recent released version. And that is XNA 2.0
Aug 26, 2008 at 12:20 PM
There is also a .NET Compact Framework 3.5 Redistributable for download. It contains the auto properties and so on.

I don't have a Xbox 360, is it possible to update the compact framework on Xbox 360?

If it introduces to many problems, I will target the framework on 2.0 again. I will test it in a vmware (XNA 3.0 on .NET 2.0) when I get the time :)
Aug 26, 2008 at 1:13 PM
No, you can't. The framework is deployed automatically when the console is being updated.
As a user of the farseer physics engine, i would prefer it, that it runs on the Xbox ;)
It would be no problem for me, to test it against XNA 2.0 and on the Xbox. I am doing it all the time while developing my game ;)
Aug 26, 2008 at 1:25 PM
Oh, okay :)

Any chance of them updating to the new framework when XNA 3.0 comes out?

If there is no chance of running 3.0 on Xbox, then I will make sure that the master version of Farseer stays with framework 2.0.
Aug 26, 2008 at 1:51 PM
Of course it will run on the Xbox, when it is released. But not the CTP.
As i said: it makes sense to make sure that the engine runs with the current release of XNA. And this is XNA 2.0
If XNA 3.0 is released, the development tree of the engine could be frozen and kept as a release for XNA 2.0. The main development tree could then support XNA 3.0.
This is what i would prefer. Only a suggestion :-)
Aug 26, 2008 at 2:11 PM
I know I haven't contributed that much, but I have been using Farseer for a few months on my never-to-be finished game, and I am slightly concerned at the seemingly spastic direction the project is taking. Using automatic properties, really? There is so much that could be done to improve the engine, and I see that some people are attempting to do that. But replacing existing code with syntactic sugar that won't ever run on the XBOX seems to me like the wrong direction. I have serious concerns.
Aug 26, 2008 at 2:31 PM
@ wmfwlr: Exactly. I just tried to argue why it is the wrong direction, in my opinion. And why genbox should undo the code changes.
The engine works well and as far as i could see, my changes regarding scaling and automatic body deactivation didn't change this.
The syntax should not be changed if it isn't clear that it will work on all "platforms" and .net derivates as long as it isn't necessary.

The goal should be to keep the stability and to improve small aspects of the existing codebase to gain some more performance.
Aug 26, 2008 at 3:19 PM
@dp2208: I agree. Bug fixes and improvements should be made, but I don't necessarily agree with completely separate branches for different platforms. If there are optimizations that can't be separated out conditionally then make them custom build tasks. I've got enough branching nightmares at work :)
Aug 26, 2008 at 3:28 PM
If there are new language features introduced with a new release of XNA, it would make sense, wouldn't it?
You misunderstood me. I wasn't talking about managing different branches. I just said, that if the engine will always work with the newest release of XNA, you should freeze a release that works with an older one.
For example: farseer physics works with XNA 2.0. If XNA 3.0 would be released tomorrow, we should say: ok, that is the last release working with 2.0
The next release will support XNA 3.0. If you want, you can still download this older version.

I was never talking about maintaining all trees ;) Sorry that this wasn't clear. As you noticed, english is not my native language.

My original intention was to argue with genbox to make clear, that it shouldn't be to only support a CTP of a new XNA release which no one can use who wants to release his game
Aug 26, 2008 at 6:29 PM
@dp2208 - "it makes sense to make sure that the engine runs with the current release of XNA. And this is XNA 2.0"

Indeed. And it does. Version works with XNA 2.0.

Don't get me wrong, bug fixes, improvements and new features are in no way a lower priority than before.
We are doing the code refactoring as a little project on the engine to improve code readability and maintenance.
Automatic properties improves code readability by removing a lot of redundant codelines. (the private field, and inlining the getter and setter)

@wmfwlr - "I am slightly concerned at the seemingly spastic direction the project is taking. Using automatic properties, really? There is so much that could be done to improve the engine"

You need to remember that the engine was filled with unused stuff and was not using a source control before. Our goals are still the same: Support for all platforms and easy/simple to use. Not to just change the way the code looks. We publish the details of the refactoring process to make sure that people can follow the progress (Info here). This way people can see what we do and what they need to be aware of, when going bleeding edge and downloading the latest release. 

@wmfwlr - "But replacing existing code with syntactic sugar that won't ever run on the XBOX seems to me like the wrong direction. I have serious concerns."

FYI changing back to ordinary properties will take 10 seconds, as I have just completed a tool to do it, in case we need it. Nothing for you guys to worry about :)

@dp2208 - "my changes regarding scaling and automatic body deactivation didn't change this."

I have planned a release with your changes based on the cleaned Thanks again for your contributions :)

@dp2208 - "The syntax should not be changed if it isn't clear that it will work on all "platforms" and .net derivates as long as it isn't necessary."
You are right. As said before, our goal is to support all platforms and nothing is going to remove that goal.

The current engine will still be the main engine for quite a while. XNA 3.0 will probably have been released before the release of Farseer 2.0. It all depends on the progress of the engine and the release (and use) of XNA 3.0. Have in mind that .net framework 3.0 was release for over a year ago. The introduction of lambda expressions, automatic properties and others greatly helps developers.

I hope this clears up some confusing.
Aug 27, 2008 at 4:06 PM

@ everyone.

My goals for Farseer haven't changed: Keep things simple for the everyday users of the engine. I'm sure 99% of the Farseer users don't even want to see the words "branch" or "merge".

While there is refactoring being done and integration with the Code Plex source control system. this is all back-end code managment stuff.  The everday users of the engine should still have the same experience:

A .zip file for Silverlight
A .zip file for XNA
A .zip file for WPF (vanilla .Net)

All the branching and source code stuff is just different means to this end.  The 1% that is interested can  look at and get the code in the Source section of Code Plex rather than the Releases section.

As for the XNA 2.0 vs. XNA 3.0 question.

I'm reluctant to release a version that has all the refactored code.  The idea is that release would be 2.0 partially BECAUSE of the refactoring and breaking backward compatibility.

So, I think I will take the code that dp2208 updated and do a release the old-school manual way.  This will get the new updates into users hands without breaking all there code.

This will then be the last version of Farseer that supports XNA/Net 2.0.  Farseer 2.0 will be build with support for XNA 3.0, Silverlight 2.0 and .net 3.0.

Will this work for everyone?


Aug 27, 2008 at 4:18 PM
Sounds great to me :)
Aug 27, 2008 at 4:26 PM
Hi Jeff,

that is exactly what i wanted to say.
May be the word "branch" was understood in the wrong context ;) I meant that there is a version for alle the XNA 2.0 users.
It was important for me to get my changes into a version that everyone can use without changing their codebase.

Aug 27, 2008 at 5:02 PM
Ok, I'll work on getting this release out.  Hopefully I can do that tomorrow morning.
Aug 27, 2008 at 6:34 PM
dp2208 - I tested out your performance demo and it works great except -

1. It seems to add quite a bit of jitter before the boxes are disabled.

2. Boxes seem to penetrate each other.

3. If the InactivityController is enabled and boxes become inactive and then it is enabled those same boxes remain inactive.

4. The boxes jitter when the InactivityController is enabling/ disabling them.

I would just like some clarification on how to use this properly and if these above items are bugs or just improper settings.
Aug 27, 2008 at 7:08 PM
hi matt,

yes, the InactivityController has some limitations. One of the disadvantages is, that the behaviour isn't exact all the time. Especially when a lot of objects are colliding with each other.
The controller works best, if used on objects which are spread all over your level and not colliding against each other in big groups. My sample doesn't show this. It shows the complete opposite. I simply had no time to make samples for the scaling AND the controller. so i decided to use it for both demonstrations.

nevertheless: you could try to reduce the bodies MiniumVelocity and raise the controllers MaxIdleTime and ActivationDistance. You will get a more exact behaviour.

You also have to make sure that the ActivationDistance is bigger than any body affected by the controller. (Did you notice that you can set this for every body by modifying the bodys IsAutoIdle-property?

Aug 28, 2008 at 10:41 AM
@dp2208,  I looked quickly at your code.  Are you only checking LinearVelocity to determine "inactivity"?  What if a body isn't moving linearly but is rotating in-place?  Wouldn't your code deactivate it when really it shouldn't be deactivated?

Could you take a look at it when you have time?

I'm going to hold off on releasing this until it's tested a bit more.
Aug 28, 2008 at 10:55 AM
Yes, i am only checking the linear velocity and it works well. Practically it makes no difference.
But you are right: i could have added another check to determine if it is rotating above a given minimum.
Aug 28, 2008 at 2:20 PM
It would not work well if someone had a rotating body attached to a revolute joint. What if that object was spinning and your logic determined it was inactive and put it to sleep.

Aug 28, 2008 at 2:24 PM
I know what you are talking about, but i noticed, that it didn't cause any problems.
Of course i could add this check. But if i should you have to wait until next week. I have a date with a publisher next monday and need to create some presentations...
Aug 28, 2008 at 4:34 PM

Probably best to wait.  It might not cause probs in your test scenarios but I can see it causing issues in some situations. 

I'd offer to do it myself but like you I'm pretty busy at the moment. :-)  No biggy. People can grab the version from the link you posted if they really need it.

One of us can make the change when we have time.


Sep 3, 2008 at 6:38 PM
    A .zip file for WPF (vanilla .Net)

This line makes me nervous.  Windows Presentation Foundation is not vanilla .NET.  I want to assume you mean, "a zip file for managed .NET."  Please clarify, because I have absolutely no interest in using WPF (except in one unrelated case, inasmuch as it's required to use MultiPoint, which pisses me off).
Sep 3, 2008 at 6:42 PM
@OmegaTree - Windows Presentation Foundation (WPF) is just a library subsystem of the ordinary .net 3.0. What crashlander means is that Farseer Physics 2.0 will work on .net 3.0 and have support for WPF.

Farseer Physics does not contain any drawing specfic code and does not in any way bind it self to a specific platform (WPF, XNA, DirectX, Zune, OpenGL or others) You do not need to be worried :)