Ok we'll hash it out here then... I would rather have a public record incase any viewer devs want to chime in.
About the dropping the ini thing. I think this is the way to go BUT XML parsing is still waaay slower. It has nothing to do with parsers and everything to do with the size of the files. I ran a test on parsing a full mame list.xml yesterday using both sax and dom. Sax took around 30 secs, not slow but definatley a noticable wait. Dom took over 2 minutes. That's just unacceptable. I think the obvious solution is to make individual files for each game. A small file doesn't take any time to read. We can either do this on the server end or I can write an application. I want it optional of course, but I think for slower systems it's a good compromise for dropping the ini.
Ok getting down to business:
First of assault needs re-done anyway. It used to have a 4 way (hack) as well as dual trigger sticks. That's been removed from mame. We need to ensure that the dual 4way constant is using joystickleft and joystickright though as those are the proper constants.
As for the new format, I thought we could save ourselves and other programmers the headache of learning two structures and just loosely base the new format on mame's ctrlr files. Not exactly mind you, but close enough.
Rather than explain it, how about an example. A game with 4-way, black, trigger-stick with a red fire button and a yellow bomb button on the cp.
<game romname="ggame" gamename="Generic Game" numPlayers="2" alternating="1" mirrored="1" usesService="0" tilt="0" cocktail="1">
<Control name="4 Way Joystick">
<Constant name="joy4way" color="black">
<input name="P1_BUTTON1" color="red">Fire</input>
<input name="P1_Button2" color="yellow">Bomb!</input>
This game is really cool!
Note the use of multi-line!
Basically I'm going back to the original discussion we had about the dat all those years ago. We break down controls first by their real world name, then the mame control constant(s) that they are made of, then the individual inputs. For inputs like buttons and the unbinded labels, where they are ungrouped, we don't bother with the control/constant grouping as there isn't any. For the advanced parser, the location of the label immediately lets them know the relationship of the individual inputs and for the lazy parser, you just have to read the game entries atts and then pull the values off of any node labeled "input". I'm not sure about the color btw.... I'm confident that it needs to be attribute as we are using a pre-determined set of constants and it has to be linked to an input anyway, but I'm unsure if allowing the option of just coloring the whole constant, like I did in my example, is a good idea. Actually it's probably best to just do each input (I was trying to save space.)
As for special unbinded inputs they should look something like this:
<input name="P1_JOYSTICK_UP/_LEFT" color="yellow" type="unbinded">Jump Back</input>
It doesn't really matter to me if we group them with the real inputs or put them in a special place, they just need a att telling parsers that it's NOT a real input but just a label. I thought we would still call them an "input" though just to make it easier for parsers to look for them.
Btw I see what you are saying with your examples, but you are linking a label to inputs. We need to link inputs to labels so that we can "build" the control groups and constants in the entry and show their physical relationship. Or at least that's what I think, considering we have to parse MAME's ctrlr/cfg files and link up inputs to labels. With my structure each input gets a unique name att anyway, so in theory at least, we shouldn't have the overlap problem we had before.