Really wierd keyboard and mouse bug

Archives Forums/Blitz3D Bug Reports/Really wierd keyboard and mouse bug

gburgess

(Posted 2005) [#1]

I'm having real trouble figuring this out, and it's a tricky one to reproduce.

This bug has so far only appeared when Blitz3D is running some software fullscreen. The software that falls into that "some" category seems to be the more graphically intense stuff. Not really intense, just basically stuff that involves a screenful of 3d.

Basically, what happens is the controls "lock" for a half-second or so. By "controls" I mean Keyboard and Mouse. If, for example, I hold down a key, sometimes when I release it the software behaves as though I'm still holding it down for a half second. Similarly, when I press a key, there may be a half-second delay before things actually happen. For the mouse, the pointer will just lock up for a half-second and then carry on.

The really odd part is that none of this affects frame rate. So the software itself doesn't freeze.

I don't think this is a programming error on my part because:

1) I can't think of any circumstance where the controls would "lock" like that but the game keep running. The controls are checked every time the game loops, and that does not change at all.
2) This bug appeared in two unrelated programs at the same time.

This MAY be a fault with my system, for latter of those two reasons.

However, I have a feeling I may have uncovered a bug in Blitz somewhere because:

1) I have thoroughly checked my system for any rogue services or startup programs that may be causing this problem.
2) This has yet to occur in any other games, or in Windows.

The bug does not happen in Blitz3d's Debug mode. It also does not happen all the time, but it seems fairly frequent.

I have ruled out:
1) External DLLs.
2) Software running in the background.

Anyone ever experienced anything like this before? I'm using Blitz3d 1.90 on a GeForce 6600, Windows XP, 1Gb RAM.

gburgess

(Posted 2005) [#2]

Okay, I think I may have found something.

This is going to sound very strange, but if I put a "Delay 10" command in the loop, the problem seems to disappear.

Also, I've not been able to reproduce this effect on anyone else's computer.

Soo... tentative conclusion... maybe reading the mouse and keyboard too often causes the buffers to lock up for a short period?

I sorta pulled that out my backside, I know, but does it sound plausible?

This is the code I'm calling each cycle to check the mouse:

	mx%=MouseX()
	my%=MouseY()
	mp1%=MouseHit(1)
	md1%=MouseDown(1)
	md2%=MouseDown(2)
	mxs=MouseXSpeed()
	mys=MouseYSpeed()

It does not change between affected and unaffected Blitz3d programs.

Switching from a PS2 to a USB mouse had no effect.

big10p

(Posted 2005) [#3]

I suspect a piece of your code is stalling things by taking too long to execute. Common causes of this are loading stuff in the main loop and using more VRAM than you physically have, causing things to get swapped in and out of main mem. Thus, the problem may not show on another computer with better specs.

I know you said the FPS doesn't change but sometimes the reported FPS can lie, depending on how you're calculating it. Can you actually see other stuff moving when the mouse stalls, etc?

Also, try putting FlushKeys and FlushMouse after reading your input into variables.

Hotcakes

(Posted 2005) [#4]

Off the top of my head, the MouseX/MouseXSpeed commands /could/ be conflicting with each other, same with the Y equivalents.

There is a (unofficial?) command to switch between using DirectInput or WinAPI (or somesuch) for input - there's a keyword something like
DisableDirectInput True/False ... or...
DirectInputOn True/False
... might be worthwhile digging for something like that and testing to see if it makes a differance...

HappyCat

(Posted 2005) [#5]

Glenny-boy, I used to get the same thing, but I had it all the time (with Debug on or off) when running my game in windowed mode (but not fullscreen) on my laptop (but not on any other PC I tried it on).

I wasn't using MouseXSpeed() and switching to DirectInput (as Hotcakes suggests) didn't help.

However it went away after I upgraded my video drivers (for an unrelated reason, ie. Half-Life 2). Has never happened again.

gburgess

(Posted 2005) [#6]

To answer y'all:

big10p: I am 100% certain no frames are dropped. I test this by loading the editor for my game, holding down an arrow key to keep the camera moving, and moving the mouse pointer with my other hand. It's very clear that the mouse freezes for half-second perionds while the camera continues to move smoothly. In the editor, nothing is being loaded with selecting something, and in it's base state puts very little strain on a graphics card. The mouse lockups coincide with keyboard lockups. I will try Flushing the buffers more often, it could well be as simple as that.

Hotcakes: Good tip, I'll give it a shot.

HappyCat: This has been happening for three different video driver revisions and two graphics cards (I got Battlefield 2 recently, and it didn't like my GeForce 4200, even after I upgraded the drivers. So I got a new card. And some even newer drivers came out, etc etc, this problem started before I bought BF2). I've also upgraded all the drivers on my nForce2 motherboard. Still no change.

Thanks for the thoughts, guys, I'll give them a roll. This one's got me tearing my hair out. I'd reinstall my system, but whenever I have a problem I can't solve (rare ;) ) and I do this, the problem always comes back. So I've learned my lesson, if I don't find the cause of a problem, it'll never go away. :D

HappyCat

(Posted 2005) [#7]

Was just a thought - but also an example of how something completely unrelated to your code can cause these kinds of problems.

gburgess

(Posted 2005) [#8]

Oh yeah, totally, wasn't a bad suggestion by any means.

Tue	(Posted 2005) [#9]

Dear all who has discussed this little mouse/keyboard delay issue:
A couple of years ago, I programmed a small DirectX engine in C++, discovering the exact same problem. Now, I think it may be a problem with Direct3D versus DirectInput (at least that was what I found out back then). Using OpenGL and DirectInput doesnt create this problem, while D3D and DInput makes it all go BAD. A really weird problem.

To me there doesnt seem to be any obvious solution. Originally it was a fullscreen only problem that could be solved by using windowed mode. I recently reinstalled my OS, and now it´s the other way around. It´s only a problem in Windoed mode, not in fullscreen.
So, in other words: It´s a Microsoft bug, not a Blitz bug.

A simple solution could be to enable your game to run in both windowed and fullscreen mode. Since there is no clear reason why and when it will happen, this is the only thing I can think of.

Tue

Tue	(Posted 2005) [#10]

gburgess

(Posted 2005) [#11]

Thanks, Tue, interesting stuff there. Bit of a bummer.

I don't even get the problem all the time, I'd say it's only 50% of the time.