unit movement/speed calculation?
some of the tutorials that try to explain using timers to lock game unit speeds propose this:
player.x += player.x_units_per_second * frame_time.
x is the new pixel location after a frame update, frame_time is the time transpired between start of frame and end of frame, and will be extremely tiny for simple scenes and on fast cpus.
This leads to my question:
how the heck do I render a 0.00245 pixel increase along the x-y axis? Do I prevent my player-render function from executing until a certain amount of time has passed, say 0.2 seconds...? I''m stumped. Hope I explained things clear enough..
thanks,
muffin
cheers,muffin
June 11, 2000 01:24 AM
You don''t. You internally calculate your sub-pixel coordinates,
and when you are ready to blt it to the screen, you cast them to integers.
and when you are ready to blt it to the screen, you cast them to integers.
You could also do it like this:
Instead of drawing a theoretically infinite amount of frames per second (like quake games) just have a definite maximum of 30 frames per second. Then you know what speed the unit will move at "normal" speed.
(anything over 30 frames can''t be detected by the human eye I thought i heard somewhere)
To get a frames per second value just check how much time was
"left over" at each draw and add it all together to see how many frames *could have* been drawn.
For me anyway, in my 2D world, this is much easier. (i know that it is probably totally wrong though)
wise_guy
Instead of drawing a theoretically infinite amount of frames per second (like quake games) just have a definite maximum of 30 frames per second. Then you know what speed the unit will move at "normal" speed.
(anything over 30 frames can''t be detected by the human eye I thought i heard somewhere)
To get a frames per second value just check how much time was
"left over" at each draw and add it all together to see how many frames *could have* been drawn.
For me anyway, in my 2D world, this is much easier. (i know that it is probably totally wrong though)
wise_guy
see, here is the perfect example of a need for fixed point integers, (as mentioned by anonymous...)
here is one way to do this....
so you store the map coords as a point * MAP_POINT_ACCURACY, this way you can adjust coords less than 1 scrn pixel.
when you want to do a screen draw, simply use the GetScrnPoint() function to get the "real pixel" location of the sprite/object.
hope this helps...
http://www.ill-lusion.com
here is one way to do this....
// setup a global define to store the accuracy of our numbers...#define MAP_POINT_ACCURACY 1000LONG GetScrnPoint(LONG virtual_pnt){ return (virtual_pnt / MAP_POINT_ACCURACY);}LONG GetMapPoint(LONG scrn_pnt){ return (scrn_pnt * MAP_POINT_ACCURACY);}
so you store the map coords as a point * MAP_POINT_ACCURACY, this way you can adjust coords less than 1 scrn pixel.
when you want to do a screen draw, simply use the GetScrnPoint() function to get the "real pixel" location of the sprite/object.
hope this helps...
http://www.ill-lusion.com
laxdigital.com
[email=ziggy@laxdigital.com]ziggy@laxdigital.com[/email]
[email=ziggy@laxdigital.com]ziggy@laxdigital.com[/email]
thanks a bunch all! Now I just have to retool all my ints to floats...
cheers,
muffin
cheers,
muffin
cheers,muffin
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement