🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Player input: buffered or imediate?

Started by
6 comments, last by Tire 24 years, 7 months ago
I would use immediate input. Just poll your input devices every frame and have your game code react accordingly. It's much simpler this way.
Advertisement
Both methods are important. Many (including my) games make use of both types, in some way.
The real question you have to ask yourself it, am I interested in the button BEING down or the button GOING DOWN (but not mattering whether it went back up yet).
Somethings, like entering a player name, is more suited to buffered input because you don't really care whether the button is down or up right now (ignoring holding down a key to repeat it). All you care is whether it was pressed. With immediate input, even with 60 fps, will miss some keystrokes when a moderate speed typist types some text in. Also, buffered input is important when the order of events is important. If you game sees, with immediate input, an 'A' and a 'K' currently down, which does it use first?

Anyway, just providing a different opinion than above.

- Splat

I was having this same problem(i still am) ,and have decided to go with buffered input. The reason being is because in my game i check for multiple key presses like LEFT && UP for diagnols on movment. Well its almost impossible to do in immediate with out delays ect. Reason being it will see well ok we have left up wait he let up it was left down last.

So its almost impossible to stay at a diagnol. Now with buffered input i dont get this problem or atleast not with the sdk samples i have tryed it on. Since i have yet to get buffered input working.

Well, this is interesting

I am using DirectX7 and Direct Input in immediate mode for my keyboard. I am doing a first person shooter demo/experimentation and am checking the keyboard before each frame gets rendered. My problem lies in the fullscreen mode where the inputs lag before and after I press keys. In windowed mode there is no problem but when I switch to fullscreen and press a key nothing happens for half-second then while holding down the key I move forward then I let go of the key and am still moving forward then after a second or two I stop. I am using D3DX util. library and was wondering if anyone out there had similar experience with this. I don't understand why there is a difference between windowed and fullscreen using the same code base. I appreciate any input. Thank you in advance.

JD, after you render each frame [or before], enter in:

SleepEx(1, TRUE);

Your problem is caused by video drivers that cheat on benchmarks. This solves that problem...

Thank you Zer for your input. I have tried to use Sleep() and SleepEx() in fullscreen mode, and the funny thing is that if I slow down my code by the length of time it takes to render it, it works. I do this:

hr = pDIKeyboard->GetDeviceState(256, keys);
SleepEx(15);

I don't have to slow down the code in windowed mode. Actually a value higher than 15 also works, but if it's 14ms then I have the same problem. So, in a nutshell I read keyboard state, then slow down code for 15ms then check for keys pressed if any, then I start timer by timeGetTime(), then I call my render function and after that I retrieve time using timeGetTime again to see how long the rendering took and calculate frames per second. I don't see why I must be slowing down the code after I retrieve input values.
All this code is located in the message loop and is executed when there are no messages in the window queue. Any ideas?

I have Direct Input all set up and working fine and I am able to read input from the mouse and keyboard but I am having trouble deciding the best way to process it. In the game loop, should I buffer the players input then process it or should I process it imediatly? If the player pushes 'up' should I process it then and there or should I put it in a que and process the que in a player input section? How do I decide how many events go in the que? What if the player doesn't imput anything? How does the player entering multiple commands affect all this? (ie. jump while running forward and firing)
Sorry for all the questions but none of my game books fully address this.
Tidbit on my progress,

I am using win98, cyrix 233Mhz, vc++ 6.0std. and DX7 and DX7 Direct input interfaces. I program on 3DLabs, Permedia2 chip, video card is called Graphic Blaster Exxtreeme from Creative Labs with latest bios. I am using the keyboard for input(immediate, foreground and exclusive modes) in full screen set up by D3DX util lib functions. The problem is still there. For an experiment I tried lenghtening my code by another 30ms by redrawing it 3 times (each redraw is 15ms) for a total of 45ms. I used Sleep(15) between begin and end scene. This time the 15ms didn't help, instead I had to change it to 45ms. So it would seem that I have to increment the time delay by the same amount as time it takes to render the scene. So if rendering takes 500ms the time delay will be 500ms also. You can imagine the fps I will be getting then in fullscreen, and if this is so then I don't have a choice and will run my game windowed instead of fullscreen. Curiously I can delete Sleep(45) and recompile, then run in windowed mode(still using immediate, exclusive, foreground modes) with no problems, except this time rendering is slower since I am redrawing same objects 3 times. Am I the only one who has this problem? Do you think it's my video card or its drivers? Anyone? Thank you and take care.

This topic is closed to new replies.

Advertisement