DirectInput Buffered Mode

Started by
1 comment, last by brekehan 21 years, 7 months ago
I was fooling around with a buffered Direct Input tutorial I found in the book "Multiplayer Game Programming" by Todd Baron. It worked fine in his code as is, however when I implemented it in my program I got invalid page faults. I tryed all night to debug it, but the problem is that it locks the system up as its one of those repeating errors that if you hit close another pops up. I deduced that it was in the code that loops through the buffer and happens in something called "DHELP" whatever that is. I give up on it and am trying to get another routine going to handle my input. On this site I see tutorials on Dinput in non buffered mode, but none in buffered mode, and in the msdn there is only one sample source that uses dialog boxes which is hard for me to learn from. Anyone know where I can get a good c style tutorial on using Dinput in buffered mode or perhaps a small explanation here of what I need to add vs non-buffered mode? I am concerned that if I do not buffer my input then keystrokes will be lost if the program happens to bog down. And that would produce undesirable effects if the user was for example typing a text message to another player. Of course I might be making this assumption falsely in which case please tell me so. Thanx, Christopher
Advertisement
I have further researched the bug I was talking about. After reading tons of msdn information I have created a theory. In my program I readfromkeyboard() in the main loop, of course this loop cycles at all times until the program terminates. Now when I get a keystroke [DIK_ENTER] I attempted to change from fullscreen to windowed mode in OpenGL. I suspect the problem is neither in the OpenGL code or the direct input code but rather is something with the "cooperative level" of the keyboard and it being "aquired" or "unaquired" in the transition between screen modes. If the program cannot read from the keyboard perhaps this is what causes my invalid page fault, and since it is being called currently 100s of times a second that would explain the repeating nature of the error. Now that I have this theory I really have no idea what to do about it
Noone seems to explain these cooperative levels in great detail and how to handle transitions like this. Of course my theory could be incorrect, oh the agony of debugging...

Do I need to unaquire the keyboard when the program is not in the foreground? (msdn says DInput does it for me?

Should I check if the keyboard is aquired every read and if so how can I do that?

Or perhaps should I defy nature and just make it so my program is always in the foreground at a set screen size until termination so I don''t have to deal with it at all?

I wish Todd went more into things like this in his book, but I can''t blame him as the focus was DirectPlay. Everyone takes the
details of Direct Input for granted it seems as it looks so simple until you run into something like this.

This really throws a big wrench in my plans

Thanx,
Christopher


The return value from KeyboardDevice->GetDeviceData() tells you whether you have the focus or not. If it''s DIERR_NOTACQUIRED or DIERR_INPUTLOST, you need to re-acquire the device.

Domenic, Underdoghttp://www.unitedunderdogs.com

This topic is closed to new replies.

Advertisement