Archived

This topic is now archived and is closed to further replies.

EDI

Textual Input

Recommended Posts

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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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,

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
>>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

Share this post


Link to post
Share on other sites
quote:
Original post by EDI
loop until end
{
proccess message
drawframe
}



I had a problem like this... turns out it was because I was trying to lock my game to 30 fps with a sleep timer (doh!)... Windows happily buffered my WM_CHAR messages for me, and my characters crawled onto the screen really slowly.

I don''t know if that''s what you''re doing, but if you are, don''t. ( ; It worked well for me, now my game is really responsive... I had to modify everything else to be aware of the time that has elapsed since the last frame was drawn, but it was worth it.

Using DirectInput, in my case, would have been overkill... I''m only using the keyboard and mouse, and it was really the update algorithm that was the problem anyway, not the input method.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
quote:
Original post by EDI
dont know all the aspects of DInput, but im sure it doesnt bring too much more to the table than what windows gives you


Buffered input, you don''t have to rely on the windows message loop, support for other stuff besides keyboard and mouse, plus the keyboard and mouse support my be a little more responsive (I''m not sure about this though.) You might as well make a separate input module, even if you don''t plan to change it. You could use it to support different devices, different versions of dinput, dinput or Win32 commands, etc. WM_CHAR is probably the best way to do things for written input though (at least if you expect your game to be played on different localized OSes.)

Share this post


Link to post
Share on other sites