Open Rubikoid opened 4 years ago
I've never played with FFB so I don't really know. I could imagine that sending things to vJoy it doesn't like or is somehow invalid causes a bad reaction in there and takes everything else with it. This happens quite regularly to me when working on the UI and feeding Qt something it doesn't like on the C++ side.
So, i have ffb wheel. Also, for checks i used the programm named WheelCheck, which can emulate some wheel ffb functions like spring.
Anyway, after few hours spent in google, i found that the easiest way to send ffb commands to physical device on windows is c# library "sharpdx.directinput". Also, vjoy has c# bindings that works fine, so entire .net library that deals with ffb maybe can solve the problem, but i'm not sure about how that solution fits into the gremlin architecture.
Sadly it doesn't fit at all with how Gremlin works. Interfacing with anything other than pure C libraries requires bindings, as such using C# libraries isn't really a possibility. I'm also not familiar with FFB so I'm not exactly clear on what functionality Gremlin would serve there, especially since Gremlin is very much designed to go from physical device to virtual devices and not the other way around.
Hi! This is only parlty relevant. For this two weeks, i wrote my own tool in c#, that for the most part solves this problem. It works not so good, but it works)
Also, some moments in my tool inspired by gremlin architecture, so thanks for that great programm.
Anyway, if i look now, i think that there will be many problems with ffb implementation in your project. At least python may not provide enough speed)
Adding FFB into Gremlin would likely be quite challenging. Feeding it to vJoy would be rather easy as that's just making sure the ctypes bindings are correct. The challenge would be to modify the input library to properly care about FFB stuff and if you want to pass effects back to the real device you'd need a new library or modify the one I wrote for input to be capable of sending FFB signals to the devices, and no idea what that involves.
The runtime speed difference between Python and C# or C++ for that matter likely isn't going to matter for any of these device-related applications. From when I last looked into this the computations are so trivial that they need millions of repetitions before being measurable and the delay is orders of magnitudes below the actual input system update rates making effectively imperceptible. If you were to go and do heavy computational things you'd definitely see differences but I haven't come across anything in these types of applications that needed that.
a new library or modify the one I wrote for input to be capable of sending FFB signals to the devices
This library should interact with directx and directinput some way, because it's the only way i know to send ffb to physical device. So, c# selected just because there was sharpdx bindings. Also ffb protocol is a very dark matter, which does not make the task easier.
Speed difference between python/c# and c++ that's another topic, so each language have advantages and disadvantages. In our case with ffb, no heavy math or calc needed, but you should handle every ffb packets as soon as you receive them, and python with GIL may case problems in this case.
FFB is DirectX standard. Just messing 2 hours with Gremlin and VJoy and now FFB don't work? Deleting...
FreePie FFB fork that can route this. It includes 15 commits: https://github.com/AndersMalmgren/FreePIE/compare/Ffb...MarijnS95:FreePIE:Ffb
FreePie FFB fork that can route this.
I'll check it, when my ffb setup will be available.
But i guess that FreePie will have the same problems as my rewrite of joymapper.
@Rubikoid Nice, I will look into your project. I currently spent a weekend till 4AM on this FreePie FFB branch. I made a fork here: https://github.com/cyberluke/FreePIE/tree/Ffb ...will update it soon. Already updated vJoy - same as you.
The crashes for me happen when I send wrong parameters to the underlying SlimDX library and then I get some DirectInput HRESULT error.
Other than that there is some kind of PacketMapper, which works async, so the latency is mostly around 30-80ms on Core2Quad (yes I'm retrogamer and will compile it even for Windows XP - dual boot)
Hello, i started writing ffb support, but encountered with very strange problem.
vJoy has a function, which registers an FFB callback. I written a little wrapper in my fork around it and tested feedback, but once the first ffb packet receives, entire app crashes without any information.
So, do you have any ideas, why this happens?