rlranft Posted August 3, 2015 Share Posted August 3, 2015 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). Quote Link to comment Share on other sites More sharing options...
JeffR Posted August 6, 2015 Share Posted August 6, 2015 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. Quote Link to comment Share on other sites More sharing options...
rlranft Posted August 6, 2015 Author Share Posted August 6, 2015 Easy now, one step at a time...I have to save something to complain about later. Quote Link to comment Share on other sites More sharing options...
buckmaster Posted August 7, 2015 Share Posted August 7, 2015 Could processTick change the control object? Funnily enough I literally just read an article about this very situation. Quote Link to comment Share on other sites More sharing options...
rlranft Posted August 7, 2015 Author Share Posted August 7, 2015 Maybe, but it doesn't look like anything in there changes the control object, just updates it. 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). Quote Link to comment Share on other sites More sharing options...
buckmaster Posted August 8, 2015 Share Posted August 8, 2015 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. Quote Link to comment Share on other sites More sharing options...
rlranft Posted August 8, 2015 Author Share Posted August 8, 2015 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. Quote Link to comment Share on other sites More sharing options...
Caleb Posted August 11, 2015 Share Posted August 11, 2015 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.