🔒 Locked 🎮 Unity

Game loop in Qt

Started by XTAL256 Oct 21, 2011 at 3:30 AM 1 replies 13.1k views

Original Post

Oct 21, 2011 at 3:30 AM

I have recently decided to use Qt for making my 2D game. All was going well until i started thinking about the game loop. Previously (when i used SDL), it was something like this:


 int main(int argc, char* argv[]) {
 
 // Setup stuff
 // ...
 
 int lastTime, dt, timeLeft;
 while(!appQuit) {
 while (SDL_PollEvent(&sdlEvent)) { // <-- Process any events in the queue
 if (sdlEvent.type == SDL_QUIT) {
 appQuit = true;
 break;
 }
 Event::eventProc(sdlEvent); // <-- Do my own event processing, for GUI and stuff
 }
 lastTime = SDL_GetTicks();
 clearScreen();
 
 if (Game::isStarted && !Game::isPaused)
 Game::update(); // <-- Update game state (physics)
 
 GUI::drawScreen(); // <-- Draw everything
 glFlush();
 SDL_GL_SwapBuffers();
 
 dt = SDL_GetTicks() - lastTime;
 timeLeft = (1000/Settings::frameRate) - dt;
 if (timeLeft > 0)
 Sleep(timeLeft); // <-- Sleep until next update
 }
 
 // Shutdown stuff
 // ...
 }

I was also intending on using a different rate for graphics and physics updates, as this guy says.

But now with Qt, i don't have access to the main event loop, so i am not sure how to do this.
Some have suggested using a QTimer, but i don't like that approach for a number of reasons. Firstly, the resolution may not be enough for high frame rates. And if i separate logic and graphics updates, i would need two separate timers. Maybe that would not be a problem, but it doesn't sound like a nice way to do it.

There is also the question of how often to update. Most people just write a loop that updates as fast as it can - i.e. with no sleeping in between. I don't like this idea because it uses an unnecessary amount of CPU for rendering a fairly simple 2D game. And regardless of your opinion on this, i have my reasons, and so i would like to be able to set a maximum frame rate for my graphics and/or physics updates.

So, does anyone have any ideas? There must be some way to do this in Qt. Using Qt (for anything, let alone games) is a joy, and i really do not want to go back from it now.

SimonForsman

Oct 21, 2011 at 6:36 AM

I have recently decided to use Qt for making my 2D game. All was going well until i started thinking about the game loop. Previously (when i used SDL), it was something like this:

int main(int argc, char* argv[]) { // Setup stuff // ... int lastTime, dt, timeLeft; while(!appQuit) { while (SDL_PollEvent(&sdlEvent)) { // <-- Process any events in the queue if (sdlEvent.type == SDL_QUIT) { appQuit = true; break; } Event::eventProc(sdlEvent); // <-- Do my own event processing, for GUI and stuff } lastTime = SDL_GetTicks(); clearScreen(); if (Game::isStarted && !Game::isPaused) Game::update(); // <-- Update game state (physics) GUI::drawScreen(); // <-- Draw everything glFlush(); SDL_GL_SwapBuffers(); dt = SDL_GetTicks() - lastTime; timeLeft = (1000/Settings::frameRate) - dt; if (timeLeft > 0) Sleep(timeLeft); // <-- Sleep until next update } // Shutdown stuff // ... }

I was also intending on using a different rate for graphics and physics updates, as this guy says.

But now with Qt, i don't have access to the main event loop, so i am not sure how to do this.
Some have suggested using a QTimer, but i don't like that approach for a number of reasons. Firstly, the resolution may not be enough for high frame rates. And if i separate logic and graphics updates, i would need two separate timers. Maybe that would not be a problem, but it doesn't sound like a nice way to do it.

There is also the question of how often to update. Most people just write a loop that updates as fast as it can - i.e. with no sleeping in between. I don't like this idea because it uses an unnecessary amount of CPU for rendering a fairly simple 2D game. And regardless of your opinion on this, i have my reasons, and so i would like to be able to set a maximum frame rate for my graphics and/or physics updates.

So, does anyone have any ideas? There must be some way to do this in Qt. Using Qt (for anything, let alone games) is a joy, and i really do not want to go back from it now.

My current main loop looks like this:


 int main(]int argc, char* argv[]) { 
 // init stuff
 while(game.isRunning()) {
 a.processEvents(); //(a is a QApplication created during the init, should use a better name i guess)
 QTime currentTime= QTime::currentTime();
 int timeSinceLastUpdate = lastUpdate.msecsTo(currentTime);
 while(timeSinceLastUpdate>updateTimeStep){
 game.update();
 timeSinceLastUpdate-=updateTimeStep; 
 lastUpdate=lastUpdateaddMSecs(updateTimeStep);
 }
 renderer.setInterpolateFraction(static_cast<float>(timeSinceLastUpdate)/static_cast<float>updateTimeStep);
 renderer.renderGameObjects();
 renderer.renderGUI();
 renderer.swap(); 
 }
 a.exit();
 return 0; 
 }

I've abstracted away quite a few things in my engine so very little code touch QT directly (Only event handling and timers in the mainloop), input and renderer use QT but has their own interface and can thus quite easily be replaced with non QT versions if needed for a future port)

If the game is simple enough you can toss in a sleep(1) to reduce cpu usage and allow the system to save some energy. (The game might sleep for significantly more than 1ms though so i'd recommend keeping it as an option for the user) (Sleep(0) will not sleep at all on Windows unless there is an equal or higher priority thread that wants to use the CPU and thus won't cause the system to save energy (sleep(0) will however cause your application to have less of an impact on the performance of other running applications))

an alternative is to use a 0 ms QTimer , it will trigger as fast as it can and the timer resolution should be irrelevant. (Use a QTime object in the QTimers callback to determine if enough time has passed to do a state update and just render as fast as you can)

XTAL256

Oct 22, 2011 at 10:58 AM

I think i will just go with the QTimer option. My game is 2D and isn't too complicated, so timing won't need to be terribly accurate.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.