JeroMiya
commented
9 years ago I'm working on this, though if you have guidance on the design that would be great. I noticed your comment on the C++ issue and I agree. I started out with an implementation which just adds: the PInvoke methods to the C interface; A set of get*State methods in Interface taking ref parameters for timestamp and the state struct; and a set of slightly easier to use properties with getters that just return the value.
As you suggest in the C++ issue, a better implementation would be a set of classes - one per state type. Each class would have an extension method on Interface to return an instance of that type of state value, and a property with a getter that either returned a cached value (updated with a corresponding Update method), or whose getter gets the value every time. Finally, the state classes should all implement a common interface that is generic on the state type.
Do you have a preference for built-in caching vs calling into the native code every time? We can also do a hybrid approach: the state class may have a method that calls the native function every time and a property that returns a cached value.
If it helps, Microsoft decided to go with the "call native methods every time" route with XNA's keyboard/mouse/gamepad state APIs, but they used methods instead of properties to hint that the calls might be expensive (e.g. Keyboard.GetState(), Mouse.GetState()).
ClientKit includes state interfaces (grabbing the data recent as of the last update call) but these aren't wrapped yet - partially because this wrapper was based on the C++ wrapper and we hadn't finalized a good model for representing state access in the C++ wrapper at time of writing (or yet, actually, but at least with C++ we can easily fall back to the C interface).
Lack of this is resulting in re-implementation (effectively) of this capability in managed code, and the potentially performance overhead of redundant callbacks into managed code from native.