orxInput_HasNewStatus problems

edited October 2010 in Help request
A curious problem with orxInput_HasNewStatus(). As I understand it, it should notice a mode change, so that if a key is pressed, it should trigger, and being held has no further effect.

Therefore, orxInput_IsActive("SomeKey") && orxInput_HasNewStatus("SomeKey") should trigger in a callback if the key "SomeKey" is pressed but not held.

I have used the 06_Sound tutorial of a good example to show what could be a potential bug.

Compiling this tutorial on Windows XP under VS2005, when I press the space key which puts some colour FX on the soldier, I have the press the space key very quickly many times to register a key hit. I presume because I have to trip both an "on" and "off" event during the life of the callback method.

However, head over to the linux binary of 06_Sound and pressing the space key is completely normal.

Didn't want to log this into the bug subforum in case it turns out to be a comping option I might have set in VS2005 that might be causing this.

This effect is also observed in my own project.

But the crazy thing is, if the project is a standalone one, and I move the keyboard code to the Run() callback. It is perfect. Isn't that odd?

iarwain, or anyone, have I discovered a bug here?

Many thanks,
Wayne

Comments

  • edited October 2010
    sausage wrote:
    A curious problem with orxInput_HasNewStatus(). As I understand it, it should notice a mode change, so that if a key is pressed, it should trigger, and being held has no further effect.

    Yes, exactly, HasNewStatus() tells you if the input just got activated or deactivated. After that, when the input remains active/unactive, HasNewStatus() returns orxFALSE.
    Therefore, orxInput_IsActive("SomeKey") && orxInput_HasNewStatus("SomeKey") should trigger in a callback if the key "SomeKey" is pressed but not held.

    To be precise, it should evaluate to orxTRUE when the input gets active (even if it's held afterward, it doesn't need to be inactivated in the same frame).
    I have used the 06_Sound tutorial of a good example to show what could be a potential bug.

    Compiling this tutorial on Windows XP under VS2005, when I press the space key which puts some colour FX on the soldier, I have the press the space key very quickly many times to register a key hit. I presume because I have to trip both an "on" and "off" event during the life of the callback method.

    This is very strange. Especially because orx can't register 2 changes of state during the same frame, there'll be at least a frame of delay between 2 consecutive status changes. I have no clue why this happens and I haven't witnessed it myself.
    However, head over to the linux binary of 06_Sound and pressing the space key is completely normal.

    Which is the expected behavior.
    Didn't want to log this into the bug subforum in case it turns out to be a comping option I might have set in VS2005 that might be causing this.

    This effect is also observed in my own project.

    There's something fishy there. Unfortunately I still don't have my cargo back from Montreal, so I can't test it on windows myself (I only have access to a macbook for now). If you can narrow the problem down, please let me know. Something like having a breakpoint in orxInput.c's update function that will get triggered hopefully when you press space, even if you hold it. If nothing triggers, something might be wrong on GLFW's side with msvs2005.

    Also, does it happen if you compile orx with other plugins (such as SFML or SDL, you can choose them in src/plugins/orxPlugin_EmbeddedList.cpp)? Or with another version of visual studio or mingw? Of course, don't feel forced to test all these, it's simply a couple of leads I'll look into myself when I get access back to a PC. :)
    But the crazy thing is, if the project is a standalone one, and I move the keyboard code to the Run() callback. It is perfect. Isn't that odd?

    Definitely weird. The only difference being that Run() is called every frame whereas the callback is called at a given fixed frequency. But as the input module update runs on the same clock, this shouldn't produce different results.
    iarwain, or anyone, have I discovered a bug here?

    Definitely a bug, but now remains to be to found on which side it is (GLFW, orx, visual studio?).
    Many thanks,
    Wayne

    Thank you for reporting it!
  • edited October 2010
    iarwain wrote:There's something fishy there. Unfortunately I still don't have my cargo back from Montreal, so I can't test it on windows myself (I only have access to a macbook for now). If you can narrow the problem down, please let me know. Something like having a breakpoint in orxInput.c's update function that will get triggered hopefully when you press space, even if you hold it. If nothing triggers, something might be wrong on GLFW's side with msvs2005.

    I can certainly put together a very simple project to demonstrate and see what happens crossplatform. Not sure what GLFM is so I'll do a quick read up and check into that. In the meantime, I have my own system of "KeyUp" global variables to track key up/downs.
    Also, does it happen if you compile orx with other plugins (such as SFML or SDL, you can choose them in src/plugins/orxPlugin_EmbeddedList.cpp)? Or with another version of visual studio or mingw? Of course, don't feel forced to test all these, it's simply a couple of leads I'll look into myself when I get access back to a PC. :)

    Not entirely sure here. Again, I am not adding any plugins I don't think. Don't understand that side of it. This is on a standalone project so I guess that means that no particular plugins are being used.

    Thank you for reporting it!

    That's ok. I'll see what I can find.
  • edited October 2010
    I just did a quick run of 06_Sound.bat from orx-tutorial-msvs2005-1.2.zip. I have to press return or space many times to register an occasional hit.

    This removes the possibility of a compiler setting in my particular vs2005 setup as being at fault. These are the tutorial binaries straight out of the box.

    Is there anyone with WindowsXP around that might be able to confirm this on their system?
  • edited October 2010
    sausage wrote:
    I can certainly put together a very simple project to demonstrate and see what happens crossplatform. Not sure what GLFM is so I'll do a quick read up and check into that. In the meantime, I have my own system of "KeyUp" global variables to track key up/downs.

    Sounds good to me.
    Not entirely sure here. Again, I am not adding any plugins I don't think. Don't understand that side of it. This is on a standalone project so I guess that means that no particular plugins are being used.

    My bad, I wasn't very precise. I was referring to the internal plugins. Orx is has a plugin architecture: a platform-independent core and plugins for I/O (mouse, keyboard, joystick, sound, display, physics and render). The plugins can be hotloaded at runtime or embedded at compile time. In addition to that you can extend orx with user made plugins but this part needs some dusting and scripting support before being of any interest. :)
    When you're not using orx in a stand alone mode, you're actually writing a user made plugin and we use it's register function to create a clock callback instead of simply providing new features through an array of functor (that's why there's a special macro that hides all this in this case: orxPLUGIN_INIT).
  • edited October 2010
    sausage wrote:
    I just did a quick run of 06_Sound.bat from orx-tutorial-msvs2005-1.2.zip. I have to press return or space many times to register an occasional hit.

    This removes the possibility of a compiler setting in my particular vs2005 setup as being at fault. These are the tutorial binaries straight out of the box.

    Is there anyone with WindowsXP around that might be able to confirm this on their system?

    Oh, good to know. I have access to a win XP with no internet connection and no way to install msvs2005 on it, but I can use it to test the official tutorial package. I'll try that tonight and tell you if I get the same issue locally.
  • edited November 2010
    I've tried the tutorial package on a WinXP SP2 with success. All the key pressed in the sound tutorial were correctly registered, wether they were long or extremely short.

    If you try the msvs2008 or mingw tutorials on your computer, do you witness the same issue?
    If so, it's definitely something related to GLFW and not being able to reproduce it on my side will make it hard to debug. I'll check GLFW's svn log to see if there's any recent mention to bugfixes that could be related to that.

    Oh, what happen if you deactivate the sounds, does it still have issues registering the key presses? I was thinking maybe there might be some timing issue with sound processing, but it sounds very unlikely actually...
  • edited November 2010
    iarwain wrote:
    I've tried the tutorial package on a WinXP SP2 with success. All the key pressed in the sound tutorial were correctly registered, wether they were long or extremely short.

    For the tests in that program, you only need to press Return or Space to see the effect. All other keys will be fine as they are keys that are meant to be held down.

    I also tested against the following windows machines with the same result:

    * HP Notebook Windows XP Service Pack 3, Intel 965 Express Chipset
    * HP Compaq Desktop Slimline, Windows XP Service Pack 2, Intel Q35 Express Chipset
    * HP Compaq Desktop Fullsize, Windows XP Service Pack 3, Intel Q45/43 Express Chipset
    If you try the msvs2008 or mingw tutorials on your computer, do you witness the same issue?
    If so, it's definitely something related to GLFW and not being able to reproduce it on my side will make it hard to debug. I'll check GLFW's svn log to see if there's any recent mention to bugfixes that could be related to that.

    Just downloaded both the 2008 and mingw tutorial binaries. Both 06_Sound.bat examples have the problem. I guess we can rule that out at least.
    Oh, what happen if you deactivate the sounds, does it still have issues registering the key presses? I was thinking maybe there might be some timing issue with sound processing, but it sounds very unlikely actually...

    I just did up a small example standalone project without object, viewport, camera, sound or anything. Just keypresses to demonstrate. Coming in the next post...
  • edited November 2010
    The following super small project can reproduce the problem. Interesting to note, it's not just keys, the mouse does it too:

    Main.cpp
    #include "orx.h"
    
    void orxFASTCALL InputCallback(const orxCLOCK_INFO *_pstClockInfo, void *_pstContext)
    {
    	/* Cut and paste this section to the Run() method to show the difference */
    	if(orxInput_IsActive("HitMe") && orxInput_HasNewStatus("HitMe")){
    		orxLOG("Key Pressed!");
    	}
    	/* End Cut */
    }
    
    orxSTATUS orxFASTCALL Init()
    {
    	orxSTATUS       eResult;
    	orxINPUT_TYPE   eType;
    	orxENUM         eID;
    	const orxSTRING zInputQuit;
    	const orxSTRING zInputKeyOrMouse;
    
    	orxInput_GetBinding("Quit", 0, &eType, &eID);
    	zInputQuit = orxInput_GetBindingName(eType, eID);
    	orxInput_GetBinding("HitMe", 0, &eType, &eID);
    	zInputKeyOrMouse = orxInput_GetBindingName(eType, eID);
    
    	orxLOG("none
    - '%s' will exit from this tutorial"
    		 "none
    - '%s' or LEFT MOUSE will show as pressed."
    		 "none
    Under Windows XP you may have to press or click many times to show result.", zInputQuit, zInputKeyOrMouse);
    
    	orxCLOCK *pstInputsClock = orxClock_Create(orx2F(0.01f), orxCLOCK_TYPE_USER);
    	orxClock_Register(pstInputsClock, InputCallback, orxNULL, orxMODULE_ID_MAIN, orxCLOCK_PRIORITY_NORMAL);
    
    	return eResult;
    }
    
    
    void orxFASTCALL Exit()
    { }
    
    
    orxSTATUS orxFASTCALL Run()
    {
      orxSTATUS eResult = orxSTATUS_SUCCESS;
    
      if(orxInput_IsActive("Quit")){
        eResult = orxSTATUS_FAILURE;
      }
    
      return eResult;
    }
    
    
    int main(int argc, char **argv)
    {
      orx_Execute(argc, argv, Init, Run, Exit);
    
      return EXIT_SUCCESS;
    }
    


    Main.ini
    [Display]
    ScreenWidth   = 640
    ScreenHeight  = 480
    
    [Input]
    SetList = MainInput
    
    [MainInput]
    KEY_ESCAPE  = Quit
    KEY_SPACE   = HitMe
    MOUSE_LEFT  = HitMe
    
    
  • edited November 2010
    sausage wrote:
    For the tests in that program, you only need to press Return or Space to see the effect. All other keys will be fine as they are keys that are meant to be held down.

    That's what I meant, I actually only tested space and return. :)
    Just downloaded both the 2008 and mingw tutorial binaries. Both 06_Sound.bat examples have the problem. I guess we can rule that out at least.

    Good to know.
    I just did up a small example standalone project without object, viewport, camera, sound or anything. Just keypresses to demonstrate. Coming in the next post...

    I'll try it on the XP with mingw right now and will let you know if it works on my side.
  • edited November 2010
    I tried your small test and unfortunately it worked as expected on my computer (which, for info, is a Fujitsu under WinXP SP2 with a GeForce 6800).

    Every left click or space press have been registered and I got the HitMe log msg instantly.

    The only time I didn't get it is when you left click while space is still pressed (or vice versa), but it's normal as they are both mapped to the same input, so the input didn't have a new status. This is the expected behavior, of course.

    I saw you were using a user created clock and was hoping the problem would come from that, but unfortunately everything worked just fine.

    Can you try downloading orx's source and compiling it? If you launch it, it'll automatically load the demo plugin called Bounce, which is my playground when I develop for orx.

    Hitting space, enter, all 3 mouse buttons and tab should all be mapped to inputs with verbose status updates sent to the log.

    Space and left click both spawn balls, enter and right click both add a wobble effect to the object under the mouse cursor if there's one, middle click will trigger a custom shader on&off and tab is mapped to an input called Empty, which will only display a log, nothing else.

    Let me know if those work for you or not.
  • edited November 2010
    Wow, works for you. Dang. No wait that's good. Hmm.. the common denominator on these machines I have is that they are all unaccelerated HP's with intel hardware.

    I have another machine as home with WinXP and a nvidia card. I'll try it on there.

    I'll get the source down tonight you suggested and see what happens.
  • edited November 2010
    A good way of testing what's going on, I guess, would be to listen for the input events.
    In the event callback, when you receive an orxINPUT_EVENT_ON, it means the status has been changed and that the next time you'll hit your clock callback, the test should be true.

    If it's not, there's a big problem there.

    Ah wait, I may have a lead there. What is your displayed FPS? Are you running with VSync on or off?

    Here's what I think might arrive: if you're not using vsync and that your computer displays a lot of frames per second (over 100), the default clock will be ticked more than once between two ticks of your custom clock, which means more than one frame will be computed before your code get executed, hence the missing NewStatus.

    Here's the scenario:

    T0: User clock get ticked, nothing to do
    T1: New input is registered while core clock is ticked, frame F1 is computed
    T2: Core clock is ticked again, input status gets cleaned, frame F2 is computed
    ...
    TN: Your 100Hz clock gets ticked but there has been many frames computed since T0

    Using VSync will artificially fix this problem as your user clock has a higher frequency than your display rate. Another way to fix that would be to fix a Clock::MainClockFrequency that will make sure the main/core clock won run wild even if there's no display synchro, still a bit artificial.

    The best way to fix that would be on of those:
    - don't use a user clock for polling inputs, register your callback on the core clock (that can be retrieved with orxClock_FindFirst() function), this way your input code will always be in sync with the core clock. The clock concept is nice for time stretching or for spacing code intensive tasks like AI, but not good for inputs as we just found. I'll update the tutorials accordingly. =)
    - if you don't want to use the main clock, you can also use the events to listen to inputs, some people prefer to do it this way. Just be careful that you're in a callback called directly from the input module's update, so you might want to store this info for later use in your main loop.

    There's isn't an ideal fix as you can see, it's just that user clock really don't work with inputs if the user clock is slower than the main clock's real execution (using VSync will help also so that orx won't eat all the CPU for displaying thousand of frames for nothing! ;)).

    Let me know if this was your issue. I'll update the tutorials right away.

    PS: I was thinking of some trick to allow even this kind of user clock/input interaction to work, but that will come with other side effects such as stacked inputs.
  • edited November 2010
    sausage wrote:
    Wow, works for you. Dang. No wait that's good. Hmm.. the common denominator on these machines I have is that they are all unaccelerated HP's with intel hardware.

    I have another machine as home with WinXP and a nvidia card. I'll try it on there.

    I'll get the source down tonight you suggested and see what happens.

    Yep, sorry, I think I figured out what was going on, but it was at the same time I was writing a post, so it took extra time for my lengthy post to be sent.

    Btw, you can display the FPS by setting, in the config, Render::ShowFPS to true.
  • edited November 2010
    iarwain wrote:
    Ah wait, I may have a lead there. What is your displayed FPS? Are you running with VSync on or off?

    Here's what I think might arrive: if you're not using vsync and that your computer displays a lot of frames per second (over 100), the default clock will be ticked more than once between two ticks of your custom clock, which means more than one frame will be computed before your code get executed, hence the missing NewStatus.

    The spooky thing, I started to have the same suspicion as you right after I posted. The Windows notebook I am running has an LCD screen (of course) and so the FPS is over 700 and won't allow vsync.

    This makes sense, as the other Windows XP machines I tested with all have LCD monitors and won't vsync either.

    As you know, I reported that my linux machine at home was perfect (didn't have this issue), and it has an CRT monitor with a FPS of 60. So perhaps it has less to do with being on linux and more about crt monitor / vsync.

    Using the examples and pressing F11 to turn vsync on and off doesn't change the vsync like my linux box. I can switch between 60 and 700 FPS with f11 there. No LCD I've tried yet does that.

    I'll switch to your proposed method tonight. Thanks for all your time on this!
  • edited November 2010
    sausage wrote:
    iarwain wrote:The spooky thing, I started to have the same suspicion as you right after I posted. The Windows notebook I am running has an LCD screen (of course) and so the FPS is over 700 and won't allow vsync.

    This makes sense, as the other Windows XP machines I tested with all have LCD monitors and won't vsync either.

    As you know, I reported that my linux machine at home was perfect (didn't have this issue), and it has an CRT monitor with a FPS of 60. So perhaps it has less to do with being on linux and more about crt monitor / vsync.

    Using the examples and pressing F11 to turn vsync on and off doesn't change the vsync like my linux box. I can switch between 60 and 700 FPS with f11 there. No LCD I've tried yet does that.

    Ah weird, I can turn VSync on&off on all the LCDs I tried (including 3 different laptops). None of the computers I've run orx on have intel hardware for graphics card though (ATI & NVidia only). My guess is that intel's driver don't allow any VSync.

    Even if it's not technically a VSync on LCDs, the high level feature remains the same and is usually handled by your graphics card driver. ATI & NVidia drivers allow to force VSync on or off or to let the application decide. Maybe there's a similar option somewhere in intel's graphics drivers?
    I'll switch to your proposed method tonight. Thanks for all your time on this!

    My pleasure. Sorry for the inconvenience. The input module should be the only module with such restrictions regarding to clock synchronizations.
  • edited November 2010
    Got home and checked out 06_Sound.sh on Linux. With vsync on, it was perfect. Switched vsync off and the issue was there. Rebooted to Windows XP partition and tried the vs2005 binary there. Same.

    So it looks like the cause is pretty much nailed. I'll switch to the work around you mentioned earlier so that the game works if someone has vsync or off.

    I don't think that Intel GFX hardware is all that crash hot. I did find the Asynchronous on/off (Intel's version of vsync) but it doesn't make a difference. From what I've read, that's not surprising.

    Thanks for everything, much appreciated as always. Hope this helps improve things.
  • edited November 2010
    Thank you for confirming our suspicions.

    I updated all the tutorials on SVN yesterday night as well as the wiki.

    Good to know about Intel's hardware. You can try playing with the MainClockFrequency in the [Config] section to achieve a similar result (at least for our issue and for CPU use, not for actual video sync).

    Also, I sent you a PM about a week ago, not sure if you got it.
  • edited November 2010
    All working perfect in my project too. I converted my "keyup" code last night and it works great.

    A PM? Hey there's one there, sorry I didn't notice it. I'll go check it out.
Sign In or Register to comment.