In my current FPS game, I have the mouse setup in a way, that it always forces the position of the mouse to be centered at the screen. This gets the job done, but also gets very annoying, since the mouse is "fixed" at the center of the screen.

Here is what I am doing:

  • get mouse current position
  • find offset from center of the screen
  • set mouse current position to center of the screen
  • apply difference to m_pTransformation (transformation matrix of the player)

Is there a better way to deal with this ?

  • 1
    \$\begingroup\$ Can you expand on why it's "annoying"? That's a pretty standard solution. \$\endgroup\$ – wkerslake Feb 5 '11 at 1:28
  • \$\begingroup\$ For one: I've always been doing first-person view like this. I wanted to learn if there is a better way out there. Also, When I alt-tab out of the game, it still tries to center the mouse. I'll somehow need to flag it when the game goes out of scope. \$\endgroup\$ – brainydexter Feb 5 '11 at 2:50
  • \$\begingroup\$ Also see gamedev.stackexchange.com/questions/7812/… \$\endgroup\$ – Ricket Feb 8 '11 at 16:32

That's a pretty standard solution. Try hiding the mouse cursor and superimposing a fixed targeting reticule (if your game needs one) if it's a distraction

  • 1
    \$\begingroup\$ I already have a cross-hair in place hiding the mouse. \$\endgroup\$ – brainydexter Feb 4 '11 at 23:50

Also make sure to unlock the mouse if the user alt-tabs out of the game and your game somehow still controls the cursor. Don't forget to test for that!

Otherwise I agree that yours is the standard solution. The alternative is to capture raw mouse input; MSDN documentation is here. This Stack Overflow question might help you starting to implement it in Mac and Linux.

I can't help but recommend against raw input though. I think you would need to test for anomalies and somehow handle all the different types of mice (different DPI, USB vs PS/2, etc.) and have a robust in-game system for sensitivity since raw input bypasses the operating system's mouse settings (acceleration, sensitivity, etc.).

It seems to me your method is just fine. It's simple (at least, much more simple than raw input) and you haven't indicated that it is broken in any way, so why are you trying to fix it? This almost seems a case of premature optimization. :)

  • 1
    \$\begingroup\$ I just have been doing things like this for a long time and always wondered if there's a different/better way to deal with this. I gather from all the answers/comments, what I'm doing is good. Thanks for the reply. \$\endgroup\$ – brainydexter Feb 8 '11 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.