MameHooker wip (2013)

[Howard_Casto]

Holy crap I'm finally well enough and have enough spare time to work on mame hooker!

Finished up the new multi emulator support.  Due to new communication methods, mh needs a bit of organization.  In the ini folder you'll find "MAME" and "SUPERMODEL" folders and the ini files for each game are stored in these folders automatically.  Likewise, the new title bar detection method will make use of individual folders for various other emulators as well. 

It's honestly been a few months since I've messed with mame hooker, so I need to give everything a once-over but I think it is about done.  I could delay the release a bit further, as I wanted to add ppjoy or vjoy support, but I think it's way past due, so it's time to release.

Again, don't hold your breath though as I have to make time to do it. 

[retrorepair]

I think it is about done.

 

Been checking the forum regularly for a few years waiting for you to say that 

My memory is a bit fuzzy, doesn't this version add proper FFB support? That'd be pretty rad

[Howard_Casto]

Yeah you can run custom effects and 1-axis ff devices (aka steering wheels) should respond now. 

[bdam]

Been checking the forum regularly for a few years waiting for you to say that 

Me as well; looking forward to a new release.

[Howard_Casto]

If you follow the modle 2 thread you'll know that I'm going to use the DDE method to have my troubleshooter app send outputs to mamehooker. 

Well it's a good thing that nobody uses dde except me because half of the functions were broken and I don't know how long they've been that way (they could have ALWAYS been broken).

Anyway, I just spent the better part of an hour fixing them.   

You can now send any of the messages mame would normally send to mamehooker via dde and mh will respond properly. 
I needed to do this anyway as mamehooker will be getting multi-emu support and I needed to modify the "mamestart" dde command to accept a emulator name. 


I think I'll hard code some output testing into the troubleshooter tonight to see how quickly mh can parse dde messages. 

We are getting there guys, it's just minor annoyances like this that need to be wrapped up. 

[Howard_Casto]

Just an update.  It might seem like I'm side-tracked with model2 stuff but they go hand in hand.  I'm systematically testing the robustness of the DDE communication while working on the model 2 stuff, this is necessary to allow me to expand the emulators/games mamehooker supports in the future and I want to get it right. 

Things are winding down, so a release prior to spring, or even prior to the end of next month is likely. 

[Gray_Area]

That name has always looked dirty. Brings interesting conceptualizations.

[Howard_Casto]

Not really... it hooks mame, so the name is self-explainatory. 

If you want to go there though, it does make mame "put out"  or output as it were. 

[Howard_Casto]

Worked on mamehooker a little bit today. 

As I said, it's mostly cleanup work at this point.  Since I'm working on model 2 so much and I actually have the wheel out of storage I thought why not test the new ff functionality for bugs?  Thankfully I didn't find any, but I had forgotten to make entries for the new functions in the functions.ini, so I went ahead and hooked them up. 

At first I was reluctant about adding support for ffe files, afterall, who uses those anymore?  But upon my testing tonight it became apparent just how useful they are.  A lot of the racers have a digital "rumble" force feedback output that works quite well on a gamepad but not so much on a wheel.  I was going to write a complex oscillating script for my wheel that toggles the movement from left to right, but just for the heck of it I tried a ffe file supplied by microsoft called "offroad3"  Guess what it does. 

Anyway, every little addition is a step closer to the release.  I'm going to take a break from model 2 this weekend and give mamehooker a bit more tlc.  I'm hoping to have a dual release of both apps as well as a suprise or two to make up for the lack of programs over the last year or so. 

[RamjetR]

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?

[Howard_Casto]

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?

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]

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?

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]

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!

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?

[BadMouth]

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?

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.

http://forum.arcadecontrols.com/index.php/topic,121412.msg1333325.html#msg1333325

[RamjetR]

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?

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.

I replied to your PM on this... and for everyone else who may be having the same reaction...

I started working on this last year and got some data working in an X-Sim profile 2.0. It wasn't much but it was things like speed, rpm, gears etc for the Symprojects Dashboard in my cabinet. Doing a bit of youtube surfing on motion simulators (the next logical step for a racing enthusiast geek) and stumbled on this....



Now I've emailed the company to see if they would kindly send me a copy of the profile they use for motion, but no reply as yet. Shouldn't be a problem because the data for the physics engine is obviously there (like all racing games) and is sufficient enough to generate motion curves for the simulator.... With a little mathematics, and possibly Mamehooker binding this data to FFB "effects" we may be able to put something together in the form of emulated FFB. Heck, if we're lucky... maybe the real FFB data is in there and just not being used. But this is going to be a whole new project.

So yes, it's possible.... and it's another thing on the "when I get the spare time and the niece doesn't want to watch The Wiggles on the weekend when I really want to do research but the family has come over for Tea and I've been nominated as childrens entertainer" List....

Ramjet

[Xiaou2]

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. 

 Highly Doubt it.

 Out Run Sit Down is drivin using a massive Worm Gear.  There is a Ton of friction on a worm gear, so much so, that once you set it in place, its not going to move.

 It does shake left to right, when the car crashes.  Similar to what happens with the wheel when you wreck.. but that the wheel motor is single direction, where as the motor in the sitdown is dual direction.

 Gotten from an old email:

The seat is moved by a large DC motor which is controlled by its own drive board which connects to the main OutRun PCB. The base has two micro switches that sense when the seat is fully left/right and also a magnetic sensor to detect when the seat is centered, there is also a pot you can calibrate the seating position with.

[Howard_Casto]

Yeah you mentioned that a few years back when I was implementing ff for outrun, sorry.  It doesn't make any sense really.  That output bit is definately strobing the left and right direction when the car is in idle.  Found tons of M2 games' output for the troubleshooter... they all do the same thing as well. 

[Xiaou2]

I seriously Doubt that the motor is going forward and reverse rapidly.  It wound probably die in a months operation if it were changing direction that rapidly.

 Also, have you never played the SD?   You can hear the motor when its turning, as well as feel it.

 Maybe theres something on the power driver board, which takes that strobe signal without moving.. and only moves when the signal double down... and or is continuous.

 Also, did you factor in motor speed?

 I know that the wheel that shakes in the standup has different speeds.. because if you drive on grass (in low speed?) ... the shake is weak.. where as if you crash, its violently fast.

 So maybe that signal is being split into speed setting as well.  (in the case of some games, this would be the equivalent to stronger wheel resistance)   Which probably makes sense, considering how complex that motor driver board looks.

 If you need the Sitdown manual, Ive managed to find the pdf.

[Howard_Casto]

Yeah I've figured out the speed as well, it's in there. 

I don't have my notes with me, but it's something like 128 for left direction and 145 for right  and then +1 to +8 on top of either value for speed.

They always send left+1 then right+1 whenever in idle.  The only thing I can think of is that it's actually a 7 speed system and +1 means no speed.  But there is a value for no movement as well, so I dunno. 

[Xiaou2]

Well, 'off' and 'broken' may be the difference.

 By sending a signal constantly in a certain frequency..  it can establish weather theres a
response, of if something mechanical has stopped working.

 At least, thats the logic that makes most sense to me.

 I also wouldnt doubt that theres several speeds also.

 

[Howard_Casto]

No in Mame I've got the limit switches hooked up and the game passes the startup test if the limit switches are pressed at the appropriate times.  Passes the i/o board test as well. 

Definately not broken. 

[Xiaou2]

I didnt mean that.

 I meant, that if you were riding in the games seat... and the motor was seizing up, or failed completely,  the game would realize that there was a problem.

 Pots and Switches can fail as well...  But a motor issue, if not taken care, could overheat and cause a fire.   Also, motor brushes that wear too far down, can cause sputtering effects.  Such an effect would be unwanted... so the games designers may have anticipated that, and had a shut down system in place. 

 It may have also to do with someone body part getting trapped inside the mechanism, and crushed.

 It also could have been to make sure the motor board was working properly.  No problems with communications... or any other issues.

 Also, remember that standup motor only goes in one direction.  So a left to right signal wouldnt make sense...  nor would any slow motor movements of the sliding plate wheel mount, while playing. You certainly would notice it.

 And finally, it may be that the signal was a sort of motor test, that wasnt powerful enough to actually move the motor... but just send enough current to form a completes measurable circuit. By measuring the returned resistance, able to tell if there were any issues.

 Edit 3:

 Also, do you have the magnetic centering switch also hooked up?   So, it should be 3 switches.. Furthest Left, Furthest Right (turn worm gear forwards and backwards),  and Centered Sensor.

 If the cabinet does not read centered, it may try to center it, by vollying left to right.   The analog pot also has to be in the proper range.

 80h seems to be the value that is mentioned as the standard default.
The picture shows 7ch  to  84h  in a box, but outside the box, it lists the Min= 3c, max C1.

[Howard_Casto]

The upright cabinet uses a totally different output system.  It's just off/on. 

All of this talk is irrelevant barring somebody taking a real outrun machine and hooking up a logic analyzer to the i/o board. 

[Xiaou2]

Actually, I do not believe its just on and off... as Ive said.. the wheel operates at different speeds.  If that were done via pulses of on and off, I believe it may be a little too jerky and cause motor wear and overheating.  I believe, theres actually a speed setting, so that the motor board actually sends different amounts of current to the motor.   The more current, the more power and speed.

But I dont have the capacity or knowledge to test it.  Not sure if the collector I know still has it either.

[griffindodd]

Reposting this question in the correct thread 

Hi Howard.

Mamehooker is great, I use it on my Revolution cab to display Marquees and control panels on a backglass monitor when playing games in Mame and it looks and works really slick.

On my next build, a VPin, I'm going to be using screens on the sides of the pinball cabinet with the intention of showing side art/marquee art on the screens. The plan is to use HyperPin as the FE and Visual/Future Pinball as the Emulators. Is there currently a way to use MameHooker to display an art file/display file that will change when viewing tables in the HyperPin FE and Playing them in the different Emulators? If I could do this then basically the entire pinball machine's skin would change depending what you were looking at or playing.

Great work!!

Joel

[JRoz]

Hey, i'm using mamehooker mostly for the marquee in a secondary monitor function..which by the way, for Mame works great!..I noticed that supermodel is now available for it and wanted to see how I can add the emulator to it?  Not sure exactly where I can add this though...I see set MAME path for Driver/Parent detection, but I can only really use one path?

[Howard_Casto]

For now yes... remember although not working, the supermodel games are also in mame. 

In the upcoming release, supermodel gets it's own folder and ect....

[charlieram]

Hey Howard, I know its been a while since you posted in this thread but I have created a serial port interface for recoils to be used with mamehooker, some of the games (such as Terminator 2) have a recoil output which is too fast for my solenoids, now I was able to overcome this by putting a something like the following Recoil1= lpe 1 5 1, wat20, lpe 1 5 0, wat10  This did work to give an automatic recoil but it buffers the shots so that when the trigger is released the recoil keeps firing.
Is there anyway to use the key detection in mamehooker to stop the buffered commands when the trigger is depressed and if so how would I go about it? Also I know your always busy on your new projects but what happened to mamehooker with model2 support? is it still on the cards for release?
Thanks.

Edit.
One other thing I just noticed, to enable recoil in model 2 for now I am using the keystates to activate the recoil but it seems to activate on Key_down and  also Key_up so that every time the trigger is pulled and released the recoil fires twice. Is this the expected behavior?

[charlieram]

Ok so I sorted the recoil issue in model 2 by editing my command in the [keystates] section of the default.ini which now reads
a=lpe 1 5 %s%, wat 18, lp 1 5 0
z=lpe 1 6 %s%, wat 18, lp 1 6 0
A and Z are the keys that are remapped by troubleshooter 2 for the triggers to work for model2, the downside to this is it also fires when shooting off screen. Hopefully this will change when Howard has had his MK9 fix and gets onto something more productive 
The upside to the above INI change means that I now have the automatic recoil working correctly in Terminator 2 and operation wolf but I think the output must be screwed up in operation wolf 3 because they are totally random.
Well I will keep plugging away until someone with more knowledge can point me in the right direction, and if anyone can think of a way to register the off screen shots please let me know, Mame hooker still register A and Z whether on or off screen