Jump to content

  • Log In with Google      Sign In   
  • Create Account


Handling Different Inputs


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
12 replies to this topic

#1 SuperOmegaCow   Members   -  Reputation: 107

Like
0Likes
Like

Posted 23 December 2013 - 05:47 PM

What is the best way to handle the mouse for an FPS game. That includes speed and the ability to read high DPI. Also how would I handle a keyboard, I assume that performance is not as big of a deal with the keyboard. BTW I am a new to game programming and would have no idea what you mean if you post code and don't explain it, thanks.



Sponsor:

#2 exOfde   Members   -  Reputation: 807

Like
1Likes
Like

Posted 23 December 2013 - 06:17 PM

Question: Are you new to Programming in general or really just to Game Programming?

 

If first true you should do this:

  • Choose a programming language of your choice
    • Learn your language
    • learn and exercise basic programming skills
      • algorythm
      • data structs
      • etc...
    • develop small minimalistic programms on your own to recive experience.
    • dependet how quick and which language you learn start think about gameprogramming 3-9 month later again

Otherwise:

 

  • Choose a programming language of your choice
  • Choose an Framework/library which fits to your project in mind best
    • SDL "very low level"
    • SFML
    • Allegro
    • Unity
    • etc. ...
    • Learn your choosen framework to use
  • develop small minimalistic programms on your own to recive experience

 

 

 


That includes speed and the ability to read high DPI.

Since when, perhaps i was all time wrong, you need to know the DPI,the only thing to know with a mouse is the deltaX and deltaY components( Framework/OS provides this information of course ). The rest makes the mouse for you and you don't have to care about it anymore


Edited by exOfde, 23 December 2013 - 06:22 PM.


#3 SuperOmegaCow   Members   -  Reputation: 107

Like
0Likes
Like

Posted 23 December 2013 - 06:26 PM

Question: Are you new to Programming in general or really just to Game Programming?

 

If first true you should do this:

  • Choose a programming language of your choice
    • Learn your language
    • learn and exercise basic programming skills
      • algorythm
      • data structs
      • etc...
    • develop small minimalistic programms on your own to recive experience.
    • dependet how quick and which language you learn start think about gameprogramming 3-9 month later again

Otherwise:

 

  • Choose a programming language of your choice
  • Choose an Framework/library which fits to your project in mind best
    • SDL "very low level"
    • SFML
    • Allegro
    • Unity
    • etc. ...
    • Learn your choosen framework to use
  • develop small minimalistic programms on your own to recive experience

 

 

 


That includes speed and the ability to read high DPI.

Since when, perhaps i was all time wrong, you need to know the DPI,the only thing to know with a mouse is the deltaX and deltaY components( Framework/OS provides this information of course ). The rest makes the mouse for you and you don't have to care about it anymore

 

 

Well no I have already made framework for rendering etc... I just don't know how to get inputs.



#4 exOfde   Members   -  Reputation: 807

Like
0Likes
Like

Posted 23 December 2013 - 06:35 PM

Okay. They are two ways:

and last but not least learn your API's. read them. do experiments with them, collect experience.


Edited by exOfde, 23 December 2013 - 06:36 PM.


#5 SuperOmegaCow   Members   -  Reputation: 107

Like
0Likes
Like

Posted 23 December 2013 - 06:38 PM

Okay. They are two ways:

and last but not least learn your API's. read them. do experiments with them, collect experience.

 

 

 

Question: Are you new to Programming in general or really just to Game Programming?

 

If first true you should do this:

  • Choose a programming language of your choice
    • Learn your language
    • learn and exercise basic programming skills
      • algorythm
      • data structs
      • etc...
    • develop small minimalistic programms on your own to recive experience.
    • dependet how quick and which language you learn start think about gameprogramming 3-9 month later again

Otherwise:

 

  • Choose a programming language of your choice
  • Choose an Framework/library which fits to your project in mind best
    • SDL "very low level"
    • SFML
    • Allegro
    • Unity
    • etc. ...
    • Learn your choosen framework to use
  • develop small minimalistic programms on your own to recive experience

 

 

 


That includes speed and the ability to read high DPI.

Since when, perhaps i was all time wrong, you need to know the DPI,the only thing to know with a mouse is the deltaX and deltaY components( Framework/OS provides this information of course ). The rest makes the mouse for you and you don't have to care about it anymore

 

 

Well no I have already made framework for rendering etc... I just don't know how to get inputs.

 

Well I have looked into DirectInput but Microsoft recommends WM_INPUT but don't know how to use it.



#6 exOfde   Members   -  Reputation: 807

Like
4Likes
Like

Posted 23 December 2013 - 06:43 PM

please don't qoute everything if don't use it.

Why don't you ask this question at the beginning?

 

But why you don't know how to use it? it's pretty well explained

in msdn: http://msdn.microsoft.com/en-us/library/windows/desktop/ee418998(v=vs.85).aspx

 

I would mention you should ask yourself what you don't understand and try then the problematic to explain first on your own. and after that process to forumlate your question with all information are needed.


Edited by exOfde, 23 December 2013 - 06:45 PM.


#7 SuperOmegaCow   Members   -  Reputation: 107

Like
0Likes
Like

Posted 23 December 2013 - 06:50 PM

please don't qoute everything if don't use it.

Why don't you ask this question at the beginning?

 

But why you don't know how to use it? it's pretty well explained

in msdn: http://msdn.microsoft.com/en-us/library/windows/desktop/ee418998(v=vs.85).aspx

 

I would mention you should ask yourself what you don't understand and try then the problematic to explain first on your own. and after that process to forumlate your question with all information are needed.

No it is transferring WM_INPUT to usable data.



#8 SeanMiddleditch   Members   -  Reputation: 3481

Like
2Likes
Like

Posted 23 December 2013 - 06:56 PM

Since when, perhaps i was all time wrong, you need to know the DPI,the only thing to know with a mouse is the deltaX and deltaY components( Framework/OS provides this information of course ). The rest makes the mouse for you and you don't have to care about it anymore


The API you use may perform undesired filtering or only send updates at a low frequency or in low-resolution coordinates. FPS games need to deal with mouse sensitivity options, response curves, and optionally also smoothing. Input handling in a high-quality FPS is not exactly trivial, though the basic stuff works to get up and running.

#9 exOfde   Members   -  Reputation: 807

Like
0Likes
Like

Posted 23 December 2013 - 06:56 PM

thanky you SeanMiddleditch and again learned something new biggrin.png

 

Perhaps you should a little bit scrolling and searching through msdn. because they explain it the how to use it:

 

 

Understanding DirectInput

This topic covers the underlying structure of Microsoft DirectInput and its relationship to the Microsoft Windows message system.

For practical information about how to implement the elements of DirectInput introduced here, see Using DirectInput.

DirectInput Objects

 

An input-only DirectInput implementation consists of the DirectInput object, which supportsIDirectInput8 Interface, a Component Object Model (COM) interface, and a DirectInputDevice object for each input device that provides data. Each DirectInputDevice object in turn has device objects, which are individual controls or switches, such as keys, buttons, or axes. Device objects are also called device object instances.

 

Each DirectInputDevice object represents one input device, such as a mouse, keyboard, or joystick. In the DirectInput API, the word joystick means any type of input device other than a mouse or keyboard. A piece of hardware that is really a combination of different types of input devices, such as a keyboard with a touchpad, can be represented by two or more DirectInputDevice objects. A force-feedback device is represented by a single joystick object that handles both input and output.

 

DirectInputDevice objects instantiate the IDirectInputDevice8 Interface. The application ascertains the number and type of device objects available by using theIDirectInputDevice8::EnumObjects method. Individual device objects are not encapsulated as code objects, but are described in DIDEVICEOBJECTINSTANCE structures.

All DirectInput interfaces are available in ANSI and Unicode versions. If "UNICODE" is defined during compilation, the Unicode versions are used.

Interaction with Windows

 

Because DirectInput works directly with the device drivers, it either suppresses or ignores Windows mouse and keyboard messages. It also ignores mouse and keyboard settings made by the user in Control Panel. It does, however, use the calibrations set for a joystick or other game controller.

DirectInput does not recognize keyboard character repeat settings. When using buffered data, DirectInput interprets each press and release as a single event with no repetition. When using immediate data, DirectInput is concerned only with the present physical state of the keys, not with keyboard events as interpreted by Windows.

DirectInput does not perform any character conversion or translation. For example, the SHIFT key is treated like any other key, not as a modifier of another keypress. Keys return the same identifiers regardless of the user's system language settings.

 

Under Windows 2000, acquiring the keyboard in exclusive mode prevents any applications that are subsequently launched from receiving keyboard data.

Because DirectInput works directly with the mouse driver, it bypasses the subsystem of Windows that interprets mouse data for windowed applications. Applications that rely on the Windows cursor for navigation should continue to use the standard Windows mouse messages and Microsoft Win32 functions.

 

When using the system mouse in exclusive mode, DirectInput suppresses mouse messages, and therefore Windows is unable to show the standard cursor.

DirectInput ignores Control Panel settings such as acceleration and swapped buttons. However, DirectInput recognizes settings in the driver itself. For example, if the user has a three-button mouse and uses the driver-utility software to make the middle button a double-click shortcut, DirectInput reports a click of the middle button as two clicks of the primary button. ---- http://msdn.microsoft.com/en-us/library/windows/desktop/ee418998(v=vs.85).aspx

 

 

 

 

By the way I wish all a Merry Christmas :D


Edited by exOfde, 23 December 2013 - 07:04 PM.


#10 SuperOmegaCow   Members   -  Reputation: 107

Like
1Likes
Like

Posted 23 December 2013 - 07:13 PM

Well with this code, the window instantly closes:

    case WM_INPUT:
    {
                     for (int i = 3000; i>0; i -= 10){
                         Beep(i, 100);
                     }
                     UINT dwSize = 40;
                     static BYTE lpb[40];

                     GetRawInputData((HRAWINPUT)lparam, RID_INPUT,
                         lpb, &dwSize, sizeof(RAWINPUTHEADER));

                     RAWINPUT* raw = (RAWINPUT*)lpb;

                     if (raw->header.dwType == RIM_TYPEMOUSE)
                     {
                         int xPosRelative = raw->data.mouse.lLastX;
                         int yPosRelative = raw->data.mouse.lLastY;
                         if (xPosRelative > 100 && yPosRelative > 100)
                         Beep(10, 1000);
                     }
                     break;
    }



#11 SeanMiddleditch   Members   -  Reputation: 3481

Like
0Likes
Like

Posted 23 December 2013 - 07:37 PM

Well with this code, the window instantly closes:


Attach your debugger, enable all exception types (MSVS silently ignores a number of errors by default unless you turn them on), then start debugging. Step through line by line if you need to.

#12 haegarr   Crossbones+   -  Reputation: 3645

Like
0Likes
Like

Posted 24 December 2013 - 04:18 AM


What is the best way to handle the mouse for an FPS game. That includes speed and the ability to read high DPI. Also how would I handle a keyboard, I assume that performance is not as big of a deal with the keyboard.

How do you define "the best way"? Here are some principal thoughts (with a "warning" close to the end):

 

From a player's point of view, an input system should be responsive, i.e. it should react without too noticeable delay. It should not be too sensible (especially meaning mouse movement to reaction translation). It should not miss input (especially meaning key / button pressing). And for flexibility it should be configurable.

 

From an implementation's point of view an input system should decouple raw input from logical input, making the other game sub-systems agnostic of what a keyboard and companions is. It has further to make sure that no unwanted look-ahead is done (i.e. input that belongs to the current state in game should be processed but not more).

 

From a developer's point of view an input system should be, well, simple. But above wishes disallow for simplicity.

 

For example, the player sees an enemy to come out behind a pillar. They presses the "fire" button. Well, the game loop is currently no longer in the input processing stage but the animation stage. It does not recognize the button down/up sequence and, because it works on key states directly, will never do this for those particular activation. The player's avatar doesn't shoot but gets shot down by the enemy. What a frustrating experience. (Hence: Performance counts even with keyboard input.)

 

IMHO the best solution for a fast paced game (like an FPS) is as follows: A thread is responsible for collecting raw input, and it does so (nearly) exclusively. It fetches input from the OS input loop and perhaps directly from drivers. It translates from OS specific values to more general ones and stores all relevant input into a queue. The game loop, running on another thread, uses this queue for its input processing w.r.t. the current time step. In fact the input is translated again, supported by some input configuration (where e.g. translation from mouse movement to angular velocity is defined) into logical input for steering actions and animations.

 

However, such a system is complicated. It is especially too complicated for beginners, because multi-threading is ever a beast even for more experienced programmers. So the first thing to do is to define the goals. Have you defined the goals yet?

 

Using the OS's input loop to read input from is a good thing, because it is a step towards not missing some input. Don't forget to use the delivered timestamp for comparison with the current time step of your game loop. Using an input configuration is another good thing, because it allows you an easy switching between different game states (introduction screen, menu screen, gameplay, …) and is the natural place to store translation parameters (e.g. speed scaling). It is further the place where user enabled input configuration has its effects, if such is perhaps implemented in a later step.


Edited by haegarr, 24 December 2013 - 04:19 AM.


#13 L. Spiro   Crossbones+   -  Reputation: 11862

Like
1Likes
Like

Posted 24 December 2013 - 08:04 AM

It is often recommended that you use raw mouse inputs via ::RegisterRawInputDevices() if you want high-definition mouse input.

There is too much to cover on general input structure, and this is something that arises often enough I am planning an interactive demo with source in the near future.

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS