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

[<trent@xxxxxxxxxx>]

I'd like to apply the patch, but there's still one thing that's not really
clear to me. When I switch my joystick to DirectInput mode, why is the
button layout different after the patch? Apologize if you already answered
this.

-----Original Message-----
From: beoran@xxxxxxxxxx [mailto:beoran@xxxxxxxxxx] 
Sent: August 11, 2014 2:00 AM
To: Allegro Development
Subject: Re: [AD] The huge Windows force feedback patch.

That was caused by the "shadowing" and by ex_joystick_event which had a bug
where it would show presses from different joystics as if they came from
the active one.

The "shadowing" should now be fixed with the fixes I pushed to that pull
request & patch, and same for ex_joystick_event. I'd be surprised if you
still saw it with the lastest version of my patch.

For people who use Allegro's joysticks the important point to keep in mind
that even before this patch, you had and still have have to use the .id flag
of the joystick event combined with al_get_joystick() to make sure you
correctly interpret from which joystick the events are coming from.

Also, in case you really need XInput devices to stay as they were, it's
possible to disable the XInput driver at compile time using cmake
-DWANT_XINPUT=no. This will also disable the XInput filter in Directinput
devices and the force feedback for them, but it apart from the directinput
force feedback driver, all should be as it was before the patch with that
flag.

Kind Regards,

B.


On 8/11/14, trent@xxxxxxxxxx <trent@xxxxxxxxxx> wrote:
> What about the multiple buttons being signalled when you press 1 
> button on the joystick? Isn't that a compatibility issue?
>
> -----Original Message-----
> From: beoran@xxxxxxxxxx [mailto:beoran@xxxxxxxxxx]
> Sent: August 10, 2014 8:03 PM
> To: Allegro Development
> Subject: Re: [AD] The huge Windows force feedback patch.
>
> Dear Trent,
>
> Thanks for taking time to check my patch. The layout of the joystick 
> should stay the same EXCEPT for XInput devices which now get the 
> XInput layout. I consider it as a functional improvement that they now 
> get the correct XInput layout, and that the two triggers show up as 
> analog slider axes and not as buttons like they would under 
> DirectInput. In this case only the poatch is not perfectly backwards 
> compatible but we can't have our cake and eat it too.
>
> I was playing around a bit with ex_joystick_events, mostly in an 
> attempt to make the button names more legible, etc. If you don't like 
> those changes I'll just revert to Allegro's current ex_joystick_events 
> later on, it's not essential to this patch.
>
> Kind Regards,
> B.
>
> On 8/11/14, trent@xxxxxxxxxx <trent@xxxxxxxxxx> wrote:
>> Thanks for doing that. Before I can say anything else I need to read 
>> the full patch and test it out some more, which might be a while. As 
>> long as the joysticks work the same as before, ie in the most common 
>> case where the user has 1 joystick, and the game is recompiled with 
>> this patch, the button mappings are all the same, then it should be 
>> fine. However, your updates to ex_joystick_events although they look 
>> better don't suit every joystick, do they?
>>
>> Thanks.
>>
>> -----Original Message-----
>> From: beoran@xxxxxxxxxx [mailto:beoran@xxxxxxxxxx]
>> Sent: August 10, 2014 7:31 PM
>> To: Allegro Development
>> Subject: Re: [AD] The huge Windows force feedback patch.
>>
>> Dear Trent,
>>
>> I understand your concern, so I spend most of the day looking for a 
>> solution.
>>
>> I looked into a better way to filter the XInput devices from 
>> DirectInput and with some inspiration from SDL and a lot of testing, 
>> I was able to make it work both on MinGW and on MSys2.
>>
>> This better way requires only user32.dll and windows.h, no special 
>> headers, and compiles fine on MinGW. Only requirement is that you use
> Windows XP.
>> For
>> some reason the DirectInput driver still supported Windows 95, but I 
>> had to upgrade to use GetRawDeviceList() on which the filtering 
>> method is based. I don't think that that is any problem, since 
>> Allegro 5 doesn't support windows 95 for other things such as audio
anymore anyway.
>>
>> With this better filtering method there should be no "gotchas" left 
>> with compiling and using Allegro on MinGW with this patch, and the 
>> rest of Allegro should keep working as it was.
>>
>> Finally, months of hard work went into this patch and while there 
>> might be some bugs left in it, he best way to get these fixed is by 
>> getting people to test it more widely.
>>
>> Kind Regards,
>>
>> B.
>>
>> On 8/10/14, Trent Gamblin <trent@xxxxxxxxxx> wrote:
>>> If the patch has this many gotchas I won't be applying it. The 
>>> entire rest of Allegro works perfectly with MinGW, there's no sense 
>>> in IMO destroying that for haptics, so find.better ways to do these
things.
>>>
>>> ---- beoran@xxxxxxxxxx wrote ----
>>>
>>>>OK, I pushed some more commits to the same pull request.
>>>>
>>>>What they do is
>>>>1) fix ex_joystick_events
>>>>2) Detect sal.h and include it only if found1.
>>>>3) Detect wbemidl.h for use by the filtering snippet. If ound, 
>>>>enable the snippet, if not disable it. For various reasons, mingw 
>>>>can't compile the filtering stippet (I said it was horrible), but
>>>>msys2/mingw64 can. That's why I was forced to conditionally compile 
>>>>it like this.
>>>>4) Some various minor bugs.
>>>>
>>>>https://github.com/liballeg/allegro5/pull/8.patch
>>>>
>>>>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