Multiple Event Handler Input

[williamlai3a]

I am implementing the movement of my game character.
I am thinking of making the character move with direction 045 degree when the player is pressing arrow up and right together.

Indeed, my question is how can I know that the player is pressing arrow up and right together, but not pressing arrow up or right ???

Thanks a lot.
William

[greenya]

the event will come to your EventReceiver of cause one by one, but you simply must to remember all the pressed buttons.

Ordinary this is implementing like:

Code: Select all

bool keys[256];

this array stores all states of keys.

Then when you receive "pressed" event -- you set proper index to true,
when you receive "released" event -- you set proper index to false.

Once next expression is true:

Code: Select all

if (keys[KEY_KEY_ARROW_UP] && keys[KEY_KEY_ARROW_RIGHT])
{
// ... here you know that ArrowUp+ArrowRight is pressed
}

Something like i described.

P.S.: the only thing am not sure about existance of KEY_KEY_ARROW_UP, and KEY_KEY_ARROW_RIGHT -- but i just wanted to show the meaning.

[rogerborg]

Since this was one of the most FAQs, example 04. Movement in the SDK has now been updated to show storage of key states.

[williamlai3a]

the event will come to your EventReceiver of cause one by one, but you simply must to remember all the pressed buttons.

Ordinary this is implementing like:

Code: Select all

bool keys[256];

this array stores all states of keys.

Then when you receive "pressed" event -- you set proper index to true,
when you receive "released" event -- you set proper index to false.

Once next expression is true:

Code: Select all

if (keys[KEY_KEY_ARROW_UP] && keys[KEY_KEY_ARROW_RIGHT])
{
// ... here you know that ArrowUp+ArrowRight is pressed
}

Something like i described.

P.S.: the only thing am not sure about existance of KEY_KEY_ARROW_UP, and KEY_KEY_ARROW_RIGHT -- but i just wanted to show the meaning.

Thx for your suggestion,

may I ask something more details?
how can I know the event is a released event??

[rogerborg]

event.KeyInput.PressedDown tell you that.

Here's the event receiver source from the recent SVN versions of example 04.Movement, main.cpp.

Code: Select all

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];
};

Does that help?

[Vsk]

Actually there are quite much events that you want to know not if the key is down but if the key is being realeased.
For example you woud like to ask for ispressDown for a motor car acelerate but isRealising key for a tank fire. (Or all the menu of GUI menu window (for the mouse the same applies).

Fot doing this you must have another checker that updates your key states from hold to realigin to realese to pressing.. etc.
Thats why is better that you have an array of enum instead of bool.

A question for the rest:

SDL have this automatic (the is realising) or should I implemented as I said?

I hope it helps you.

[rogerborg]

Indeed, that's a good point. There are many different ways of handling and consuming events, and the example code could and probably should demonstrate all of them. I look forward to seeing your patch for it.

[Vsk]

Indeed, that's a good point. There are many different ways of handling and consuming events, and the example code could and probably should demonstrate all of them. I look forward to seeing your patch for it.

Are you saying the last part with some kind of sarcasm or is serious?
I was not meaning that irrlicht example was wrong, but talkin to the guy which ask. And as I never saw any similar post that explained what I just explained, the I just take the chance to explain this (which is very important). Sorry if you take it in the wrong way:?

Indeed I was think on sending not a patch but a code snipet (or whatever it writes) for good desing for handling event and flexbile for change between differen peripherics on run time even (having intiatlized ofcourse this pheriferics on the logic level). But maybe it sucks .

Actualy in my even handling I can consider 3 event of 4 : pressed, realeased and realesing. Pressing I have no yet implemented, because it is almost not used.

Well while I getting better the code for sendin to code snipet , the idea (only for the 3 or 4 states (or use the 4) , not the different peripheric desing) is somethin like that:

-You must have and Key array of type State (enum pressed, pressing,realising, realesed).
-if event key donw is reacived then put for this KEY state "PRESSING",
-if event key down is pressed check if the key state is pressing, if so, then to stat "PRESSED".
-IF event key is up go to the key and set "REALESING".

Here are the part maybe ugly, but it works, and (wih irrlicht events) have not found other way to do it:
You must have inside a loop a function that for every key in "REALISING" state goes to "Realeased". This is a quite cheap function and don't have any performance issues. It is just a if condition follow by an asination of primitive types.
This function must be call ofcourse after that you have handled what you need.
This works perfectly, I used since almost a year without a single problem (no retard, not missing keys, nothign wrong at all).

Maybe there is form without this last fucntion that realy make ugly because you must use sometin else besides the event receiver, but I've no found it yet (although I've no made a hard found neither).

I will send soon this code with the other part the named above.

I hope it'd be usefull for someone .

[rogerborg]

Indeed, that's a good point. There are many different ways of handling and consuming events, and the example code could and probably should demonstrate all of them. I look forward to seeing your patch for it.

Are you saying the last part with some kind of sarcasm or is serious?

Completely serious. I believe strongly that the examples are the best place to demonstrate this sort of commonly queried functionality.