supertuxkart / stk-code

The code base of supertuxkart
Other
4.54k stars 1.06k forks source link

Keep track of input state while game is paused #1021

Closed supertuxkart-sourceforge-migration closed 7 months ago

supertuxkart-sourceforge-migration commented 10 years ago

Author: btdavis

Currently, the player controller resets all inputs (that is, it considers all buttons to be "not pressed") after a pause. However, it is sometimes natural to keep a button held down as the game unpauses, in particular the accelerate key.

The attached diff makes changes such that the player controller always receives actions while in game mode, but buffers those actions during a pause. Then after the pause, instead of resetting, the controller is updated and any relevant actions are performed (and only the most recent input state is used, to prevent spamming/accidentally triggering actions).

Migrated-From: https://sourceforge.net/apps/trac/supertuxkart/ticket/965 ( attachements can be found at http://supertuxkart.sourceforge.net/TracFilesBackup/965 )

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria I am sorry for the late answer. Will try to take a look before 0.8.1 is released

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Hi,

sorry for the delay, we've been quite busy.

Some comments :

1) You do not appear to buffer "axis direction", this means that your code will likely only work correctly for buttons, not for axes

2) You moved a large chunk of code that used to be inside if (action_found) { } out of this if. You then duplicated the call to 'translateInput', but you missed many other mappings, like mapping arrows, space, return. First, code duplication should be avoided, so ideally translateInput should be called only once. Second, your code will not handle properly the "factory" values of arrows, enter, spacebar, since your duplicated code does not apply the fallbacks for those keys

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Actually sorry, I take back my comment on axis direction : you are mapping actions, not raw input. So please discard point 1. Point 2 still holds however

I also wonder though, we have logic for axes that prevent having values in both up and down of the same axis. I think your code bypasses that logical and can end up in problematic states if the player moves an axis very fast

supertuxkart-sourceforge-migration commented 10 years ago

Author: auria Postponing this for now; the patch unfortunately does not quite work in the current state (does not compile, and after perfoming the seemingly obvious fix I could not get it to do what it should have done). I did not have time to further debug this. Since this is not strictly required for 0.8.1, just postponing

hiker commented 10 years ago

Postponing.

Alayan-stk-2 commented 7 months ago

For many inputs, it is irrelevant to not keep the button pressed when resuming after a pause : nitro, powerup...

For others, namely acceleration and turning left or right, it is really easy to correct after getting out of pause, with negligible losses.

Drifting is the only exception, as pause interrupts the drift. However, in online play pauses don't interrupt the game, so the issue of interrupted drifting only really exists in local play... But in single player, it's also very easy to just wait a second or two before pressing the pause button.

So the only meaningful use case for such a change would be splitscreen multiplayer, when one player suddenly pauses while the other is drifting. This is a very limited situation, and even then the impact is very minor. For reference, I did a test and with 10 scheduled pause at specific times, I lost a total of 3 seconds from interrupted drifts compared to no pause. That's around 0.3s / pause on average, some more, some less.

If this minor discrepancy bothers some players, it is simple enough to not pause... If two players playing together in splitscreen are concerned about the other pausing abusively, the game trying to make resuming afterwards fairer should not be their first concern either.