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

[<trent@xxxxxxxxxx>]

Ok, ya I think it def. needs to compile with the real DX SDK and MinGW. I
don't have much time right now, wrapping up a game this week or next, don't
really have time for my own patch either. Will test anything you need me to
though.

-----Original Message-----
From: beoran@xxxxxxxxxx [mailto:beoran@xxxxxxxxxx] 
Sent: August 9, 2014 1:05 PM
To: Allegro Development
Subject: Re: [AD] The huge Windows force feedback patch.

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/libxinp
ut.a
allegro_LIB_DEPENDS:STATIC=general;kernel32;general;user32;general;gdi32;gen
eral;comdlg32;general;ole32;general;winmm;general;psapi;general;shlwapi;gene
ral;C:/Windows/System32/d3d9.dll;general;C:/opt/msys64/mingw64/x86_64-w64-mi
ngw32/lib/libxinput.a;general;C:/Windows/System32/dinput8.dll;general;glu32;
general;opengl32;general;C:/opt/msys64/mingw64/x86_64-w64-mingw32/lib/libd3d
x9.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
>

----------------------------------------------------------------------------
--
--
https://lists.sourceforge.net/lists/listinfo/alleg-developers