MAMEInterop SDK v1.3 Released for Developers

[Howard_Casto]

Took a break from the mess that is the iowarrior stuff (although it's almost complete).  I went ahead and added that graphical display stuff I talked about. 

Right now it only supports images, but eventually I'll support text as well. 

Aside from that, I'm rather suprised at how well it works.  There don't seem to be any focus issues, and even vb's crappy gdi rendering seems more than fast enough to keep up with the flashing lights of, say digdug.  It doesn't seem to be much of a memory hog either.  Of course I'm sure really hi-res/complicated displays would eat up the memory.

[headkaze]

Hey Howard, nice to hear things are progressing. I've got a couple of MameInterop functions working in my plugin, basically led0 and led1 flashing start1/start2 buttons and pause flashing. You can check out some videos on the bottom of my LEDWiz makeover page.

It would be nice if the Mame developers added more events to do things with. Wasn't it you (Howard) that got the pause event added from your request? Can we get more added or let me know where I can request things regarding this.

Are the Mame developers aware of MameInterop? If they knew that people were actually making use of the outputs they might consider adding more support for it.

Do you think it would be useful for Mame to output info about the current game, like orientation and resolution? Perhaps we should figure out what other outputs would be useful before making a request.

[Howard_Casto]

Nah I hadn't formally requested it.  I'm sure I complained about it at some point though. 

Aaron is probably your goto guy.  Links to his email and such are on his homepage. 


Aaron was aware of the fact that I was going to start an app the used the outputs sometime this winter.  As to if he knows how far we've gotten, I dunno.

I'm not sure about adding a lot of extra junk through the output system.  Mind you it'd be convenient, but there are other ways.  We have the rom name, so we can call another instance of mame to print out listinfo for that rom and get any data we need.  Considering there is the slightest bit of lag when you ask for strings from mame, it might actually end up quicker to just call the listinfo.

It'd sure be nice to get the parent/rom/driver relationship though. 

Looks good btw..... I'm not a big fan of all the buttons, but still...

[Howard_Casto]

My question is do any of you guys know the daphne devs and can we get support added for daphne?


We've got several outputs in daphne, scoreboards in thayer's dl and space ace, a "shoot" lamp in badlands, rank lights in space ace and a high/low gear indicator in gp world.  Most of the outputs are alredy hooked up either by parallel port or keyboard leds.  It would be a fairly simple matter to add a function.... of course it'd be windows only, I don't know how well they'd like that.

Mame, daphne and pinmame are pretty much the only emulators I know of that deal with games that have actual outputs.  I think once we get those we are done.

[edge]

howard / hk,
On my trackball cab, I have RGB LEDs in my trackball with a LEDWiz.  By far, the most popular game on there is World Class Bowling.  In WCB, is there any output to track player changes?  It would be amazing if I could change the color of my trackball to match the color of the player's bowling ball on the screen (ie, P1 = blue, P2=red, etc).

very nice job, thus far, guys.

[Howard_Casto]

Nope... much like the gameover, gamestart flags hk is trying to implement, this is quite impossible if you wish to do it accurately.  Think of mame like a dvd player... it has no clue what is on the dvd (or in this case rom) it just plays it.  So there's no real way to know when the current player changes. 

Besides that, the goal here is to be able to hookup real outputs, not fake ones.  Now some of the ones implemented aren't real (like pause) but they serve a functional purpose and thus must be included.  There isn't any way the mame devs are gonna approve of a bunch of odd-ball hacks to do extra stuff though. 

[Howard_Casto]

Looking at the iowarrior mess, I've determined that there isn't any easy way to read the current states of the lights automatically.  Instead, I'll be adding "read status" functions for all three types. 

This may be a pain to users, but it is the only accurate way I can get the current light state, which is useful if you launch an external app to light your layout.

In light of this I'll also be adding a "shell and wait" function to go with the shell function I've already added.  There's no point in reading the state while it's being set. 

[Howard_Casto]

Hk:

Would it be possible for you to add the ability to get mame's hwnd into your dll?  I know that mame sends it to you and it might be useful for something I'm working on....  (integrated external control viewer support).  Of course I can search for the hwnd myself, but seeing as how the dll already has it....

[Howard_Casto]

I went ahead and added a bit of code in the mamehooker to list all compatable devices hooked to ones system.  It gives the id# as well, which should help users to understand which device to call when writing scripts. 

[headkaze]

Hk:

Would it be possible for you to add the ability to get mame's hwnd into your dll?  I know that mame sends it to you and it might be useful for something I'm working on....  (integrated external control viewer support).  Of course I can search for the hwnd myself, but seeing as how the dll already has it....

I could send the hwnd but I would either have to enumerate all the window captions looking for "MAME:" in the titlebar, or use FindWindow with MAME as the class. The reason is the dll never actually gets the hwnd of Mame sent over, it only gets the hwnd of the "Mame Output" window used in the communication which is not even a child Window of Mame (so I couldn't even use FindWindowEx API function to look for it as a parent window).

I did just do a test using enumeration and I can add that into the dll if you really want. I just don't think it's very elegant and something the end user can do just as well using the above methods when they get a mame_start() callback.

[Howard_Casto]

Eh, I'd rather just get it myself then.

[Howard_Casto]

added a shellandwait function along with a restorewindow function....

Using these in sequence, along with the "pause" event allows the user to launch a cp viewer on mame pause and have mame restored once they exit the viewer....

Essentially it replaces the ahk scripts I've used to do this with johnny5. 

[headkaze]

added a shellandwait function along with a restorewindow function....

Using these in sequence, along with the "pause" event allows the user to launch a cp viewer on mame pause and have mame restored once they exit the viewer....

Essentially it replaces the ahk scripts I've used to do this with johnny5. 

Pause is a handy event for things like this. Also saves having to tell your CP viewer what key you have assigned to pause if it's not "p". The only thing is, when you press p again to go back to Mame does it register the key while not in focus and unpause and send the pause event again? Or do you have to unpause mame by sending a key to it?

[Howard_Casto]

Well the plan was to also add a "send key" function... This would also add wiimote support as the two major wiimote interfaces basically allow you to bind parts of the device (like the leds and rumble) to keys.  The problem I've been having is I can't find a simulated keypress api call that actually works for mame....

I've tried good old sendkeys, setkeyboard state, keypress, ect.... nothing will penetrate it's directinput nuget center. 

As of now it returns you to mame, still paused.  It doesn't have syncing issues though as we actually know the pause state now. 

[headkaze]

Well the plan was to also add a "send key" function... This would also add wiimote support as the two major wiimote interfaces basically allow you to bind parts of the device (like the leds and rumble) to keys.  The problem I've been having is I can't find a simulated keypress api call that actually works for mame....

I've tried good old sendkeys, setkeyboard state, keypress, ect.... nothing will penetrate it's directinput nuget center. 

As of now it returns you to mame, still paused.  It doesn't have syncing issues though as we actually know the pause state now. 

Well I've cracked that issue when I wrote CoinDrop using a DirectInput wrapper dll that sits between DirectInput and Mame allowing you to inject input into it. I'll see if I can knock up some sort of dll if you want.

[Howard_Casto]

Well I've already got directinput code in the app for force-feedback anyway.

If you can show me how you did it then I can just add a function and save you the trouble.

[headkaze]

Well I've already got directinput code in the app for force-feedback anyway.

If you can show me how you did it then I can just add a function and save you the trouble.

It's alot more involved than just running DirectInput in background mode. It actually hooks into the DirectInput API and sits between the two allowing injecting keys. You have to use a dll to do this method.

[csa3d]

mamehooker

 

[Howard_Casto]

That sounds like a lot of work man for one feature.  Mind you it'd be useful, but I can do it other ways (like compiling a ahk script, which somehow magically does it.)

Sorry about the lack of a release guys... I've had some real-world resposibilities lately.  I'll throw a version over to laodman so we can double-check the iowarrior functionality and then hopefully we can get it out the beginning of next week. 

I think the source is about ready for a release too.  I've cleaned up most of my bad code. 

[loadman]

I'll throw a version over to loadman so we can double-check the iowarrior functionality

Ready When you are..

I've pulled out the MaLa hardware  (based on Iowarrior 40's) from my Cab and have the Led-Wiz ready to Mod  with the Iowarrior 40 chip. They are all on my Desk/TestBench ready to test.

 

[Howard_Casto]

Glad your ready lm, but It's probably gonna be a day or so, I've barely felt like testing the new code today (still need to double-check things). 

Btw hk about the key-press thing..... I found a much simplier solution......  I just compiled a very simple ahk script into a exe that takes a keyname passed to it and presses it.  It wouldn't work for everything (might be slow if pressed often), but it works great in this instance. 

I'm also looking into adding partial daphne support... the only problem is I haven't been able to figure out what method they are using to press the keyboard lights.  There are quite a few ya know.

[Howard_Casto]

Ok things are starting to slow down here, hopefully I can finally get a beta out to lm and we can get started again.  (Grandma was in the hospital, but don't worry, she's fine and will be released today probably.)

Here are some random thoughts....

I looked at different inter-communication methods besides the windows messages mame uses and my favorite thus-far has been dde communication.  I know that this method is going the way-side, but it's really the best.  I've added dde support to j5 just to see how I like it and it works really well.  Basically the next version of J5 will be able to pass commands to itself if you run it multiple times......  (So you can load the mk layout on the first launch and then type "johnny5.exe mk2" while it's still running and it'll load the mk2 layout... true non-hacky residency)

I will post the server and topic names in the doc, so developers can communicate via direct dde if they so choose. 

My question is, do you think this would be useful for the mame hooker app?  I thought perhaps for misc stuff (lesser known emulators, front-ends ect) It might make more sense for them to simply use the dde than windows messages as, quite frankly windows messages are overkill for some simple stuff (like loading a layout).  Also I could set it up like I did j5, where you could simply launch the hooker with a command line and it would pass it to the resident app.  I don't know how you could possibly make communication easier than that....

[rockin_rick]

Well, the main reason is they don't want to I guess.  I've brought it up a few times and while nobody said, "hell no we won't add it" or anything like that nobody seemed thrilled about gving it a shot, mainly because converting "real" force feedback (like afterburner) into directx force feedback is going to take a lot of work, probably a good weeks worth of actuator mapping to create the proper feel per game.  And then once it's done you try it on another controller and it doesn't feel right.  FF is very device dependant.  Like I'm using a xbox controller, cause they are cheap, so it's going to make it really hard for me to make effects for games like outrun.

I don't know what's all been done with force feedback, and perhaps this has already been suggested or considered, but how about dealing with converting the FF actuator mapping using transfer functions?  Have mame output a value of FF, then run it through a transfer function to map it to the controller used.  The function would allow for different maximum force per device, and different ramp rates.  You could have different transfer functions for different devices, and different functions for different games.  This would allow end users (?) to tweak their FF to their liking.  Someone/anyone could generate transfer functions for different devices outside of mame. 

(Perhaps this has no merit to the problem, as I don't have a full understanding of the issue/sitaution...)

Rick

[Howard_Casto]

Mamehooker supports ff now, so what exactly would be the point?

[headkaze]

It's been reported to me by Arzoo that mame.dll is no longer working. After inspecting the latest MAME (0173) source I have noticed the following missing source files:

src\osd\windows\output.cpp
src\osd\windows\output.h
src\osd\windows\ledutil.cpp

I can only conclude that the MAME Output System has been removed. If so this impacts a variety of software such as LEDBlinky, Mamehooker, CPWizard and the LED Plugin for GameEx.

Please post back here any information regarding this issue.

Haze: If you read this can you please let us know what's going on and how we can communicate with MAME going forward.

[Howard_Casto]

Someone had complained to me that with 173 mame games (arcade stuff) did fine but console games crashed mamehooker.  I hadn't looked into it yet assuming they just added a new flag that the dll was having issues with.  Let me give it a look. 

*update*

The calls to the output functions are still within the drivers, but unless I'm overlooking it the output stuff itself is missing.  Is this an oversight?

[arzoo]

I tried posting a new thread on the official mame forum to see if I could get any info on the missing output functionality but after 24 hours the thread has still not been reviewed/posted. There's only two threads on the forum so I'm not even sure if it's active? Any thoughts on who to contact about this issue?

[Howard_Casto]

I'm not sure.  Normally Haze would be the goto guy around here but apparently he's retired according to his blog. 

Maybe mametesters?

[arzoo]

Looks like they fixed the outputs for ledutil... http://mametesters.org/view.php?id=6134

[heyyouguys]

Looks like they fixed the outputs for ledutil... http://mametesters.org/view.php?id=6134

So >= .171 is working fine for led'sand ledblinky?

[arzoo]

Looks like they fixed the outputs for ledutil... http://mametesters.org/view.php?id=6134

So >= .171 is working fine for led'sand ledblinky?

Unfortunately not. Maybe they just fixed ledutil.

[arzoo]

I've posted on two mame forums asking for a clarification on the missing Output functionality. No reply yet.
http://forum.mamedev.org/viewtopic.php?f=14&t=68&sid=2e69194327855101c0b2ecd6f9c16ce9
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=354122&page=0&view=expanded&sb=5&o=&fpart=1&vc=1

[headkaze]

So MAME's new output system creates a TCP server on 0.0.0.0 port 8000 for outputs.

I'll look into updating the MameInterop dll's to support communication this way so we can maintain backward compatibility.

[arzoo]

So MAME's new output system creates a TCP server on 0.0.0.0 port 8000 for outputs.

I'll look into updating the MameInterop dll's to support communication this way so we can maintain backward compatibility.

Thanks hk - really appreciate your help with this!

[Howard_Casto]

Hmmm.....  TCP server on paper should be easier.  Damn that means having to deal with windows and your anti-viruses draconian strangle hold of all things internetz though.  We are going to get a lot of complaints about stuff not working when in reality windows firewall just has the app blocked. 

Could you tell me where I can find the specs on the new system? 

Btw unlike previous changes to mame we should be able to support both.  New Mame just won't send any window messages so the interop stuff would remain idle.... in theory at least. 

[headkaze]

The areas to check out are osd\modules\output and the server specific code is in osd\modules\ipc.

I'll probably just use MAME's own server code in the dll's like I did with the old output system. I'll make it so you can still use the same callbacks as before so it shouldn't be any different to how you use MameInterop now (ie. drop in replacement). The only difference is I will probably make a 64-bit version of the dll also.

The one annoying thing that appears to be missing is the ability to send commands back to MAME like pause/unpause. It would be nice to get those added back in somehow.

[Howard_Casto]

Yeah did they include an example app this time?  Sorry I've been out of the mame game so long I don't know where anything is anymore.  I looked at the source.... there wasn't much in the output/ipc folders, so I'm guessing the actual possible commands are elsewhere?  Again, I'm a bit lost. 

The actual TCP connection is fairly easy... two lines of code and I'm good to go.  I just need a bit of guidance on the specifics. 

Yeah I'm a bit confused as to why the pause/unpause commands were removed as well.  One of the main things TCP connections have going for them is easy two-way communication and mame certainly has that ability now that lan connections are an option.  If anything we need MORE two way communication.... like the ability to send limit switches or outright inputs for E.M. sims. 

[arzoo]

Here's a response from MAMEWorld;

you'll want to take a look at src/osd/modules/output. The "network" provider is preferred, although I don't know how well any of this stuff has been tested. In theory it'll now also be possible to have an output provider that just lights up the GPIO pins on some of the beefier ARM dev boards like the ODROID-C2.

Also, the new "network" provider works the same on Windows, Linux, and Mac, which the old output stuff definitely did not.


http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=354131&page=0&view=expanded&sb=5&o=&fpart=1&vc=1

[headkaze]

I'm going to have a look at all this today.

[Howard_Casto]

I managed to make a connection, but it didn't do anything.  I'm guessing some sort of handshake is required.  Anything I tried to send threw up an error, so I'm probably missing a key step. 

btw, I know you mentioned this in another thread, but the lua scripts have the pause/unpause commands.  Mind you that still doesn't help us because you have to load a script and thus they can't be called externally.  I think whoever converted it over didn't understand the nuts and bolts of how we use the output system and why we need things a certain way.  It's an honest mistake, but it could have been rectified if they had gotten into contact with any of the 3 or 4 people that write software for the thing.  I'm just sayin'