Game Development Community

interesting: simTime doesn't advance while the sim is in a hard loop ?

by Orion Elenzil · in Torque Game Engine · 06/25/2009 (4:32 pm) · 3 replies

we've got some funky stuff going on server-side which has led to some investigation into the nature of time itself, with some sort of interesting results.

it looks like simTime is paused while the sim is in a hard-loop.
ie, not only does it not advance during the loop (expected) but it also doesn't catch up once the hard loop terminates.

check it,
here is some code (testSchedule) which first schedules an echo() for say ten seconds in the future, then goes into a hard sleep for twenty seconds. after the twenty seconds have elapsed, another ten seconds pass and then the echo() fires:

function echoSimTime(%s)
{
   echo(%s SPC getSimTime());
}

function scriptSleep(%ms)
{
   echo(getScopeName() SPC "starting" SPC getSimTime());
   schedule(0, 0, "echoSimTime", "started");
   
   %start = getRealTime();
   
   for (%delta = 0; %delta < %ms; %delta = mSubS32(getRealTime(), %start))
   {
   }
   
   echo(getScopeName() SPC "finished" SPC getSimTime());
   schedule(0, 0, "echoSimTime", "finished");
}


function testSchedule(%delay, %sleepTime)
{
   schedule(%delay, 0, "echoSimTime", "made it.");
   scriptSleep(%sleepTime);
}

[6/25/2009 16:12:32][Inf][General] ==>testSchedule(10000, 20000);
[6/25/2009 16:12:32][Inf][General] scriptSleep() starting 570797
[6/25/2009 16:12:52][Inf][General] scriptSleep() finished 570797
[6/25/2009 16:12:52][Wrn][General] Simulation is behind; 20021 ticks elapsed since last iteration. (no scope)
[6/25/2009 16:12:52][Inf][General] started 570797
[6/25/2009 16:12:52][Inf][General] finished 570797
[6/25/2009 16:13:01][Inf][General] made it. 580797

it's also interesting that the print "finished" appears *after* the "scriptSleep() finished" line, because the latter line is an immediate execution which comes before the former which is a schedule(0).


#1
06/25/2009 (10:43 pm)
Doesn't schedule(0) require returning to the event loop for anything to happen?

Actually, this all makes sense, pretty much.

echo is immediate, schedule is not.

You're not letting the simuation progress because you're deciding to stay in the bytecode interpreter for 10 seconds.

Or, am I missing something?
#2
06/26/2009 (12:41 pm)
ah, yr totally right, i was getting the echos confused and thought a schedule(0) was executing before an immediate-mode call.

so, yeah, it makes sense but it's interesting.
it means that stuff you schedule for the future will be delayed as far as wall-time is concerned by the amount of heavy processing you do. i wonder what would happen if you advanced simtime up to wall-time each tick. bad things, probably.
#3
06/29/2009 (10:41 pm)
If you wanted to fix that, you'd need to enforce checks in the interpreter that call back into the runtime to ensure that any currently pending schedules get handled.

I'm not sure how complicated that would be, since re-entrancy is a massive issue in the interpreter.

Honestly, if one were to undertake fixing interpreter re-entrancy, you might as well just allow for full-blown multiple threads of execution with their own stacks, locals, etc. The former is probably 90% of the work of the latter.