Lunick, on 24 April 2016 - 10:35 PM, said:
Works a charm, the default mappings in the EDuke32.cfg provided are a bit weird but can be easily fixed. Aiming control was inverted so to remedy that you have to invert the mouse aiming controls.
(EDuke32 starts with Button 0 for some reason but in Windows that means Button 1)
Button 0 ( A ) = Jump
Button 1 ( B ) = Inventory
Button 2 ( X ) = Open
Button 3 ( Y ) = Crouch
Button 4 ( LB ) = Previous Weapon
Button 5 ( RB ) = Next Weapon
Button 6 ( Back ) = Map
Button 7 ( Start ) = ??? (Not sure if I can bind this to the menu)
Button 8 ( Left Stick Press ) = Toggle Autorun
Button 9 ( Right Stick Press ) = ???
Dpad:
Hat O Up = ???
Hat O Right = Inventory Right
Hat O Left = Inventory Left
Hat O Down = ???
If I could suggest something, left trigger should be Quick Kick.
Well, that was a personal preference to put the emphasis on using thumbsticks, i.e. a COD-like approach resulting in rarely using A, B, X, Y buttons ... See that configuration as a 'sample' and adjust it to your personal preferences
Trooper Dan, on 25 April 2016 - 02:14 AM, said:
Good work! This is indeed an improvement in several ways
I did find one bug: My settings for input scale on Axis 3 and Axis 4 (looking and turning on my setup) do not save. All the other controller settings that I use do save, but not those. It's annoying because the default is 50%, which is way too slow for me. I didn't use use your setup, I just did my own from scratch on a 360 controller (mostly because I'm using a mod with some different controls anyway).
As Lunick said, aiming is inverted as compared with the mouse. Ideally, those should be separate settings, but if they are not then they should at least be consistent.
Aside from the aforementioned bugs, the big shortcoming with setting up a controller on EDuke32 is that there is no display showing what button you are pressing. We have to guess which button on a particular controller is button 0, or button 5, etc., which is a process of trial and error.
Oh, and another thing -- EDuke32 does not register the fat trigger buttons on my 360 (it only registers the skinnier trigger buttons above them). This is true in the main branch as well.
Thank you, as I've mentioned in the README it seems that assigning digital buttons to triggers are only effective after a restart; honestly I haven't tried to find the cause in the source code as soon as it worked. Regarding the axes I'm not sure what's happening on your side, here I can adjust their scales and they are properly saved
I've also swapped my XB1 controller with a X360 and it worked exactly the same way without any changes. And for the inverted axis, yes, I've deliberately inverted it and I agree this should be a user preference by setting the scale to -1.0 in the menu, this can be fixed very easily by simply negating the value
in this line of code.
Lunick, on 25 April 2016 - 02:30 AM, said:
If you change a setting in the Axis menu, you have to restart EDuke32 for the changes to take affect for some reason. I was able to map Quick Kick that way.
As for the trigger buttons not working on your 360 controller, that's pretty strange since they worked fine with my 360 Afterglow controller. They are known as Axis 5 and 6 in the EDuke32 menu I believe
Yes, restarting the game fix that issue but I haven't really tracked the cause as I said previously.
icecoldduke, on 25 April 2016 - 05:07 AM, said:
Great job getting that working! *EDITED* see below.
As a side note, its great to see another person doing engineering work on EDuke32!
Thank you
Hendricks266, on 25 April 2016 - 05:39 AM, said:
These patches are not any good.
"Using all available devices instead."
You've changed the default value, sure, but there is some kind of bug in our startup window code that prevents this setting from being remembered in the cfg, and that is the real problem.
"Fixed crazy XINPUT axes by using the official API instead of SDL"
No! SDL provides a wrapper around XInput using the newer Game Controller API. For a while we had separate code paths just for Windows (see winlayer.c and rawinput.c) but using SDL has lifted that burden from us. If SDL's functionality turns out to not work well enough, then we can look at XInput, but even if we do, we're going to need to do it in a way that works with MinGW-GCC, not just MSVC.
"Fixed recurrent assignment of default bindings for joystick axes/buttons."
Hmm. I agree that the game binding the default options over None is a bug, but I don't agree that completely abolishing default bindings is the fix. Besides that, using a preprocessor token here is completely the wrong approach to making this an option. I'm also not sure why changing the space indentations of these lines to tab stops is part of this commit.
Don't. It would only mean more work for you to rip the patches back out before we merge.
Yes, deciding this was a compromise, but since now the axes don't act crazy it ends up being transparent if the user would use keyboard/mouse instead.
I guess For sure you have a better understanding of the code base than I do, you know there are deficiencies in the current design, I've seen them and haven't tried to address them, i.e. people are probably better off sitting down and devise some solution before one rushes to code.
icecoldduke, on 25 April 2016 - 05:53 AM, said:
Understood then I will hold off. Aybe0 I hope you don't get discouraged by Hendrick's comments, even though he comes off very angry, a lot of his points are valid. Can you work with him and TX to fix there concerns, and get your stuff into the main branch? I would prefer a correct and final solution to the controller problem, so I can ditch my controller code.
I also failed to realize that SDL had proper controller support, and I grabbed Windows::Gaming::Input code from DirectxTK, and he yelled at me for it too. I was getting lonely being on Hendrick's shit list all by myself, glad I'm in good company
.
This patch is the result of a C novice sitting down for an afternoon trying to see if he could easily fix that XInput issue so he could enjoy DN3D with his gamepad, it did the trick even though it could be perfected, but at least DN3D is enjoyable with a XInput device.
Of course this is not multi-platform-friendly code, nor it pretends to be ever merged with the main branch or
put whatever here hence why I just forked and provided binaries for end-users. At least people doing a web search for
'eduke32 xinput' don't end up with solutions like
"use Xpadder, Joy2Key or whatever", they can simply have their DN3D fix with their XInput controller without having to use another piece of software such as those and retain the analog feeling of thumbsticks.