So I've looked up tutorials and noticed that a lot of people keep the game loop method call outside the main method. Is there a reason not to have
While (bIsRunning)
{
gameLoop();
}
Inside the main method?
Sorry for not formatting. I'm on my phone. I have a feeling the answer will just be preference or something. Thanks for any answers.
Game loop
At some point within your code, you absolutely will need some kind of loop that at the very least gets user input, handles game events, and renders the next frame. How you choose to implement this is indeed personal preference. I choose to do all of this behind the scenes using an engine. The way my engine works is you create a state for the menu, one for the game, maybe a pause state etc. and each state has it's own objects it wants to draw, I only need to work with one state class this way, and whichever state is active the engine will draw its objects on the screen and handle that states own events etc. if I want to change states, I have some kind of state like when the user clicks the play button change to game state and then the new state takes over. The main.cpp only has 20 or so lines in it, all it's used is to initialize the Framework object with the initial state and the rest is done through the states themselves.
So I've looked up tutorials and noticed that a lot of people keep the game loop method call outside the main method. Is there a reason not to have
While (bIsRunning)
{
gameLoop();
}
Inside the main method?
Sorry for not formatting. I'm on my phone. I have a feeling the answer will just be preference or something. Thanks for any answers.
Modularization. If the game loop is outside main, e.g. encapsulated in a Game class, you can put the following building blocks in main in a very organized and clean way: initialization, game loop, and shutdown.
Of course, you can write it any way you want.
Of course, you can write it any way you want.
Not if, as previously mentioned, you ever need to give control back to the operating system, which on all modern devices you do.
Sixoul, assuming Windows, but it really doesn’t matter which platform, your loop starves the window from input unless run on a second thread, and if you aren’t sure why your loop has a problem you are not yet ready to dive into that realm.
And either way you did go, the loop should never be that simple, this time for reasons georger.araujo mentioned. A game should be divided into modules. I have outlined this in several posts:
Passing Data Between Game States
And what you will eventually want to do, making your loop more complex:
Fixed-Time-Step Implementation
L. Spiro
georger.araujo, on 22 Oct 2013 - 4:31 PM, said:
Of course, you can write it any way you want.
Not if, as previously mentioned, you ever need to give control back to the operating system, which on all modern devices you do.
I beg to differ.
It is perfectly possible for one to write a game loop any way he/she sees fit. For example, in the Snake article here on gamedev.net, the game loop is all in main(). One could hardly say it's the best way to do it, but it works and you can make games with it.
When did anyone mention giving control back to the operating system?
Allow me to correct myself:
Secondary threading aside, not if you intend to either not return control back to the operating system, which is the case on some consoles but not on most systems with pre-emptive schedulers, or if you desire to starve the window’s message queue.
Returning control to the operating system was a loose way of saying, “give resources back to the operating system for better system performance.”
L. Spiro
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
