| Main > Software Forum |
| MameHooker wip (2013) |
| << < (3/7) > >> |
| Howard_Casto:
--- Quote from: RamjetR on February 02, 2013, 04:41:42 am ---Howard, if I get you data for Force feedback in OutRun 2006 coast to coast, can you push it to the wheel with Mamehooker? I have some preliminary information with regards to interfacing to X-Sim3 but you can just as easily read this information also? Perhaps kill 2 birds with 1 stone on this one? --- End quote --- I would be extremely interested in it. Outrun 2006 is literally my favorite arcade racer. Since the PC version doesn't support force-feedback I was going to throw an xbox in my rig. Yeah we can add it to the troubleshooter. |
| Howard_Casto:
Somewhat mamehooker related news. For those of you in a cave, I made a patch to mame a couple of years ago that adds force feedback outputs to mame for outrun and it's clones. I've never officially submmitted it because it has to be re-written but also because I wasn't so sure about how well I had implemented it. Ironically my model 2 adventures have given me a bit of confidence in it. Sega Rally Championship is a m2 game I never really cared for and thus never really tried. In the process of detecting outputs for the troubleshooter I noticed that it has the EXACT same output as outrun for the motion cabinet. Elsemi uses this data for a ff wheel as do I. And it behaves exactly the same both in outrun and srallyc. What's a little odd about it is when the wheel is idle, the ff data strobes between left and right rapidly. On the motion cabs I'm sure thus was to keep the cabinet balanced on the y axis it tilts on, but on a wheel this is a bit more jarring. Oh well, it's still quite useable data and depnding upon how you implement it, that strobing feature makes for a simulated engine rumble. Back to the main program. My "testing" has led me to find a few configuration bugs in mamehooker, which is good as I don't want to do 5 ".1" increments before the upcoming release is bug free. The fact that mamehooker now officially supports multiple emulators means that any configuration data on the user interface and the code that reads/writes them has to be modified. I thought I had done that, but sometimes the best way to find out is to use the program normally. So what's left to do: 1. Add two more functions to the functions.ini 2. Find and correct any errant configuration bugs. 3. check to see if the new multi emu settings have broken anything, most notably key detection. 4. Try to see if there is a workaround for mamehookers initial sluggishness upon it's first game launch. After this release I would consider mamehooker essentially done. I had thought about adding the ability to simulate joystick presses, but this was mainly to deal with the issue of limit switches in the arcade racers and I've decided that a stand alone app would be better suited for this and it doesn't fit in the scope of what mamehooker needs to do. There are only two other things I would like to add but atm they are sort of a pipedream. I want to add wiimote speaker support, but the wii hackers (including myself) have yet to find a reliable way to send sound files to the device. Also if I ever get around to making an android/html app that will load display files and images to any device I would naturally add support for that. |
| Howard_Casto:
As expected, there were a few glitches in regards to multi-emu support, specifically the keystate detection code. It was easy enough to fix fortunately. So on #3 of my todo list I'd say we are about 75% there, hopefully 100% after I do some more bug-squashing. As for #4, there are two issues going on here, one I can deal with and another I can't. The first issue is that the window messages api that both mame and mamehooker use seems a bit sluggish on system start. I can't do much about that unfortunately. As for the other bit, when a mame game is detected, I launch another instance of mame to retrieve the driver/clone relationship. For whatever reason, sometimes mame doesn't allow another instance to be launched, depending upon the timing. I did have a good old "resume next" call in there, but it really wasn't the best way to go about it. I've since put a more robust error-trapping code in, basically if the launch fails, mamehooker will try to get the data two more times before giving up. This is one of those things that's hard to test (the glitch doesn't happen predictably) but I think I've squashed it. So knock #4 off the list. So 1 3/4 down, 2 1/4 to go! Not bad for an evenings work! |
| isamu:
--- Quote from: RamjetR on February 02, 2013, 04:41:42 am ---Howard, if I get you data for Force feedback in OutRun 2006 coast to coast, can you push it to the wheel with Mamehooker? I have some preliminary information with regards to interfacing to X-Sim3 but you can just as easily read this information also? Perhaps kill 2 birds with 1 stone on this one? --- End quote --- Wait a second did I just read that correctly? I'm confused...are you referring to OutRun 2006 Coast to Coast for the PC? If so, How or where would you get the data for force feedback, when the game never supported FFB in the first place? Please clarify this, as I am on the verge of having a heart attack at the idea of OR2006 for PC getting force feedback. |
| isamu:
--- Quote from: Howard_Casto on February 02, 2013, 08:34:01 pm ---As expected, there were a few glitches in regards to multi-emu support, specifically the keystate detection code. It was easy enough to fix fortunately. So on #3 of my todo list I'd say we are about 75% there, hopefully 100% after I do some more bug-squashing. As for #4, there are two issues going on here, one I can deal with and another I can't. The first issue is that the window messages api that both mame and mamehooker use seems a bit sluggish on system start. I can't do much about that unfortunately. As for the other bit, when a mame game is detected, I launch another instance of mame to retrieve the driver/clone relationship. For whatever reason, sometimes mame doesn't allow another instance to be launched, depending upon the timing. I did have a good old "resume next" call in there, but it really wasn't the best way to go about it. I've since put a more robust error-trapping code in, basically if the launch fails, mamehooker will try to get the data two more times before giving up. This is one of those things that's hard to test (the glitch doesn't happen predictably) but I think I've squashed it. So knock #4 off the list. So 1 3/4 down, 2 1/4 to go! Not bad for an evenings work! --- End quote --- Glad to hear about the progress Howard. Good stuff. Just wondering...after these issues are ironed out and you get MH released, will you eventually take a look at possibly getting ffb output from Namco's System 22 hardware? |
| Navigation |
| Message Index |
| Next page |
| Previous page |