Key Inputs, some double?

edited August 2014 in General discussions
Interesting discovery this evening that some keys appear to trigger on and off twice where some only once. For example, with this code:
if (_pstEvent->eType == orxEVENT_TYPE_INPUT){

	orxINPUT_EVENT_PAYLOAD *pstPayload;
	pstPayload = (orxINPUT_EVENT_PAYLOAD *)_pstEvent->pstPayload;
	
	if (_pstEvent->eID == orxINPUT_EVENT_ON){

		if (orxInput_IsActive("MyKey") == orxTRUE && orxInput_HasNewStatus("MyKey")){
			orxLOG("--------------- MyKey ON ------------------");
		}

	}
	
	if (_pstEvent->eID == orxINPUT_EVENT_OFF){
		if (orxInput_IsActive("MyKey") == orxFALSE && orxInput_HasNewStatus("MyKey")){
			orxLOG("--------------- MyKey OFF ------------------");
		}
	}
	
}

And some ini:
[KeysForInput]
KEY_DOWN    	= MyKey

This code will generate this with a keypress:

MyKey ON

MyKey ON

MyKey OFF

MyKey OFF

Whereas another key:
[KeysForInput]
KEY_D    	= MyKey

Will generate this with a keypress:

MyKey ON

MyKey OFF

Keys like cursors, paging and return generate twice. Alphanumerics and function keys generate once.

Are these special for any reason or is there a bug here?

Comments

  • edited August 2014
    Hi I couldn't repro any input duplication on osx/linux/windows, however before digging further, I think the problem comes from the code you posted.

    The event notification isn't linked to the actual check made further(orxInput_IsActive("MyKey")): if the key you're pressing is bound to more than one input, you'll get an event notification for all of them, however you're not checking which event is received, you check only if "MyKey" is active (which in this case is true, even if more unrelated input events get fired).

    What I believe is happening with KEY_DOWN here is, when you press that key, you get one notification for your actual input "MyKey" and one for the input "Next" (from the input set "-=ConsoleSet=-").

    When you listen for input events, you have all the information inside the payload, no need to call any orxInput_* function in addition to that:
    payload->zSetName: name of the set
    payload->zInputName: name of the input

    The orxInput_* functions are useful when you want to poll input state from any other part of the code (like logic loops, etc).

    Attempt at code correction:
    if(_pstEvent->eType == orxEVENT_TYPE_INPUT)
    {
        orxINPUT_EVENT_PAYLOAD *pstPayload;
        pstPayload = (orxINPUT_EVENT_PAYLOAD *)_pstEvent->pstPayload;
    
        if(_pstEvent->eID == orxINPUT_EVENT_ON)
        {
            orxLOG("--------------- %s ON ------------------", pstPayload->zInputName);
        }
        else if(_pstEvent->eID == orxINPUT_EVENT_OFF)
        {
            orxLOG("--------------- %s OFF ------------------", pstPayload->zInputName);
        }
    }
    
  • edited August 2014
    Yep makes all good sense. I've been mixing different concepts! Thanks, Iarwain.
  • edited August 2014
    My pleasure!

    That being said, there's an annoying semi-related issue on OS X only: when using keys such as the arrows and concurrently trying to get the text content of keypresses, you'll get the key unicode characters with the text content as well.

    That's why the console is misbehaving on OS X when navigating with the arrows. I'll need to patch GLFW in order to filter out all those extra unwanted unicode characters from being send to the text buffer.
Sign In or Register to comment.