Written by Click on video to play:
Posts by
Farseer Physics Engine Continuous Collision Detection Not Working
In my PhysiBricks game, the user is able to fire a ball at a group of stacked bodies. I noticed that when I reduced the number of times per second it ran using the TargetElapsedTime and IsFixedTimeStep=true, my ball would sometimes go right through the bodies without colliding with them. This was very frustrating. I found that if I raised the number of iterations per second to 50, I didn’t see this problem. The funny thing was, I had the problem regardless of whether Continuous Collision Detection was on or not.
You may be asking why I would want to reduce the number of iterations per second? Well, the more iterations the less bodies I can have in play simultaneously, while keeping a descent frame rate.
I was recently looking through the properties of a Body and found a property called “IsBullet”. Immediately, it dawned on me that Continuous Collision Detection would only work if this was set to true. I ran it in the debugger and found that the value was false by default. I quickly changed the code to set it to true for the balls that I am firing. After doing this the anomaly was gone. Sweet! This means I can reduce the iterations per second to 30 and get more bodies on the screen at one time. Very nice, especially since I am developing this for the Windows Phone 7, which has limited processing power.
XNA Windows Phone 7 Performance and IsFixedTimeStep
I’ve recently started doing more work on the levels for PhysiBricks. I found that the Farseer Physics Engine was behaving differently in Windows Phone 7 than in Windows. Of Course, I wasn’t sure why this was, but believed it had more to do with the differing performance between the two devices. This was a big concern for me, because I wanted to be able to edit the level files while the game is running in windows and just reload it (No in game editor yet.) My hope was that if I could get the physics behaving the same in Window Phone 7 and Windows, I could do all my level development in Windows and then do final testing in Windows Phone 7.
After much searching on the internet I found that my problem was related to the “IsFixedTimeStep” and “TargetElapsedTime” properties on the XNA Game object. In Windows “TargetElapsedTime” defaults to 0.01667(60fps) and “IsFixedTimeStep” was false. In my Windows Phone 7 build, “IsFixedTimeStep” was true and “TargetElapsedTime” defaults to 0.03333(30fps).
By setting IsFixedTimeStep to true in both builds and setting the TargetElapsedTime to something that worked well in both environments 0.02(50fps), I was able to get the physics to behave the same in both environments. Yay!
Of course, it looks smoother in Windows cause it renders at 60fps, but at least the physics behave the same.
Xbox 360 XNA Floating Point Performance
I have been working on PhysiBricks for a while now. I have only been testing it on my 5 year old laptop, and it has been running at descent frame rates. I expected that the game would run better on the Xbox 360. I was wrong! Turns out that XNA on the Xbox 360 has poor performance for performing floating point operations. This isn’t very good news, especially when I want to make Physics games, using a Physics engine, which does A LOT of floating point operations.
I am using the 3.3.1 version of the Farseer Physics Engine and found that the “Breakable Bodies and Explosions” Sample drops the framerate to 2fps on the Xbox 360. On my laptop this same example keeps a constant 30fps. It appears the main problem has to do with the higher (100+) number of bodies colliding at the same time.
I find this a bit disappointing, as I was hoping to create physics games with a large number of simple bodies in play at the same time. I will need to watch the number of bodies that are play in a time and make sure I continually test on the XBox 360 to keep performance up.
I should also point out that my test were performed with a release build and without the debugger attached. Debug mode with a debugger attached really degrades performance.