[SOLVED][SDL] Delta Timing Question

[xiphirx]

So, just to make sure I'm doing this correctly, in my loop I have

Code: Select all

		thisTime = SDL_GetTicks();
		delta = (thisTime - lastTime) / 1000.0f;
		lastTime = thisTime;
		update(delta);

If it was done correctly, delta should contain the time it took to display a frame in seconds.

Then, when I move something

Code: Select all

		changeInPosition = changeInPosition * dt; //dt = delta
		ballPosition = ballPosition + changeInPosition; //both are vectors

But I have a few questions about this. If I set the velocity to 1 for the ball, it moves extremely slow, which I'm guessing is because I'm telling it to move 1 pixel per second... right?

However, if I put a high value for the velocity, like 100, it moves as if I were just moving it one pixel every frame. By setting it to 100, I'm telling it to move 100 pixels every second correct?

Is it normal to have high values such as 100 for medium speed movement when you use delta timing?

Also, say I wanted to wait for 5 seconds before doing something, couldn't I just keep accumulating delta until it is greater than or equal to 5.0? I've tried this, but it doesn't work at all, leading me to suspect that I may have to do some multiplication of the deltas...

[xiphirx]

Anyone?

[XianForce]

Code: Select all

      changeInPosition = changeInPosition * dt; //dt = delta
      ballPosition = ballPosition + changeInPosition; //both are vectors

That's your problem there... So I'm guessing "changeInPosition" represents your velocity? So let's take a look at what happens each frame starting from 100:

Code: Select all

//changeInPosition = 100...

//frame 1
changeInPosition = 100 * 0.3;

//frame 2
changeInPosition = 30 * 0.3

//etc, etc, etc...

0.3 was just an arbitrary number, but hopefully it highlighted the issue?

It should be something like:

Code: Select all

ballPosition += changeInPosition * dt;

[xiphirx]

No, the change in position is made from a velocity vector, so it doesn't degrade in value.

[Falco Girgis]

So, just to make sure I'm doing this correctly, in my loop I have

Code: Select all

		thisTime = SDL_GetTicks();
		delta = (thisTime - lastTime) / 1000.0f;
		lastTime = thisTime;
		update(delta);

If it was done correctly, delta should contain the time it took to display a frame in seconds.

Then, when I move something

Code: Select all

		changeInPosition = changeInPosition * dt; //dt = delta
		ballPosition = ballPosition + changeInPosition; //both are vectors

But I have a few questions about this. If I set the velocity to 1 for the ball, it moves extremely slow, which I'm guessing is because I'm telling it to move 1 pixel per second... right?

However, if I put a high value for the velocity, like 100, it moves as if I were just moving it one pixel every frame. By setting it to 100, I'm telling it to move 100 pixels every second correct?

Is it normal to have high values such as 100 for medium speed movement when you use delta timing?

Also, say I wanted to wait for 5 seconds before doing something, couldn't I just keep accumulating delta until it is greater than or equal to 5.0? I've tried this, but it doesn't work at all, leading me to suspect that I may have to do some multiplication of the deltas...

You have been absolutely correct about everything.

Yes, it's normal to have high deltas for slow/medium moving objects. Our characters need to move at 3 pixels per frame or 3 pixels * 60 fps = 180 pixels/sec.

And yes, for a delay you simply add the delta each frame until it becomes greater than some threshold. There is no reason whatsoever that that approach would not work.

Multiplying deltas would not ever, EVER work. Think about it. You're multiplying each frame by a number that is already less than 1.0 second... Your delta is going to be getting smaller and smaller like that.

[Falco Girgis]

Code: Select all

ballPosition += changeInPosition * dt;

That is exactly what he's doing here in a very convoluted way:

Code: Select all

    changeInPosition = changeInPosition * dt; //dt = delta
      ballPosition = ballPosition + changeInPosition; //both are vectors

No, the change in position is made from a velocity vector, so it doesn't degrade in value.

What he's TRYING to say is that changeInPosition is reset back to the value of the velocity every frame (and not actually changing frame-to-frame).

[xiphirx]

Okay, thanks for clarifying.

But about delaying, if I do that in my game currently, it adds up to 5.0 practically instantly... The framerate is being limited to 60

Wait, I think I just figured it out as I wrote it lol, so since there is 60 frames per second, that would mean that I want to add up to 300 (60*5) for 5 seconds?

[Falco Girgis]

Okay, thanks for clarifying.

But about delaying, if I do that in my game currently, it adds up to 5.0 practically instantly... The framerate is being limited to 60

Wait, I think I just figured it out as I wrote it lol, so since there is 60 frames per second, that would mean that I want to add up to 300 (60*5) for 5 seconds?

No. The point of deltaTime is that there aren't 60 frames per second necessarily. That's how you would create a naive frame counter.

Something is fucked with your deltatime then. The deltatime is literally the time ellapsed since the last frame (in seconds), so when it becomes 5, that's 5 seconds...

[XianForce]

Ooops... My bad XD

[xiphirx]

Okay, I'll look into it more.

This might sound stupid, but If I remove the frame rate limit, wouldn't that cause my game to go and pretty much use all available resources (its on the PSP btw) and start to overheat the system? :S This is a (probably) false belief I have had for a long time D:

[Falco Girgis]

Okay, I'll look into it more.

This might sound stupid, but If I remove the frame rate limit, wouldn't that cause my game to go and pretty much use all available resources (its on the PSP btw) and start to overheat the system? :S This is a (probably) false belief I have had for a long time D:

Uhhm, heeeeell no. There is no reason to ever cap the framerate on an embedded device.

Are you sure the PSP will even LET you run at over 60fps?

Framerate capping is for platforms with runtimes, operating systems, and other processes sharing your resources. A PSP (other than the simple kernel that probably isn't doing shit until you raise a hardware interrupt by pushing the home key or something) is not doing anything other than running your game.

So you're doing SDL on a PSP and the performance is even good enough that you think it could even get over 60fps?

[xiphirx]

Okay, I'll look into it more.

This might sound stupid, but If I remove the frame rate limit, wouldn't that cause my game to go and pretty much use all available resources (its on the PSP btw) and start to overheat the system? :S This is a (probably) false belief I have had for a long time D:

Uhhm, heeeeell no. There is no reason to ever cap the framerate on an embedded device.

Are you sure the PSP will even LET you run at over 60fps?

Framerate capping is for platforms with runtimes, operating systems, and other processes sharing your resources. A PSP (other than the simple kernel that probably isn't doing shit until you raise a hardware interrupt by pushing the home key or something) is not doing anything other than running your game.

So you're doing SDL on a PSP and the performance is even good enough that you think it could even get over 60fps?

Actually, I sorta mutated my question through the topic. lol

I have delta timing in this Pong clone on my PC, which is what my initial question was for, but I am also working on a game for PSP (not using SDL) using a engine called JGE. It uses delta timing too, and I limit the frame rate on it (which is stupid now that I understand why )

If you don't cap the frame rate, it does go well over 60FPS. I've had it go to 600FPS with very simple stuff, but I haven't tried it with more complex things.

[Falco Girgis]

Gotcha, gotcha. I kinda figured, actually.

Yes, cap it on the PC. If it were a top-end 3D game that will be running fullscreen and pushing your PC, don't bother, but since it's a smaller game that will potentially be running windowed, please do cap it.

So you're getting that ~600fps on the PSP?! Holy shit... Maybe the GPU is what would be capping the framerate, and since SDL is software rendered, that isn't happening? Oh well. I highly doubt it'll stay anywhere near that intense when you start getting even a moderate amount of things going on in your scene. The performance of software-based rendering on any embedded platform is usually borderline shit. XD

[xiphirx]

Okay, so I don't need to cap it on the PSP since the system doesn't need to take care of the kernel (well not as much, just the home callback), but on a PC, I need to let the computer take care of the OS.

I'll try removing the frame cap and see if it still gets to 5 instantly...

[Falco Girgis]

I'll try removing the frame cap and see if it still gets to 5 instantly...

I still don't think you get it. If you remove the framecap less time will elapse between each frame, so it'll take more frames to hit 5 seconds--It will STILL take 5 seconds. It should ALWAYS take 5 seconds. That's the point of delta time. Whether it be 1fps or 9999999 fps, when the deltaTime sums to 5 seconds, 5 seconds has gone by. XD

Does your detaTime not work on the PSP or PC? The PSP might not actually have implemented a way of getting ticks in milliseconds, so the standard dictates to just return current time+1 (which would imply that only 1 ms has gone by), but that number is LESS than 1/60th of a second, so 5 seconds should take LONGER than 5 seconds to accumulate if this were the case...