Ticked Physics Related Question(s)
by Eric Robinson · in Torque Game Builder · 07/16/2007 (5:32 pm) · 6 replies
I will quote Stephen Zepp from this thread:
Quote:To expand on this further, the major difference between a fixed tick and a variable tick is the number of ticks you will receive over a given period of time. If your code is "tweaked" (timing wise) to provide a certain feel of speed/flow of game at your (hypothetical) FPS of, say, 60, that means that you probably wrote your code with a hidden assumption of 60 ticks per second. With the new tick based system, you are going to get a fixed rate of 30 ticks per second, which, assuming you did in fact have the hidden assumption of tick rate, will give the appearance that you have a "notable slowdown".Question: In all previous versions of TGB (<=1.1.3) I would get unwanted functionality with the Physics simulation. Specifically, the player in a platformer game (built on a slightly modified version of the MiniPlatformer Tutorial) would occasionally jump higher than expected. Whenever this happened it was accompanied by a heavy stutter in performance (as if something was loading in the background or what-not). Could this be due to the variable rate physics? I.e. the old physics route would check the time that had passed, update the character's position on screen based on its velocity and then begin calculating constantForce (acceleration), etc. from the updated location? Is this the kind of thing that would be 'resolved' by the new tick-based implementation?
This is the "fundamental design difference" I mention in my first post, and yes, we do understand it can be painful in some cases to re-design with fixed ticks in mind. The biggest advantage in a fixed tick system however is that regardless of the cpu or video card performance (within reasonable limits of course), your game play, when designed against a fixed tick system, is going to be much more consistent across different hardware, and even different operating systems.
#2
Do you have an example of that? Are all the forces static without any random elements?
I'd like to help you sleep at night.
Melv.
03/26/2008 (11:07 am)
Kevin,Do you have an example of that? Are all the forces static without any random elements?
I'd like to help you sleep at night.
Melv.
#3
Yes, fixed-ticks guarantee that the physics will get a constant update no matter what happens. If you task away and come back to the game, the physics won't explode as it receives constant updates always.
The "stutter" as you put it was the old physics system trying to manage a low update situation. The new tick-physics won't do that.
Melv.
03/26/2008 (12:04 pm)
Eric,Yes, fixed-ticks guarantee that the physics will get a constant update no matter what happens. If you task away and come back to the game, the physics won't explode as it receives constant updates always.
The "stutter" as you put it was the old physics system trying to manage a low update situation. The new tick-physics won't do that.
Melv.
#4
Thanks man! Yeah, all I do for jumping is set an impulse force on the player. The impulse force amount is defined in a datablock loaded in from a separate script. I have scripted no random element into the player movement scripts.
I noticed this primarily when I was trying to narrow down the "platform sticking" problem. (The character jumps up and near the peak of his jump, he hits a platforms and gets stuck. I can still move side to side, but he doesn't become unstuck until I float along to the end of the platform.)
What I did was jump around in a test level and try and get the guy stuck in the platform. 80% of the time he hit the platform but didn't get stuck. 10% of the time he hit the platform and did stick. The last 10% he didn't jump high enough to even hit the platform.
Perplexing.
03/26/2008 (6:55 pm)
Melv,Thanks man! Yeah, all I do for jumping is set an impulse force on the player. The impulse force amount is defined in a datablock loaded in from a separate script. I have scripted no random element into the player movement scripts.
I noticed this primarily when I was trying to narrow down the "platform sticking" problem. (The character jumps up and near the peak of his jump, he hits a platforms and gets stuck. I can still move side to side, but he doesn't become unstuck until I float along to the end of the platform.)
What I did was jump around in a test level and try and get the guy stuck in the platform. 80% of the time he hit the platform but didn't get stuck. 10% of the time he hit the platform and did stick. The last 10% he didn't jump high enough to even hit the platform.
Perplexing.
#5
Melv.
03/27/2008 (1:15 am)
Well I'll be doing some of my own QA soon by testing my recent physics fixes against some of the demos, platformer included. Hopefully that problem should've gone away.Melv.
#6
As for me, the higher-than-normal jumping would occur in a level that followed the MiniPlatformer Tutorial (possibly out of date now... I rewrote/augmented it back in late 2006/2007 but haven't played around with it in anything beyond the early 1.5 days).
Glad to hear my understanding of the situation was on target. I'm also glad that the engine is now tick-based. ;D
@Melv: I noticed that you have put some work into the collision and physics engines. That's really exciting news! In reading a few threads here this past half hour I've come to feel that not much has changed since I last grappled with the inconsistencies. Fantastic to hear that code's been retooled!
04/03/2008 (7:53 pm)
Hey guys! Glad to see there's some activity in these hills :)As for me, the higher-than-normal jumping would occur in a level that followed the MiniPlatformer Tutorial (possibly out of date now... I rewrote/augmented it back in late 2006/2007 but haven't played around with it in anything beyond the early 1.5 days).
Glad to hear my understanding of the situation was on target. I'm also glad that the engine is now tick-based. ;D
@Melv: I noticed that you have put some work into the collision and physics engines. That's really exciting news! In reading a few threads here this past half hour I've come to feel that not much has changed since I last grappled with the inconsistencies. Fantastic to hear that code's been retooled!
Torque Owner Kevin James