Gamepad and Keyboard difference of input... Why?

0 favourites
  • 5 posts
From the Asset Store
Total customisation of the input! You can combine inputs from all peripherals. Make your game accessible for everyone!
  • So, I have this problem where my jumps go higher on a gamepad, even though I made the controls universal (at least I thought so.)

    The values on the image below reflect the "Player.Platform.VectorY" values, and there's a clear difference that I can't find why it exists.

    The file I'm using for this test is below.

    Gamepad_Keyboard.c3p

    Any feedback is appreciated.

    Cheers.

    EDIT: I updated the file to be more concise.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Yeah, this is odd. My guess is that keyboard and gamepad "On pressed" events trigger at different stages in a tick. Perhaps the keyboard event triggers earlier, before the Platform behavior makes its vector calculations. So the event sets vectorY to -400, then the behavior reduces it by gravity value. So at the end of the tick the vector value is already reduced to something like -370.

    In case of gamepad, the behavior updates the vector first, then the "On A pressed" event sets vectorY to -400, which remains -400 until the end of the tick. That's why the sprite jumps higher.

    Player.Platform.VectorY returns -400 in both cases, but from my experience you can't trust vectorX/vectorY expressions, they often return wrong (not actual) values. See this bug report for example:

    github.com/Scirra/Construct-bugs/issues/6323

    Three objects move at different speeds, by vectorX returns the same value for all of them..

  • Your issue helped me to understand the Vectors a lot better! I'm extremely glad you mentioned it.

    But still, now I'm faced with this strange difference of Gamepad VS Keyboard that I never thought was to be an issue.

    Can you think of any workaround? I've been frying my brain trying to get a more succint approach, but the only "reasonable" solution was to get input directly from JavaScript, which is not great, but... I can't think of anything else.

    Still, I really appreciate the feedback, thanks.

  • In "On key/button pressed" event you can set a variable jump_start to 1.

    Then add another top-level event:

    jump_start=1 
    ... Platform set vector
    ... Set jump_hold to Jump_Hold_Strength
    ... set jump_start to 0
    
    

    This should fix the issue!

  • f***, why didn't I think of that. I gonna say I'm tired to not say I'm stupid lol.

    Flawless fix, thanks!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)