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?

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.

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

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?

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.

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).

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.

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?

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.

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.

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.

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.

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.