Re: [AD] The huge Windows force feedback patch.

[<beoran@xxxxxxxxxx>]

Well I just tried to cross-compile on linux using mingw and it works fine.

I see that at least on Linux, even the older mingw has the xinput.h
header. Is it the same on windows? I think with Mingw we have to
compile with gcc against mingw's headers (which are not hacked, but
open source clones from the wine project), and then link against Mingw
stub libraries that load the real DirectX SDL's dlls.

To solve the compilation problem for now, I think either moving the
DirectX SDK where gcc can't find it, and/or setting the
XINPUT_INCLUDE_DIR and XINPUT_LIBRARY options of cmake should enable
you to compile. Below's the relevant part of my CMakeCache for msys
, I assume it should look similar on Mingw.

grep -i XINPUT CMakeCache.txt
//Windows XInput support header
XINPUT_INCLUDE_DIR:PATH=C:/opt/msys64/mingw64/x86_64-w64-mingw32/include
//Windows XInput support library
XINPUT_LIBRARY:FILEPATH=C:/opt/msys64/mingw64/x86_64-w64-mingw32/lib/libxinput.a
allegro_LIB_DEPENDS:STATIC=general;kernel32;general;user32;general;gdi32;general;comdlg32;general;ole32;general;winmm;general;psapi;general;shlwapi;general;C:/Windows/System32/d3d9.dll;general;C:/opt/msys64/mingw64/x86_64-w64-mingw32/lib/libxinput.a;general;C:/Windows/System32/dinput8.dll;general;glu32;general;opengl32;general;C:/opt/msys64/mingw64/x86_64-w64-mingw32/lib/libd3dx9.a;

But I agree that the definitive solution for the older mingw will
probably need some CMake trickery to detect a situation like yours and
avoid it. I'll install mingw in my windows VM and investigate, but you
might actually find the solution before I do... Sorry for the
inconvenience!

Kind Regards,

B.



On 8/9/14, Trent Gamblin <trent@xxxxxxxxxx> wrote:
> If this can't be compiled with the standard MinGW installation then I
> suggest it should be disabled or detect what's being used.
>
> I can't use Allegro's hack DirectX files because you need
> to redistribute the hack d3dx dll which is illegal, you have to distribute
> part of the official DX sdk which doesn't work with Allegro's hack dx
> files.
>
> ----- Original Message -----
> From: <beoran@xxxxxxxxxx>
> To: "Allegro Development" <alleg-developers@xxxxxxxxxx>
> Sent: Saturday, August 09, 2014 12:32 PM
> Subject: Re: [AD] The huge Windows force feedback patch.
>
>
>> What is happening is that __in is one of Microsoft's nonstandard "SAL"
>> "annotation" macros that annotate the use of every function parameter
>> and make it hard to compile it with anything else but MSVC.
>>
>> Are you compiling with msys2 and have the Microsoft DirectX
>> development SDK installed? Then it won't compile. Nowadays msys2 has
>> it's own DirectX headers and libraries, and the ones of the Microsoft
>> actually don't work at all.
>>
>> If you don't use msys2 but an older mingw, then you also have to use
>> "cleaned up" header files provided by Allegro. Its possible that the
>> xinput.h header file your compiler finds is in stead the "unclean" one
>> with the SAL headers still present. If you are compiling with GCC you
>> will definietly need cleaned up version of XInput.h.
>>
>> Kind Regards,
>>
>> B.
>>
>>
>>
>> On 8/9/14, Trent Gamblin <trent@xxxxxxxxxx> wrote:
>>> I'd like to try to filter out the shadows, but first, I can't seem to
>>> compile with this patch. I get a bunch of errors the same as this:
>>>
>>> [ 18%] Building C object CMakeFiles/allegro.dir/src/win/whapxi.c.obj
>>> In file included from C:\Documents and Settings\Trent
>>> Gamblin\code\allegro\src\win\whapxi.c:55:0:
>>> C:/Program Files/Microsoft DirectX SDK (June
>>> 2010)/Include/xinput.h:231:5:
>>> error: unknown type name '__in'
>>>      __in  DWORD         dwUserIndex,  // Index of the gamer associated
>>> with
>>>
>>> the device
>>>      ^
>>>
>>> Googling a little suggests maybe sal.h needs to be included? Ok, I tried
>>> installing the platform SDK but for some reason it doesn't have sal.h (I
>>> swear it usually does!) Compiling on XP.
>>>
>>> ----- Original Message -----
>>> From: <beoran@xxxxxxxxxx>
>>> To: "Allegro Development" <alleg-developers@xxxxxxxxxx>
>>> Sent: Saturday, August 09, 2014 12:16 PM
>>> Subject: Re: [AD] The huge Windows force feedback patch.
>>>
>>>
>>>> Yes, the names are different. XInput API supports no names so XInput
>>>> Joysticks are named XInput Joystick 0, 1, 2 or 3. Also, XInput
>>>> joysticks are always listed first before their "shadows".
>>>>
>>>> For example this is what I get with ex_haptic with a F710 and a Strike
>>>> 2 connected:
>>>>
>>>> Joystick XInput Joystick 0 supports force feedback.
>>>> Joystick Controller (Wireless Gamepad F710) does not support force
>>>> feedback.
>>>> Joystick   USB  Joystick   supports force feedback.
>>>>
>>>> The DirectInput "shadow" works just as well as a joystick, apart from
>>>> the fact that it cannot support force feedback. If the end user of an
>>>> Allegro game accidentally chooses the "wrong" joystick then this has
>>>> no effect on their ability to play the game.
>>>>
>>>> Also, if this really bothers you, there is a configuration setting
>>>> [joystick] driver = which can be set to xinput or directinput to
>>>> disable the wrapper driver and only use one of the two drivers
>>>> exclusively.
>>>>
>>>> The reason why I needed this "shadowing" is because AFAICS there is no
>>>> way in either the DirectInput API to see if a joystick really is an
>>>> XInput one, or in the XInput API, which DirectInput device corresponds
>>>> to the XInput joystick. It might be possible though a different API to
>>>> find out about this, so I could filter out the "shadows" but SDL does
>>>> something I don't understand, so that's why I opted for the simplest
>>>> solution. If you'd really like me to filter out those "shadows", then
>>>> I'll need some help with that.
>>>>
>>>> Kind Regards,
>>>>
>>>> B.
>>>>
>>>> On 8/9/14, Trent Gamblin <trent@xxxxxxxxxx> wrote:
>>>>> How do the joysticks show up as "shadows", Logitech F710 (DirectInput)
>>>>> and
>>>>> Logitech F710 (XInput) or something like that? Otherwise that's quite
>>>>> annoying to me.
>>>>>
>>>>> ----- Original Message -----
>>>>> From: <beoran@xxxxxxxxxx>
>>>>> To: "Allegro Development" <Alleg-developers@xxxxxxxxxx>
>>>>> Sent: Saturday, August 09, 2014 11:38 AM
>>>>> Subject: [AD] The huge Windows force feedback patch.
>>>>>
>>>>>
>>>>>> Get it here:
>>>>>>
>>>>>> https://github.com/liballeg/allegro5/pull/8
>>>>>> https://github.com/liballeg/allegro5/pull/8.patch
>>>>>>
>>>>>> It is a huge patch because it covers a lot of ground.
>>>>>>
>>>>>> The situation of joystics and force feedback on Windows is complex.
>>>>>> There are several input and force feedback APIs for Windows.
>>>>>> Amongst those DirectInput and XInput are most useful.
>>>>>>
>>>>>> DirectInput, alhough it has been declared legacy by Microsoft has
>>>>>> the best support for force feedback though a very complex
>>>>>> and quirky API. But it works reasonably well for older joysticks
>>>>>> and joypads that have a DirectInput compatible driver.
>>>>>>
>>>>>> XInput, supposedly the successor to DirectInput is a much simpler
>>>>>> API, but also far less powerful. It is only compatible with newer
>>>>>> joysticks and joypads that emulate the XBox's controllers.
>>>>>> XInput devices are "backwards compatible" with DirectInput
>>>>>> but that compatibility is limited invarious ways. For example,
>>>>>> the only way to get force feedback on XInput devices is through
>>>>>> the XInput API.
>>>>>>
>>>>>> Furtermore, older devices generally don't have an XInput driver
>>>>>> available.  Some newer joypads such as those of Logitech have a
>>>>>> switch to  set them to DirectInput or XInput mode. All in all
>>>>>> this means that both API's must be supported simultaneously
>>>>>> on Windows.
>>>>>>
>>>>>> To deal with all that I have implemented an haptics driver for
>>>>>> DirectInput, a joystick and haptics driver for XInput, and then
>>>>>> a "wrapper" driver that enables both drivers to be used
>>>>>> simulaneously. The only downside of the wrapper is that
>>>>>> for some devices, the same  device may show up twice
>>>>>> as a "shadow" of itself if it is  supported by both API's.
>>>>>> However, since a game should let the user choose their joystick,
>>>>>> I think this  is not really a problem.
>>>>>>
>>>>>> This patch includes an uncrustify.cfg I used to adjust the
>>>>>> style of what I had programmed. I added it because I feel
>>>>>> uncrustify is more powerful and effective than indent, and
>>>>>> the uncrustify configuration will be generally useful.
>>>>>>
>>>>>> This patch has been compiled and tested versus Mingw on
>>>>>> linux and wine, and in with msys2 a Windows VM. Therefore
>>>>>> it's still needed that someone tests it with MSVC,
>>>>>> I was not able to get it to install on the VM.
>>>>>>
>>>>>> Finally I'd like to thank Tomasu for providing me with a Logitech
>>>>>> F710
>>>>>> to thoughoughly test XInput with.
>>>>>>
>>>>>> Kind Regards,
>>>>>>
>>>>>> B.
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> --
>>>>>> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> --
>>>>> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> --
>>>> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> --
>>> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>>>
>>
>> ------------------------------------------------------------------------------
>> --
>> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>>
>
>
> ------------------------------------------------------------------------------
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>