Timeline for Correctly handling input in case of frame drop
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 13 at 10:07 | comment | added | pan | @Job_September_2020 It is. I can't add another tag (limit appears to be 5). But my problem is irrelevant to the language used. | |
| Jul 13 at 8:10 | comment | added | Job_September_2020 | Is it C language ? Can you add the "C" tag if this is C langue ? | |
| Jul 13 at 6:07 | history | edited | pan | CC BY-SA 4.0 | added 2067 characters in body |
| Jul 11 at 13:50 | comment | added | DMGregory♦ | If you were guaranteed one input check between each update tick, that would make sense, but here you can have multiple update ticks after a single call to input(), so even if the key "should" have been pressed in both time intervals, you're not giving your game an opportunity to detect that. The logic is a little different for persistent state (like a mouse position, analog stick deflection, or held button) versus a discrete event (like a button press / release / tap), but again, we'd need to see your movement logic to give you specific guidance. It would help to use actual code, not psuedo. | |
| Jul 11 at 11:45 | history | edited | pan | CC BY-SA 4.0 | change misleading pseudocode |
| Jul 11 at 11:11 | comment | added | pan | @DMGregory For inputs I have counters. When the player presses a key, I increment the appropriate counter. Every iteration in the update loop decrements each counter (unless it was zero) after updating the state accordingly. Is that implementation wrong? Should I do it another way? | |
| Jul 11 at 10:57 | comment | added | DMGregory♦ | It looks to me like when the renderer takes a long time, you run multiple update_state() calls to "catch up". That means you should still be applying the right amount of movement: in 2 frames' worth of time, I get 2 moves. If that's not what you observe, you may be incorrectly clearing your input state between update calls, so held buttons get treated like they were not held for the second and subsequent updates in each frame. Try showing the code that actually translates the input state into movement for more specific troubleshooting of those parts. | |
| S Jul 11 at 8:43 | review | First questions | |||
| Jul 15 at 8:30 | |||||
| S Jul 11 at 8:43 | history | asked | pan | CC BY-SA 4.0 |