• 12
• 12
• 9
• 10
• 13

# Acceleration Issue (WM_TIMER and/or pixel skip count)

This topic is 4235 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi All: I'm an experienced C/CPP Programmer working on a simple game. This is my fourth attempt on a simple game. I have done Scrabble with Visual Basic, Solitaire with Java and following on through the suggestions posted on this site, I am now working on Breakout after developing a quick clone to Tetris. Since I am not that experienced in Game Programming, I decided to post in beginners. I have implemented a very simple test to have a go at gravity and acceleration. My aim is to have a 4 pixel rectangle accelerate vertically down a black window from top. I am doing this by implementing a timed event so if the time expires, then that means it's time for the box to move down. My viewpoint tells me that we can increase speed by either increasing the frequency for the event or by increasing the number of pixels the box goes down every time the event triggers. I can only move down a limited number of pixels every time the event triggers. The reason is because the box would otherwise appear to be jumping from one location to another rather than moving down. I also have a limited period on how frequent the timed event triggers. Ideally, I would prefer to move the box down by a constant number of pixels everytime the event triggers. Alas, when WM_TIMER is 0, the box still is going down the window at a slow speed. Maybe it's just an illusion of having a small box and/or a big space. I really would like the box to move down one pixel at a time in order for my game to look smooth and fast. Trying it with 3 pixel steps also does not look bad however it's still not moving as fast as I would wish. My next attempt will be to decrease the size of the window to see how that will affect the illusion of speed. But other than that, I have no other plan. Can anyone give a lending hand on ideas please?

##### Share on other sites
Using WM_TIMER messages is not really accurate, especially with small intervals. For actions of type "notify me in 3 seconds" it's good, but of type "notify me in 2 milliseconds" it sucks. The message is send from the Windows, placed on the queue and dispatched to the window procedure. All this kill accuracy.

Also, trying to define how many pixels an object will move doesn't really work. Say your game is running in a computer that is able to achieve 40FPS(frames per second). If the box is moving one pixel at a time, the maximum speed it can achieve is 40 pixels per second. In a more powerful computer that runs at 80FPS, you got 80 pixels per second and so on.

In games we usually use time-based movement which makes the motion as smooth and as physically-correct we want to, and also indepedent of the system the game is played on. This is nothing more that implementing physic formulas on games. We give each object attributes like velocity and position. In your case, we would work with 2D vectors. For example, we have an Update(dt) functions that updates an object based on a given interval. We use timeGetTime(or other functions like QueryPerformanceCounter) to get the amount of milliseconds that have passed since the last update:

struct Vec2D{  float x,y;  Vec2D(float x,float y):x(x),y(y){}};struct Box{  Vec2D pos;  Vec2D vel;};void Update(Box &box,float dt){   box.vel.y=box.vel.y-1.0*dt;//increase velocity down the -y axis(gravity)   //Move box according to its velocity   box.pos.x=box.pos.x+box.vel.x*dt;   box.pos.y=box.pos.y+box.vel.y*dt;}//main loopBox box;box.pos=Vec2D(0,0);box.vel=Vec2D(0,0);last_time=timeGetTime();while (bGameRunning){  cur_time=timeGetTime();  float dt=(cur_time-last_time)/1000.0;  last_time=cur_time;  Update(box,dt);  DrawBox();}

The formulas here could be more accurate, but you get the idea.

##### Share on other sites
Hi mikeman:

That has been really helpful. I'll be on my way to implement something similar and will let you know of any results ;)

I know about the physics formulae so it'd be quite easy to implement I presume.

I still have to study about determining the points in a line (practically the slope) in order to determine the next position of the ball. I also have to work out which direction the ball takes as it bumps. I presume that will be sin/cos/tan but first I'll get this acceleration working.

Thanks and Regards

Duncan