Inputs being missed

[AntonReinhard]

When a key is pressed for less than a full frame (in between two frames) it can be missed by the input display. It would be nice to still see the input for the frame after the key was pressed.

In speedrunning (what I and many others use this for) that happens quite a lot and prevents you from going back in the recording to see what actually happened when some inputs didn't show up.

[joao-mambelli]

From what I remember when messing within the code, it refreshes every 50 ms...

Idk if it’s possible to update the window as soon as a key is pressed instead of every fixed delay... if it was possible, that would be the ideal solution.

If not, a setting could be added to let the user choose this delay

[AntonReinhard]

That might help, but it would still at least be limited by the refresh rate of the monitor used. That's why I was suggesting just showing otherwise missed inputs on the next frame. I hope that makes sense.

[joao-mambelli]

Another thing you might consider is the fps of the recording you are making... if you are recording at 120fps, but your monitor is 144hz, you might not see some inputs in the recording that you see while recording...

I think the solution would be you select in the settings the fps of your recording, so the app know the minimum it should hold a key being pressed on screen

[kynowoo]

@Rubydrag0n
I released a version that key pressing is shown for 40 ms at least so that inputs would not be missed if the fps is more than 30.
(The release excludes the keyboard settings, and you have to copy the configure of yours into the folder.)

@joao7yt
I hope this feature can be set and unset with a configure, but I'm a newbie in the C# language and poor at English. I would be glad if the feature can be merged (or put?) into the software.

[AntonReinhard]

That's definitely really cool you did that!
Problem might just be that it's a fixed amount of time (40ms) now. So when I press a key in a 60fps game for <1 frame, so <16.6ms, nohboard will show the press for 40ms which will be 2-3 frames in the recording if I record in 60fps. But maybe that could be fixed with a setting telling nobhoard what framerate you intend to use? So that instead of showing an input for at least 40ms it's shown for at least 1/fps.

[joao-mambelli]

I think i will try to implement it at home later

[captain-majid]

I can confirm this also, the last typing of '2' is not detected by Noh, but displayed in the Run box:
https://youtu.be/xhaawHdxvQ4

I hope someone can ping me when this issue is fixed.

[ThoNohT]

Should be implemented in 38301a4 and 7f90f81.

This adds a setting allowing you to choose how long to show every (keyboard and mouse) key for at a minimum. Maybe the settings for the keyboard and mouse should be split up, I'm not sure. Please let me know.

Can be tested here: https://ci.appveyor.com/project/ThoNohT/nohboard/builds/31963205/artifacts

[joao-mambelli]

Working fine.

[ThoNohT]

So, I tested what you did in #104.

There's still a couple problems:

1. It's still possible to hit a key fast enough that NohBoard won't even detect the event...

2. Imagine you have a macro that will press a certain key every 30 ms, with this new setting set to, > let's say 34 ms, which is the required to every key hit to appear in a 30 fps recording, the key will appear to be held, and not spammed...

---

1. It's still possible to hit a key fast enough that NohBoard won't even detect the event...

If at this point, NohBoard doesn't detect it, it probably never even got the message. Because right now, once it gets the keydown message, it will definitely hold it until the timeout (given that the timeout is longer than the render delay of 33ms). If it never got that keydown message, there's nothing I can change about it.

2. Imagine you have a macro that will press a certain key every 30 ms, with this new setting set to, let's say 34 ms, which is the required to every key hit to appear in a 30 fps recording, the key will appear to be held, and not spammed...

That's true, but unavoidable. I mean I could force it to blink off for a short moment, but if that's too short for your capture software, it's going to still look like a continuously pressed button. If it's too long, it'll look like it is always off, or erratically blinking.

And I guess, since NohBoard never updates faster than once every 33 ms, it really physically is unable to show anything between those moments. So if the delay is shorter than that, and the key is pressed and released entirely within one period of 33ms, it will not be shown.

---

This can be prevented though. I could even add a setting that keeps a key pressed until it has been rendered at least once. Then at least every key will appear at least once. But then never shorter than 33ms.

However, this does flip the problem around. If the key is released and re-pressed within those 33 ms, it will never be rendered as loose because NohBoard has to do at least one render with it pressed, and by the next frame, it is pressed again.

And finally, this gives no guarantees about capturing software, because I don't know what framerates they use, so NohBoard might still be rendering it too short or too long for it to pick it up, or for it to pick up the release. And that's also why I didn't go this route. There will always have to be concessions when looking at this high speed stuff and all NohBoard can do is a best effort and make an error either on the side of showing too much or too little. This setting basically allows you to tune that.

---

Input history would provide a solution to this all, I am aware. But I don't have the time to work on that at this moment. But I will keep it in mind for future projects, and we can continue that discussion in #111.

[joao-mambelli]

Regarding the first problem: how does NohBoard get the events? Does it compares the current frame keys statuses with the previous one or does it hook the pressed keys? I would guess it compares, because logically if it's hooked, then it wouldn't rely on refresh rate, right?

[ThoNohT]

No it uses a low level keyboard and mouse hook. So every input that it gets there will be registered.

But if it detects the key being pressed and release before a frame can be rendered, it will have detected it but just not rendered it. That's how it depends on the refresh rate.

[joao-mambelli]

So NohBoard detects a fast pressed key. The solution would be to check if the key is pressed and released in a same frame, if so, consider it as pressed for that frame and released in the next frame. Right?

[ThoNohT]

That is a solution, which I also described in my long reply above. Which has similar issues.

[joao-mambelli]

Okay, then only the history element would solve this... But could you also add a setting where you could change the frame rate of nohboard?

[ThoNohT]

I could. But I'm kind of afraid to add it. NohBoard doesn't do the most efficient rendering, so upping the frame rate might cause some performance issues, which might not be desirable while gaming.

I'm thinking I might add the setting, but not add it to the interface, so someone who knows what he is doing can always change it in the settings file.

[joao-mambelli]

I agree with that decision.

[ThoNohT]

eafcac2 makes the update (and render) interval configurable. 5ms or 200fps is the maximum, my pc seemed to handle this pretty well. Please give this a go, and see if it now captures all of your keypresses.

https://ci.appveyor.com/project/ThoNohT/nohboard/builds/32018731/artifacts

[joao-mambelli]

Working just fine.