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.

ggrs/src/frame_info.rs

Lines 56 to 61 in 0af1a04

	pub(crate) fn blank_input(frame: Frame) -> Self {
	Self {
	frame,
	input: I::zeroed(),
	}
	}

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:

ggrs/src/frame_info.rs

Lines 28 to 35 in 0af1a04

	pub(crate) struct PlayerInput<I>
	where
	I: Copy
	+ Clone
	+ PartialEq
	+ bytemuck::NoUninit
	+ bytemuck::CheckedBitPattern
	+ bytemuck::Zeroable,

[gschup]

#82 changed the trait bounds on inputs, so this issue should be a thing of the past.