Re: dinput: Convert keyboard buffer from internal data format to user data format
Sergey Khodych wrote:
Any particular reason for this? Do you have a program that sets different data format? The reason I ask - copying 256 bytes is much faster then iterating over the whole data format and copying one byte at a time. Vitaliy.
A possibility of using custom data format, for any type of devices, is described in DirectX SDK documentation. For example Monolith's F.E.A.R. use this method.
Any particular reason for this? Do you have a program that sets different data format? The reason I ask - copying 256 bytes is much faster then iterating over the whole data format and copying one byte at a time.
Vitaliy.
Sergey Khodych wrote:
Any particular reason for this? Do you have a program that sets different data format? The reason I ask - copying 256 bytes is much faster then iterating over the whole data format and copying one byte at a time.
A possibility of using custom data format, for any type of devices, is described in DirectX SDK documentation. For example Monolith's F.E.A.R. use this method.
That is not what I asked. If you read MSDN it tells lots of things that are not true. Also I do not recall seeing any problems with FEAR game that were related dinput. If you have that bug handle please point me to it. Vitaliy.
Vitaliy Margolen wrote:
Sergey Khodych wrote:
Any particular reason for this? Do you have a program that sets different data format? The reason I ask - copying 256 bytes is much faster then iterating over the whole data format and copying one byte at a time.
A possibility of using custom data format, for any type of devices, is described in DirectX SDK documentation. For example Monolith's F.E.A.R. use this method.
That is not what I asked. If you read MSDN it tells lots of things that are not true. Also I do not recall seeing any problems with FEAR game that were related dinput. If you have that bug handle please point me to it.
To reply to myself. I've missed the fact that if the requested format is the same as Wine's internal format it will be a simple memcpy. I did not want to penalize most dinput applications that just use default keyboard format (array of 256 bytes). Sergey, please resend this patch. It might resolve few keyboard problems applications having with Wine. At least I hope it might. Vitaliy.
To reply to myself. I've missed the fact that if the requested format is the same as Wine's internal format it will be a simple memcpy. I did not want to penalize most dinput applications that just use default keyboard format (array of 256 bytes).
What do you think about using common buffer for all types of devices and translating a new event direct to user's data format? In this case we just copy buffer of base device.
Sergey Khodych wrote:
To reply to myself. I've missed the fact that if the requested format is the same as Wine's internal format it will be a simple memcpy. I did not want to penalize most dinput applications that just use default keyboard format (array of 256 bytes).
What do you think about using common buffer for all types of devices and translating a new event direct to user's data format? In this case we just copy buffer of base device.
It's hard to find something common for say keyboard and joystick. Former have lots of only buttons while later can have lots of axes and only few buttons. So still have to use some specialized data buffer. Or you mean to use user data format internally? That will still require some mapping - from indexes to offset & size. But that gets really messy and still requires conversion (which we are doing anyway). Unless everything will be changed in one go. However when I'm thinking about it - it will require extra work while doing object enumeration. For a time being (during the code freeze) I'd prefer not to change any core functions. Vitaliy.
participants (2)
-
Sergey Khodych -
Vitaliy Margolen