Aaron removes xml2info as of u12 (in other words, we are screwed)

[krick]

yeah figured that out and promptly deleted the whole mess as it isn't really needed if you know the xml version. 

Actually, you can't just delete the DTD.  The DTD defines default values for some attributes so they don't need to be explicitly spelled out in the actual XML data.  See "runnable", "status", etc...

[Howard_Casto]

I haven't ran into any issues yet, with or without the dtd. 

I suppose it depends on what you are doing to the data.

[krick]

I've updated my xml2info XSL Transformation again.  This time, it's just a lot of cleanup and re-formatting but it's FAR easier to follow now.  This is what a one day crash course in XSLT will get you.

As usual, anyone who's interested can get it from my xml2info page...

http://mame.3feetunder.com/xml2info/

[Howard_Casto]

Added multiple input controls in -listxml output for games with more
than one type. Added pedal control type. Added more info on analog
controls as defined in the driver: minimum, maximum, sensitivity,
keydelta, and reverse. This required the 'control' attribute in the
XML to be moved into an element. There can now be more than one
'control' element in the input secction. [uRebelScum]

This does sound good

Yes... this is the good news.  And as I'm always one to turn a negative into a positive:

http://fe.donkeyfly.com/forum/index.php?topic=119.msg1342#msg1342

 

[Minwah]

Yes... this is the good news.  And as I'm always one to turn a negative into a positive:

http://fe.donkeyfly.com/forum/index.php?topic=119.msg1342#msg1342

 

Good stuff

Aside from actually parsing the stuff from -listxml, this is gonna slightly mess up my filtering in Mamewah a touch...having multiple control types.  I might just join them into one string for the sake of getting it to work again quickly...

[Minwah]

I've updated my xml2info XSL Transformation again.

Works very well as far as I can tell...thank you

[krick]

Aside from actually parsing the stuff from -listxml, this is gonna slightly mess up my filtering in Mamewah a touch...having multiple control types.  I might just join them into one string for the sake of getting it to work again quickly...

In my XSL transform, I just grab the first display and the first control and ignore the rest because that produces output that matches the old listinfo format.  Of course, if you want to offer proper filtering by number of screens or types of controls, then you'll have to do something different.

The XSL transform is easy enough to modify to output multiple screen items and input items if you want it that way.  Or you can just do the right thing and write the XML parser. 


Oh, and here's a tip for anyone parsing the XML:

If you want to determine if a game is vertical, you can do it like this...

convert the "rotate" attribute to an integer (r), then...

boolean vertical = ( ( ( r / 10 ) mod 2 ) != 0 )

[Howard_Casto]

what I do with the control types is I merge them together and then slap the input element on the end.... the result looks exactly the same as the ol listinfo output except now you cna have strings like

joy8way trackball buttons 2 coins 2 players 2 instead of only the first control


As for display types I just ignore all the data but the first one.  I dare you to find a multi-monitor game in which the secondary monitor runs at a different res.  The vertical and horizontal deal isn't a big thing.  Horizontal games are gonna be 0 or 180 (those odd-ball games that project through a mirror) vertical is everything else.  What does stupify me is the fact that now the dimensions aren't rotated with the native orientation.  I can't see the logic in that one myself. 

[krick]

As for display types I just ignore all the data but the first one.  I dare you to find a multi-monitor game in which the secondary monitor runs at a different res.

MAME currently has a few "multi-display" games where the second and third display are small monochrome LCD screens.  They definitely have different resolutions and I'm not really sure about the refresh rate but I assume it's probably not the same.

In the future, I think you'll see things like single line LCD readouts and seven segment LEDs showing up under the "display" tag too.

[Howard_Casto]

I'm gonna need some examples, cause I haven't run across them.

[krick]

I'm gonna need some examples, cause I haven't run across them.

Thanks to the magic of XSL...

housemnq:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
housemn2:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
livegal:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
bijokkoy:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
bijokkog:
   display  -  width:512  height:224
   display  -  width:480  height:64
   display  -  width:480  height:64
mt_beast:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_shar2:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_stbld:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_ggolf:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_gsocr:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_asyn:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_shnbi:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_aftrb:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_tfor2:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_astro:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_lastb:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_wcsoc:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_tetri:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_gng:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_shang:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_gaxe:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_mystd:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_revsh:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_parlg:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_tgolf:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_tlbba:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_cols:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_eswat:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_smgp:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_mwalk:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_crack:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_arrow:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_astrm:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_bbros:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_sonic:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_sonia:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_fshrk:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_gaxe2:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_stf:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_mlh:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_kcham:
   display  -  width:256  height:192
   display  -  width:320  height:224
mt_soni2:
   display  -  width:256  height:192
   display  -  width:320  height:224

...there may be more.  I just printed out the ones where the with on the first display isn't equal to the width on the second display.

[Howard_Casto]

thanks... had the same idea though

yeah i just went through a filter myself and tried every single dual screen game (ugh)

The one's the use the lcds are japanese mahjong porn, so nobody really cares about those.  Also the extremely squased aspect would make it difficult to display on multiple monitors. 


The mega tech are a different res, but they are both stretched to the same aspect. Apparently the mt cab's selection display was smaller, and they didn't see the need to use hi-res output on it. 

One I did run into that seems really odd, even though mame reports it as bothscreens being the same is :

rocknms (Rockin' Mega Session)

 The top monitor appears to be horizontally oriented while the bottom is vertically oriented.  This isn't reflected in the output, probably because a custom layout had to be made to show both screens in the proper layout on a dual screen monitor. 


My point is the display stuff seems to be a tad inconsistant.  It's also rather hard to tell anything from the data.  So for now, until the fields are fleshed out a little more (such as display number or display position) it might be best to leave all but the first (which is always the primary display) out. 

[u_rebelscum]

Coming in late again....

Added multiple input controls in -listxml output for games with more
than one type. Added pedal control type. Added more info on analog
controls as defined in the driver: minimum, maximum, sensitivity,
keydelta, and reverse. This required the 'control' attribute in the
XML to be moved into an element. There can now be more than one
'control' element in the input section.

Do you guys have anything else that you want added to the listXML input controls data set? 

Things I'm considering of:
- Krick mentioned cases where the players have different controls. 
- The (v)2/4/8-way, (v)dial & (v)paddle types handle the single X, single Y, and both X & Y cases, but the rare cases where only one axis of the analog stick or trackball (DOT) is not. (Opps, the vertical dial and paddle types are not checked for, either.)
- Krick also suggested putting the buttons as another control type.  I'm thinking as it's own element, but only if it needs something extra like:

• Show if different players have a different number of buttons. (see examples)
• Show if the start button exists in the driver.  Most games have start buttons, others do not although sometimes mame fakes it by mapping a fake one to (another) the game's button 1.  But then there's the two player alternating games with more starts than players (DOT), hmm...

The players could have the controls item under them, or vice versa.  I'm thinking put the players sub the controls, with the default player to "All", leave the start buttons item out and add the axis item to replace the special "v---" types.  So I'm thinking, as examples:

For normal two player, one button & one 4-way per player:

Code: [Select]

<input players="2" coins="2">
<buttons number="1"/>
<control type="joy4way"/>
</input>
For two player, two buttons & ADstick for player 1 & four buttons for player 2, no start buttons:

Code: [Select]

<input players="2" coins="2">
<buttons number="2" player="1" start="No"/>
<buttons number="4" player="2" start="No"/>
<control type="stick" sensitivity="100" keydelta="10" player="1"/>
</input>
Basebal2 (IMO, the buttons should be emulated more like above example, but that's for another discussion):

Code: [Select]

<input players="2" coins="2" tilt="yes">
<buttons number=6 player="1"/>
<control type="stick" sensitivity="100" keydelta="10"/>
</input>
DOT:

Code: [Select]

<input players="1" coins="2" tilt="yes">
<buttons number="4"/>
<control type="joy8way"/>
<control type="dial" sensitivity="50" keydelta="10" reverse="Yes"/>
<control type="trackball" sensitivity="100" keydelta="10" axis="Y"/>
</input>

An alternative is putting the control sub to the player (Basebal2 example):

Code: [Select]

<input players="2" coins="2" tilt="yes">
<player number="1"/>
<buttons number=6 player="1"/>
<control type="stick" sensitivity="100" keydelta="10"/>
</player>
<player number="2"/>
<control type="stick" sensitivity="100" keydelta="10"/>
</player>
</input>
However, since most games have the same inputs and with the players number defaulting to "All", though, it would be not be nice IMO (DOT example):

Code: [Select]

<input players="1" coins="2" tilt="yes">
<player>
<buttons number="4"/>
<control type="joy8way"/>
<control type="dial" sensitivity="50" keydelta="10" reverse="Yes"/>
<control type="trackball" sensitivity="100" keydelta="10" axis="Y"/>
</player>
</input>Somehow the players attribute in the input could be moved to inside the players element, but I don't know how to put "total number of players" vs "this player number" clearly.


Better suggestions?  Improvements?  Additions?

[SirPoonga]

Heh, urebel, you know everything you mentioned is how controls.dat works   We assume controls are for all unless player2 or greater is specified.  So I would agree with your last two examples.

If you haven't looked at the controls.dat format take a peek, it might give ideas.

[Howard_Casto]

Something that's key that is missing, is the status of play... if it's alternating or not.  This tells you if it's a two player game with one set of controls (like pacman) or a two player game with two sets of controls (like street fighter).  With that, the basic data is there. 


Also I don't think controls.dat specifically is written for this, but this is how I handle those rare instances like dotron you were mentioning in J5:

If all of the controls are used for a control type then the control type constant is used  (like trackball or joy8way) but if some aren't used then each individual input is treated as a control  (control p1_trackball_Y+ and controls p1_trackballY- or whatever)  of course this is a bad example as for analog controls you can just define the axis and up and down is assumed, but for a digital example you would give both directions. 

I really like the new way you've arranged it btw.  Any chance of you fixing the missing elements in the ctrlr files?  Like allowing you to reverse the axis, set the sensitivity or define a bit offset for those odd-ball inputs?

[krick]

Heh, urebel, you know everything you mentioned is how controls.dat works   We assume controls are for all unless player2 or greater is specified.  So I would agree with your last two examples.

If you haven't looked at the controls.dat format take a peek, it might give ideas.

I'd really like to see MAME document the controls better and I think that fits in with MAME's goals.

I looked at the controls.dat XML version and I think that it's a bit "string" heavy but definitely along the lines of what is needed in MAME.  I definitely like each button having its own element so you can attach attributes like "Fire" and "Hyperspace" to them.  Button names/functions should definitely documented in MAME.


The biggest problem I see is convincing the MAME devs to go along.

Check out this thread to see what I mean...

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

It appears that Haze is against it, and R. Belmont seems indifferent.  Based on my experiences with Aaron, I think that he will be for it.  I don't really know enough about the other devs to know how they'd feel.

[Howard_Casto]

Ehh I dunno about the internalizing of controls.dat..... things get corrected and altered all the time.  Plus we get a lot more volunteers due to how easy it is to make a submission.  If someone had to modify the mame source to add and entry, that'd be rough.  Now having mame be able to read an externalized controls.dat into itself and label the buttons in the ui... that seems like a good idea.  It should be fairly doable considering we use the same input constants as mame. 

[krick]

Code: [Select]

<input players="1" coins="2" tilt="yes">
<player>
<buttons number="4"/>
<control type="joy8way"/>
<control type="dial" sensitivity="50" keydelta="10" reverse="Yes"/>
<control type="trackball" sensitivity="100" keydelta="10" axis="Y"/>
</player>
</input>Somehow the players attribute in the input could be moved to inside the players element, but I don't know how to put "total number of players" vs "this player number" clearly.

stupid tabs aren't working but I think you can figure out what I mean...

There's two ways that I think you could go.

The first way has a "player" tag that contains the controls for a player.  If both players share one set of controls, then there is only one "player" group...

For Defender...

Code: [Select]

<input players="2" format="alternating" coins="2">
<player>
<control type="button" name="Start"/>
<control type="joy2way" axis="y" name="Move"/>
<control type="button" name="Fire"/>
<control type="button" name="Thrust"/>
<control type="button" name="Smart Bomb"/>
<control type="button" name="Hyperspace"/>
<control type="button" name="Reverse"/>
</player>
</input>
For Smash TV...

Code: [Select]

<input players="2" format="simultaneous" coins="2">
<player>
<control type="button" name="Start"/>
<control type="joy8way" name="Move"/>
<control type="joy8way" name="Fire"/>
</player>
</input>
For a made up game where player 1 and player 2 have different controls and
the fire button doubles as the start button...

Code: [Select]

<input players="2" coins="2">
<player>
<control type="joy8way"/>
<control type="button" name="Fire"/>
</player>
<player>
<control type="trackball" sensitivity="100" keydelta="10" axis="y"/>
<control type="button" name="Fire"/>
</player>
</input>
Or we could do something completely different and try to just document the
physical controls attached to the machine and use the name to indicate how
they are used by the players:

For Defender...

Code: [Select]

<input players="2" format="alternating" coins="2">
<control type="button" name="P1 Start"/>
<control type="button" name="P2 Start"/>
<control type="joy2way" axis="y" name="Move"/>
<control type="button" name="Fire"/>
<control type="button" name="Thrust"/>
<control type="button" name="Smart Bomb"/>
<control type="button" name="Hyperspace"/>
<control type="button" name="Reverse"/>
</input>
For Smash TV...

Code: [Select]

<input players="2" format="simultaneous" coins="2">
<control type="button" name="P1 Start"/>
<control type="button" name="P2 Start"/>
<control type="joy8way" name="P1 Move"/>
<control type="joy8way" name="P1 Fire"/>
<control type="joy8way" name="P2 Move"/>
<control type="joy8way" name="P2 Fire"/>
</input>
For a made up game where player 1 and player 2 have different controls and
the fire button doubles as the start button...

Code: [Select]

<input players="2" format="simultaneous" coins="2">
<control type="joy8way" name="P1 Move"/>
<control type="button" name="P1 Fire"/>
<control type="trackball" name="P2 Aim" sensitivity="100" keydelta="10" axis="y"/>
<control type="button" name="P2 Fire"/>
</input>

I think that this second option fits more in with what MAME is about: documenting the hardware.

[Howard_Casto]

That creates a ton of bulk though.... again  controls.dat has already dealt with this problem. 

You don't brecket stuff by player.. you read two flags

alternating and mirrored controls. 


Alternating means that players take turns.  Mirrroed means that although each player has his or her own control set, they all have the same control set. 

The best example I can get is tmnt. 

All you need to say is that it's a 4 player simultaneous play game with mirrored controls. 

With this data it's only necessary to post the controls for player 1 (joy8way with two buttons with the labels attack and jump).  Keeps a large list from data from becoming an insainely huge one. 

Again though, I do not think it makes a lot of sense to include this data internally with mame. 

[krick]

Again though, I do not think it makes a lot of sense to include this data internally with mame. 

Most of the data is already in MAME in the form of input definitions.  We're trying to come up with some way of dumping the internal input definitions into the XML so it can be more useful.

For the first pass at this output, we should just concentrate on dumping all the inputs, similar to the way all the dipswitches are dumped.  Then on the second passs, we can look at adding some grouping and/or organization information into MAME to enhance the XML dump.

I'm still partial to listing every separate button as a control.  I'm debating whether we should list each directional input as well and group them with a "joystick" tag if appropriate.  Something like this...

For Defender...

Code: [Select]

<input players="2" format="alternating" coins="2">
<button name="P1 Start"/>
<button name="P2 Start"/>
<joystick>
<direction name="Up">
<direction name="Down">
<joystick>
<button name="Fire"/>
<button name="Thrust"/>
<button name="Smart Bomb"/>
<button name="Hyperspace"/>
<button name="Reverse"/>
</input>
Or maybe...

Code: [Select]

<input players="2" format="alternating" coins="2">
<button name="P1 Start"/>
<button name="P2 Start"/>
<joystick type="2way" axis="y" name="Move"/>
<button name="Fire"/>
<button name="Thrust"/>
<button name="Smart Bomb"/>
<button name="Hyperspace"/>
<button name="Reverse"/>
</input>

[Howard_Casto]

well... actually it isn't in mame.  Mame doesn't use manual/cpo accurate label descriptions. 

Asteriods is a prime example:

First off some of the labels are slightly off from the official cpo labels.  Secondly it's mapped to a joystick, which is wrong as asteroids actually used pushbuttons.  (This is fixed in controls.dat by the direcitonal buttons constant.)

So it's less of a documeting thing in mame and more of a "this description was added because the button mappings are confusing and the full label name was altered to fit in the ui."  Not that they aren't appreciated mind you, I'm just saying they don't have anything to do with the documentation aspect or else they'd be more accurate.   


It's a waste of space to output, say directions for a joystick unless it's a special case.  Simply defining defender as a vjoy2way (which is a mame control constant) tells you that there is an up and down and of course they would be labeled up and down.  There isn't a need to define each direction. 

I'm not sold on the individual button entries either.  Some of the classics have captions for the button function, but most don't.  Around 90% of the listxml file would be "<button name=p1_button1/>" ect....

I actually liked it better early on in the xml cfg file's history when all the possible inputs were printed in the cfg, even ones that weren't remapped.  Made more sense to have it there for me as most (note I said most) people could care less about that data. 

While we are on that tangent...... Somebody really needs to modify the cfg files so that they always print hardcoded remaps even if they haven't been changed by the user.  It was in there for a while and it was great... j5 and those types of viewers potentially were 100% accurate as even keys that were internally remapped from their defaults could be read. 

Makes sense to me.... a user always assumes that button 3 on a game is space and it throws them for a loop when they find out the driver author remapped that button to "a" for this particular game or what have you.  So that kind of craziness definately needs to be documented somehow. 

[Minwah]

I like much of the stuff mentioned here...I think the key is getting as much useful stuff we can, but not being so over complicated that the MAMEdev don't accept it.  IMO the multiple control types is a huge step forward already, combined with no. buttons is pretty decent info for a good number of games.

I like the second system shown by u_rebel...if the issues with the ctrlr files (HC & I have touched on) were sorted too then I think we should be pretty happy fella's

[SirPoonga]

Krick, what do you mean by string heavy?  Just curious as I am always looking for ways to improve the project.

When I designed the xml format I went with the suggestions most books give.  Use attributes as they are faster to parse with some parsers, etc...  times have probably changed and it may need improvement.

Also one thing controls.dat does is assocciate button with a control.  Like the dotron triggerstick has two buttons on it that are player 1's button 1 and 2.  The other thing is there is more resolution on type of controls.  Like you can sort by 360 degree steering wheel or spinner instead of just dial.  That type of stuff I don't see being internalized in mame.  However, I could see that controls.dat be treated like other dat files as an add-on.

HowardC, going to bring up the service button issue? *hint hint*

[krick]

Krick, what do you mean by string heavy?  Just curious as I am always looking for ways to improve the project.

No need to worrry, I didn't make myself clear.  I meant that the content of the controls.dat includes a lot more "text" than the MAME devs would be comfortable with in the -listxml output.  Mainly the "miscDetails" content, but I'm sure we'd get resistance to adding functional labels for the buttons as well. I personally think button functions are a really important part of documentation but Haze (and possibly other devs) worry that all the extra text will bloat the source and make the EXE a lot larger.

I think the ultimate solution for MAME is to have an XML file for each game that defines all the control, display, and dipswitch, roms, etc... information.  These files can be either parsed in at runtime (probably not likely) or translated into actual code at compile time.  If you look at the source for most of the drivers, they look like just a bunch of macros for the most part.  There's no reason that that information can't be generated from XML files.

The upside is that the XML files can include more information than MAME actually uses so it provides a convenient place for further documentation.

[AaronGiles]

I personally think button functions are a really important part of documentation but Haze (and possibly other devs) worry that all the extra text will bloat the source and make the EXE a lot larger.

That's a bit of a mischaracterization. The reason is that right now in many cases there can be one set of input port definitions for multiple games on a system. If you started adding descriptions for the buttons to each port, then you have to create separate input port defs for each game in a driver. So neogeo.c would be polluted with 200+ input port definitions, etc. This also hides all the commonalities of the inputs and makes it difficult to understand how one set of inputs maps differently from others. It really hinges on source code readability.

That said, I think there are ways to fix this. Basically, get rid of the existing way of naming input ports, and have some mapping that says IPT_BUTTON1 = "Jump" for this game. And have that information be separate from the input port definitions. Which is basically controls.dat, as far as I understand it. Whether or not that data should be internal to MAME is a good question. Some of the devs want to push some of MAME's current data out of the EXE and into other files (XML, sorry Howard), while others like to have the "canonical" data stored in the EXE where it is guaranteed to be verified through a known process.

Plus, input port names technically don't matter at the PCB level, which is officially what MAME focuses on emulating. But if we were super sticklers about that, then even joysticks would be mapped as raw switches, the DIP switch information wouldn't be provided, and we wouldn't provide any control mapping. I can hardly claim consistency on anything in MAME (nor would I want to).

[krick]

I personally think button functions are a really important part of documentation but Haze (and possibly other devs) worry that all the extra text will bloat the source and make the EXE a lot larger.

That's a bit of a mischaracterization. The reason is that right now in many cases there can be one set of input port definitions for multiple games on a system. If you started adding descriptions for the buttons to each port, then you have to create separate input port defs for each game in a driver. So neogeo.c would be polluted with 200+ input port definitions, etc. This also hides all the commonalities of the inputs and makes it difficult to understand how one set of inputs maps differently from others. It really hinges on source code readability.

I was just simplifing the issue for purposes of discussion but that's basically what I meant when I said "bloat the source".   The obvious side effect being a loss in readability.

That said, I think there are ways to fix this. Basically, get rid of the existing way of naming input ports, and have some mapping that says IPT_BUTTON1 = "Jump" for this game. And have that information be separate from the input port definitions. Which is basically controls.dat, as far as I understand it. Whether or not that data should be internal to MAME is a good question. Some of the devs want to push some of MAME's current data out of the EXE and into other files (XML, sorry Howard), while others like to have the "canonical" data stored in the EXE where it is guaranteed to be verified through a known process.

Plus, input port names technically don't matter at the PCB level, which is officially what MAME focuses on emulating. But if we were super sticklers about that, then even joysticks would be mapped as raw switches, the DIP switch information wouldn't be provided, and we wouldn't provide any control mapping. I can hardly claim consistency on anything in MAME (nor would I want to).

I'm definitely in the camp that wants to push the extraneous data out of MAME.  All input ports/switches/buttons/etc... should be just numbered/enumerated using some democratically agreed upon system.  Then external XML files for each game could define what these ports/switches/buttons "mean" for that game and how they relate to each other.  The MAME UI can then look at these files to get the text to display when the menus are shown.

If you want, each version of mame can include a zip archive with all the latest XML game mapping files.  Or if you really want to get fancy, you could probably put them in a folder, zlib compress the folder, and imbed them into the exe itself like a resource.  That way, they're not physically mixed in with the source code, but they are still "canonical" data stored in the EXE.

[SirPoonga]

And have that information be separate from the input port definitions. Which is basically controls.dat, as far as I understand it. Whether or not that data should be internal to MAME is a good question. Some of the devs want to push some of MAME's current data out of the EXE and into other files (XML, sorry Howard), while others like to have the "canonical" data stored in the EXE where it is guaranteed to be verified through a known process.

Yep, that's a simple summary of controls.dat.  Not only is it for labelling controls it is for higher resolution sorting of controls.  Like I said earlier, you can sort by 360 steering wheel instead of dial (which would include the spinner games too).

I agree is not putting the info in mame.  I like how history.dat is outside of mame and optional.
It's also makes it easier for non-programmers to add info or correct it.

Krcik, yeah, I figured that was what you meant.  miscDetails is there to be the catch all since games do not use standardize control layouts   Some of the games are even too wordy for my liking but there is no other good way to document the controls in an easy and consistant way to parse.

[Howard_Casto]

You and me both.  Control constants are sometimes "bastardized" for lack of a better word to piece together inputs for odd-ball games with strange control schemes.  It makes documenting our end of stuff very difficult.  On the other hand, I wouldn't want to subject mame users to the horror of opening up the ui only to find "input 1-input 12" and have those guys try to figure out which ones are joystick directions and which ones are buttons.  

If ctrlr files supported bitmasks and all that fanciness it wouldn't be that much of an issue... an external doc could bind itself to the port "address"  and it wouldn't matter if mame called that port "p1_button1" or "p1_joystick_up."


Btw Aaron, while I'm completely in agreement with you on this one, neogeo is a bad example.  A person could document the game's control functions, but what we do (since it is easier to verify and standardize) is to document the official label given on the cpo or if that isn't available the instruction card, manual ect.... in game descriptions of a control are a last resort.  Anyway, the "official" labels for every single neogeo game with the exception of the prototype game with the spinner and irritating maze are A, B, C, D  just like the mvs cpos.  So their label descriptions could be stored at the driver level with over-rides in those few exceptions.  Even neogeo games that don't use all 4 buttons are most likely going to be in a mvs cab, and since the main pcb still has outputs for 4 buttons, the constant still applies.  

Of course there are "classics" drivers that would really be effected.  I driver in which every single game has a 4 way joystick and a single button would now have to have seperate input port definitions.  

Regardless, what you might have been getting at anyway.... a real hassle comes once the listxml is generated and the "bulk" is increased considerably.  Mame is gonna output that A, B, C, D grouping for all 200+ neogeo games.  An external file, like the controls.dat has the benefit of not having to output replicated data.  We don't have entries for clones (except bootlegs that used hacked controls) and when a system has  a universal layout, like the neogeo, we simply make a driver entry and consolidate all of that mess into just a few lines.  Large xml files take a while just to load.  

While the new rom flag output helps a  person that needs just the basics from the entire listxml file is gonna be slowed down.  I don't think anyone would mind this if the data was useful.  In this case, however, I've gotta agree that unless there was some way to toggle the captions on and off, port descriptions generally just confuse things at the mame level, and in the case of documentation it simply isn't possible as a great deal of "official" descriptions won't even fit in the ui screen.   That's why I suggested some sort of external file that could be read in at the ui level only.  People that want to use it could, people that don't won't.

[very slight rant]
Btw krick... I've gotta laugh a little at your string heavy comment.  We are documenting captions and labels.  What did you expect that to be short?  Even the ini version which saves space by not using all the xml tags is still rather huge.  Save maybe removing misc details I don't see how you could possibly make it smaller if you are really trying to accurately document.  Those are the researched official labels and physical controls, there isn't any way to shorten them without making them unofficial and thus you aren't really documenting anything are you?  If anything they are string light.  We could put the driver and clone names in each entry to aid in parsing, but since that can be obtained by asking mame we left them out.  It is the absolute bare minimum format you can document the controls and their labels with.  Actually in some ways it has provento be too minimal and sirp and I are considering expanding the format slightly to add a few misc stuff.  I'm not picking on you, I just wanted to explain.  Controls.dat doesn't use labels that some guy made up that help you understand what's going on in a game, each entry is researched to get the most arcade accurate description of the controls as possible.  If you were to read an entry while looking down at the real dedicated arcade machine, it would precisely describe the panel you are looking at and the labels printed on either the control panel or the instruction card on the bezel.  I'm not saying that the format we have setup would have to be used in mame, but the data would, as that is the actual data.  
[/very slight rant]

[krick]

[very slight rant]
Btw krick... I've gotta laugh a little at your string heavy comment.  We are documenting captions and labels.  What did you expect that to be short?  Even the ini version which saves space by not using all the xml tags is still rather huge.  Save maybe removing misc details I don't see how you could possibly make it smaller if you are really trying to accurately document.  Those are the researched official labels and physical controls, there isn't any way to shorten them without making them unofficial and thus you aren't really documenting anything are you?  If anything they are string light.  We could put the driver and clone names in each entry to aid in parsing, but since that can be obtained by asking mame we left them out.  It is the absolute bare minimum format you can document the controls and their labels with.  Actually in some ways it has provento be too minimal and sirp and I are considering expanding the format slightly to add a few misc stuff.  I'm not picking on you, I just wanted to explain.  Controls.dat doesn't use labels that some guy made up that help you understand what's going on in a game, each entry is researched to get the most arcade accurate description of the controls as possible.  If you were to read an entry while looking down at the real dedicated arcade machine, it would precisely describe the panel you are looking at and the labels printed on either the control panel or the instruction card on the bezel.  I'm not saying that the format we have setup would have to be used in mame, but the data would, as that is the actual data.   
[/very slight rant]

I think my comment was misunderstood by all.  Sir Poonga originally mentioned controls.dat in response to u_rebelscum wanting suggestions on additions to the MAME XML output in the controls area.   I think what is done with controls.dat is awesome, however, I know that if anything was to be added to the MAME source code, it would have to be as minimally invasive and non-bloating as possible in order to be accepted by the devs.  In that respect, controls.dat *is* too heavy.  It doesn't make it invalid or unimportant, just more than the MAME devs would go for if it was incorporated into the source.  External XML files, however, put an entirely new spin on it.

[Pi]

Yeah it works, but it seems to only keep data relevant to crc checking. 

There's an option called -k to (quoting the manual) "keep as much information as possible from the source file". In the past it worked quite well, I'm not sure right now. But as I said, he's available for some requests, if time permits.

In any case, if people really care about xml2info, then someone should take over the source and maintain the project from now on... It'll be much better and cleaner than any other solution, IMHO.

[krick]

In any case, if people really care about xml2info, then someone should take over the source and maintain the project from now on... It'll be much better and cleaner than any other solution, IMHO.

I've been in the xml2info source a lot in the last week or two and let me tell you, it's not a clean solution by any stretch of the imagination.  The original author never anticipated having displays and controls nested the way they are now.  So to get it working at all with the new XML format, I had to resort to some MAJOR hacking and it's still not 100% as I cant' see any way to get the actual control type into the output due to the way the data is parsed.

The cleanest solution, and by far, the easiest to modify for future changes, is to use an XSL Transform:
http://mame.3feetunder.com/xml2info/

[Howard_Casto]

I think my comment was misunderstood by all.  Sir Poonga originally mentioned controls.dat in response to u_rebelscum wanting suggestions on additions to the MAME XML output in the controls area.   I think what is done with controls.dat is awesome, however, I know that if anything was to be added to the MAME source code, it would have to be as minimally invasive and non-bloating as possible in order to be accepted by the devs.  In that respect, controls.dat *is* too heavy.  It doesn't make it invalid or unimportant, just more than the MAME devs would go for if it was incorporated into the source.  External XML files, however, put an entirely new spin on it.

No we got it, but you keep mentioning that you want to add labeling into mame for the sake of documentation.  Well the only possible way you can do that is to get as detailed as controls.dat.  Anything else you could think to replace the current mame labels with isn't documenting anything.  As Aaron pointed out the constants in mame are just there to keep the user from getting confused and at the pcb level they are all just singular inputs. 


Btw, on the xml2info thing......  I've gotta agree, the proggie is dead.  If it isn't going to be officially in mame then it will never be kept up and thus it isn't as useful.  When it gets to the point where you can get more data from one format than the other then it's time to ditch the old format.  Again I don't like it at all, but if it isn't going to be in mame, where it can constantly be updated and have the same data as the xml version then it isn't very useful, with the exception of putting a "band-aid" on older front-ends and applications that aren't going to be updated. 

[headkaze]

This may be a stupid question, but why does Mame.exe generate this data in the first place? Why isn't this data stored in a separate file rather than generated on the fly?

[Howard_Casto]

Because this data already has to be stored for mame.  rom crc's are required, the driver relationship has to be known ect....

Adding some of the stuff others are suggesting would indeed be adding data just for the sake of data. 

[headkaze]

Because this data already has to be stored for mame.  rom crc's are required, the driver relationship has to be known ect....

Adding some of the stuff others are suggesting would indeed be adding data just for the sake of data. 

I still don't get why it's not all stored in an external file, surely Mame could just read an external file instead of having it embedded into the source.

[Howard_Casto]

Because, mame reads this data internally and uses it to run the games.  Games will not function without basic stats like rom crc's and driver, clone and parent relationships.  If it were an external file then people could potentially completely screw up mame.  Since this particaular data MUST be inisde mame for functionality's sake anyway, it might as well be outputted when listxml is called.