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

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).

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

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.

but it was soo sooo slow (FPS goes under 100 /w no polygons rendered).
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.