mirror of
https://github.com/libsdl-org/SDL.git
synced 2026-06-07 23:20:58 +00:00
8795ca7067
pj5085 I added some printf to verify the math being done. Of the three joysticks I have, it works correctly for at least two, and seems to work correctly for the third. I say "seems to" because, for the third joystick, the values never go through the AxisCorrect function, and thus never hit my printf statements, even though they did in the version I wrote my patch against. I'm not sure what's going on there, but it at least seems to be working correctly in as much as I can tell. I note this result in particular, for an SNES Gamepad (min=0, max=255): Joystick value 0 becomes -32768 Joystick value 127 becomes 0 Joystick value 255 becomes 32767 Without the code that forces a zero point, the 127 input value would become -129, so I think you see why I added that code to turn it into zero. However, I think Kai Krakow has a point about how SDL shouldn't assume that there should be a center. Obviously in the majority of cases there actually should be a center, and the code that turns that 127 into an actual 0 is creating only a 0.2% error over 0.4% of this joystick's range. However, what if there is an axis that is some kind of special control, like a 4-position switch, and, for whatever reason, the joystick reports it as an axis with 4 possible values, 0 to 3? In that case, mutilating the two center values to the same value is much more of an error and and turns that 4-position switch into a 3-position switch. If any joystick does this with a 2-position switch, then this code would render that control entirely useless as it would report the same value with the switch in either position. Obviously the code could require that there be at least N possible values, to guess whether something is a proper axis or just some kind of switch, but the choice of N would be arbitrary and that's ugly. I guess the real problem here is that my gamepad is just kind of broken. It should be reporting a range of -1 to +1 since that's what it actually does. Also, as Kai Krakow points out, it's probably not SDL's place to fix broken hardware. I'll add that, if SDL does fix broken hardware, it should probably actually know that it's broken rather than be merely guessing that it is. So, to the extent that SDL is able to do stuff like this, perhaps it's something better left for the user to configure in some kind of config file. |
||
|---|---|---|
| .. | ||
| atomic | ||
| audio | ||
| core | ||
| cpuinfo | ||
| dynapi | ||
| events | ||
| file | ||
| filesystem | ||
| haptic | ||
| hidapi | ||
| joystick | ||
| libm | ||
| loadso | ||
| locale | ||
| main | ||
| misc | ||
| power | ||
| render | ||
| sensor | ||
| stdlib | ||
| test | ||
| thread | ||
| timer | ||
| video | ||
| SDL.c | ||
| SDL_assert.c | ||
| SDL_assert_c.h | ||
| SDL_dataqueue.c | ||
| SDL_dataqueue.h | ||
| SDL_error.c | ||
| SDL_error_c.h | ||
| SDL_hints.c | ||
| SDL_hints_c.h | ||
| SDL_internal.h | ||
| SDL_log.c | ||