Jump to content

Redundant test in onTickObject()


rlranft

Recommended Posts

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...