Default predicted input on first frame (zeroed Input) assumes zeroed is equivalent to no movement

[MaxCWhitehead]

Describe the bug When GGRS provides a predicted input for a client with no previous inputs on session startup, it uses a zeroed value of PlayerInput. https://github.com/gschup/ggrs/blob/0af1a044b96465bd10398947b7fb5e0a34a75f70/src/frame_info.rs#L56-L61

If the user provided input type does not represent no input when zeroed, this seemed to sometimes lead to desync on session start. Not 100% sure if it actually makes sense that this should've caused desync though, perhaps should have been rolled back on remote once actual input was replicated.

We were representing movement input between [-1.0, 1.0] quantized to integer such that 0 bits represented -1.0 movement and ran into this issue. Changing representation such that zeored represents 0.0 or no movement on axis resolved the issue.

Expected behavior It might be beneficial to document this assumption on ggrs::Config::Input. Another option is to require Default trait and use this for blank input.

[red15]

Would it not just make sense that you implement the Zeroable trait correctly for your type that will set your axis value to it's relevant neutral (or Zero) value instead ?

It is after all defined in the required traits for PlayerInput: https://github.com/gschup/ggrs/blob/0af1a044b96465bd10398947b7fb5e0a34a75f70/src/frame_info.rs#L28-L35