Main > Software Forum
What is Mame's "generic output support system" capable of?
headkaze:
I'm referring to this blog entry on Aaron Giles' blog...
http://aarongiles.com/?p=181
--- Quote ---I’m hoping this new functionality will inspire some of the BYOAC folks to update their MAME hacks to use this new solution instead, and come up with some other new cool ideas. I’m also hoping it will inspire folks documenting the outputs better in MAME proper, which is something I’ve been wanting to see for quite some time.
--- End quote ---
What information can an external app extract from Mame using this? And what are some practical uses of this output system?
Does anyone have some example code in C++ that interfaces with Mame this way?
Howard_Casto:
The output system is very convoluted to setup, but once you get it running it is nice and fast. Basically it works like this, if a game had some sort of output (flashing light, siren, propeller, rumble motor, ect) and the mame driver has that output hooked up to an output port, you can use an external app to read the status of the output device. Then of course you can have that external app do whatever you want with the data (control ledwiz, play a wav file, display a graphic on a secondary monitor, ect).
You already have an example actually. In the mame source, the led controller has been made into an external app by aaron. Look in the mame source and you'll find it. Really simple stuff, but it's enougnh to understand how the interface works.
Now the problem with it is that the driver has to support it. Right now, 90% of the games that support output ports were added by aaron himself, and it's ususally just coin/rank lights. However, there are still a ton of games that support it, it's just not the things you might be wanting to do (like terminator 2's recoil or afterburner's force feedback joystick, which are not supported yet).
headkaze:
Thanks for the info HC.
I'm curious, what are led0, led1, and led2? I understand that ledutil.exe has been externalised to convert these outputs to the numlock, capslock etc. LED's on a keyboard. What is this functionality emulating from a real cab?
What other outputs are there and where can I find a list of them. I had a look at ListInfo.xml for anything relating to outputs but did not find anything. Is there a C file in the mame source listing all the outputs or are these all stored in individual drivers?
Howard_Casto:
Well there in lies the problem. When aaron added the output system, he basically generically converted all of the game that used to use the keyboard leds to "led0-led2" so they could represent anything, depending upon the game. Usually it's the coin lights, but you can't always assume that. Gorf, for example has 6 rank lights, that have been labeled led0-led5.
Output names are stored in individual drivers unfortuantely. Also imho they are kind of useless because of the way it has been setup. You see your app doesn't get data from "led0" it gets data from a digit address, like 0001. Once you get some data from a digit address, you can call mame asking it for the string name and it'll send it back. This is all well and good, except that you don't know what outputs are in there until each one sends you data, and by then it's too late. Couple that and the fact that you have to pretty much treat each game on a case by case basis and you might as well use the digit addresses as it saves you a step.
I should also note that I couldn't get the string to return for me in vb6, but that is my issue. In c languages it works fine.
So basically, to support a game properly you need to look in it's driver, get the addresses, and make a custom ini file that describes the outputs. Now you could make a "discover mode" app that pretty much only reads for addresses and translates them to thier string names for a custom ini, but again, you aren't going to get the string name if some data doesn't get sent to the address, which could happen more often then you'd think.
Imho, the easiet and best way to deal with these issues is to do a controls.dat deal, but maybe on a simpler scale. People could go into a driver, get the data, and make an ini file that looks something like this:
[captions]
Coin Light 1=00010
Coin Light 2=00020
[settings]
00010=
00020=
And basically a developer could bind the caption to the address from the captions entries and then in the configuration part of thier app, use the real caption names, only save the real life dodad they want to control to the actual address number. Then when you are actually running mame, it is super fast as it can ignore the captions read the addresses instantly without doing a translation.
I was the guy that bugged aaron to add output support, and I'm ashamed to say I've sat on it for a few months now. I have thought about ways of doing it though, as you can see.
headkaze:
I'll look into this whole thing a bit more some time, perhaps we can come up with a better way of dealing with outputs. I do like your idea of creating some sort of ini file though.
--- Quote ---aaron I’ve setup a test app of my own and all is doing well, except for the stuff i get back from wm_copydata. It comes back as gibberish.
I’m first dumping it into a copydatastruct, then using the info from that to fill a byte array, then converting the array to unicode.
--- End quote ---
Are you using this method...
http://www.mredkj.com/vbquicktakes/Subclassing.html
Navigation
[0] Message Index
[#] Next page
Go to full version