Different results with ProccessManager

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Different results with ProccessManager

      Hi,

      i did bought the 3. edition of the book and i am writing a game engine as descripted in the book.

      Now i am seeing a problem in the proccessmanager. I will explain it on a example:

      A game like CS in this engine would have a Process for the bomb waiting to explode and a process for the player who is defusing. So in the ProcessManager would be two processes. Both processes will be implemented like the WaitProcess descripted in the book. (Page 162)

      ProcessManager
      WaitingToExplode(4000ms), Diffuse(3000ms)

      Now the game works smoothly and no laggs, the player will diffuse the bomb in time.

      Now the same example and something happens, that the computer will stock and send 5000ms to the ProcessManager.

      The ProcessManager will go through the list and gets the WaitingToExplode first and that process would trigger the bomb because the time is over. And after that the diffusing process will trigger, but that would already to late.
      That would mean with a lagging computer there would be another result.

      Is there a way that this can be prevented without changing the hole concept?


      I hope my english isn't that horrible. It isn't my native language.

    • RE: Different results with ProccessManager

      Hello!

      You are correct - if the game experiences lag times that are significant the relationship between dependent processes could be broken. But, significant lag times in games or other interactive simulations tend to cause havok with many other systems, including audio and especially physics.

      One thing physics systems do in worst case scenarios is maximize the delta time - so even if the last frame took 5000ms, each process would only get an update with say, 250ms or 100ms. This would have the effect of slowing down everything, as if the hands of time were physically slowed down.

      Of course, finding the cause of that 5000ms frame is also important. :)
      Mr.Mike
      Author, Programmer, Brewer, Patriot

    • I would say, the easiest way to fix the given situation would be to assign priority levels to processes. so the WaitToExplode process would be LOW priority, and the Diffuse process would be a HIGH priority. That way the high priority process would always get processed first.

      There's probably a better way to handle this, but that would be a simple solution.

      Edit: what mike said, my solution is realy just a cheap band-aid fix.

      The post was edited 1 time, last by Kl1X ().