Welcome to the ZDoom Forums!

I realized I had a crappy wireless USB controller laying around so went and added the button mapping (and POV hat support). Is it intentional the the menu move up/down is assigned to joystick axis 1 (x) and left right assigned to joystick axis 2 (y) for generic joysticks?

Also, I should note that in regards to button mapping all axes. From what I can tell ZDoom only support mapping 8 axes due to the limitation in DirectInput. On Linux there is no problem with having a much larger number of axes. (IIRC the PS3 controller has 24.) That said, besides the sixaxis motion axes (which are the final 4), the others are all button mapped in the driver since they're just the individual button's pressure sensitivity.

I have an XBox 360 Controller. For the best parallel with Windows, every axis also needs to generate button events.

As for referencing the Windows code, you should probably be looking at the XInput code instead of DirectInput. The DirectInput version is rather complicated, since it needs to work with completely generic input devices, whereas the XInput code is short and to-the-point.

Do you have such a controller on hand? The only joystick I have that matches that description is my PS3 Sixaxis/Dual Shock 3 controllers, but on Linux the button mapping is already done for those controllers.

I suppose I could make due with button mapping the analog sticks, but I notice the direct input code makes an exception for the first one or something like that.

[quote="Blzut3"]the direct input code on Windows has some kind of Axis to button mapping code that I'm not entirely sure if that needs to be ported.[/quote]
It should be. Controllers these days commonly have two trigger buttons that are analog axes, so if you don't do axis to button mapping, you can't use them as buttons.

For some reason I thought that would be more work than it was... Anyways, fixed. One thing to note is that the direct input code on Windows has some kind of Axis to button mapping code that I'm not entirely sure if that needs to be ported.

Looking at the relevent Windows code this is not the proper way to handle the Dead Zones. The Windows code has a ProcessInput() function which is called from I_StartFrame. The negation of the dead zone should be handled by Joy_RemoveDeadZone().

Index: src/sdl/i_joystick.cpp
===================================================================
--- src/sdl/i_joystick.cpp	(revision 3386)
+++ src/sdl/i_joystick.cpp	(working copy)
@@ -118,7 +118,13 @@
 		for (int i = 0; i < GetNumAxes(); ++i)
 		{
 			if(Axes[i].GameAxis != JOYAXIS_None)
-				axes[Axes[i].GameAxis] -= float(((double)SDL_JoystickGetAxis(Device, i)/32768.0) * Multiplier * Axes[i].Multiplier);
+			{
+				const float axisValue = SDL_JoystickGetAxis( Device, i ) / 32768.0f * Multiplier * Axes[i].Multiplier;
+				if ( fabsf( axisValue ) > Axes[i].DeadZone )
+				{
+					axes[Axes[i].GameAxis] -= axisValue;
+				}
+			}
 		}
 	}

In SDL-based builds joystick deadzone settings are not taken into account when setting axes values.
This issue can be fixed with a small change, here is a patch:

[code]
Index: src/sdl/i_joystick.cpp
===================================================================
--- src/sdl/i_joystick.cpp (revision 3386)
+++ src/sdl/i_joystick.cpp (working copy)
@@ -118,7 +118,13 @@
for (int i = 0; i < GetNumAxes(); ++i)
{
if(Axes[i].GameAxis != JOYAXIS_None)
- axes[Axes[i].GameAxis] -= float(((double)SDL_JoystickGetAxis(Device, i)/32768.0) * Multiplier * Axes[i].Multiplier);
+ {
+ const float axisValue = SDL_JoystickGetAxis( Device, i ) / 32768.0f * Multiplier * Axes[i].Multiplier;
+ if ( fabsf( axisValue ) > Axes[i].DeadZone )
+ {
+ axes[Axes[i].GameAxis] -= axisValue;
+ }
+ }
}
}
[/code]
Tested on Mac OS X but will work on all SDL-based target platform.