How does Mame map input?

[headkaze]

Can someone please clarify how Mame maps input? This is a guess but does it work like this..

default input -> ctrlr -> cfg\default.cfg -> cfg\[ROM].cfg

Eg.
1. Default Input: P1_BUTTON1 is mapped to LCTRL
2. If I have a ctrlr file it can have a default map of LCTRL to the A key. It can also specify per game mappings. So does this override what is in the cfg folder?
3. In cfg\default.cfg what happens if P1_BUTTON1 is mapped to the B key? Does it override what is under default in the ctrlr file?
4. If I play 1942 and I have custom key mappings for it in both ctrlr file and cfg\1942.cfg which key mappings are used?

So does each one overrides the last mapping or do some get ignored down the chain? It's pretty damn confusing, any insight into how the logic works behind this?

[arzoo]

Can someone please clarify how Mame maps input? This is a guess but does it work like this..
default input -> ctrlr -> cfg\default.cfg -> cfg\[ROM].cfg

I'm pretty sure you've got it right. Each one overrides the previous.

[headkaze]

Thanks for the reply arzoo but I really need a detailed explaination on how it works. I'm working on a really cool project and I want to get the key mappings right. I will of course release a beta version here for testing as soon as it's in a working state but I need to figure this out first.

[arzoo]

Thanks for the reply arzoo but I really need a detailed explaination on how it works. I'm working on a really cool project and I want to get the key mappings right. I will of course release a beta version here for testing as soon as it's in a working state but I need to figure this out first.

I know how I do it (LEDBlinky), but it sounds like you're looking for an answer from the mame devs, yes?

[headkaze]

Well I do basic cfg mapping my PluginLCD for GX but I need to be more precise now for the application I'm writing. I don't take into account any ctrlr files for example in PluginLCD. I was actually hoping Howard could bust in on this thread, but he tends to be a big vague in his explainations. I'm hoping he can be a bit more detailed on how I should process the input files.

I guess I could ask Mame developers but I think I come from an external processing perspective. Asking Mame developers might just confuse me more. I'll see what BYOAC members can come up with then maybe I'll go ask them.

Always appreciate your input arzoo, cheers.

[2600]

It's been a while since I looked at it, but don't forget a crucial part.  Ctrlr mappings don't have to per game.  In a Ctrlr file, you can also map per driver(everything using that drive will use that mapping) and/or map by the Master (Master and all clones will use that mapping).  IIRC the Ctrlr file is order dependent.


I want to say it goes:

Default -> game.cfg -> Ctrlr

but it's been too long since I looked at it.  Only a 1 minute test to prove it or you should be able to find it in the source pretty easily.

[u_rebelscum]

I'll go into details, but basically you got it:

Default -> OS specific (coded) -> ctrlr -> cfg/default.cfg -> driver coded non-defaults -> cfg/[game].cfg

Mame has two seperate input mapping lists; I'll call them "general" and "local".  They have been this way from before ctrlr files were added, so things might seem not well planned.    Each list is seperate and while local overrides general (general -> local in the above format), edits to one list does not change what's in the other list.

General's part of the whole is:

Default -> OS specific (coded) -> ctrlr -> cfg/default.cfg -> ...

To most people, the OS specific part is part of the "default" default, since it is hard coded.  However, other OS variants that don't use official mame's src/osd/windows/input.c (or a copy of osd_customize_inputport_list() function therein) can have different "defaults".  Both the ctrlr and cfg/default.cfg files change the general input map, the latter overriding the former.  The general list is complete with all input ports included. 


Local's part of the whole is:

... -> driver coded non-defaults -> cfg/[game].cfg

This list is not complete, and includes only the gaming inputs in the specific game's inputs.  The defaults for each input in the list is "default". IOW, this tells mame to "look the the general list".  If it's not "default", then mame uses that setting and ignores the general list.  You can tell if it's set to "default" by looking into the tab, inputs this game, and seeing if it's highlighted or not: highlighted = not "default", not highlighted = "default".

However, sometimes (examples: rotary joysticks, toobin') the driver is coded to set it something besides "default".  This not only makes the vanilla setup (aka default) not set to "default", but also negates any changes in ctrlr file (game specific or not).  Since cfg/game.cfg overrides the driver coded inputs, however, you can reassign that input back to "default" by pressing enter, esc [pause], enter, esc in the tab inputs this game menu.


I hope this helps.  If I glossed over anything, was unclear, or forgot something, please ask.  (I totally skipped the ctrlr file order, for example: it's not order depend anymore, just the order they're put in the ctrlr file.)

edit: added ctrlr file not listed note.

[headkaze]

Thanks heaps for the input u_rebelscum, really appreciated

Okay, I got around to doing some actual testing in Mame and it does confirm to work the way you described. Here are my test results. (BTW I'm only interested in the way it works in Windows). There were a few times where it didn't act the way I expected. But I think it was because I manually created the config files. It seems you need to have Mame generate them for them to work. The mask/index/defvalue values seem to be important to Mame.

-- MAME Default --

Code: [Select]

P1_BUTTON1 : KEYCODE_LCONTROL
-- cfg\default.cfg --

Code: [Select]

<?xml version="1.0"?>
<!-- This file is autogenerated; comments and unknown tags will be stripped -->
<mameconfig version="10">
    <system name="default">
        <input>
            <port type="P1_BUTTON1">
                <newseq type="standard">
                    KEYCODE_A
                </newseq>
            </port>
        </input>
    </system>
</mameconfig>
-- cfg\1942.cfg --

Code: [Select]

<?xml version="1.0"?>
<!-- This file is autogenerated; comments and unknown tags will be stripped -->
<mameconfig version="10">
    <system name="1942">
        <input>
            <port type="P1_BUTTON1" mask="16" index="13" defvalue="16">
                <newseq type="standard">
                    KEYCODE_B
                </newseq>
            </port>
        </input>
    </system>
</mameconfig>
-- ctrlr\Test.cfg --

Code: [Select]

<mameconfig version="10">
<system name="default">
<input>
<port type="P1_BUTTON1">
<newseq type="standard">KEYCODE_C</newseq>
</port>
</input>
</system>
<system name="1942">
<input>
<port type="P1_BUTTON1">
<newseq type="standard">KEYCODE_D</newseq>
</port>
</input>
</system>
</mameconfig>
These are all tests running 1942

1. No config files
P1_BUTTON1 : KEYCODE_LCONTROL

2. With cfg\default.cfg only
P1_BUTTON1 : KEYCODE_A

3. With cfg\1942.cfg only
P1_BUTTON1 : KEYCODE_B

4. With cfg\default.cfg and cfg\1942.cfg
P1_BUTTON1 : KEYCODE_B

5. With cfg\default.cfg and cfg\1942.cfg and ctrlr\Test.cfg
P1_BUTTON1 : KEYCODE_B

6. With cfg\default.cfg and ctrlr\Test.cfg
P1_BUTTON1 : KEYCODE_A

7. With ctrlr\Test.cfg only
P1_BUTTON1 : KEYCODE_D

8. ctrlr\Test.cfg with 1942 config removed
P1_BUTTON1 : KEYCODE_C

So is that all I need to know to get the right key mapping? Can you please verify my results?

[Howard_Casto]

That looks about right to me.... there's one thing, I dunno if it's been fixed yet or not, that you need to be aware of though.  (And it's a real pain!)  The ctrlr file, which should work in a hierarchy, actually works from top to bottom.... so if the 1942 entry was above the default entry, the default would be used.  I ignore it myself because most people are aware of the glitch and organize their files accordingly (my ctrlr converter does this as well) but it's worth mentioning. 

The main thing to remember is those stupid cfg files override everything!  I really wish there was code in mame to optionally re-direct in-game remappings to the current ctrlr file (hint! hint! hint!).

Also as rebel explained, unfortunately some games have their keys hard-coded other than the default.  For a brief period (maybe 2 mame versions) cfg files printed out the default mappings when a game was launched, and thus we could get 100% accuracy, but as of now they don't, so there is no way of knowing.  I really wish somebody would add code to have only hard-coded changes print in the cfg file when the game starts (again hint! hint!). 

[headkaze]

Thanks Howard, I think that's about all I need to know.

The ctrlr file, which should work in a hierarchy, actually works from top to bottom.... so if the 1942 entry was above the default entry, the default would be used.

That is really annoying! I don't think I'll bother supporting that either. It's quite amazing how mind bending all this is really. So many little nuances and checks to make. But I guess thats all part of the challenge.

Cheers guys

[Howard_Casto]

Oh... also don't forget that the ctrlr file can have a driver entry (in this case cps1).  That is VERY useful and needs to be supported.  Again, I assume that the driver entries are above the rom entries.  And parent roms too....  If you have a sf2 entry it should work for sf2ce as well.  Just remember that this is the case for ctrlr entries and NOT cfg files.... modifying sf2 in-game does NOT effect sf2ce. 

[u_rebelscum]

... there's one thing, I dunno if it's been fixed yet or not, that you need to be aware of though.  (And it's a real pain!)  The ctrlr file, which should work in a hierarchy, actually works from top to bottom.... so if the 1942 entry was above the default entry, the default would be used.

Still there.  Start at first system in the file, check if it should be read, go to next, check, repeat till end of file.  Requires the user to do the hierarchy in the order the systems are put in the file, which can be lots of work if the ctrlr file gets big.  [shrug]

... I really wish somebody would add code to have only hard-coded changes print in the cfg file when the game starts (again hint! hint!). 

This is the way it is ATM.  Since the hardcoded is not "default", mame prints it out in the cfg.

It's quite amazing how mind bending all this is really. So many little nuances and checks to make. But I guess thats all part of the challenge.

It actually is fairly logical if you know the history and order features were added.  Not that it's easy, just that there's reasons why it's the way it is.


As for input changes in mame in general, Aaron hinted that it needs a major rewrite at some point.  He was talking about internally moving much of the code into the core and out of the OS specific area, and not about redesigning, but maybe that will be done too. 

[Howard_Casto]

... I really wish somebody would add code to have only hard-coded changes print in the cfg file when the game starts (again hint! hint!). 

This is the way it is ATM.  Since the hardcoded is not "default", mame prints it out in the cfg.

......
.....
.....
It actually is fairly logical if you know the history and order features were added.  Not that it's easy, just that there's reasons why it's the way it is.


As for input changes in mame in general, Aaron hinted that it needs a major rewrite at some point.  He was talking about internally moving much of the code into the core and out of the OS specific area, and not about redesigning, but maybe that will be done too. 

Can you give me an example (I lost all my notes in a hd crash some months back) because the last time I checked it didn't.  We might be talking about different things.  I left the code in there for it in j5 because, well it's already done and I assumed it'd be fixed eventually. 


....
....

Moving it into the core would make sense.  I mean the files are all ascii, so it's not like it couldn't be read in any os.  Xml is fairly non-os-specific as well.  I agree with you in that it actually makes a lot of sense, the only issues I've ever had is the ones we just brought up (although I'm still not fond of the xml, but I'll let that go). 

Imho all that needs done is to fix the hierarchy in the ctrlr file, add some method of editing them inside mame (solves a lot of newbie problems) and do something with the hardcoded inputs, and oddities like games that only have buttons 3-5 instead of the more sensical 1-3.  Probably what would be good for the hardcoded inputs would be to keep them all defaults instead and put a function in mame (similar to listxml) to print custom cfg files for said games. Then people who like em can use em and those who don't aren't stuck with the chore of manually editing all of those games.

[u_rebelscum]

... I really wish somebody would add code to have only hard-coded changes print in the cfg file when the game starts (again hint! hint!). 

This is the way it is ATM.  Since the hardcoded is not "default", mame prints it out in the cfg.

Can you give me an example (I lost all my notes in a hd crash some months back) because the last time I checked it didn't.

You're right, I'm wrong.   Mame puts it in the cfg if it's different from the hardcoded default, which is "default" normally, unless driver hardcoded, which makes that the default.

...and oddities like games that only have buttons 3-5 instead of the more sensical 1-3...

Yes, and buttons 1-3 + 7, where buttons 1-3 are used, and that out lying button is not AFAICT.  And that mame outputs in list.xml the wrong number of buttons in both cases, 5 in yours and 7 in mine.

[headkaze]

I've already hit my first hurdle in the magical world of Mame control mapping. I am quite happy to figure this one out myself, but I thought I'd post about it here and see what experience others have had.

So basically my goal is to get labels from controls.xml mapped to the right controls even if you have custom ctrlr, or cfg files. Lets for now just forget about ctrlr and cfg files for a minute. Lets assume the user is using the default keys.

I've taken Howards suggestion to use KEYCODE's to define controls on the CP, rather than P1_BUTTON1 etc. so that mapping is more accurate.

So my first problem comes to light when getting the labels for tnk3. The output looks like this:

Code: [Select]

KEYCODE_LCONTROL: Fire
KEYCODE_LALT: Cannon
KEYCODE_UP: Up
KEYCODE_DOWN: Down
KEYCODE_LEFT: Left
KEYCODE_RIGHT: Right
KEYCODE_LEFT: Aim Left
KEYCODE_RIGHT: Aim Left
So KEYCODE_LEFT and KEYCODE_RIGHT (by default is P1_JOYSTICK_LEFT and P1_JOYSTICK_RIGHT). Why does it end up being assigned to "Aim Left" and "Aim Right" instead of "Left" and "Right"?

Okay lets take a look at the controls.xml entry for tnk3...

Code: [Select]

<game romname="tnk3" gamename="T.N.K. III (US)" numPlayers="2" alternating="1" mirrored="1" usesService="0" tilt="0" cocktail="1">
<miscDetails>
This rotary is a unique one.  It almost looks like a dial at first glance, but the dial can also be shifted in 8 directions, just like a rotary 8-way.
</miscDetails>
<player number="1" numButtons="2">
<controls>
<control name="8-way Rotary Joystick(Optical)">
<constant name="joy8way"/>
<constant name="dial"/>
</control>
<control name="Misc">
<constant name="other"/>
</control>
</controls>
<labels>
<label name="P1_BUTTON1" value="Fire"/>
<label name="P1_BUTTON2" value="Cannon"/>
<label name="P1_JOYSTICK_UP" value="Up"/>
<label name="P1_JOYSTICK_DOWN" value="Down"/>
<label name="P1_JOYSTICK_LEFT" value="Left"/>
<label name="P1_JOYSTICK_RIGHT" value="Right"/>
<label name="P1_DIAL" value="Aim Left"/>
<label name="P1_DIAL_EXT" value="Aim Right"/>
</labels>
</player>
</game>
If we take a look at P1_DIAL and P1_DIAL_EXT (not sure why it's called that, there is no P1_DIAL_EXT in Mame), you will set it's mapped to "Aim Left". Now if we take a look at the Mame defaults we will understand why it ends up being mapped the wrong way.

Code: [Select]

INPUT_PORT_DIGITAL_DEF( 1, IPG_PLAYER1, JOYSTICK_LEFT, "P1 Left",
SEQ_DEF_3(KEYCODE_LEFT, CODE_OR, JOYCODE_1_LEFT) )

INPUT_PORT_DIGITAL_DEF( 1, IPG_PLAYER1 JOYSTICK_RIGHT, "P1 Right",
SEQ_DEF_3(KEYCODE_RIGHT, CODE_OR, JOYCODE_1_RIGHT) )

INPUT_PORT_ANALOG_DEF ( 1, IPG_PLAYER1, DIAL, "Dial",
SEQ_DEF_3(MOUSECODE_1_ANALOG_X, CODE_OR, JOYCODE_1_ANALOG_X),
SEQ_DEF_3(KEYCODE_LEFT, CODE_OR, JOYCODE_1_LEFT),
SEQ_DEF_3(KEYCODE_RIGHT, CODE_OR, JOYCODE_1_RIGHT) )
Now it becomes at bit more obvious whats going wrong here. Both KEYCODE_LEFT and KEYCODE_RIGHT are assigned to P1_DIAL, so that is overriding P1_JOYSTICK_LEFT and P1_JOYSTICK_RIGHT.

Now here comes the question, if you use keycodes to define the controls on your panel, how do you know which keycodes to remap when there is multiple mappings like this? Also how do you know which keycodes are supposed to be for player 1 or player 2 for mirroring controls? I can only assume that Johnny 5 does this by requiring a ctrlr file that defines what controls are what. Is that correct?

[u_rebelscum]

I've already hit my first hurdle in the magical world of Mame control mapping. I am quite happy to figure this one out myself, but I thought I'd post about it here and see what experience others have had.

You found one of the games with inputs hardcoded in the driver that are different from default that howard and I were talking about.   The driver hardcodes the dial inputs to something different than default because the defaults would cause the input conflict you are seeing.  (Actually, if left to defaults, pressing left would move the player left and spin the player counterclockwise.)

So basically my goal is to get labels from controls.xml mapped to the right controls even if you have custom ctrlr, or cfg files. Lets for now just forget about ctrlr and cfg files for a minute. Lets assume the user is using the default keys.

I've taken Howards suggestion to use KEYCODE's to define controls on the CP, rather than P1_BUTTON1 etc. so that mapping is more accurate....

Now here comes the question, if you use keycodes to define the controls on your panel, how do you know which keycodes to remap when there is multiple mappings like this? Also how do you know which keycodes are supposed to be for player 1 or player 2 for mirroring controls? I can only assume that Johnny 5 does this by requiring a ctrlr file that defines what controls are what. Is that correct?

The problem is the game hardcoded different inputs for dial and dial_ext (the digital - and + of an analog input).  Currently you can't look in the cfg files to see what the hardcoded inputs were changed to.  Basically, you need ctrlr file that duplicates the hardcoded inputs, or cfg files that change the hardcoded values to something else.  Which require you to know which are hardcoded.

You're using the defaults for player 1, right?  Just use mames defaults for player 2.  Or am I missing what you're talking about

Maybe you might not be visioning "keycodes on the CP" correctly for what you are trying to do.  Your controls are keycodes (or joycodes if you use gpwiz or gamepad hack).  That button you think of as P1B1 sends the computer the keycode 'G' for example, not P1B1.  Mame does not know the upper left most button in the left set of buttons is supposed to be P1B1, mame knows what keycodes are mapped to P1B1 and if those keycodes are pressed or not.  If that keycode is at that location, then it's P1B1 for those games that mapped like that.

CP (keycode) --> mame input map (including ctrlr cfg and hardcode) --> control type in game (P1B1)
controls.xml (P1B1) --> mame input map --> keycode --> which button on your CP that should have that label

I see two solutions for your problem.  First is let a keycode have more than one label, since that's fine with mame.  It might help people figure why spyhunter shoots and goes faster when "P1B1" is pressed and other conflicting mappings.  Second is to fix mame so it outputs the hardcoded maps, or add to your app a way to read such hardcoded remaps.

[Howard_Casto]

Exactly.

The beauty of using keycodes is your parser doesn't know (or care) what mame constant it's binded to.  When you come up with a game that has a label for p1_joystick_up, you run that mame constant through all the mapping heirarchy (default.cfg, ctrlr, ect.....) to determine which is which and then it takes that label and pastes it over that keycode.  By reading the analog settings (if joystick/mouse is enabled, and which auto-enablers are active via the new "_device" settings) you can make the layout prettier by turning off disabled keycodes for said game, but you really don't know which to display so you display all with a valid match.  So if your 8 way joystick and 4 way joystick are using the same keycodes then they both get the labels, which is why johnny5 supports layouts based on control type.  I *think* that was part of what you were asking.  Now on to the other parts:

See what rebel said, that game is hard-coded so there isn't much we can do about it.

To get the defaults that are NOT remapped I wrote a little program that reads the mame source and gets the defaults that way.  Seeing how mame changes it's source so often anymore, it might not work.  I probably still have it if you want it though.  It basically reads the source and makes a old ini-style ctrlr file of the defaults.  I include the file with j5 and update it once in a while.  But to answer your question, yes I do read the default.cfg and ctrlr files as well, along with individual game cfgs and individual game inis (to get analog settings changed by ini files) as well as driver and clone-based inis. 

People wonder why j5 takes a sec to display controls, I have to check and parse about a dozen files before I even get to the displaying part. 

[headkaze]

Thanks guys I really appreciate your help, and will be putting a thanks in the credits.

You're using the defaults for player 1, right?  Just use mames defaults for player 2.  Or am I missing what you're talking about?

Yes, I was obviously not realising the obvious there. It was getting late when I posted that. It works fine now.

By reading the analog settings (if joystick/mouse is enabled, and which auto-enablers are active via the new "_device" settings) you can make the layout prettier by turning off disabled keycodes for said game, but you really don't know which to display so you display all with a valid match.  So if your 8 way joystick and 4 way joystick are using the same keycodes then they both get the labels, which is why johnny5 supports layouts based on control type.  I *think* that was part of what you were asking.  Now on to the other parts:

Hmm not sure what you mean by the new "_device" settings. Maybe I will release my program first and then people can request "can you add support for".. and then I can figure it out as I go. Also with joystick mouse enabled do you mean by the -joystick -mouse command line options? Are these stored in ini\Mamexx.ini too?

To get the defaults that are NOT remapped I wrote a little program that reads the mame source and gets the defaults that way.  Seeing how mame changes it's source so often anymore, it might not work.  I probably still have it if you want it though.  It basically reads the source and makes a old ini-style ctrlr file of the defaults.  I include the file with j5 and update it once in a while.  But to answer your question, yes I do read the default.cfg and ctrlr files as well, along with individual game cfgs and individual game inis (to get analog settings changed by ini files) as well as driver and clone-based inis. 

I would like to see this program if thats okay. Also if you could explain to me where is the Mame source these custom mappings are located?

EDIT: Also forgot to ask what is "DIAL_EXT"? There is no default mapping for this in mame so how do I handle the label for it?

[Howard_Casto]

I'm not talking about custom mappings, I'm talking about the mame default.  You know p1 up is the up key, ect...?  It'll take me a while to hunt up that app.

By device i mean the paddle_device joystick_device, whatever that are at the bottom of the mame.ini file.  This act as auto-switches to turn on and off -mouse, -joystick and -lightgun depending upon the control.

Yes the ini files can do this, amoung other things.  You can put anything from the mame.ini into a game/clone/driver based ini file in your ini folder. 

You do know that you have to parse the mame ini file and all of it's settings (particularly ctrlr, and all the previously mentioned analog settings) to accurately get the data right?  And then you have to check for the driver/clone/parent versions because those can totally change the value yet again.

Dial_ext is basically dial+

In your controls.ini kit on the homepage, there should be a translation file, basically you keep running things through this file and eventually you get the constant.  It's a little to technical to get into on this thread.  (dial and dial_ext are the internal names used in game drivers btw).  I have like three pages of code to handle analog mappings in j5 because it can either be an analog axis mapped to both directions (so you have to manually duplicate the keycode for both labels) or individual axis/buttons.   Or for even more confusion, it can be both at the same time!  UGH!

[Howard_Casto]

STOP THE PRESSES!!!! LITERALLY IF YOU ARE WORKING ON A VIEWER YOU MIGHT AS WELL STOP NOW AND WAIT UNTIL THE SMOKE FROM .116U1 CLEARS!!!

To quote from the latest whatsnew.txt:

"Added support for multiple keyboards: [Andrew Kuruhin]
 - added multikeyboard input support through RAWINPUT mechanism
    (up to 8 simultaneous keyboard inputs
 - fixed RAWINPUT device registry enumeration bugs
"


Now I haven't seen the code yet, so I might be overreacting, but I don't see how this could cause anything but pure chaos!  The keycode constants will have to be diferent now right?  The keycode constants that have been the same since almost the initial release of mame, those are null and void? Surely, hopefully they had the sense to keep the current constants and just add to them, because if not this will be like that horrible multiple mouse de-backle except you'll have to manually change every single input on your mame cab!  Not only that but now you can't use your keyaord for testing because it'll be keyboard 1 and your encoder will be keyboard 2. 

I'll check it out to see and report back here.  Even best case scenario, we have a whole new batch of constants to add, worst case all the current ones are null and void.

[headkaze]

STOP THE PRESSES!!!! LITERALLY IF YOU ARE WORKING ON A VIEWER YOU MIGHT AS WELL STOP NOW AND WAIT UNTIL THE SMOKE FROM .116U1 CLEARS!!!

To quote from the latest whatsnew.txt:

"Added support for multiple keyboards: [Andrew Kuruhin]
 - added multikeyboard input support through RAWINPUT mechanism
    (up to 8 simultaneous keyboard inputs
 - fixed RAWINPUT device registry enumeration bugs
"


Now I haven't seen the code yet, so I might be overreacting, but I don't see how this could cause anything but pure chaos!  The keycode constants will have to be diferent now right?  The keycode constants that have been the same since almost the initial release of mame, those are null and void? Surely, hopefully they had the sense to keep the current constants and just add to them, because if not this will be like that horrible multiple mouse de-backle except you'll have to manually change every single input on your mame cab!  Not only that but now you can't use your keyaord for testing because it'll be keyboard 1 and your encoder will be keyboard 2. 

I'll check it out to see and report back here.  Even best case scenario, we have a whole new batch of constants to add, worst case all the current ones are null and void.

I see what you mean Howard, this could indeed turn things ugly. K1_LALT, K2_CONTROL, K3_ESC? If so that would mean a fair bit of re-writing for the CP viewers. I hope your wrong about this but I guess these things happen in the world of Mame. I have written a fair chunk of my controller mapping code already. You know this could mean they will change the default inputs for multiple keyboards too. It's definately a cool idea for people without arcade cabs but if your right about an IPAC being treated as a second keyboard it could be a total nightmare for everyone with one. I personally think (and hope) they impliment this feature with caution! (fingers crossed)