 |
I do not have any controller to test this with, so unless someone comes forward to see what happens, there's nothing that can be done, so I am putting this on hold. |
 |
Is this thread relevant at all? [Tutorial] Compiling the GZDoom source code with CMake I have a controller (wii u pro controller with a Mayflash wireless adapter) and am willing to help test any changes you want to make. |
 |
This Wiki article contains up-to-date information. You can ignore anything related to FMOD, OpenAL and DirectX SDK. To build GZDoom without sound/music support you need only Visual Studio 2015 (or 2017) and CMake. Something like: install VS and CMake, download source code from GitHub and unpack it, run CMake and select source directory, press Generate, Finish, Open Project buttons in CMake, press Debug button in Visual Studio. But first, one simple question: did you able to reproduce this issue using 2.4.0 x64? It works for me using wired Xbox 360 controller using 32- and 64-bit version. |
|
|
I was referring specifically to DaMan's post in that thread: DaMan wrote You might want to get a Windows7 user to test a Xbox controller. The Windows SDK only links to the Win8/10 Xinput14 or gimped Xinput91 (unless Zdoom reports battery life for wireless controlers don't think it affects anything). IIRC Zdoom is defining WIN32_WINNT as XP before including Xinput.h so it should be linking against the latter. I've got a 64-bit build setup and can confirm the issue in the original report. I tested it with 2.5pre G4f67DC4. Xinput controllers are being reported as DirectInput. Disabling DirectInput controllers will remove the controller from the list. I did download the 32-bit version of 2.4.0 and tested it there to find it worked perfectly. I'm going to add this info just in case it is relevant. My controller adapter has a switch on it to change from Xinput (1 controller only) to DirectInput (up to 4 controllers), and has its own drivers which haven't been updated in a while. |
|
|
Could you please check with 2.3.2 and maybe some earlier versions? To do something meaningful with this we need to now when it was broken. |
|
|
I think I've narrowed it down to this commit, which coincides with the discussion on the earlier linked topic. I tested eff03d13 (the commit right before it) and the controller showed up as 'Xinput Controller #1' with Xinput controllers enabled. With DirectInput enabled and Xinput disabled, it showed up as 'Controller (xbox 360 for windows)'. |
|
|
The commit you linked to was later reverted, so it should no longer be an issue. |
|
|
Can't say for sure but I think this issue is somehow related to toolkit being used. Graf, did you use Windows XP compatibility toolkit for 2.4.0 release, 32- and 64-bit both? |
|
|
32 bit is built with XP toolset, 64 bit with modern toolset. So, this sounds like something in the modern toolset is not working correctly. Of course, just forcing the old toolset is not a solution, as sooner or later XP support will be removed, so whatever causes the problem needs to be found. |
 |
Just to let you know. I've also tested in 2.3.2, both 32 and 64 bits builds. They detected Xinput controllers correctly. So the issue is with the 64-bit build on the current version, as the 32-bit build has no issues when it comes to Xinput controllers. |
|
|
The problem is with XINPUT_DLL preprocessor definition: its value is xinput1_3.dll for legacy toolkit (DirectX SDK to be precise) and xinput9_1_0.dll for modern one (Windows 7 SDK that came with Visual Studio). Apparently there are some issues with the latter DLL. Should we hardcode name of working one to fix this bug? |
|
|
If that works it's at least an option. |
|
|
Fixed in b6774e7 |
|
|
Just tested the new commit on a 64-bit build. It seems to work just fine now. |
- Anonymous
