Redundant test in onTickObject()

Expanding and utilizing the engine via C++.
8 posts Page 1 of 1
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Mon Aug 03, 2015 3:33 pm
I'm on a mission to implement pausing for single-player games and so I'm rooting around a bit. I noticed this in T3D/gameBase/std/stdGameProcess.cpp:
// Do we really need to test the control object each iteration? Does it change?
      for ( m = 0; m < numMoves && con && con->getControlObject() == obj; m++, movePtr++ ) // call con->getControlObject()
      {         
         #ifdef TORQUE_DEBUG_NET_MOVES
         U32 sum = Move::ChecksumMask & obj->getPacketDataChecksum(obj->getControllingClient());
         #endif
      
         if ( obj->isTicking() )
            obj->processTick( movePtr );

         if ( con && con->getControlObject() == obj ) // call con->getControlObject() again
         {
Seems to me that the comment at the top questions the frequency of control object changes, but aside from that why don't we just rely on the condition in the for() statement? We shouldn't even be inside this for loop unless con->getControlObject() returns our obj, or am I missing something? Seems like it might save us a little time in a fairly heavily called area.

And I still don't know where to short-circuit scene processing - before we go there, the last time I tried setting TimeScale to 0 (back in T3D 1.2) it made all event processing unresponsive (including GUI events).
JeffR
Steering Committee
Steering Committee
Posts: 858
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Aug 06, 2015 3:51 pm
Yeah, That should probably be cleaned up.

We could also have the con && con->getControlObject() == obj part of the conditional tested pre-emptively so that if it doesn't match, we just skip the whole mess, as having that function call in the for condition is less efficient as well.
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Thu Aug 06, 2015 10:33 pm
Easy now, one step at a time...

I have to save something to complain about later.
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Fri Aug 07, 2015 5:08 am
Could processTick change the control object? Funnily enough I literally just read an article about this very situation.
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Fri Aug 07, 2015 5:53 am
Maybe, but it doesn't look like anything in there changes the control object, just updates it. <shrug>

I've pulled it out and no ill effects so far - but really mild test case (single player only, no AI units around yet, etc).
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Sat Aug 08, 2015 6:09 am
Where does the control object get selected? It's probably somewhere outside the process tick loop right? Problem is even if that's currently the case, someone could write a class that does update the control object. Then we'd have a bug, assuming the second if is significant.
rlranft
Posts: 298
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Sat Aug 08, 2015 3:33 pm
By the time the ticking object has a chance to change its control object we're already at the end of the method. So even though we're checking for it, if the object changes its control object we won't find out about it until the next pass through here. And if the control object can change itself during its tick we're already past these checks when that could happen as well.

To me this looks like prematurely catching a potential edge case that should never arise - and if it does, it should be corrected at the source. Meanwhile we burn clocks for something that doesn't currently happen.
Caleb
Posts: 19
Joined: Tue Feb 10, 2015 5:01 pm
by Caleb » Tue Aug 11, 2015 6:20 pm
I don't have much to add to this discussion, but I have done some fun things that allow for my game to pause if you're interested.
8 posts Page 1 of 1

Who is online

Users browsing this forum: No registered users and 3 guests