Game Development Community

Does schedule eat cpu cycles?

by Lee Latham · in Torque Game Engine · 02/22/2007 (9:42 pm) · 8 replies

Hello,

I've found a hack that works, but it is bringing my (quite fast) machine to it's knees. It seems quite odd, and I presume I'm doing something dumb.

What I've got is AI's mounted in Wheeled Vehicles (Flight Compendium Complex ones to be specific), following paths (AIPatrol resource). I've got some nice rocket launchers mounted onto the cars. What I would like to do, for example, is have them squeeze off a shot every five seconds. Makes for a nice tableau, no? :-)

So I wrote this little function:
function AIPlayer::RandomFire (%player)
{
    if (%player.isMounted()){
       %thiscar = %player.getControlObject();
       %thiscar.setImageTrigger(0,true);
       
    %player.schedule(5000,"RandomFire",%player);
    }
    else 
    %thiscar.setImageTrigger(0,false);
    %player.schedule(5000,"RandomFire",%player);
}

I'll admit that I find the syntax for schedule confusing, but it does actually work. However, once only three or so vehicles are in there, the game starts hanging on and off, getting worse as more cars are added. Without this, I can have dozens and dozens of happy path following wheeled vehicles with no problem. (It's quite amazing, really--I expected Torque to break under what I've been throwing at it a long time ago, but it just chugs away like a champ!)

Anyway...this surely must be a braindead approach? Or is it just a goof?

Edit: Just wanted to mention that it doesn't seem to be due to the missiles themselves. I hacked it up thus:
function AIPlayer::RandomFire (%player)
{
    if (%player.isMounted()){
       %thiscar = %player.getControlObject();
       %thiscar.setImageTrigger(0,true);
       
   // %player.schedule(5000,"RandomFire",%player);
    }
    else 
    %thiscar.setImageTrigger(0,false);
    %player.schedule(500,"RandomFire",%player);
}
and they all fired every half second, lots of missiles, framerate down, but no lockup-ish-ness.

Say wait a minute. How can that work? They are mounted but it is scheduling the call to RandomFire...
Please be merciful...I am essentially an amateur...


Lee

#1
02/22/2007 (10:20 pm)
You know, I really don't understand why the second set of code is working. It should only get to the else statement if the player is not mounted, correct? In which case it's _not_ firing. Yet it is firing at the interval set in the schedule command of the else statement. ?
#2
02/22/2007 (10:46 pm)
I believe if the ELSE chunk of code had { CODE } around it, then it would be correct.

One may use IF (BLA BLA) DoThis; ELSE This;
Or a more complex form as:
IF (BLA BLA)
{
Stuff;
Things;
}
ELSE
{
Other Stuff;
More Things;
}


If that is any help...

And yes, schedule will use CPU time, just as any other code executing would.
#3
02/22/2007 (10:48 pm)
Quote:They are mounted but it is scheduling the call to RandomFire

Try adding {} around the else:

else
    { 
      %thiscar.setImageTrigger(0,false);
      %player.schedule(500,"RandomFire",%player);
    }

Edit: Haha - beat me to it. Too busy with the fancy formatting :-)
#4
02/22/2007 (11:07 pm)
DOH!

I shoulda known that. Thanks. I'm a bit embarassed, actually. You can tell I'm a novice, eh?

I still rather wonder why the first chunk brings the machine to its knees, though. It just seems a bit extreme...but wait. Oh...it's got two schedules going almost simultaneously, doesn't it? In fact...it's almost a closed loop. Iiiii Seeeee....

Thanks y'all...
#5
02/23/2007 (9:14 am)
Schedule in and of itself is very lightweight--it does not do much other than create a new SimEvent object, give it a maturation time, and place that event on the Event Processing Queue.

However, things that you may schedule of course can cause extensive load, and right off the bat creating lots of projectiles very often can bring any game to it's knees for a very wide variety of reasons. I realize that your brute force testing doesn't lead directly to this conclusion, but in general the process of schedule itself is not a very large issue until you start making hundreds of schedules per second.
#6
02/23/2007 (9:17 am)
Which is apparently what I ended up doing on accident.

Thanks!
#7
02/23/2007 (9:28 am)
The real reason for the slowdown is that way your function was written, it was creating two schedules at each call (the one inside the IF block and the one that was supposed to be in the ELSE block, but was actually outside of it). So you created a chain reaction: the first time the function is called, it schedules itself twice. When those schedules fire, the function will be called two times, and four schedules will be created. When they fire, you'll have 8 schedules, and things will keep growing up until all of your RAM is consumed and everything crashes.
#8
02/23/2007 (10:59 am)
Quite. Learn something new every day!