Engine loop chronology

Started by Monsieur OUXX, Wed 11/10/2017 12:14:13

Previous topic - Next topic

Monsieur OUXX

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: ags

bool valueChangedCount=0;
void repeatedly_execute() 
{
    for (int i=0; i<10;i++) {
         Display(String.Format("i=%d, valueChangedCount=%d, mouse.x=%d", i, valueChangedCount, mouse.x));
        TestLabel.Text=String.Format("%d", i);
    }
}

void repeatedly_execute_always() 
{
    valueChangedCount++;
}


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?
 

Crimson Wizard

#1
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.

Monsieur OUXX

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

SMF spam blocked by CleanTalk