Hi!
Just to be clear, checking real-time states is not a type of event. The 'first type' you mentioned are events and the 'second type' are states. I only mention it because if you mention events when meaning testing real-time states, there can be confusion.
So, the "Inputs handling" can handle events in two ways :
1. Call window.pollEvent() and send each event to associated listeners (game entities, etc...)
2. Browse each entity and call a handleInputs() method that will check for real-time inputs
Actually, it's more likely that you would do both.
You
must process events for the window anyway since an operating system may complain or close your application if it doesn't, plus you probably want to use events for mouse clicks, single key presses etc..
Checking real-time states for input would then be used for things that are pressed (or held or whatever) or not. For example, you may hold a key to continually move right. Use real-time checks to see if it's (still) pressed. In this case, it doesn't matter when it was pressed, only that it is 'right now'.
- Main loop :
- Inputs handling
- Game logic
- Rendering
With the above said, you can process real-time states inside the game logic directly or use real-time states inside the input handling block to set internal application states and use these internal states for use in the game logic. Note, though, that if you do this, the game logic will have the same input for each update per frame and may not be what you want if you are updating logic (possibly) multiple times per frame.
Mentioning updating logic multiple times per frame, I would recommend game logic to be updated by a fixed time step, with multiple updates occuring to 'catch' up with the amount of actual time passed. For more detailed information, you can read
Fix Your Timestep and/or use the small timing library -
Kairos - and use its
Timestep class to simplify things.
Rendering can be taken care of if a separate function, method (if application itself is a class), directly in the loop, or in a thread. Rendering in a thread is very likely to not worth it. Rendering in the main thread is highly recommended. Remember that if you're rendering in a separate function, you may need to pass references to everything that it needs. If your game logic updates graphical objects directly, you'll need to pass those. If your game logic updates 'frames', 'skeletons' or 'proxies', you pass those and the renderer would create the graphical output from that information. This can have the added benefit that none of the graphics are actually involved in the game logic.
