Open 0x098 opened 2 years ago
I fixed FreePie and vJoy for FFB, it is here: https://github.com/cyberluke/FreePIE/tree/Ffb
Youtube video about usage and steps for installation in description: https://www.youtube.com/watch?v=pIR5bgpmE7E
Developer info: I have added new vJoy interface based on nzj3 (pull request has not been accepted). The current nzj3 vJoy C++ API is using nested pointers and that has a very big performance impact in language such as C#. Therefore I have added a second, alternative, function calls as well without nested C++ pointers.
Now it works much faster in FreePIE. In my FreePIE branch, there is vJoy and SlimDX (Device class) implementations that are reading FFB data, parsing FFB data, recalculating and correcting FFB data and finally routing these data to a real DirectX FFB device.
My vJoy fork: https://github.com/cyberluke/vJoy
can it also read ffb from self and register self? i just need the data in my freepie as numbers
vJoy[0].registerFfbDevice(vJoy[0])
also that freepie version is a bit funky
I don't understand what you try to achieve. Can you please describe it more? Yes, the Freepie is a little bit outdated, but works. I spent two months fixing only FFB bugs in three libraries and solving five year old bugs nobody care about. My time is limited, so I will try help here, if I can.
Here are exposed bindings from vJoy to be used in FreePie script: https://github.com/cyberluke/FreePIE/blob/Ffb/FreePIE.Core.Plugins/VJoyPlugin.cs
You can find registerFfbDevice there as well.
What I would do: 1) add my new custom logic in VJoyGlobalHolder or any other VJoy class 2) add method to call VJoyGlobalHolder in VJoyPlugin.cs, so it can be used in FreePIE script
But reading FFB happens in a specific circular buffer on a background thread, it is very latency sensitive, otherwise you start loosing FFB packets and latency increases.
The main use case here was to route all FFB data to some other DirectInput device and then read from that device.
Here are all VJoy files: https://github.com/cyberluke/FreePIE/tree/Ffb/FreePIE.Core.Plugins/VJoy
Here is PacketMapper. You can write your own packet mapper and it will call these methods when FFB packet comes: https://github.com/cyberluke/FreePIE/blob/Ffb/FreePIE.Core.Plugins/VJoy/PacketMapper.cs
Here is background packet manager which queues packets and you could change it, so you could read queued packets when YOU want: https://github.com/cyberluke/FreePIE/blob/Ffb/FreePIE.Core.Plugins/VJoy/BackgroundActionRunner.cs
Otherwise you cannot read FFB packets when you want. They will not wait for you. The C++ FFB callback is a blocking call, you must not do any processing there, you can only enqueue the packet to the background thread and process it there. The FFB protocol has not been designed for heavy processing or OOP class design "memory bloat".
Based on your first post, the easiest thing might be to extend BackgroundActionRunner.cs and add a configurable feature to send it over a network (messaging queue or OSC protocol would be a prefered high level protocol for that). I would recommend UDP over TCP.
Then if you download the binary release here, it contains my FreePie script for G940 FFB: https://github.com/cyberluke/FreePIE/releases ...you could just leave the vJoy[0].registerFfbDevice() call, so the FFB packet logic gets activated and you could run this FreePie script from a console without GUI. (Freepie test package has some freepie.console.exe file)
How it works: 1) vJoy C++ library gets FFB from game 2) FreePie vJoy plugin reads in memory C++ buffer 3) Parses packet header only, enqueues for a background thread and quickly returns from the C++ callback 4) Each packet is reconstructed in C# managed class on a background and based on a packet type, PacketMapper will route it to a specific class and method call in async 5) This final method is https://github.com/cyberluke/FreePIE/blob/Ffb/FreePIE.Core.Plugins/Dx/Device.cs - it will properly recreate FFB with proper parameters. Sometimes the packet might come in a wrong order, so this class takes care of that. Some parameters come in a wrong unit (ms instead of ns, so we have to multiply by 1000).
So beware that DirectInput FFB parameters have different format than vJoy FFB. Often vJoy receives FFB data as a DirectInput device, but you cannot resend these data to another DirectInput data, because vJoy parses them into its own format. I had to parse all these parameters and fix them, so it can be re-send to another DirectInput device using pure DirectX 8.0 interface.
============= FFB Packet =============
> Device ID: 1
> Effect Block Index: 1
> Packet Type: Condition Report
>> X Axis
>> Center Point Offset: -1241
>> Positive Coefficient: 9900
>> Negative Coefficient: 9900
>> Positive Saturation: 10000
>> Negative Saturation: 10000
>> Dead Band: 0
FFB Size 23 Cmd:000B000F ID:B000F Size:15 - 13 01 00 27 FB AC 26 AC 26 10 27 10 27 00 00
======================================
============= FFB Packet =============
> Device ID: 1
> Effect Block Index: 1
> Packet Type: Condition Report
>> Y Axis
>> Center Point Offset: -1669
>> Positive Coefficient: 9900
>> Negative Coefficient: 9900
>> Positive Saturation: 10000
>> Negative Saturation: 10000
>> Dead Band: 0
FFB Size 23 Cmd:000B000F ID:B000F Size:15 - 13 01 01 7B F9 AC 26 AC 26 10 27 10 27 00 00
======================================
============= FFB Packet =============
> Device ID: 1
> Effect Block Index: 1
> Packet Type: Effect Report
FFB Size 26 Cmd:000B000F ID:B000F Size:18 - 11 01 08 FF FF 00 00 00 00 FF FF 04 3F 00 00 00 00 00
======================================
@cyberluke I got some data dump from DCS world AH-64D flyying data. But I can't explain some data. Can you tell me what is "Positive Coefficient" "Negative Coefficient" "Positive Saturation" "Negative Saturation" and what is the data "11 01 08 FF FF 00 00 00 00 FF FF 04 3F 00 00 00 00 00". It show repeat,and unchange.
@cyberluke: thanks for your many corrections in vJoyInterface. I can merge your changes on the current master of my fork if you are ok.
For what it's worth, I was able to write an application for force feedback (in C++, not C#) with basically no issues. Just some types need to be converted to signed (apps\FFBMon
shows which ones).
im super fresh around these grounds because i need to get force feedback from the driver - the amount and towards where to it(the game) wants to feedback.
im using FreePIE to do my funky stuff and there clearly isnt a vjoy[num].getforcefeedback or .currentffb
OR is it possible to relay these over local net with tcpcomms over a certain port?
OR is all of this not possible and i need to get funky with this project? (it would be really great to get it over to freepie)