Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
I did this because I wanted to fly around maps using a Spaceball 4000FLX, or any other 6DOF controller. These fixes help it work. Various fixes to joystick support: - joyaxiscallback() used strtol() to check to see if the supplied string was an integer, then didn't assign the parsed integer to the cvar. - Wrong multiplier for left/turnleft values. - Delete `axismap[]` from J_JoystickAxis(). It was causing problems, and smells like it was trying to do what the cvars joyadvaxis[xyzruv] are doing now. - Fix compiler error by adding case statements for: SDL_SENSOR_ACCEL_L SDL_SENSOR_ACCEL_R SDL_SENSOR_GYRO_L SDL_SENSOR_GYRO_R New cvar: "joyonly". "Joystick" axes are typically return-to-center affairs; their deflection values are therefore reported as -MAX - MAX, with zero in the center. "Game controllers" are similar, but also often have analog left and right "triggers" which are reported as 0 - MAX, with zero at one end (fully released to fully depressed). Unfortunately, SDL will try its darndest to make a joystick look like a "game controller." It does this by reinterpreting certain of the axes to report the range 0 - MAX, as if they were triggers. This is not a thing to do with 6DOF controllers, where all axes are return-to-center. While it may be remotely possible to put together an SDL2 controller mapping that reports -MAX - MAX on all axes, for me it was simpler to hack on FTEQW. Coupled with that is FTEQW's giving preference to "game controllers," i.e. if SDL_IsGameController() returns true, FTEQW will treat it as one. "joyonly" is a boolean cvar. If true, FTE will ignore "game controllers" and treat everything as a joystick. The default is false. "joyonly" must be set at startup to be effective, when the controllers are being enumerated by SDL.
- Loading branch information