[SDL] Same Execution Time != PC's

What about

while ((finalTicks - initialTicks) < 17)

intead of

while (finalTicks - initialTicks < 17)

The change in the above post should make no difference.

What you're probably finding is that you are simply not managing to get 60 frames per second on one or both machines. That code limits you to 60 frames per second if you would normally run faster, but won't speed you up if you were running slower!

Measure your actual frames per second on each computer and see what you get.

I took some tests.
Pc (1 Processor) = 23 fps
Pc (2 Processor) = 47 fps

What can I do??? With my method I can down fps, but I can't increase them.

Thanks!

You need to optimize your code

With SDL that usually means drawing less, or not using any alpha blending, or both. Or moving to OpenGL for rendering.

Thanks for the answers. I found the error. Basically I do this for each frame:
(1) Draw Map
(2) Compute colision
(3) Render Enemies (ship, shots, explosions)
(4) Render player ship (ship, shots, explosions)
(5) Show info (lifes, score, nº level, etc)

(2) to (5): I have developed the code.
(1): I use the SDL_Mappy class to render map.

Then I skipped (1) and I counted 170 fps :)
Maybe I need to write the code to draw the map.

First, you need to let the OS breath. You can't just while like that, the CPU will be stuck at 100% usage. I know some PCs *cough*mac book pro*cough* that will simply shutdown after couple minutes. You need a sleep or wait for the SDL paint event.

Then after that, as Kylotan said, you need to compensate if you have less frames available. Rendering is lagging, and you have 30 fps for example, each frame you will need to update twice.

Quote:

Original post by Daivuk Then after that, as Kylotan said, you need to compensate if you have less frames available. Rendering is lagging, and you have 30 fps for example, each frame you will need to update twice.

What if you get 45 fps, should you update 1.5 times per frame then? Or update once this frame, and twice the next? I think that might result in very jerky movement.

A better solution would be to calculate seconds per frame instead of frames per seconds, and then multiply that with for example the speed of a ship. Assume for example that you want to move the players ship 20 pixels per second. If it takes 0.1 seconds to draw a frame you get 20 * 0.1 = 2, so you move the ship 2 pixels this frame. With this approach it won't matter how many frames you render per second, the movement will be constant.

Peros:
In my example, I'm assuming you are interpolating in the render too. But that works fine anyway without it. it will not look jerky without interpolation.

And I understand your way of doing it, but this breaks the "perfect" simulation. Try to run a physical situation, with your method the simulation will be different every time you run the game.

It's also unfriendly for networked game, for the same reason above: It breaks the simulation.

It also makes collisions more difficult if you have lags.

Quote:

And I understand your way of doing it, but this breaks the "perfect" simulation. Try to run a physical situation, with your method the simulation will be different every time you run the game.

Not necessarily.

What Perost mentioned should work the same regardless of frame rate since it performs the physics independent of frame rate. For example, a slower computer should show a falling block in the same place as a faster one after 1 second with the noticeable exception that the slower one will look more jumpy.

One of the problems you may encounter when the time slice of a particular frame exceeds a certain amount is that certain collisions may be missed i.e. objects may appear to pass through another object producing different results on different machines.

This can be worked around by specifying a maximum allowed time slice. If a particular frame takes longer than this maximum, run the physics portion multiple times until it has used the amount of time the frame has taken.

for example:


The physics method will run 2 times because the frame took 1.75 times longer than the maximum time. The first iteration will go at the maximum time slice, the second at slightly less. This will help make an object in motion be in the same place on 2 different machines at the same time regardless of computing speed however slower machines will show slower/jumpier movement since the object will most likely travel greater distances per frame.

Other factors affect how accurately something like a physics simulation can be reproduced such as fixed vs floating point math however that is a different topic better left to someone with more math skills than myself and this is a good place to start.

Quote:

Original post by evillive2 Quote: And I understand your way of doing it, but this breaks the "perfect" simulation. Try to run a physical situation, with your method the simulation will be different every time you run the game. Not necessarily.

Fix Your Timestep! ;)

Thanks for info.
Now I'm counting miliseconds per frame and I compute movement in this manner:

//
// (1) I compute miliseconds per frame
//

int msPerFrame = ComputeMsPerFrame();


//
// (2) I move the ship, depending in msPerFrame and ship speed
//
//
// void cShip::moveRight(float units) {
// setXCoord( getXCoord() + (getSpeed() * units));
// }
//
//

myship.moveRight( ((float)msPerFrame) / 1000);


Is this correct to manage execution speed?

Yeah, though it's more common to pass the value in as the time in seconds rather than calling it the 'units', and to pass it in as a float or double.