Shedule() precision
by Dmitriy Stukalov · in Torque Game Builder · 11/16/2007 (3:23 am) · 4 replies
Hello,
Recently I've tryed to examine a precision of the shedule() metod. The code I've used:
1. What the reason for beginning zero values for getRealTime() function?
2. What the relation between RealTime and SimTime time scales?
Excuse me for the long message.
Thank you.
Recently I've tryed to examine a precision of the shedule() metod. The code I've used:
function testObject::onLevelLoaded(%this, %scenegraph)
{
// initialization of variables
$start_time= getRealTime();
$stop_time= 0;
// start sheduling (50 milliseconds)
$test_event = schedule(50, 0, "TestShedule");
}
function TestShedule()
{
$stop_time = getRealTime();
schedule(50, 0, "TestShedule");
// real shedule time
%frame_time = $stop_time - $start_time;
$start_time = $stop_time;
echo(%frame_time);
}I've been shocked with results!0 0 0 ... 0 // 27 times 0 !!!!! 16 64 48 48 48 48 64 ...then I've replace getRealTime() with getSimTime(). The result is
50 50 50 ...I have two qvestions.
1. What the reason for beginning zero values for getRealTime() function?
2. What the relation between RealTime and SimTime time scales?
Excuse me for the long message.
Thank you.
#2
The minimum precision for schedule is 32 milliseconds, and it is not a guaranteed precise hard core scheduler due to the nature of how it works.
When you schedule an event for the future, what actually happens internally is the following:
--The engine creates a new event that contains the information related to your intended function call (name, namespace, and arguments)
--it calculates the most approximate tick in the future based on the time you provide, by multiplying the provided "time" value by a previously calculated internal constant called TicksPerSecond (or something equivalent, I don't have the source code in front of me right now), and then identifies which tick to trigger your event.
--it places the event on the event processing queue with a maturation tick as calculated.
This has a couple of implications :
--events can only happen when they are called by the event processing queue, and since that queue pulses every 32 milliseconds, you can't have an event occur between pulses--therefore, there is a 32 ms precision.
--The schedule algorithm makes a "best guess" of which tick is appropriate for your event to trigger, but at the scale of your numbers (50 ms, with a 32 millisecond precision), there will be all sorts of rounding going on.
--Once the calculation of which tick to trigger is made, it is not updated. That means if something else slows down (or speeds up) Torque on your CPU for whatever reason, it may take longer before that tick occurs on the processing queue.
Regarding your lines of zeros, I'm not 100% sure of the exact reason, but one possibility could very well be that the difference between $stop_time and $start_time is so small that it is below the precision available for variables in TorqueScript when they are echoed, so it's being rounded to zero.
11/20/2007 (7:43 am)
Hmm--I honestly thought I had commented on this already--sorry for the delay!The minimum precision for schedule is 32 milliseconds, and it is not a guaranteed precise hard core scheduler due to the nature of how it works.
When you schedule an event for the future, what actually happens internally is the following:
--The engine creates a new event that contains the information related to your intended function call (name, namespace, and arguments)
--it calculates the most approximate tick in the future based on the time you provide, by multiplying the provided "time" value by a previously calculated internal constant called TicksPerSecond (or something equivalent, I don't have the source code in front of me right now), and then identifies which tick to trigger your event.
--it places the event on the event processing queue with a maturation tick as calculated.
This has a couple of implications :
--events can only happen when they are called by the event processing queue, and since that queue pulses every 32 milliseconds, you can't have an event occur between pulses--therefore, there is a 32 ms precision.
--The schedule algorithm makes a "best guess" of which tick is appropriate for your event to trigger, but at the scale of your numbers (50 ms, with a 32 millisecond precision), there will be all sorts of rounding going on.
--Once the calculation of which tick to trigger is made, it is not updated. That means if something else slows down (or speeds up) Torque on your CPU for whatever reason, it may take longer before that tick occurs on the processing queue.
Regarding your lines of zeros, I'm not 100% sure of the exact reason, but one possibility could very well be that the difference between $stop_time and $start_time is so small that it is below the precision available for variables in TorqueScript when they are echoed, so it's being rounded to zero.
#3
Of course it is :) You are scheduling it to happen every 50 milliseconds--or 20 times a second. It would take just over 1 second for it to be called 27 times.
11/20/2007 (7:44 am)
Quote:
It looks like TestShedule() has been called for the 27 consecutive times since a level has been loaded!
Of course it is :) You are scheduling it to happen every 50 milliseconds--or 20 times a second. It would take just over 1 second for it to be called 27 times.
#4
OK. Now, I want to know an exact time between TestShedule() calls to correct a scene objects behaviour. Can I use GetRealTime() for my needs?
Thank you.
11/20/2007 (10:47 pm)
Thank you for your explanation, Stephen.Quote:I've tried the next code:
Regarding your lines of zeros, I'm not 100% sure of the exact reason, but one possibility could very well be that the difference between $stop_time and $start_time is so small that it is below the precision available for variables in TorqueScript when they are echoed, so it's being rounded to zero.
echo(%stop_time);And I've got
173870781 173870781 173870781 ... 173870781 // about 27 timesWow! TestShedule() has been called 27 times per one millisecond! Correct me if I wrong, I suppose getRealTime() is inherited from API function GetTickCount() (for Windows platform). Am I right? If I'm right, I don't get any reason for TestShedule() to be called rapidly. It is not a "best guess" for the event I've defined!
OK. Now, I want to know an exact time between TestShedule() calls to correct a scene objects behaviour. Can I use GetRealTime() for my needs?
Thank you.
Torque Owner Dmitriy Stukalov