Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Arcanor]

I'm using OIS and CEGUI in my Ogre project.  I'm using buffered input, and deriving from OIS::KeyListener.  I setup my keyboard as follows:

Code: [Select]

mKeyboard = static_cast<Keyboard*>(mOISInputManager->createInputObject(OISKeyboard, true));

I have a CEGUI Editbox control which takes input text from the user's keyboard, and then sends it out to a CEGUI Listbox control.  It's all working fine most of the time.

I'm noticing when I type really fast it's sometimes missing characters.  This happens pretty often actually.  I'm putting a log output at the very top of my keyPressed() function and it's never even being called sometimes (for individual characters here and there).

For example, I could type the following into my application's text input box:  "this is a very quickly typed sentence", but it might only print the following to my output window: "ths is a veryquicky typed sentce", and keyPressed() would only be called for those characters in the 2nd sentence.  Not sure what's happening to the missing character inputs.

I was under the impression that when using buffered input for my keyboard that it should always call keyPressed() for each character, regardless of the input speed.  Is this not the case?  What can I do to fix my broken application?

I'm using Ogre 1.4.6, with the standard dependency versions of OIS and CEGUI.

[pjcast]

OIS uses something like 17 or so events for DX buffered mode. So, unless you are running at extremely low FPS, there is little chance of missing  an event. Because, at 30 FPS, that is around 33 ms each loop allowing for 17 keystrokes each 33ms, which equates to about 510 characters per minute (17 * 30). So, with average characters per word of 5, a person could type around (on average) 100 WPM and have no issues. Of course, it might be possible for some duration to exceed the amount of characters in buffer for some phrases... But, really, in most games, who would be typing that fast?

You can try increasing the Buffer size in the Win32 Prereqs file and rebuild OIS to maybe help your specific problem. If it still drops letters, i would say that a) your keyboard is not keeping up b) you have something wrong with your system. This is of course assuming you are using Win32, if not, then you have an OS issue (since OIS does not have any buffer size limitations on other platforms besides whatever the OS has).

[Arcanor]

Thanks for the reply pjcast!

Sorry, I should have mentioned earlier: I'm using Win32 and building with VC++ 2005 Express.

I am testing in debug mode and my frame rate is often down around 15-25fps.  I suspect the frame rate must be related to this problem, however even at 200fps or more I still see it happen occasionally.  Not nearly as often as at lower frame rates though.  Down the road we will have much more content in our world, so I expect our Release code's framerate to drop significantly as well, perhaps to below 30fps for some configurations.

I do think there will be some end-users who will choose graphics settings that may create low frame rates such as 15fps if it means they can see certain aspects of the game better.  I'd like to know that OIS isn't holding the user back if they make those choices.  I would rather not put limits on acceptable graphics performance because of text input issues.

As for your question of "But, really, in most games, who would be typing that fast?", I think there are many people who use a game client as a chat front-end.  Think of all the WoW users who don't even play the game any more  but only login so they can chat with their guildmates.  I think a multi-user game application needs to be efficient enough to act as an effective chat client.  Chatting may be a primary reason for some players to continue to enjoy the game, especially after they've played the game for a while.

So, presuming that this is a limitation of OIS and I can bump up the tolerance by increasing the buffer size - how far would be safe to go?  Would doubling the buffer size be appropriate?

Is there any other possible explanation which doesn't have to do with overflowing the buffer?  Is it possible that OIS is just missing those inputs somehow?

I really don't think it's my keyboard as I type (quickly) on it all day every day and it's quite reliable and does not drop characters in other applications.

[pjcast]

It is a DirectInput setting, simply increase buffer size until keyboard loss becomes negligible. Alternative, you can try to put OIS in a separate thread updating at a fixed time step to not make input. Though, you may run into some issues other issues on different platforms related to concurrent use of Window Objects... On window, though, it should work fine. Depends on your needs. Increasing the buffer will increase memory usage, I am not sure how much, for that you will have to consult DX SDK Docs and/or perform tests.

HTH

[Arcanor]

As I suspected, the keyboard characters being dropped have nothing to do with the size of the buffer.  I changed it from 17 to 170 and am getting the same result.

As additional evidence, it's often one or more of the first 17 characters that gets dropped, meaning even a 17 character buffer couldn't have possibly overflowed.

So I'm still dropping characters whenever my app is at a low framerate.  I'm not very experienced with writing threaded code though.  Is there any other alternative that might explain this behavior?  Something else I could try before I dive into the wide world of threads?

Thanks in advance!

[Arcanor]

I've just done another test and discovered this is apparently not an OIS issue.  Sorry to bug you pjcast!

The way I determined this is that I loaded up a Navi GUI text entry box and typed into it and had no dropped characters even at 15fps.  It's apparently a CEGUI issue, as that's the place I'm losing characters: when I enter text into a CEGUI::Editbox control.

Thanks anyway!

[pjcast]

No bother at all.. Just glad to hear the issue was not being caused by OIS.

I've never had/heard of this problem with CEGUI. I can't see how it would be impacted by low framerates in regards to character handling. Is this a new version? I guess best place to take it up is with CEGUi forum. I know, from previous experience, CEGUI is fairly complicated and difficult to trace through if you don't know the system to well.

[Arcanor]

Not a new version of CEGUI, no.  I'm just using the standard 0.5.0b.

I've posted in the CEGUI forums but not gotten any reply yet.  We'll see how it goes.

[Arcanor]

Okay, news update... I think this may be an OIS issue after all.

I'm seeing characters dropping in both BetaGUI and CEGUI text entry windows.  I had concluded earlier that this couldn't be an OIS issue because I was able to use Navi without missing any keystrokes, however I have since realized that Navi doesn't actually use keyPressed() to inject characters into it, instead Navi grabs input direct from the keyboard asynchronously (i.e. I'm guessing it's doing it in its own thread).

keyPressed() is definitely not being called at all for some keystrokes, somewhat randomly.  It happens more often at lower frame rates, and when inputting several characters in a row quickly.  But it doesn't have to be a lot of characters.  For example, I can type "lins" four times in a row and (sometimes) see the following output: "linlinlinlin" (instead of "linslinslinslins").  However, this is not a problem with my "s" key.   I can change the characters and have the same problem, like typing "kube" 4 times and getting "kubkubkubkub" sometimes, or maybe "kubkubekubekub" or some other combination.

So is there any possible reason why inputting 4 characters quickly should only call keyPressed() for the first 3?  If there's a pattern that seems to happen more frequently that's it.

[pjcast]

First, it is obvious to find where the problem is. Add some cout's to keyDown to see if you were getting the events.

Secondly, I suggest you reproduce the problem on a demo app, and try on a different system. Simply, add some more sleep() time to the OIS console demo to reproduce 14-15 FPS and see if issue happens there. If it does not, then it is not an OIS problem. You can also try some of the DirectInput SDK samples and see if the issues happens there. The only possible problem could be buffer size, and if increasing it does not help (hopefully you rebuilt the OIS lib and used correct lib) then there is not much that can be done. Note, this error does not happen here, nor I have heard of this before.

[OvermindDL1]

Yes, I find that odd as well.  If you could create a demo app (with plenty of something like sleep(250)'s in there to simulate 4fps) that does not work for you and give it to us so we can try, it would at least confirm whether it is OIS or something on the system that OIS is not working well with.

First of all though, just start dumping the events you get (keypressed and so forth) to a log or std::cout or something and compare it to what you typed with.

If you have a higher end keyboard like mine (G15), then you can tell it to do a whole host of keypresses so you can have a nice repeatable test (not to mention I program in keypresses for some very long things in my keys that output with no delay and I have yet to see one drop in my apps that use OIS, although a lot of other games tend to drop though, freaking immediate output should never be used...).

[Arcanor]

Thanks for the replies guys.  I am working on creating a deployable demo to do more thorough testing on another (non-development) box.  Right now I'm battling the "This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix this problem" annoyance.  I've solved this problem before though, so hopefully it won't keep me long, then I will report back here.

[pjcast]

You simply need to install the VC8 (SP1) runtime to your target system. This can be done easiest by creating an installer for you project. In anycase, I don't expect (or really want) a GUI app/demo which shows this problem. I would rather you get the console demo to show the issue and post a small code snippet or small source zip.

[OvermindDL1]

Yes, console app, preferably just as a very simple short program c/cpp file you could post here in [code] tags even.

[Arcanor]

Thanks for the followups guys.

I'm able to deploy the Release version (of my app) to another box, but not the Debug version.  I'm not seeing the problem on the other box, so it's either a Debug-only issue, or it's a problem with my local machine somehow (although I doubt that).

There's nothing anyone can do until/unless I am able to deploy and replicate this problem reliably.  As for now, my testing is at a standstill unless someone knows an easy way to deploy a Debug build to a non-dev box.  I've copied in the whole Microsoft.VC80.DebugCRT folder with the dlls and manifest, and also run the "vcredist_x86.exe" but no luck.  I'm still unable to run the Debug build on the non-dev box.

I also looked into creating a Setup project, but it doesn't seem that VC Express supports them.  Even so, it might not allow deployment of a Debug build.

Anyway, I think it's safe to drop this issue for the moment.  As long as the Release version isn't showing the problem then my eventual users won't complain.  Thanks again for following along.