After running Super Model 3 games with force feedback, it breaks force feedback on other emulators

[ericharbison]

I've been setting up multiple racing games for a racing cabinet. I noticed sometimes forcefeedback stopped working after playing certain games, then launching other games. After trying a bunch of scenarios, I have determined that running a game like Sega Rally 2 (Super Model 3), then trying to run Sega Rally 1 or Sega Rally 3, force feedback wont work. Emergency Room Ambulance also breaks other emulators after running it.

[Yardl3y]

Funny, I was about to post about a similar issue. I don't remember this happening with Model 3, I'd have to double check. But this happens with MAME, I've been dealing with it for years. The problem is exactly as you described, FFB will completely stop working for other games/emulators after starting and exiting a MAME game. It doesn't always happen but it happens pretty frequently. The only fix I know off is to restart my PC.

If there is a lingering process or other dependency that can be terminated through a script on game exit that would be great.

[ericharbison]

Funny, I was about to post about a similar issue. I don't remember this happening with Model 3, I'd have to double check. But this happens with MAME, I've been dealing with it for years. The problem is exactly as you described, FFB will completely stop working for other games/emulators after starting and exiting a MAME game. It doesn't always happen but it happens pretty frequently. The only fix I know off is to restart my PC.

If there is a lingering process or other dependency that can be terminated through a script on game exit that would be great.

That was my first thought too. What can I kill after existing the emulator to keep force feedback working. I haven't figured it out yet. I have bigbox setup and even created a batch file to launch supermodel 3 and was going to kill the process on exit, but can't figure out which process needs to get killed. For now I reboot my PC.

[ericharbison]

I took a look at the code. Looks like SuperModel 3 and MAME use the same code in the FFB plugin. I haven't setup FFB in MAME yet, but will probably experience the same issue you were seeing with MAME too. Going to see if I can fix the exit code in the FFB plugin.

[Yardl3y]

Nice, I didn't think to do that. Let me know if you figure something out!

[ericharbison]

I think I figured it out. I changed the exit code in MAMESupermodel.cpp to this:

static int __stdcall ExitHook(UINT uExitCode) { //TerminateProcess(GetCurrentProcess(), 0); MH_DisableHook(MH_ALL_HOOKS); Sleep(1300); ExitProcess(0); return 0; }

I need to do more testing, but so far I haven't had any issues. I don't know if the sleep is needed. If I can verify this for a few days I'll recommend the code change to the devs. It seems like the TerminalProcess was causing the issue. The M2 emulator was was doing an ExitProcess(0), so I tried that. It only worked half the time, but was better. Then I added the MH_DisableHook(MH_ALL_HOOKS); and Sleep before exiting process, and now it seems to work all the time and I've had zero issues launching games on different emulators. I've tried launching different games after launching SuperModel 3 Games about a dozen times now and it just works.

EDIT:

I did find an issue that I will need to investigate. If I run The same or different SuperModel 3 games twice in a row it breaks other emulators like before. If I Run a SuperModel 3 only one time and a different emulator it works every time.

[ericharbison]

I think I need to give up. I seems like it has something to do with not freeing the MAME.dll library on exit or possibly something else on exit. I can't get it to be consistent.

Doing this seems to work sometimes, but then it wont work.

static int __stdcall ExitHook(UINT uExitCode) { FreeLibrary(ProcDLL); TerminateProcess(GetCurrentProcess(), 0); return 0; }

[Yardl3y]

Good effort man, maybe you'll get it eventually. Unfortunately Boomslangnz isn't working on this plugin anymore.

[ericharbison]

I think I have it officially working. In the MAMESupermodel.cpp file I changed:

First I moved the HWND hWnd; outside of the WinMain() function so that I could access it later.

In the FFBLoop() function I changed:

Original:

if (StopConstant == 255) { MotionFalse = true; }

New:

if (StopConstant == 255) { MotionFalse = true; triggers->Constant(constants->DIRECTION_FROM_LEFT, 0); triggers->Constant(constants->DIRECTION_FROM_RIGHT, 0); StopConstant = 0; PostQuitMessage(0); CloseWindow(hWnd); FreeLibrary(ProcDLL); return; }

These are the main things that fix this:

PostQuitMessage(0); CloseWindow(hWnd); FreeLibrary(ProcDLL);

I noticed that the WndProc WN_DESTROY is never called, so I'm doing the PostQuitMessage(0), then I call the CloseWindow which seems to destroy the MAME.dll Window that was created earlier for the MAME.dll file. Finally I destroy the MAME.dll connection.

I left the ExitHook the same:

static int __stdcall ExitHook(UINT uExitCode) { TerminateProcess(GetCurrentProcess(), 0); return 0; }

I have been playing different games, sometimes multiple times with exiting and then playing other emulators and it seems to just work now.

[Yardl3y]

Nice! Can you post the entire script you’re using? I can test it thoroughly to see if it works for me. This should fix the issues with MAME too!

[ericharbison]

Let me do a little more testing first on different machines.

[ericharbison]

I found some oddities on another machine. This code listed below seemed to do better.

if (StopConstant == 255) { MotionFalse = true; triggers->Constant(constants->DIRECTION_FROM_LEFT, 0); triggers->Constant(constants->DIRECTION_FROM_RIGHT, 0); StopConstant = 0; TerminateProcess(hEdit, 0); PostQuitMessage(0); CloseWindow(hWnd); return; }

But while testing I discovered something new. At least for SuperModel, When I copy in the files and overwrite the old ones (opengl32.dll, MAME64.dll, and SDL2.dll). opengl32.dll is the updated file that I've been making changes to. When I do this, it seems to reset the issues. If I restart my machine and try to play games again, its broken again because I didn't overwrite the files. So now I'm wondering if I just rename these files and name them back again on Exiting SuperModel or MAME, that might just fix the issue. I'll have to do some testing, but it's getting late. This would be a hack, but at this point I don't care. I'll put some code on exit to rename the files and name them back again to see if that fixes it. If not I can share a batch script that can do this on exit.

I'll try to get something for you to test on your machine in the next few day. :)

[ericharbison]

I don't think renaming the files does anything. When I have some time I want to see if I can fix the WndProc destroy. It doesnt appear to be running on exit, which is why my code chage seems ro get closer to the solution.

[Yardl3y]

Let me know if you need me to test anything on my end.

[Yardl3y]

Hey, just checking to see if you made any progress with this issue?

[ericharbison]

Im rewriting the ffb code to not use the mame dll directly. Im getting closer to finishing.

[Yardl3y]

Good to hear! I've been having issues with Demul too. I would think your fix could potentially solve that as well.

[ericharbison]

I think I finally have it working. I made extensive code changes to the MAMESupermodel code to separate out the MAME dll from the code. I got that working but it ultimately didn't make a difference. But it did give me much simpler code to debug the actual issue. After getting that to work with some additional code changes, I went back to the original code and added the very simple bug fix only and it works. There is a chance that after playing for many hours it may have issues, but so far it is now gracefully exiting the MAME/Super Model/Flycast. I've only tested it with Super Model so far but it's the same code as the other 2 emulators as well. The bug is that on my newest PC, it wouldn't happen very often with my original bug fix, but on my new but not as fast PC it happened often. This is because when exiting these games you have less than 1 second to run code to clean up any processing that are still running before the application shuts down. This is barely any time to close all of the processes that need to close and it would end up take too long to close and not do the final procedure in the DllMain file. I noticed on my slower machine that it still had forcefeedback in the queue and would take a few cycles to finish running those which would make the application end before running the final cleanup procedure. My fix is to alert the final procedure in DllMain the moment mame_stop happens which is the first indicator that the application is closing.

[Yardl3y]

Nice man! Are you going to create a fork?

[ericharbison]

Im going to need to create a fork. Im going on vacation for a few days, but will try when I get back.

Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Yardl3y @.> Sent: Saturday, June 8, 2024 9:56:38 PM To: Boomslangnz/FFBArcadePlugin @.> Cc: ericharbison @.>; Author @.> Subject: Re: [Boomslangnz/FFBArcadePlugin] After running Super Model 3 games with force feedback, it breaks force feedback on other emulators (Issue #68)

Nice man! Are you going to create a fork?

— Reply to this email directly, view it on GitHubhttps://github.com/Boomslangnz/FFBArcadePlugin/issues/68#issuecomment-2156284909, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3AIBP7O5NRSM7XAQIKRH3ZGO76NAVCNFSM6AAAAABHSGXOU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGI4DIOJQHE. You are receiving this because you authored the thread.Message ID: @.***>

[Yardl3y]

Any chance you can take a quick look at the code for Demul when you have a chance? I think that one might be affected as well and your fix might work for it too.

[ericharbison]

I can take a look. I have demul games that I plan to use as well

---

From: Yardl3y @.> Sent: Sunday, June 9, 2024 8:26:39 AM To: Boomslangnz/FFBArcadePlugin @.> Cc: ericharbison @.>; Author @.> Subject: Re: [Boomslangnz/FFBArcadePlugin] After running Super Model 3 games with force feedback, it breaks force feedback on other emulators (Issue #68)

Any chance you can take a quick look at the code for Demul when you have a chance? I think that one might be affected as well and your fix might work for it too.

— Reply to this email directly, view it on GitHubhttps://github.com/Boomslangnz/FFBArcadePlugin/issues/68#issuecomment-2156606410, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3AIBMBVNVJIDOZ4FREUS3ZGRJY7AVCNFSM6AAAAABHSGXOU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJWGYYDMNBRGA. You are receiving this because you authored the thread.Message ID: @.***>

[ericharbison]

I made a few more tweeks to the MAME and Supermodel code changes. When I started to set up MAME forcefeedback I noticed some issues. I think I have the issues straightened out, but want to finish setting up the rest of my games and test some more before forking the branch. I also notice Le Mans 24 force feedback is wrong. Im making some code chages for that Supermodel game. I noticed I don't have any of the demul games installed that use forcefeedback. Ill have to get that setup before I can test it.

[ericharbison]

I got Demul Setup with ATV Track and Smashing Drive. At first I thought ATV Track force feedback didn't work at all, but after some testing, if you press start button before waiting 15-20 seconds after launching the game force feedback doesn't work. That might be the game not initializing the force feedback until some time after it launches. These used to be arcade games so I'm not sure that behavior could be fixed in this code.

I'm pretty happy with my changes to MAME and Supermodel. I'll be creating a fork soon.

[ericharbison]

I created a fork: https://github.com/ericharbison/FFBArcadePlugin

I added the opengl32.dll file that needs to replace the old one in the Supermodel directory and the dinput8.dll file that needs to go into the MAME folder.

[Yardl3y]

Awesome! I'll give this a try. So to implement your fixes I just need to place the two dll files in the directories you mentioned? Everything else remains the same?

[ericharbison]

Yep. The other files I used were from the latest release. Both of these files are 64bit versions. Just replace the one dll from mame and one dll for supermodel. Also, I recently got flycast installed. Im not seeing issues with flycast using the release version.

[ericharbison]

Did you get a chance to try it? After testing Flycast some more. It looks like the original code (not my changes) is causing similar problems. I started using the update code version to see if that fixes it, but it looks like Flycast doesn't send a mame_start or mame_stop. The only way to have Flycast send a mame_stop would be to modify that emulator to send a mame_stop on exit. It should work if Flycast sent the mame_stop.

[Yardl3y]

Sorry for the delay! I just tested it and as far as FFB not breaking, it looks like you nailed it! I went in and out of Ace Driver for MAME and Daytona USA 2 for Model 3 a number of times following that up with Daytona USA for Model 2 and Dirty Drivin' for Teknoparrot and FFB didn't break a single time.

The bad news is that FFB for Daytona 2 in Model 3 is really off now. It feels very different than when playing with the original opengl32.dll file, I alternated between the two back to back just to make sure that was the root cause. For me, with your dll the wheel is very jerky and registers false FFB events. For example, if I'm turning a corner and the wheel feels stiff from the centering spring, it will randomly jerk and get soft/lose the stiffness. Can you check if the same happens to you?

As for MAME, it feels fine, but I have been testing only with Ace Driver for weeks haha, and while it feels fine for that game, I'm not sure about others.

[ericharbison]

Thanks for the input. I can rebuild it with the latest code and post an update. I had actually been messing around with daytona 2 and lemans, so its possible i messed something up. I didnt change any of the other games. Ill rebuild it with the latest dev branch.

[ericharbison]

I rebuilt the fix with the latest dev release. I noticed that the latest release already fixed LeMans24, and Daytona 2 feels different then what I was used to now. Let me know if it fixes the issue you saw with Daytona 2.

Release: https://github.com/ericharbison/FFBArcadePlugin/releases

[Yardl3y]

just tried it, didn't make a difference. Seems to behave the same as the previous one.

[ericharbison]

To answer your question about turning the corner and it randomly jerks. I notice that too. I'm using an arduino and creating my own code to interact with my Real Out Run 2 arcade machines original force feedback in the wheel.

Maybe you were using an older version of the FFB Plugin that did things a little different. Let me check some settings.

The only way I can get it to not be so jerky or get rid of the jerk all together for that game is to Force Spring Effect (No Jerk) for that game or Increase the Feekback Length to something greater then 1500 (Default is 500) and it is less jerky.

Edit:

I just tried it with Daytona 2 Settings: "Force Spring Effect" and "Feekback Length" set to 1500. No jerk and get feedback when I hit the wall or other cars.

[Yardl3y]

I'm using the latest FFB version 2.0.0.37 but I am using the SDL2.dll from version 2.0.0.33 because I found a similar issue to what I am experiencing with your dll with the SDL2.dll included with versions 2.0.0.34 and above. You can read my post about that here: https://github.com/Boomslangnz/FFBArcadePlugin/issues/65

I did however test your dll with the 2.0.0.37 and the included SDL2.dll with that version and it didn't make a difference. Unfortunately the FFB is completely different with the original and your dll. With the original one I don't experience any wheel jerk.

[ericharbison]

Ill take a look at is soon. I didn't actually rebuild SDL2.dll. Mainly because I don't know how and I haven't found any documentation on it. I just used the sdl2.dll from 2.0.0.37. Im only just getting into setting up the force feedback plugin very recently, so I didn't know any better. Ill try the sdl2.dll from 2.0.0.33 and see if anything changes for me. My code changes are from the latest dev build now which hasn't been released yet. Lemans24 works now, but didnt in 2.0.0.37. Also, Im using visual studio 2019. The official build is using 2022. I don't have a pro license for the newer compiler. Not sure it would make a difference, but maybe because it uses a newer .net runtime engine.

[ericharbison]

I tried using the SDL2.dll from 2.0.0.33 and it wasn't jerky anymore in Daytona 2 with the default settings. There is a different issue however, when I drove on the grass it didn't stop shaking my wheel unless I bumped another car. Also, LeMans24 no longer works. I wonder if the newer code isn't fully compliant with that old SDL2.dll. It's as if the feedback doesn't end at any particular point unless a new feedback comes in and resets it.

[Yardl3y]

When you say latest dev build are you referring to the FFB plugin? I thought that 2.0.0.37 was the latest?

[ericharbison]

The latest dev code base has updates that aren't in 2.0.0.37. Eventually the devs will create a new release that includes these code changes. Im going to see if i can fix the daytona 2 force feedback code to work correctly with the new SDL2.dll. The force feedback that comes out of these games are just numbers, and those numbers are then translated to a force feedback commands with length, magnitude or interval. These can be subjective. Clearly that game isn't configured correctly in the code.

[Yardl3y]

Gotcha, although I doubt those changes will be implemented since the original dev is no longer working on this project. Remember that any version of SDL2.dll starting with version .34 has issues. I would use .33.

[ericharbison]

Without looking at what changed in SDL2, I can only speculate. My plan is to get the output from daytona 2 as Im running it to see what it looks like. The old sdl2 did behave differently, but from what I have seen from the output from other games, I think it can be fixed with the new sdl2. I wouldn't be changing the sdl2, and dont need to in order to change the way daytona 2's force feedback works. Most of the other games that I have played with the new sdl work great. I think there are just a few games that need tweeking.

[Yardl3y]

I know that Ace Driver in MAME has issues with teh SDL2 from .34 and above. I can't remember if any other games I've tested do too, I want to say that maybe Daytona USA for Model 2 did as well but I'm not 100% sure. I ended up switching to the SDL2 included with version .33 for everything because I noticed that if you use different versions of SDL2, it registers different hardware IDs for my wheel which can be a pain if I need to search/replace the IDs when switching between my wheels.

[ericharbison]

Can you try the updated opengl32.dll I posted with Super Model 3 and Dayton 2 with the new SDL2.dll ? I noticed that the old SDL2 behaved differently, and I think I have an easy work around with the new SDL2. I'd have to make the fix to each game that is having problems.

[ericharbison]

I also had to implement in my wheel Friction, because I hadn't done that yet and I noticed Daytona 2 had friction happening but I wasn't getting the feedback in my wheel. I assume you have Friction on your wheel already.

[Yardl3y]

Just tried, with your latest opengl32.dll and the SDL2.dll included with version .37, I still have the weird jerkiness. However, I also tried your latest opengl32.dll with the SDL2.dll from version .33 and that works great!