Duke4.net Forums: [RELEASE] EDuke32 with proper XInput support and a few bugfixes - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

[RELEASE] EDuke32 with proper XInput support and a few bugfixes

User is offline   aybe0 

#1

 
Here's my contribution to the project, a patched version with proper support for XInput (Xbox One Controller) and a little more. So next time you'll try to play Duke with your favorite controller, it won't act crazily as it previously did.

I am a bit stumped in regards to the joystick support within the game, are the devs unaware of such issues ??? Anyway, it is fixed now and I hope you will enjoy it :D

Here's the list of the other things I've addressed in the mean time:

  • All supported devices is now the default choice, you don't have to explicitly set it every time
  • the joystick axes are read directly from the official API, but the rest (buttons) is left to SDL (i.e. no functionality has been lost)
  • thumbsticks are smoothed out using cubic interpolation, i.e. you have more precision when aiming
  • ranges have been pre-adjusted, giving in-game scale option finer granularity
  • last but not least, eduke32.cfg contains only what you've mapped (no more recurrent default bindings after setting them explicitly to None for the billion-th time)


TL;DR version : EDuke32 with decent support for XInput devices !

Download link at GitHub (see release tab at top)

Notes:
  • this is open source as you've seen, anyone can see/improve it, the SVN history is in the repository, should be easy to keep this up to date with the official version
  • tested against a Xbox One Controller, not sure for a Xbox 360 Controller !
  • take a look at the README, I've attached a default configuration, you can navigate in the menus with the D-Pad but since few things have been hard-coded in the game, accept/cancel buttons won't necessarily be A/B buttons; also there's no binding in-game to raise the menu (use the keyboard)
  • the patch is aware of 'auto-run mode' but make sure to press Caps Lock so you can walk/run from the gamepad
  • you should keep default settings for deadzone (0%) and saturation (1%) for all axes


Drop a line to tell how it worked on your side :blink:

This post has been edited by aybe0: 24 April 2016 - 08:09 PM

7

User is offline   Lunick 

#2

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.
0

User is offline   Danukem 

  • Duke Plus Developer

#3

Good work! This is indeed an improvement in several ways :D

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.
0

User is offline   Lunick 

#4

View PostTrooper Dan, on 25 April 2016 - 02:14 AM, said:

Good work! This is indeed an improvement in several ways :D

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.


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
0

#5

Great job getting that working! *EDITED* see below.

As a side note, its great to see another person doing engineering work on EDuke32!

This post has been edited by icecoldduke: 25 April 2016 - 05:59 AM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #6

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.

View Posticecoldduke, on 25 April 2016 - 05:07 AM, said:

If you are ok with it, I would like to potentially use the rest of your code in PolymerNG, since taking a quick glance you have everything hooked through EDuke32's button system.

Don't. It would only mean more work for you to rip the patches back out before we merge.
0

#7

View PostHendricks266, 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.

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 :D.

This post has been edited by icecoldduke: 25 April 2016 - 05:57 AM

0

User is offline   aybe0 

#8

View PostLunick, 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 :yucky:


View PostTrooper Dan, on 25 April 2016 - 02:14 AM, said:

Good work! This is indeed an improvement in several ways :nuke:

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 :D 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.


View PostLunick, 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.


View Posticecoldduke, 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 :D

View PostHendricks266, 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.


View Posticecoldduke, 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 :blink:.


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.
0

#9

View Postaybe0, on 25 April 2016 - 08:35 AM, said:

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.

It seems like you have done all the hard work already. Can you put in some effort just to port the system layer of your code from Xinput to SDL? I haven't looked at your code extensively enough to know how well its coded, but I think that would be a great start to get your code into main. I hope you can appreciate the need for everyone to use one unified code base. Having a fractured codebase is never a good idea, and as Duke4 adds more features to EDuke32 your repository won't get the updates unless you plan on keeping your repository up to date.

This post has been edited by icecoldduke: 25 April 2016 - 08:58 AM

0

User is offline   Danukem 

  • Duke Plus Developer

#10

View PostLunick, 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.


Ironically, I wasn't having that problem. The problem I had is exactly as stated -- the changes worked fine but after I restarted the game they reverted. Again, this was only on the input scale settings for axis 3 and axis 4.

Anyway, this is encouraging and I hope it results in the controller issues finally getting addressed in the main branch. It has been neglected for a long, long time.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options