purpose of 2 queues in event system?

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

    • purpose of 2 queues in event system?

      In the event system chapter, having 2 event queues was proposed as a solution for events that can generate other events, causing the queue to grow too long.

      How does having 2 queues help? My understanding is that you process queue A, any new events that results from the processing are sent to the other queue B. Then once queue A is done processing, you switch and process queue B, adding new events to A. This doesn't seem to actually change the number of events that could get processed as you still have to deal with them at some point.
    • The idea here is that you only process a single queue per-frame, this means that if you have 20 events queued in a frame, at processing time you would process each event, if those events themselves queued up 20 more events they would be passed to the second queue, and processed the next frame.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • It also prevents a potential infinite loop. If Event A pushes Event B and Event B pushes Event A, you'd never break out of the loop. You still have to be careful if you go through the TriggerEvent() path because that bypasses the queue entirely and just calls the callback immediately. In my example, if both Event A and Event B triggered each other, you'd have the same issue.

      This double queue system is a very common pattern in games called double buffering. You see it all over the place. The most famous example comes from graphics programming where you often have the buffer you're drawing to and the buffer that's being displayed. In DirectX, they are called the back buffer and primary buffer, respectively.