[DirectInput] The current semantics of GetBufferedData() is unable to replicate native functionality

[GoogleCodeExporter]

SlimDX (June 2010)

The semantics of the GetBufferedData() method seems to be a bit different from 
Managed DirectX, since it returns a list of buffered device states, instead of 
a list of device 'object' changes.

This makes it impossible to reproduce native functionality of identifying which 
device object (e.g. axis) has effectively changed with buffered input.

To illustrate the difference, in the Joystick class, the GetBufferedData() 
method returns a list of 'JoystickState', however the JoystickState class does 
not by itself indicate which actions have changed, nor does it provide a 
uniform polymorphic way of identifying an action.

Using JoystickState, if I want to access axis X, I would use the 'X' property, 
but if I want a slider, I have to use GetSliders() and index the array 
appropriately, etc.

In Managed DirectX, I merely needed to store the 'Offset' of the device object, 
for instance I would store 4 corresponding to axis Y, and each 'BufferedData' 
object from GetBufferedData() would indicate both the value of the object and 
its offset, so I could know for each device change the corresponding concrete 
action.

Unfortunately, the abstract CustomDevice<TDataFormat> is incompatible with the 
original semantics, since GetCurrentState() and GetBufferedData() use different 
underlying return types.

GetBufferedData() should return a list of BufferedData structure including 
original DirectX semantics, such as Offset, Timestamp, etc.

This also makes it more difficult to build a custom action mapper 
implementation, such as the one presented for MDX in 
http://www.codeproject.com/Articles/37446/Direct-Input-Custom-Action-Mapping-ref
resh.aspx

Original issue reported on code.google.com by goncaloc...@gmail.com on 4 Jul 2010 at 4:06

[GoogleCodeExporter]

N.B. that maintaining comparability with Managed DirectX is not something we 
are interested in pursuing at all; but you do have a point concerning the 
ability to reproduce a native call sequence.

Original comment by josh.petrie on 5 Jul 2010 at 2:52

[GoogleCodeExporter]

Fixed in r2079.

Original comment by Mike.Popoloski on 9 Jun 2011 at 3:57

[GoogleCodeExporter]

Original comment by Mike.Popoloski on 9 Jun 2011 at 3:57

• Changed state: Fixed