Physics inconsistancies across various speed machines
by Fenrir Wolf · in Torque Game Builder · 03/10/2005 (5:26 pm) · 3 replies
Okay! I was putting the finishing touches on Cloudburst and was just about to release it, when I went to go play it on my older laptop. It's not exactly super-old but neither is it top of the line (1.2 GHz CPU, Geforce 440 Go graphics, 512 M memory).
Argh! My wee spaceship controls all differently! It's sliding all over the screen. Melv, the physics system in T2D really needs to be nailed down, insofar as getting consistant results across various speeds and platforms. On the laptop, I'm getting anywhere from 40 to 90 fps, versus my development machine which gets 120 fps on up.
I control my ship by giving it a density and damping factor. Then, when the player holds down a movement key, I continue to apply velocity using setImpulseForce in the necessary direction (using setMaxLinearVelocity to cap it so they don't move too fast) via a schedule.
On slower machines, since the physics system isn't getting as many ticks, things like damping don't seem to work as well. I've tried setting mScenePhysicLimits/TargetFPS to fairly low values (10 and 30 respectively), but even so the physics system behaves differently on my development system versus one of my low-end test systems.
Now, I could just give up the inertia-based movement and go with a straight SetLinearVelocity, but I wanted to avoid jerky movements and give the ship a little slide. But if the amount of slide is going to vary based on frame rate of the engine, then that utterly destroys all of the game mechanics. (As I had tested them...faster ship makes the game a lot harder.)
Any ideas? I consider this to be a real show-stopper insofar as my game is concerned -- I'm only relying upon the physics system for movement, and if it gives varied results per platform, then I'd hate to imagine using it for something more complicated. (Like a side-scrolling platformer, where how the game feels and handles is a huge part of the gameplay mechanics.)
Argh! My wee spaceship controls all differently! It's sliding all over the screen. Melv, the physics system in T2D really needs to be nailed down, insofar as getting consistant results across various speeds and platforms. On the laptop, I'm getting anywhere from 40 to 90 fps, versus my development machine which gets 120 fps on up.
I control my ship by giving it a density and damping factor. Then, when the player holds down a movement key, I continue to apply velocity using setImpulseForce in the necessary direction (using setMaxLinearVelocity to cap it so they don't move too fast) via a schedule.
On slower machines, since the physics system isn't getting as many ticks, things like damping don't seem to work as well. I've tried setting mScenePhysicLimits/TargetFPS to fairly low values (10 and 30 respectively), but even so the physics system behaves differently on my development system versus one of my low-end test systems.
Now, I could just give up the inertia-based movement and go with a straight SetLinearVelocity, but I wanted to avoid jerky movements and give the ship a little slide. But if the amount of slide is going to vary based on frame rate of the engine, then that utterly destroys all of the game mechanics. (As I had tested them...faster ship makes the game a lot harder.)
Any ideas? I consider this to be a real show-stopper insofar as my game is concerned -- I'm only relying upon the physics system for movement, and if it gives varied results per platform, then I'd hate to imagine using it for something more complicated. (Like a side-scrolling platformer, where how the game feels and handles is a huge part of the gameplay mechanics.)
#2
Yeah, that work plus lots more on the physics has been done and checked-in to SVN. Expect it in the next release. You can now configure, from the scripts, limitFPS, targetFPS, max-iterations as well as allowing the system to free-run with incoming elapsed-time (something you may still want to do).
Leaving the max-iterations at x16 was a dumb mistake as well by me. :(
All is good now though. :)
- Melv.
03/11/2005 (1:11 am)
Can't wait for CloudBurst! Gimme gimme gimme.Yeah, that work plus lots more on the physics has been done and checked-in to SVN. Expect it in the next release. You can now configure, from the scripts, limitFPS, targetFPS, max-iterations as well as allowing the system to free-run with incoming elapsed-time (something you may still want to do).
Leaving the max-iterations at x16 was a dumb mistake as well by me. :(
All is good now though. :)
- Melv.
#3
Yeah, I kinda jumped the gun and panicked. I didn't even think to check the bugs forum to see if anyone else had known about this problem. I knew about how target/limitFPS was supposed to cut back on the time, but it never occurred to me that the time-slice code wasn't working as it is.
I've tried Cloudburst on that lappy again, and played it all the way through. Even when it started to get crap framerates (with the boss), the physics system behaved no more worse than I would expect it to, with Noolness' patch and a conservative setting for target/limitFPS (60/30 respectively) and max-iter at 8.
03/11/2005 (1:44 am)
Check the T2D threads. ;)Yeah, I kinda jumped the gun and panicked. I didn't even think to check the bugs forum to see if anyone else had known about this problem. I knew about how target/limitFPS was supposed to cut back on the time, but it never occurred to me that the time-slice code wasn't working as it is.
I've tried Cloudburst on that lappy again, and played it all the way through. Even when it started to get crap framerates (with the boss), the physics system behaved no more worse than I would expect it to, with Noolness' patch and a conservative setting for target/limitFPS (60/30 respectively) and max-iter at 8.
Torque Owner Fenrir Wolf
My problem wasn't related to the physics bottoming out on the slow laptop, as I had originally thought. It was due to the faster machine having accumulative errors due to precision. This thread has more information, plus a fix.
Therefore, I was setting my force values to be WAY too large in order to get the behavior I wanted, due to the precision errors. On the laptop, since the physics system wasn't able to do a bazillion frames-per-second integration, it was modeling this correctly by having my ship move way too fast.
After the fix, I've verified that Cloudburst's physics are behaving a lot more consistantly now, on both the fast and slow machine. I'm still testing, but it looks good, CB might be up for download later tonight. :)
Big huge thanks to Nic for pointing out that thread to me and saving me heaps-o-debugging!
As a side benefit, the TargetFPS/PhysicLimit variables now work as expected.
Apologies for dissing T2D. ;)