Print

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

[pjcast]

Getting debug to work on a non-development machine is not going to work very well. Hence, your problems with that

So, to clarify, does the release build function correctly on your machine where the debug build is having issues? Are you getting a very different FPS between release and debug? You could try add some sleeps to your release on your machine to try to simulate that.

Are you using VC8 SP1? I would assume so, but just have to ask.

You could install VC Express on another machine and test debug that way. Depending on your access to other Window's boxes this may or may not be a problem.

If this is truly a debug only problem, and not release problem, this could indicate some kind of uninitialized memory issue - since debug will set variables to certain values, but release won't. Please, try to replicate the issue with the OIS Console demo application in debug on your machine, put a Sleep(100) will get you 10FPS - and if that works, something is strange within your code base. (Like memory corruption, buffer overflow, uninitialized data, etc).

[Arcanor]

Ah, "Sleep()", not "sleep()".  I didn't realize the difference.  I looked into adding sleep() into the application but the only way I saw it implemented was using threads.  Since I'm not experienced using threads I figured it would be best to leave it alone for now.  I've not implemented any kind of threaded code in my application; at least not on purpose.   But now I see from the OIS console demo that "Sleep()" is part of windows.h.  That changes things...

Anyway, yes.  I'm running VC8 SP1, just to answer your question.  Before using Sleep(), I was getting about 400fps in Release builds and about 60fps on Debug builds.

Okay, so I've tried replicating the problem in the OIS console demo but not seeing the issue at all.  Even after setting Sleep(100) and rebuilding in Debug mode I'm not dropping any characters.  It looks like OIS is handling the inputs very speedily, without any problems.

However, in my application I'm now seeing the issue in the Release build too, now that I've added a Sleep(100) into my main program loop.  I'm also seeing the problem on my non-development box, running the slowed-down Release build.  So that means it's not specific to one machine and it must be code related.

I will spend some time ripping things out one at a time until the problem goes away.  I no longer believe this is an OIS issue but I will report back here to let you folks know what the problem was, just in case you're interested.

Thanks for your patience and assistance!

[Arcanor]

Okay, I finally figured this issue out!

I was reading in another thread (http://www.wreckedgames.com/forum/index.php/topic,904.0.html) where OvermindDL1 said "Yep, should basically always return true, returning false essentially flushes the buffer of any remaining buffered events."  And it occurred to me that that's exactly what's happening.

My application code was sometimes returning false from keyPressed() and keyReleased(), if I didn't process the keystroke.  Basically I was returning true if I did something with it, and if it fell through to the end of my handler function I was returning false.   It seemed natural and similar to the way CEGUI::System::getSingleton().injectKeyDown(arg.key) returns a bool to tell me if the keystroke was processed.  I figured I should be passing that value similarly onward in my keyPressed() function.  Looks like I was wrong.

In summary, the "rule" that I've learned is this:  If your input event handler functions (keyPressed(), keyReleased(), mouseMoved(), mousePressed(), mouseReleased()) return false then you are telling OIS to discard the remaining events in the buffer.  This should probably only be done when you're quitting your application.

This is not obvious from looking at the simple OISConsole application, and the Ogre demos are similarly built for simplicity.  This rule should be clearly stated, perhaps with a source code comment in Win32KeyBoard.cpp, and/or elsewhere.

I have to say this was a very difficult problem to find!  I have been searching for over a week now, nearly non-stop.  I've debugged, profiled, ripped my code apart, dug into the CEGUI library, etc.  It was a painful process, and this is an insidious bug that doesn't show itself except under extreme (and difficult to test) conditions, and even then its effects are intermittent at best.

Anyway, I'm glad this problem is solved!  Thanks for the help!

[pjcast]

Hmm, I didn't think of that. Which is why, I always suggest getting the issue to reproduce in the most simplist of apps (i.e. OIS console app), and then you can compare simply code

In regards to why there is a return value, it is there in case you want to destroy a OIS::Object as the result of a event.. That way, the function will end immediately and not access invalid local objects. Anyway, which is why all the demos (Ogre included) simply return true.

It may need to be documented better. Feel free to submit a bug/issue on the sourceforge page.

However, if you had debugged into the listener callback function as it returned into OIS, you probably would have noticed the code returning immediately in some situations.

[OvermindDL1]

We all have debug here, but still, if you could post up a little code snippit that shows that problem for you, then we can test it, or better yet since you are using VS2k5 then give us the project file with all relevant source and so forth, then we can setup a remote debugging session and watch it manually.

But still, have you tried just dumping the events to std::cout?  Do the demo's that come with the OIS source work, especially the console demo (as all it is, is just something that reads the events and dumps them to the console).

[Arcanor]

Not sure what you mean OvermindDL1.  The problem is solved.  Did you read my prior post?  Everything is fine now.  Thanks!

[OvermindDL1]

Heh, another page appeared.