void engine(){

particle_effects();

calculate_anim();

do_gravity();

for(int i=0;i<3;i++) do_collision_code(); // so you wont walk into walls

render_every_3d_object();

render_every_sprites_and_texts();

swapbuffers();

if((rendered_frames%1000)==999) toilet(); // free unused memory buffers, throw unused textures, etc

}

//your game:

while(1){

// input

#ifdef WIN32

STOP USING TOY OPERATING SYSTEMS

#else

x11_poll_keyboard_mouse_joystick();

#endif

DO YOUR GAME CODE HERE

// whenever your 3d engine needs to be activated or somethign has to be rendered

engine();

}

Shaarigan said:
If we start talking about “the standard loop” and games, then we should also talk about why it is recommendable to avoid putting everything into the loop on the main thread and instead let that loop do what it is supposed to do, catching OS events and nothing else. I've seen this in Godot for example, where the event loop is also performing calls into the game.

It worked fine back when every Windows game was single-threaded. What has changed?

I would remind you that Godot performs well enough that quite a few people ship games with it. ?

Shaarigan said:
So every OS message interrupts the game for milliseconds.

Milliseconds has not been my observation. How did you measure this?

Shaarigan said:
Also stop catching user input in the main loop!

Why? Recall that checking input state directly can lead to inputs being lost due to timing issues (eg. if the user holds a keyboard button down for less than a frame).

You definitely want to handle all pending events as soon as you get them, without stopping to update the game state or render. In other words, something like this:

while (running) {
  while (event pending) {
    process_event();
  }
  update_game_state();
  render();
}

This is roughly equivalent to your option 1, just structured differently. The reason for handling all events immediately is to prevent a backlog of unhandled events from forming.