SetPressed release key/button timeout

[CyberVillain]

Today the setPressed code in FreePIE just waits one script cycle until is releases a pressed key. This means that with the default FreePIE speed it will be held down for 16 ms (64hz clock speed). If you overclock FreePIE this could be as low as 1ms or even lower if you use the new micro second timer in 1.9. The game could then entirely miss that the key was pressed.

I'm thinking of changing this so that the setPressed code instead waits until a certain time has elapsed. I was thinking of setting this value to 16ms since that's the default with the old code.

Do you think that is a good value or should we wait a little longer? Some games render at 60hz and that mean they could miss the key press if we keep it pressed for 16ms (64hz)

[HarvesteR]

This would be a very good addition, IMO. Perhaps take an arbitrary timeout in a new overload to setPressed? (the default being 16)

My PWM axis malarkey script would definitely benefit from being able to tweak the length of a key event.

Cheers

[CyberVillain]

Strange thing is that I could not repoduce the problem, even with the script running at 10 000 hz i could not get it to miss a key press. But I guess it would be more correct if the pressed interal is based on time rather than iterations

[HarvesteR]

I reckon a lot or (most, probably) game engines must queue input API events to sync them with the main game thread.... that would make this issue moot, but there must be the inevitable case out there where this doesn't happen.

One situation I had problems with out-of-sync data was in a script I wrote to grab data off spacenavigator devices and feed them to vJoy. The precision of the axes seemed to be directly affected by the thread interval (found a happy place at 32ms), so either the 3dconnexion drivers or vjoy must have a thread unsafe update loop...

Either way, that case falls outside the scope of this feature... but serves as an example of the inevitable case where all reasonable assumptions fail.

Cheers