Author Topic: Engine loop chronology  (Read 150 times)

Monsieur OUXX

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
Engine loop chronology
« on: 11 Oct 2017, 12:14 »
I'm asking a question which answers are everywhere in the foruls and in the manual, but I need to have it discussed in one place to make sense of it.
What's the chronolgy/order of operations within one game loop?

Consider this piece of code :
(pre-requisite : create a GUI with a label called TestLabel somewhere)
Code: Adventure Game Studio
  1. bool valueChangedCount=0;
  2. void repeatedly_execute()
  3. {
  4.     for (int i=0; i<10;i++) {
  5.          Display(String.Format("i=%d, valueChangedCount=%d, mouse.x=%d", i, valueChangedCount, mouse.x));
  6.         TestLabel.Text=String.Format("%d", i);
  7.     }
  8. }
  9.  
  10. void repeatedly_execute_always()
  11. {
  12.     valueChangedCount++;
  13. }
  14.  

Now run the game. You will observe this :
- While the Display popup is displayed, the mouse will move on the screen because it's handled at a very low level by the engine.
- However mouse.x is not updated
- when i changes, the change is reflected into the Display popup AND in the TestLabel
- valueChanged does get updated.

All of that demonstrates  :
- that an instruction like Display (which can't be called in a blocking script) really blocks the engine.
  Proof: the game does not switch to next game loop (mouse.x not updated). So its behaviour is different from,
  let's say, Wait(1).
- however repeatedly_execute_always is called at each Display call (proof: valueChanged becomes true),
  which tends to demonstrate the opposite
- GUI changes are immediately rendered(even though the GUI not interactive since mouse is technically frozen). It means
  that GUI rendering is "outside" of game loops, i.e. outside of the repeatedly_execute/repeatedly_execute_always
  chronology.


Is there some logic in there? (not asking in a mean way, just trying to get the whole idea to avoid mistakes)
Is there some queued instructions black magic that I'm missing? Is this snippet code changing game loop each time yes or no?
« Last Edit: 11 Oct 2017, 12:17 by Monsieur OUXX »
 

Crimson Wizard

  • AGS Project Tracker Admins
    • Best Innovation Award Winner 2013, for spearheading the AGS 3.3.0 project
    •  
    • Lifetime Achievement Award Winner
    •  
Re: Engine loop chronology
« Reply #1 on: 11 Oct 2017, 13:28 »
You cannot "block the engine" with the script, there is always a basic game update loop running, which does rendering and audio update, so that e.g. the music won't halt.

Repeatedly_execute_always is too run always, even during blocking functions, as the name implies.

It's hard to tell why the mouse.x parameter is not updated without investigation, this could simply be a design quirk, but these parameters are just reflection of mouse status, it's not like there is a direct connection between real mouse position and them.
Also, there is a Mouse.Update() function that forces engine to update these parameters. I haven't experimented with this, but maybe it updates mouse even during Display, if you call it in rep-exec-always.
« Last Edit: 11 Oct 2017, 15:52 by Crimson Wizard »

Monsieur OUXX

  • Cavefish
  • Mittens Vassal
  • Mittens Half Initiate
    • I can help with proof reading
    •  
    • I can help with translating
    •  
    • I can help with voice acting
    •  
Re: Engine loop chronology
« Reply #2 on: 11 Oct 2017, 16:04 »
Thanks I'll experiment on that.

One last thing : Could you briefly elaborate on the differences between putting a Display in a loop in repeatedly_execute, and calling Wait(1) ?