Jump to content
• Advertisement

# RAW Input Integration to the engine, but how ?

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

If you intended to correct an error in the post then please contact us.

## Recommended Posts

Hi all,

First, I don't know whether this is the correct place to ask this question or not. If not, execuse me.

At first, I went through implementing DirectInput; but later I saw that it was not a good option.

After a long search for another alternative, I've found some materials tells us that raw input system was very useful. But needs to be implemented under windows message pump procedure.

Now let me come to the question: I'm get stuck in implementing a RAW input system for my renderer. Because of implementing this in windows message procedure (waiting WM_INPUT, getting some extra data etc.), it's so hard to write a specific class and integrate to my engine, I think. First, I tried getting message by GetMessage() then checking message content whether it is WM_INPUT or not. And performing the traditional stuff in every frame, but it was soo sooo slow (FPS goes under 100 /w no polygons rendered).

How can write a raw input system for my engine and how can I integrate it without dealing with WNDPROC? Is it possible to write a specific class for it?

thx. in advance.
-R

#### Share this post

##### Share on other sites
Advertisement
Because of implementing this in windows message procedure (waiting WM_INPUT, getting some extra data etc.), it's so hard to write a specific class and integrate to my engine, I think.
I don't see what problem you're going to fight here. You will have to pull out stuff from WndProc anyway aren't you? Maybe it's me but I don't see much of a connection from the input system to the rendering system... unless you elaborate a bit on your architecture, I cannot quite understand why this should be a problem.
Personally I just have different interfaces (abstract base classes in C++ jargon), WndProc forwards the input there after some fast mangling. The interface collects those calls and updates state once per tick. Have you tried that? What is the problem?

First, I tried getting message by GetMessage() then checking message content whether it is WM_INPUT or not. And performing the traditional stuff in every frame, but it was soo sooo slow (FPS goes under 100 /w no polygons rendered).
That's for sure. GetMessage blocks until a message is available and that means potentially never if memory serves. You should be using PeekMessage instead!

Is it possible to write a specific class for it?
Sure, but considering its stability and low-levelness, I'd just put it in my WndProc directly and live with it. A "class" is useful if you have multiple objects to deal with, or if you need flexibility using overriding. You can still put it in a class if you want but I don't see this buying you much (and have phun telling C code to call C++ funcs, especially when exceptions are involved).

#### Share this post

##### Share on other sites
Sorry for my bad explanation.

* My goal was doing raw input stuff (i.e. working under WM_INPUT case) in every frame (not in WndProc message procedure).
* First I thought that I could do it by using GetMessage() or PeekMessage (). I succeeded, but software became so slow.

After a lot of work on it, now I see that there's no way to do this stuff outside WndProc.

Thanks Krohm.

//--------------------

Now another question:
Is there a way to get at least one of SHIFT, CTRL and ALT keys pressed? For example, how can I check SHIFT + F3 pressed (with raw input system)?

thx.
-R

#### Share this post

##### Share on other sites
Maintain a bool for shiftDown or ctrlDown. Look for WM_INPUT for the VK_SHIFT or VK_CONTROL key. Set or reset the corresponding bool according to whether the key message indicates it's being set or reset.

When you get VK_F3 input, check the shiftDown and ctrlDown flags (bools).

Unless you really need it for some reason, you should avoid using ALT as that's involved with the Windows menu system.

#### Share this post

##### Share on other sites

Now another question:
Is there a way to get at least one of SHIFT, CTRL and ALT keys pressed? For example, how can I check SHIFT + F3 pressed (with raw input system)?

And if you want to differentiate between the left/right alt/ctrls etc:

 case WM_SYSKEYDOWN: { // handle left/right alt keys if (wParam == VK_MENU) { if (lParam&(1<<24)) wParam = VK_RMENU; else wParam = VK_LMENU; } // handle left/right control keys if (wParam == VK_CONTROL) { if (lParam&(1<<24)) wParam = VK_RCONTROL; else wParam = VK_LCONTROL; } // handle left/right shift keys if (wParam == VK_SHIFT) { if ((GetKeyState(VK_RSHIFT) & 0x8000) /*&& (KeyboardInput[KEY_RIGHTSHIFT] == FALSE)*/) { wParam = VK_RSHIFT; } else if ((GetKeyState(VK_LSHIFT) & 0x8000) /*&& (KeyboardInput[KEY_LEFTSHIFT] == FALSE)*/) { wParam = VK_LSHIFT; } }

#### Share this post

##### Share on other sites
To go with what Buckeye said, you are better off just having an array of bools to hold your input that is updated in the main WinProc loop with WM_KEYDOWN/WM_KEYUP instead of trying to deal with raw input outside of the loop. If you have to be OO about it just wrap the array in a class and give it a static function to access keys and you have keyboard access anywhere you need it.

#### Share this post

##### Share on other sites
but it was soo sooo slow (FPS goes under 100 /w no polygons rendered).[/quote]
This is sort of a side issue with respect to a method to get user input, but - "frames/second" doesn't have much meaning if you're not doing rendering. In general, for visual continuity and rendering, anything above 30 fps presented to the screen isn't necessary. You can perform other operations (collision detection, other calculations, etc.) as often as desired and those non-rendering activities need not be related to rendering.

In any case, if you have a general game loop such as...
 while( not done ) { get_input ( PeekMessage can be here ) update_objects if( time to present a frame ) render } 
...you don't have to worry about the "speed" of getting user input through the window procedure.

#### Share this post

##### Share on other sites

• Advertisement
• Advertisement

• ### Popular Contributors

1. 1
2. 2
Rutin
19
3. 3
4. 4
khawk
15
5. 5
• Advertisement

• 13
• 26
• 10
• 11
• 44
• ### Forum Statistics

• Total Topics
633743
• Total Posts
3013644
×

## 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!