Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

caution of the day

Sign in to follow this  


I didn't really get alot done, as far as lines of code. I actually have less code now. Last time I was working on my project, I was trying to get mouse input to affect the paddle movement. I was writing my first DirectInput mouse reading function, I expected it to be like Win32, giving the screen coords in the data. So I wrote some code to remember the last mouse position, blah blah it never worked. Then I was pondering my switch statements cases, (oh, I basicly took the function from the DX SDK chm, but made it work for me, not copy-paste, look-n-type) and I tried to decypher the meaning of DIMOFS_X. Pretty simple, Direct Input OFfSet - X. So yeah, as many of you may already know, it only gives the offset of movement on that axis. So yeah, it worked better after that.

Which brings me to the thing I like better, the way I had to handle the data. It really was pretty simple to work it into my current function. You pass 2 args to the MovePaddle function, both arguments are float types. The first argument is used to determine direction and velocity of the paddle. If the sign of the value is negitave, then the direction is [-1,0,0], positave would give a direction of [1,0,0], and zero is no movement. Then we can examine the value, and assign it to our velocity (reversing the sign if it is negitave). The second function is the frametime, for collision detection. So, to the point I guess. When you sample this data from DX, it is going to give you a higher result if your frame time is higher. The mouse may have moved the same distance on your table, but the application is sampling slower at 80 fps compared to 1000 fps. In one frame, the mouse may only move +2 at 1000 fps, but may give you a value of 34 at 80 fps. This does not make things easy when you use a mouse_speed factor, to scale the movement. Well, I should say it does not make things easy at first. My problem really came from the way I thought it was going to work. I remember so many games that have had a mouse_speed setting in the configuration, so I figured it would be good to use. My formula was something like: tmp=mouse_speed*dimouse.data, and pass tmp to the MovePaddle function, that is what made it get crazy speed at slow frame rates. So, you are still reading, either you want to see how I did it because you have never delt with it, or you just want to see my silly implimentation. I had to change my mouse_speed from the 5.0 value, way down to 0.005. Also I figured using the frametime as a divider would work. So here you go.

float tmp = Game_MouseSpeed * (signed int)od.dwData / m_fFrameTime;
m_OManager->MovePaddle( tmp , m_fFrameTime);

And there you have it! I call it Mozie's Time Independent Mouse Movement Procedure. [grin] I guess its only good if you have a dependent function like my MovePaddle, I could just apply the division with.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!