I've recently added support for DirectInput force feedback effects to my input framework (yeah, very 1998, but still cool to support). Everything works great, but the one annoyance is that there is no provision for loading an effects file (.ffe) from memory, which means that if you want to use the old SDK effects editor (I knew hoarding those old DXSDK CDs would pay off!), you will have to accept having loose .ffe files in your asset tree instead of tucked away in a pack file.

Now, obviously one could just do their own serialization and manually create the effects; the data structures involved are not complex. However, there is one other desirable behavior of EnumEffectsInFile that is specified via the DIFEF_MODIFYIFNEEDED flag, which "Instructs DirectInput to modify the authored effect, if necessary, so that it plays on the current device.". I'm interested to know what exactly it's doing under-the-covers, so that I might replicate that behavior if I go about doing my own serialization. There are somewhat obvious things, such as discarding invalid axes and what have you, but I'm interested to know if it's doing anything more advanced (modifications aside from discard). Anyone have any experience/knowledge of the inner workings?

The other tack I took on this was to see if there are any (win32) OS mechanisms to make a section of memory available as a "file" openable via normal file routines (sort of the inverse of a memory-mapped file), but I did not come across such a thing. Any thoughts on that idea? Obviously I could do a temp extraction, load, and deletion, but that is rather inelegant and inefficient.

You'd be surprised at the efficiency of creating some files in %TEMP%. The overhead is unlikely to be a problem in practice. Especially given that the idea is to have many effects in one file – so you already have a “pak” of effects.

Custom file systems on Windows is a right pain, full of undocumented magic and kernel nastiness. This is one reason why there aren't any good NFS clients, ext4 file system plugins, and so forth, for Windows.

True enough. Ultimately, adding any sort of OS file/memory shenanigans or temp file extraction kind of already outweighs the (simple) grossness of a few loose files. But it was an interesting area to explore nonetheless.

The real answer to “how do I force feedback in games” is of course “haptic input largely failed; nobody ended up using more than big and little spinner wheels in practice, so just use XInput" but if you enjoy the archaeology, then by all means, enjoy!

(That being said, I once had one of the “dinosaur turd” powered joysticks that could twang your hand in a bunch of directions – it's gotta have been more than 20 years ago!)

Indeed. My framework supports both XInput (vibration via my own “effects” specification/files) and DirectInput (more simply via .ffe files). Ultimately, it was a matter of adding it since it was easy enough to support, and there is still some desire/support in the simulation niche. I couldn't find more than a handful (2 or 3) of actual force feedback joysticks online…mostly, it's just re-sold Microsoft Sidewinder Force Feedback 2 joysticks. In fact, I had one from life at a previous studio sitting unopened in my closet, which halfway initiated this endeavor. I suspect there are probably some high-end joysticks and steering wheels out there that I missed. Frankly, I was surprised that DirectInput force feedback still worked on Windows 10, but sure enough I just plugged in the joystick and it was good-to-go, so kudos to Microsoft on that front.

The irony is that I'm actually not a big fan of rumble effects (or force feedback back in the day), but inevitably for me “I wonder how hard it would be to support this…” leads to doing it. ?