eventreciever delay on key press

[gheft]

okay I started getting this really mysterious bug in my code related to physx and key input so I started reorganizing my ridiculously messy code and I may have found a bug in irrlichts event reciever...

my eventreceiver is a simplified version of this http://irrlicht.sourceforge.net/phpBB2/ ... ntreceiver

So I have an array representing keys which are set to up/down/pressed...

Anyways the problem is in my custom camera class which before worked by having one function updated every frame. so it checks the array of keys and moves if the key is down.

now I split the camera function into two:

camera::does() is called every frame

camera::input() is called by the eventreceiver during OnEvent

when I press the key to move the cam forward, it moves when I press the key... stops for a few frames and then keeps moving as I hold the key down. So the eventreceiver is not being called for a few frames after the key is pressed.

In my main loop I put
while(device->run())
{
cout<<"loop"<<endl;

and in OnEvent I put
cout<<"event"<<endl;

and the ouput looks like this when I run it

...
loop
loop
loop
event //key==pressed
loop
loop
loop
loop
loop
loop
loop
event //key==down
loop
event //key==down
loop
event //key==down
loop
event //key==down
loop
event //key==down
loop
event //key==up
loop
loop
...

so there is a delay after the key is pressed.
now logically if the keys state isn't being changed its not really an event but the way the eventreceiver works OnEvent should be called shouldn't it.

sorry if I added to much irrelevant information, hopefully someone knows whats going on.

[rogerborg]

Since that behaviour sounds exactly like you're responding to key events rather than persistent key states, I'd suggest that's what's going on.

If you are storing key states, then is it possible that you're accidentally setting them to false other then through receipt of an event?

Before answering, how about you set a data breakpoint on the suspect state, and find out?

[gheft]

Since that behaviour sounds exactly like you're responding to key events rather than persistent key states, I'd suggest that's what's going on.

responding to key events is exactly what I'm doing, however it seems to me that the eventreceiver handles a persistent key state(a key being held down) as an event.

about the key states the issue isn't what the state of the keys actually is, whether or not I even update the key states I still get the output posted above.
So the problem is just the uneven frequency of OnEvent. Sorry if the first half of my post was misleading

maybe it is not a bug only some behaviour I don't understand

[rogerborg]

Ah, OK, fair enough. The good news is that the behaviour that you're getting is exactly correct.

Initial event -> delay -> repeated events is what's generated by your OS. Your app is getting the same key events that any other app/widget gets; hold down a key and seeeeeeeeeeeeeee.

Irrlicht doesn't generate repeated events while a key is down, but that's generally OK, because what you're probably interested in is the key state instead.

If you've got Irrlicht 1.4 or the SVN version, then have a look at the event handler in example 04. Movement. Ah, I'll just post it here:

Code: Select all

/*
To receive events like mouse and keyboard input, or GUI events like 
"the OK button has been clicked", we need an object which is derived from the 
IEventReceiver object. There is only one method to override: OnEvent. 
This method will be called by the engine once when an event happens. 
What we really want to know is whether a key is being held down,
and so we will remember the current state of each key.
*/
class MyEventReceiver : public IEventReceiver
{
public:
	// This is the one method that we have to implement
	virtual bool OnEvent(const SEvent& event)
	{
		// Remember whether each key is down or up
		if (event.EventType == irr::EET_KEY_INPUT_EVENT)
			KeyIsDown[event.KeyInput.Key] = event.KeyInput.PressedDown;

		return false;
	}

	// This is used to check whether a key is being held down
	virtual bool IsKeyDown(EKEY_CODE keyCode) const
	{
		return KeyIsDown[keyCode];
	}

	MyEventReceiver()
	{
		for (u32 i=0; i<KEY_KEY_CODES_COUNT; ++i)
			KeyIsDown[i] = false;
	}

private:
	// We use this array to store the current state of each key
	bool KeyIsDown[KEY_KEY_CODES_COUNT];
};

Then your app can just call receiver.IsKeyDown() repeatedly to check whether a key is down or up. "repeatedly" is up to your app (which is why Irrlicht doesn't do it!); you can call it every time round your main loop, or every X milliseconds, or whatever you like.

[gheft]

thats interesting. its only the repeat delay on the keyboard I guess I just thought it only applied to inputting text not pressing butons... but oh wait thats what a keyboard is for

anyways this problem is easily fixed in my program, since I already have the key states working, I just wondered why I couldn't use OnEvent to move my camera. Now I know why the fps camera has a key map

[rogerborg]

It catches out nearly everyone; that's why it's in the tutorials now.