Controlling by velocity and acceleration instead of direct coordinates.
This question is concerning my 2D engine.
I have created a sprite class that has members for X,Y,and Z for position, velocity, and acceleration.
This has proved very useful for me in creating my games, and I have found that I rarely work with the x,y,and z positions. This works well with games where exact precision isn''t required. However, I have found one problem in a game I''m making.
I am working on a top down game about a frog. In the game, you can walk and jump, and if you press a button down, the frog stands still, and a small red circle appears marking your "landing target". I have some basic math functions to convert the desired distance to required initial velocity to make the frog jump to the cursor, and for the most part it is accurate. The problem lies in the inconsistency of the framerate of the game.
Let''s say that my jump will last 1 second, and I am running at a framerate of 100. This means the position of the frog will be updated every 10 milliseconds and a check will be made to see if the frog''s jump is over or not. The problem is every once in a while, I will get little freezes in my game which may last for half a second or so. If the freeze occurs at 999 milliseconds after the jump, the frog may stay jumping for nearly an extra .5 seconds, since a check won''t be made until that next frame, which will come that delayed. This means the frog may land a good distance away from the intended target, since my function is position += velocity*frameTime.
Also, there are some movements that don''t have constant velocities. To accentuate the change in speed when a frog jumps (a frog moves faster in the air then when he has landed and is preparing for another jump), I don''t have constant velocities. I have a jump force, which is depending on how far the player pushes the analog stick, which is multiplied by constants depending on the frame of animation. When the frog is stretching his legs, as if pushing off of the ground, he moves faster and faster, until reaching the point where he is actually in the air and is at his top velocity. Then when landing, the frog slows down again.
The problem again is that the change in velocity needs to occur at certain times after the jump has been initiated, but these times are thrown off by the inconsistency of the framerate on the computer. My frame rate may fluctuate at any given moment (I don''t know if my computer is weird).
So my question is what have you that have worked with velocity done to make sure that things occur accurately even though you work with inaccurate framerates. How can I be sure that my frog will land square on the lilypad, instead of in the lake?
--Vic--
If I have confused you, this problem may help solve it. Think of a ball that is thrown in an arc. If we were to graph the position, we would get a nice clean arc, and with constant velociy and constant gravity, the ball would land in the same place. But this doesn''t happen if you write a program that every frame changes the velocity according to the acceleration, and the position according to the acceleration.
Let me see if I''m getting this straight. Let''s say I have an object that moves 1 foot a second.
My old method would be to see how many milliseconds we have since the last frame, and then times that by the velocity (divided by 1000 if the velocity is in feet/second).
The method of the link you posted suggests setting a constant "physics framerate" where you simply conduct the movement, collision, etc, for every given amount of time passed. If the physics framerate is less thatn your actual framerate in the game, then you will not conduct movement and so on every frame. If you would like way accurate movement, then you lower the physics frame time, which increases the number of tests done per second. Ahh, I think I''m getting it now. So if your screen is drawn every 100 milliseconds, and your physics frame time is 10, then you will call the move function 10 times every frame .. . . genius
Thanks for the excellent link. I guess I''ll have to rewrite my movement function.
--Vic--
My old method would be to see how many milliseconds we have since the last frame, and then times that by the velocity (divided by 1000 if the velocity is in feet/second).
The method of the link you posted suggests setting a constant "physics framerate" where you simply conduct the movement, collision, etc, for every given amount of time passed. If the physics framerate is less thatn your actual framerate in the game, then you will not conduct movement and so on every frame. If you would like way accurate movement, then you lower the physics frame time, which increases the number of tests done per second. Ahh, I think I''m getting it now. So if your screen is drawn every 100 milliseconds, and your physics frame time is 10, then you will call the move function 10 times every frame .. . . genius
Thanks for the excellent link. I guess I''ll have to rewrite my movement function.
--Vic--
Is the player able to redirect the frog once it jumps?
You mentioned the "target" thingy...so I''m assumeing that the frog is just suppost to jump there directly.
What you could do is calculate a arc that the frog is to travel sense you have a starting and ending location (from the "target")...something like a Benzir curve purhapse...then you only need to set a interpolation factor (basied on how much time has passed) and calculate the location each frame...and the frog will always land exactly where you want it to.
You mentioned the "target" thingy...so I''m assumeing that the frog is just suppost to jump there directly.
What you could do is calculate a arc that the frog is to travel sense you have a starting and ending location (from the "target")...something like a Benzir curve purhapse...then you only need to set a interpolation factor (basied on how much time has passed) and calculate the location each frame...and the frog will always land exactly where you want it to.
If a player accidentally presses the jump button, and the frog goes into "target mode" the player can get out, but once the frog is in the air, it is like real physics. He is dedicated to that path.
It would be a pain in the butt to make functions and keep track of where things should go and so on in more complex games with objects that have curved movements. This solution is much better in that it is simple to implement, and will work with not only movement, but also collision.
--Vic--
It would be a pain in the butt to make functions and keep track of where things should go and so on in more complex games with objects that have curved movements. This solution is much better in that it is simple to implement, and will work with not only movement, but also collision.
--Vic--
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement