Hello all, my game engine has the ability to render it''s own windows, it doesnt use any of the win32 windowing api, so i obviously had to write some code to handle textual input to text boxes and such. well the way i finaly decided on was cathing the WM_CHAR event, and going from there... unfortunetly this is brutaly slow, probably because between each wm char message a frame gets drawn, since my wnd proc is set up as such, loop until end { proccess message drawframe } this means that even when there is a message my frame draws, unlike some other non blocking loops ive seen that only draw a frame when there is no message enqued. so i guess my question is should i use the *dont draw unless no messages* or is there another way to get faster more real-time keyboard input. any info is apreciated ;-) thanks Raymond Jacobs, Profesional Web Applications Developer, Weekend Game Developer, www.EtherealDarkness.com

This may sound obvious, but have you lokked at DirectInput?
It's much simpler to initialise than D3D (so don't be put off!) and provides very easy access to the keyboard and mouse devices.

[edited by - carrot on August 13, 2002 9:53:54 AM]

Yes i have considerd Direct Input,

but my engine is API indipendant, all api specifics are performed trough adaptor extensions *for graphics sound and net*

thus putting Direct input into the engine would be wrong,

the correct place to put it would be in an adaptor, but i dont belive that input should have it''s own HW adaption,

so in this case i plan on using the base service of windows for input,

well maybe look at GetASyncKey documentation - might help.

I was thinking more along the line of,

SetGlobalHookEx

to hook the keyboard for exclusive access..,

im just wondering if that will cause any unseen problems with the rest of the OS

btw, using get asynckeystate, would work, but that would still cause the poll-per-frame problem wherein i could only get one character per frame i need to have somthing that runs on a different thread, and simply calls a proc in the app indiferent to the execution state of the app...

i think SetGlobalHookEx is my best bet, either that or have my frame draw become conditional uppon the message que

[edited by - EDI on August 14, 2002 8:50:53 AM]

>>Yes i have considerd Direct Input, but my engine is API indipendant, all api specifics are performed trough adaptor extensions *for graphics sound and net* thus putting Direct input into the engine would be wrong, the correct place to put it would be in an adaptor, but i dont belive that input should have it''s own HW adaption,<<

Just to play devils advocate, isn''t it already API specific by using Win32 methods? Are are you setting up a windows-only deal that''s agnostic to add-on API''s? If not, what''s the difference between being tied to the Win32 API vs. the DX API?

In any event, I''m curious about this as well. There was some talk, and I asked some questions in another thread on here yesterday( "Keyboard Input"...or something like that), and it sounded like the general concensus for keyboard input was to use WM_CHAR. But the problems you''re running into make me think even moreso that not going that route may be the better call.

-John

ok, let me xplain ;-)

first off i solved the problem as i posted above,

>>>Just to play devils advocate, isn''t it already API specific by using Win32 methods? Are are you setting up a windows-only deal that''s agnostic to add-on API''s? If not, what''s the difference between being tied to the Win32 API vs. the DX API?<<<

i dont have ANY aspirations for my engine to ever leave the windows platform, thus i dont really consider WINAPI to be a constricting API...

but since the engine is meant to be able to adapt to different HW based libraries, that is why any very specific api, such as GDI,DirectX,OpenGL,etc... will never be in the engine library itself they will remain as external ''throw away'' adaptor moduels

so i guess to say it is API indipendant is false,
to be more specific, it is GRAPHICS,SOUND and Networking Indipendant

hope that clears it up.

WM_CHAR works perfectly, as long as you let the message pump proccess messages with precidence over drawing your frame.

my game now is exceptionaly responsive and the problem is cleared up, using DirectInput is definetly overkill since there wont be many changes to INPUT api except for maybe the addition of new types of devices.

dont know all the aspects of DInput, but im sure it doesnt bring too much more to the table than what windows gives you

Raymond Jacobs,
Profesional Web Applications Developer,
Weekend Game Developer,
www.EtherealDarkness.com