Perfomance (FPS) problems in OpenGL and SDL. Help.

Member
Posts: 249
Joined: 2008.10
Post: #1
Hi!

I'm having some perfomance problems when trying to stick my frame rate to 30 FPS (just because physic engine, box2d, requires a constant frame rate)

This is my game loop, as you can see there is a SDL_Delay call. In this case sometimes my game stops when I move the camera, like a random lag. If I remove SDL_Delay, everything works fine, but as FPS are variable I cannot use box2d.

Do you have the same problem with SDL_Delay?
Do you have any idea or suggestion?


Code:
void CApp::StartGameLoop() {
    g_log->WriteInfo("Starting game loop.");
    SDL_Event event;
    while (!m_exit_game_loop) {
        unsigned int then=SDL_GetTicks();

        // sound, input, update, render
        m_sound_manager->Update();
        while (SDL_PollEvent(&event)) ProcessPendingEventSDL(&event);
        Update();
               Render();

        // must wait?
        int elapsed=SDL_GetTicks()-then;
        int wait=FRAME_TIME-elapsed;
        if (wait>0) SDL_Delay(wait);
        //printf("wait %d\n", wait);
    }
    g_log->WriteInfo("Finishing game loop.");
}


Even on the Simulator I have this problem, although it is more intensive on the iPhone.

By the way, is SDL compatible with Instruments? I can't launch it.

FRAME_TIME is 33 (ms) in order to get no more than 30 FPS. If I uncomment printf("wait %d\n", wait); I see as usually after update and render, wait is about 22 ms. So the iPhone actually do not have any problems updating and rendering my world.

Thanks a lot for your help.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #2
No matter what you do, it's generally impossible on a modern computer system to guarantee that you'll run at a specific frame rate. The best way to deal with this is to decouple your logic updates from your screen updates; run the logic updates at a (conceptually, if not physically) constant interval, and the screen updates at a variable interval. This article I wrote might help: http://sacredsoftware.net/tutorials/Anim...tion.xhtml
Quote this message in a reply
Member
Posts: 249
Joined: 2008.10
Post: #3
ThemsAllTook Wrote:No matter what you do, it's generally impossible on a modern computer system to guarantee that you'll run at a specific frame rate. The best way to deal with this is to decouple your logic updates from your screen updates; run the logic updates at a (conceptually, if not physically) constant interval, and the screen updates at a variable interval. This article I wrote might help: http://sacredsoftware.net/tutorials/Anim...tion.xhtml

Thanks for reply.

It works perfectly on Windows, that's what I don't understand.
BTW: When you say "screen updates at a variable interval" do you mean render at maximun capacity?

Thanks.
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #4
ThemsAllTook Wrote:No matter what you do, it's generally impossible on a modern computer system to guarantee that you'll run at a specific frame rate. The best way to deal with this is to decouple your logic updates from your screen updates; run the logic updates at a (conceptually, if not physically) constant interval, and the screen updates at a variable interval. This article I wrote might help: http://sacredsoftware.net/tutorials/Anim...tion.xhtml

Fixed interval time-based animation works fine ... the only tradeoff is that it can result in heavier CPU load than neccesary.
Sometimes it may be more efficient to design your collision detection or animation interpolation system to deal with widly variable time intervals rather than doing it with brute force by iterating updates.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #5
riruilo Wrote:BTW: When you say "screen updates at a variable interval" do you mean render at maximun capacity?

More or less. The generally agreed best practice is to render as fast as possible with VBL sync on, so that the system will sleep until the next screen refresh before letting your rendering finish. However, I'm not sure if this changes with the new CVDisplayLink...

warmi Wrote:Fixed interval time-based animation works fine ... the only tradeoff is that it can result in heavier CPU load than neccesary.
Sometimes it may be more efficient to design your collision detection or animation interpolation system to deal with widly variable time intervals rather than doing it with brute force by iterating updates.

Agreed. The main reason I prefer fixed interval logic is because depending on what you're doing, it can be *incredibly* difficult and basically unverifiable to get a variable interval system working consistently at all possible intervals. Using a fixed interval system, while technically less efficient, simply takes nondeterministic behavior out of the picture entirely (as far as time based things go, at least).
Quote this message in a reply
Member
Posts: 749
Joined: 2003.01
Post: #6
That happens because SDL_Delay is not always precise.

Instead of SDL_Delay you could use

while (SDL_GetTicks()-then<FRAME_TIME)
{
//do nothing
}
this gives you pretty precise timing, though it uses 100% cpu (but who cares, for a physicsy iphone game this is expected)

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #7
Najdorf Wrote:That happens because SDL_Delay is not always precise.

Instead of SDL_Delay you could use

while (SDL_GetTicks()-then<FRAME_TIME)
{
//do nothing
}
this gives you pretty precise timing, though it uses 100% cpu (but who cares, for a physicsy iphone game this is expected)

It is better to simply put your process to sleep for whatever miliseconds you have left .... sure, the sleep method may not be 100% accurate but so won't be your battery-killing loop - your thread may get preempted in the loop and still overshoot.
Quote this message in a reply
Member
Posts: 249
Joined: 2008.10
Post: #8
warmi Wrote:It is better to simply put your process to sleep for whatever miliseconds you have left .... sure, the sleep method may not be 100% accurate but so won't be your battery-killing loop - your thread may get preempted in the loop and still overshoot.

That is what I thought. I mean, wasting CPU is not a problem in a PC, but not on the iPhone. Battery will ran out faster, and phone maybe will became warn/hot.

By the way, I use SDL just bacause I like the way events are managed.
Can I do something similar without using SDL? ie, create an event queue and process them as I'm doing with my SDL program?
Quote this message in a reply
Member
Posts: 749
Joined: 2003.01
Post: #9
Meh, you're making an iphone game, it's fine if you use up all the resources you can, It's not going to overheat and explode... And yeah, of course it eats up battery, but that's something that's expected for any game that isn't tic-tac-toe.

Nobody cares if your game uses 20% more resources than it should, if people are so concerned with battery life they dont buy an iphone, they buy a Nokia 3310.

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #10
Najdorf Wrote:Meh, you're making an iphone game, it's fine if you use up all the resources you can, It's not going to overheat and explode... And yeah, of course it eats up battery, but that's something that's expected for any game that isn't tic-tac-toe.

Nobody cares if your game uses 20% more resources than it should, if people are so concerned with battery life they dont buy an iphone, they buy a Nokia 3310.

This is absolutely the wrong attitude to have, and directly against Apple's guidelines. Power management is crucial to any mobile application, and perfectly relevant on the desktop too. There's no excuse whatsoever for wasting CPU cycles unnecessarily as in the above example.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #11
I don't think Najdorf is completely off-base with this. I agree that it's nice to be a good citizen and help the customer save battery life, and it's all fine and good to go along with Apple's "guidelines" ... but here's reality: it's a ridiculously competitive market where Apple really only cares about itself and it's rube goldberg app approval process where some apps get away with breaking the rules and some don't, and likely most of the customers probably only care about whether the game is fun or not. If it makes their hand hot they'll whine and moan -- so what? The App Store is already flooded with app-tards that complain about anything. So really, if it passes Apple's mystical app approval process, and it doesn't crash the device ... I say it's good enough.

I say that now, but I wouldn't have said that a few months ago. Things have changed. The whole iPhone thing is a chaotic world. ... and Apple just seems to keep feeding more entropy into the system. It's not our fault!

riruilo Wrote:By the way, I use SDL just bacause I like the way events are managed.
Can I do something similar without using SDL? ie, create an event queue and process them as I'm doing with my SDL program?

I don't know how SDL does it, but I have my own queue of input events that I create. This is so I don't have to stop any game processing in-progress to handle input when it arrives -- I just stuff any newly arriving input into my queues as the system feeds it, and the game copies all the input out of the queues at the beginning of each update. At the end of each update, I clear the queues. So there are the input queues that the system stuffs input into and the working queues that the game reads, and the input queues are copied fresh into the working queues each update. It works flawlessly.
Quote this message in a reply
Member
Posts: 166
Joined: 2009.04
Post: #12
AnotherJake Wrote:I say that now, but I wouldn't have said that a few months ago. Things have changed. The whole iPhone thing is a chaotic world. ... and Apple just seems to keep feeding more entropy into the system. It's not our fault!



I don't know how SDL does it, but I have my own queue of input events that I create. This is so I don't have to stop any game processing in-progress to handle input when it arrives -- I just stuff any newly arriving input into my queues as the system feeds it, and the game copies all the input out of the queues at the beginning of each update. At the end of each update, I clear the queues. So there are the input queues that the system stuffs input into and the working queues that the game reads, and the input queues are copied fresh into the working queues each update. It works flawlessly.

Are you running your game loop in a separate thread ?
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #13
warmi Wrote:Are you running your game loop in a separate thread ?

Sometimes I am, sometimes I'm not. On iPhone I do not, although I can. On Mac my engine is switchable to threading on the fly. I always run off a timer, not a classic "loop-in-place", although queuing input has nothing to do with that either way. My queue system works great with the constant update rate in either situation because it separates input from the update. IOW, the input might input a whole bunch of stuff in-between updates (although that's only relevant with analog input), but since it's all queued, the update never misses anything and there are no timing issues at all.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Retrieving "friends" from my REST highscore webservice, a perfomance question riruilo 6 5,173 May 3, 2010 01:46 AM
Last Post: riruilo
  OpenGl ES Texture Problems jhbau1000 4 4,250 Mar 24, 2009 02:41 PM
Last Post: AnotherJake