Original Post
🔒 Locked
Speed
Advertisement
Instead of moving your character a number of pixels per frame, you make him move a number of pixels per second. You can calculate the amount of time that has passed since the last update of the character's position and then use this amount of time do calculate the new position.
x = x + v*dt
dt is the amount of time that has passed since the last frame, v is the velocity.
x = x + v*dt
dt is the amount of time that has passed since the last frame, v is the velocity.
You check the time when you start doing stuff, and then again when you're done. Then you subtract the two, and you're left with the difference, that is, how much time passed from the first timestamp to the second.
Nope, as far as I know there is no standard crossplatform way to do this.
Assuming Windows: timeGetTime()
Assuming Windows: timeGetTime()
Quote:
Original post by Grantyt3
Well, I know that, but how do you check the time before and after. Isn't there something that's part of the standard library?
Maybe this?
If you are using an APi like SDL or whatever, they usually have easier to use functions.
Okay, I'm using that, but I have a little question.
It returns milliseconds. If vx is equal to 1 and frameTime is equal to 7 and I do this: x = vx * frameTime,
Then that's way too fast. I think the only way to resolve this is to either turn those milliseconds into a fraction of a second (0.007 instead of 7), or make my movement speeds into smaller fractions. Either way, it's going to have to convert the floats into integers when it gets sent to the display function. This doesn't seem very efficient to me, does anyone else know another way I could do this?
It returns milliseconds. If vx is equal to 1 and frameTime is equal to 7 and I do this: x = vx * frameTime,
Then that's way too fast. I think the only way to resolve this is to either turn those milliseconds into a fraction of a second (0.007 instead of 7), or make my movement speeds into smaller fractions. Either way, it's going to have to convert the floats into integers when it gets sent to the display function. This doesn't seem very efficient to me, does anyone else know another way I could do this?
Quote:I didn't read the whole thread so I don't know what kind of game you're making, but generally it's easier to perform game calculations (physics, collision detection, AI, movement, and so forth) in floating point. You may have to convert the integer milliseconds value returned by SDL to a floating-point 'seconds' value and/or float position values to integers for drawing via SDL, but a few such conversions are not going to hurt your performance.
Original post by Grantyt3
Okay, I'm using that, but I have a little question.
It returns milliseconds. If vx is equal to 1 and frameTime is equal to 7 and I do this: x = vx * frameTime,
Then that's way too fast. I think the only way to resolve this is to either turn those milliseconds into a fraction of a second (0.007 instead of 7), or make my movement speeds into smaller fractions. Either way, it's going to have to convert the floats into integers when it gets sent to the display function. This doesn't seem very efficient to me, does anyone else know another way I could do this?
If your using .NET, C# and VB.NET (well any .NET language anyhow) has a property
called Environment.Tickcount which is the number of milliseconds since the computer
started so in order to get the time you would probably do something like this:
called Environment.Tickcount which is the number of milliseconds since the computer
started so in order to get the time you would probably do something like this:
Public Class CSomeGame{private float m_seconds;CSomeGame(){m_seconds = 0.0f;GameLoop;}void GameLoop(){int frameTimeBegin = Environment.TickCount;Input();Render();int frameTimeEnd = Environment.TickCount;// Since there are 1000 milliseconds in a second we// divide by 1000 to get the number of seconds passed.m_seconds = (frameTimeEnd - frameTimeBegin) / 1000.0f;}}Quote:
Original post by JBourrie
Standard C++ cross-platform way to do it
That's awesome. Until you realize that the resolution of that is absolute shite... ;-)
Look, it's easy... You just need to convert thing to the right scale/magnitude/whatever...
Let say you're making a car game. The player's car is moving foward at 120km/h (or whatever the system you use), and for simplicity let say a frame took 10ms to render.
So the question now, how much do you have to translate the car foward for it to look like he's going 120km/h
Car speed: 120km/h
Frame time: 10ms
Let's convert the car speed into m/ms (meter per Ms)
120Km/h / 60 / 60 / 1000 (60 min in a hour, 60 second per minute, 1000ms per second)
This is: 3.33333e-5 Km/ms
Now, 3.333e-5 * 1000 * 1000 (there's 1000meters in a KM, 1000CM in a meters)
So final answer:33.333cm/ms
So, its not a matter of converting to float or in or ms or .... Its simply a matter of doing the right thing ;)
Best luck,
Jonathan
Let say you're making a car game. The player's car is moving foward at 120km/h (or whatever the system you use), and for simplicity let say a frame took 10ms to render.
So the question now, how much do you have to translate the car foward for it to look like he's going 120km/h
Car speed: 120km/h
Frame time: 10ms
Let's convert the car speed into m/ms (meter per Ms)
120Km/h / 60 / 60 / 1000 (60 min in a hour, 60 second per minute, 1000ms per second)
This is: 3.33333e-5 Km/ms
Now, 3.333e-5 * 1000 * 1000 (there's 1000meters in a KM, 1000CM in a meters)
So final answer:33.333cm/ms
So, its not a matter of converting to float or in or ms or .... Its simply a matter of doing the right thing ;)
Best luck,
Jonathan
Thats pretty cool Johnathan if you want to be able to define what speed you
want the player to move using a standard system that John Doe uses (like inches, milimeters, feet, yards, etc..)
however the given methods above define how fast you want the player to move in
pixels or units for 3D applications.
I'll be sure to save that though I might find some use for it sooner or later.
want the player to move using a standard system that John Doe uses (like inches, milimeters, feet, yards, etc..)
however the given methods above define how fast you want the player to move in
pixels or units for 3D applications.
I'll be sure to save that though I might find some use for it sooner or later.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement