Short inputs can be dropped

[WAZAAAAA0]

If you press a button for less than 1 full frame, it can drop.

Tends to happen when you make the input logic of your program state-based (e.g. poll only once per frame) instead of event-driven afaik.
Easier to reproduce with 1000+ Hz USB polling rate I suppose.
Similar to this case: https://twitter.com/WAZAAAAA00/status/1258803470670409730
Padlight is the second program you see on screen, modded to run at high FPS (and in English), here's an archive if you need it for tests: https://www.mediafire.com/file/elmsg9uqq89kcry/padlight_archive.zip/file

DEMO:

InputDisplay.vs.padlight.input.drops.mp4

[lucasteles]

🤔 I need to investigate a way to do this in monogame.

I don't believe this can cause huge trouble tho

[Chinta03]

It happen a lot especially on a hitbox while performing Zangief's SPD. As shown in the screenshot below, I am missing the down input because that direction lasted for less than 1 frame. Here, I got unlucky that the polling didn't happen at the moment I was holding down. So the SPD fails

It happens in the InputDisplay app and should be the the intended behavior, as it replicate the input the game would register.
Worst case, the input in the game and from InputDisplay is different because of different polling timings. Syncing the game and the InputDisplay is probably out of scope of what that tool was intended for.

[WAZAAAAA0]

I don't know about "not a huge trouble" and "intended behavior"...

One reason someone would want to use an external input display tool is wanting a "second opinion". Like, "I swear I did the input right, lemme check my recording real quick..." but if said tool is inaccurate then it can't be used for that purpose

that picture alone doesn't really show anything though

[Chinta03]

Hey @WAZAAAAA0,

I mean, why do you want to display input that is not a reflection of what the game reads?

I understand that you want to know if you truly pressed that button at all, but realistically it's very difficult to press a button so shortly that it's not being registered. You have to purposely tap it as quickly as humanly possible, which isn't practical and not a common occurrence. And if you ever did tap this shortly, you will have to change your way of using the controller anyway, because what you want in the end is the game to read inputs you intended to do.

I would be curious however how often that ever happen to you and what's your setup that makes it such a common occurrence.

I do get my jump "eaten" in SF6 a lot when my opponent Drive Rush at the same time, but that's a game mechanic related issue, not so much the controller or the game not reading inputs.

I am pretty confident this would be out of the scope for what the tool is designed for.

[WAZAAAAA0]

why do you want to display input that is not a reflection of what the game reads?

But that's not the case either, it does not reflect what the game reads because they're 2 different programs polling inputs at different moments despite both running at 60 FPS. Here's as real world example: the first input is missed only by the game, the last input is missed only by InputDisplay

InputDisplay.vs.padlight.vs.DOA5LR.mp4

I would be curious however how often that ever happen to you and what's your setup that makes it such a common occurrence.

For the demonstration I did purposely tap as quickly as possible (on a 1000 Hz overclocked HitBox to decrease the input latency), but without a reliable input display tool we can never truly tell whether it's a "common occurrence" or not while playing normally.

[Chinta03]

Yeah, I think we're fairly confident this is a syncing issue between the game and the tool. I highly doubt that tool will ever be in sync with all games in existences or even the mainstream ones, it seems quite a complex thing to implement.