Button Mapping Graphic Display

[SteveJ34]

Short of mapping LEDs to physical buttons, I've been pondering a graphic display for what buttons are used for each game.

Granted, you would still have the issue for those games that had been re-mapped and the different cp layouts that people have chosen.

I am quick to visualize an application/frontend/graphic file generation that draws against datasources of:

1. game database which provides buttons, joys, trackball, spinners, guns used by each game

2. a cp layout database which defines what controls are available.

For example, I have (2) 8 way with 6 buttons each, trackball in the center, and (1) 4 way with 4 buttons mounted above trackball in center. My 4 way and 4 buttons are mapped to the same keys as player 1 joy and buttons 1-4.

3. your mame key config

4. your custom configs for certain games

5. a set of generic graphics to piece together like a puzzle

I toss up these questions:

1. There was one fellow in the examples pages that was headed down this path but for the life of me I cannot find his example again....anyone? He had a plan similar to the above and sample graphics generated that he planned to use.

2. As I contemplated this idea and began to explore sortinfo as a starting point for the button layout database, I am confused by some of the output I see.....

For example, it shows galaga using an 8 way joy.

What's with that?

The task of documenting button layouts for 3,000 games doesn't frighten me....I have resources that can be applied to that if I can determine a method of acquiring this information....sortinfo seems to fall short.

I welcome any and all feedback regarding the pursuit of this concept.

Steve

[neuromancer]

I just put an idea along those lines in your original thread. The 8way in galaga must be what the driver uses, as opposed to the game. Maybe there are clones that actually use an 8 way.

If you made the graphics .pngs, then you could store them in the marquees folder and mame32 would automatically show them. If you could make a list of controls in a regular format, like a tab delimited ascii file with the same things in the same places, you could load it into FileMaker Pro to generate all the templates. The catch is that you still don't know what the buttons actually do.

Consider Defender. The buttons are fire, thrust, hyperspace, reverse. MAME only knows player 1, button 1 through 4. I think you would need to play the games to figgure that out. Just knowing that 4 buttons are used is a little helpful, but not really enough.

Bob

[Steve Johnson]

<snip>
..... The catch is that you still don't know what the buttons actually do.

Consider Defender. The buttons are fire, thrust, hyperspace, reverse. MAME only knows player 1, button 1 through 4. I think you would need to play the games to figgure that out. Just knowing that 4 buttons are used is a little helpful, but not really enough.

Bob

Good points, Bob.

I agree totally with the need for definition beyond "4 buttons", ie: what do the buttons "do".

I looked into www.klov.com as one resource that might be drawn against for controls that have been documented.

Granted, button 1,2,3,4 may not match up to the order that they have them defined in their database display.

I opened this thread to see if others had any interest and/or ideas and data resources that might be utilized in support of creating such a database documenting cp layouts.

Thanks again for responding.

I welcome any additional feedback you or others may care to share.

Steve

[u_rebelscum]

Check out http://www.mameworld.net/emuadvice/controls/controls.html

I don't know if it's still being worked on, but it's a project on displaying the layout of control panels.  Pretty much what you are talking about.  I never have tried it, though, so I don't know how good it is.

[Carsten Carlos]

I have though about adding a vertical mounted LCD/TFT-display somewhere in the cab which shows the instruction-card regarding the choosen game. Of course, it won't be that easy to find instruction-cards for 1500+ games (counting only unique games), but for the good ones they should be out there somewhere. For the others, you could make some of your own, one by one, no need to have them complete in one day, so you have always something to work on your cab -that's what hobbies are about!

But I discarded this all, 'cause

- Color LCD's are very very expensive (industry style with a 6,4" e.g. costs about $290 +$170 for VGA-adapter)

- Might look very unauthentic (this is my personal preference, yours might differ)

- The worst of all - the viewable vertical angle is very very bad on these LCD-displays, you'd have to get the display near eye-height which just would look stupid. Never saw a instruction-sticker that height on a cab.

I guess I might display the instruction-card on the frontend for -well, 5 second- and let it skip by pressing any button. Best would be to show the instruction-card plus a controlpanel shot (half of the panel would be enough, 1up and 2up are the same anyway) explaining the additional buttons.

[ErikRuud]

Here is how I do it on my machine.

I create images that look like this:


I place these in my snap folder for MAME.  These then get displayed in GameLauncher instead of the usual screen shot of just the game.

[neuromancer]

Granted, you would still have the issue for those games that had been re-mapped and the different cp layouts that people have chosen.

Maybe we should start our own project. What we would need is a translation table for button values, and a listing of controls used. It would need to be a database friendly file that had columns (fields) for each type of control (like trackball, horizontal 2-way stick, 8-way stick, etc,) and also columns for each button. The controls field would be the number of those controls it has (0 for none). The buttons fields would have the name of the button on the control panel (Like fire, shield, magic, hyperspace, etc.).

It would be pretty easy to do the input. We could probably get help from all the other people who want controls for their games ;-)

Of course, some people might swap some of the buttons around for various games, but I think they could be expected to handle those on their own.

It would be pretty easy to make a layout in Filemaker Pro that had buttons and controls that anyone could drag around to simulate their panel, but Filemaker is sort of expensive. Actually, it probably wouldn't be too hard to write a Visual Basic program that would read the inputs and draw the panels. I'm assuming there would be some way to save the images as .jpg or .png files.

The more I think about the exceptions, the more challenging this project becomes! Robotron uses 2 sticks at the same time, and  they should be labled "move" and "fire". For defender, my panel uses P1 buttons for reverse and hyperspace, but P2 buttons for thrust, fire, and smart bomb.  Then some games use two buttons pressed at once for an action. qbert has a diagonal stick.  Defender's stick moves up and down while galaga's move side to side. Star Wars has 4 buttons that all do the same thing.

I might just draw pictures in Illustrator for my favorite games, and let any hypothetical visitors figgure out their own.

Bob

[SirPoonga]

Of course, some people might swap some of the buttons around for various games, but I think they could be expected to handle those on their own.

If it was just a database then there is no issue, a person deals with the data however.  Button 1 in mame will always be the fire button for game X.  A person deals with that data however.

You can easily get what controls, how many players, how many buttons from the mame exe right now.  Just know what exactly button 1 is is another story.

[neuromancer]

If it was just a database then there is no issue, a person deals with the data however.  Button 1 in mame will always be the fire button for game X.  A person deals with that data however.

You can easily get what controls, how many players, how many buttons from the mame exe right now.  Just know what exactly button 1 is is another story.

Button 1 will be fire in game x until someone changes it to something else. Example: Vanguard requires 4 fire buttons in a diamond pattern. Most people probably don't have that on their control panel, so they might remap the 4 fire buttons to the player 2 joystick.

Bob

[SirPoonga]

Button 1 will be fire in game x until someone changes it to something else. Example: Vanguard requires 4 fire buttons in a diamond pattern. Most people probably don't have that on their control panel, so they might remap the 4 fire buttons to the player 2 joystick.

Bob

No no, I don't mean button 1 on the control panel, i mean button 1 in mame.

[Howard_Casto]

No no, I don't mean button 1 on the control panel, i mean button 1 in mame.

[u_rebelscum]

Exactly.  You would need a skin exactly Like Rd uses....  [snip]

I think three (or maybe four) database tables would be the best way:

1.  game input table: game name, joysticks used (ie: player1 joy, player2 ad-stick), joystick labels, buttons used (ie: player1button1, p2b4, p2start), button labels, trackball/spinner used & their labels. (and maybe game driver coded input settings with BITX or ANALOGX, yuck.  this data belongs in table 4.).

2.  mame default input mapping:
player2start == "2"
player1button1 == "lctrl", and OS joystick 1 button 1
spinner1left == "left arrow", and OS joystick 1 X axis negative, and mouse 1 X axis negative

3.  user's personal control panel map (the skin):
up on joystick located here is analog with joystick ID 1 Y axis and normally called "left stick",
left on joystick located here is digital == "d" and normally called "right stick",
button here (the one with a one person icon) == "1" and usually called "player 1 start"

4.  user's personal remapping of games.  Would be like table 2, but with the gamename included (gamename, p1b1 == "z").  If this is used, the special game driver mapped inputs could go here instead of in table 1.  If the user uses the new ctrlr\*.ini method of remapping controls, those .ini files could be used instead of making a another table, except maybe to hold the driver remaps.

(italics stuff being optional)

Tables 1 & 2 should be separate for a smaller database size and portability.  This would let table 3 (skin) reflect the reality that the control panel is just key presses, mouse movements, and joystick presses.  The first table also would be a lot "cleaner" without the multiple (keypress+joybuttonpress+mousebuttonpress) values for each input.  (The optional) table 4 would be easier to add.

In my vision, the software would take the gamename, look up all its inputs in the first table, assign keys to each input from table 2 (and table 4 if used), find the locations of those keys on the person's control panel, and display the resulting layout.

Table 2 is already stored in mame\ctrlr\std.ini.  I think table 1 can be made (without the "fire"/"jump" type labels) with a few changes in mame source.  Table 4 with just the driver specified non-default inputs would take only a few more edits.  I can do tables 1, 2, and part of 4 (minus the user specific remaps): the easy parts.

I don't know how to do table 3 (skin) at all.  Nor what database format to use or how to do the real software programming.  If any of you guys deside to do it, I can try to help with my minor & out-of-date experence with database constuction/use.

[SirPoonga]

Well yeah, first off if this was a database there would be different tables storing this.

I think table 1 can be made (without the "fire"/"jump" type labels) with a few changes in mame source.

[u_rebelscum]

Right.  a "mame.exe -listinfo" give you all of that minus the fire/jump type stuff.  Unfortunately -listinfo isn;t accurate for all games, look at dotron.  but it is a start.

Sorry, I wasn't clear.  With a few edits, I have gotten -listinfo to write a list of all direction inputs; i.e. dotron listed both the spinner and the joystick, and spyhunter to list both the paddle and pedal.  Also, instead of listing the number of buttons used, I could (haven't done it yet) get it to list which buttons used; i.e.: it would list "player1start, player1coin, player1button1, player1button4" if those buttons are used, instead of just "player 1 buttons 2".  This is what I meant by: all the info minus the fire/jump game specific labels.

With this info, and table 2 in my previous post, the database would be much more flexable to different control panel layouts and different hardware button to key assignments (example: on the hotrod panel), and user specific software changes (example: with the old -hotrodse option, or with the "Input (this game)" menu).

If would give an extra step for the FE to link through, true.  But the overall data would be much more accurate, and the layout at the user level.

Ok, here's how an FE using this data would work.
You highlight a game.  The FE has to look up (form -listinfo table??) how many button, what controls, etc.  Then it knows that it will have to look up the label for button 1 (in mame, not cp), button 2, etc...
Then there has to be a mechanism to hightlight those controls and put on labels.  What that mechanism is depends on hte FE and language used.

Yes, that's pretty what I meant to say:
In the FE

• You highlight a game.  
  
• The FE has to look up (from -listinfo with the additions discribed above) how which buttons, what controls, etc.
  
• It knows that it will have to look up the game label for button 1 , button 2, etc...
  
• It matches what inputs mame would interpet as to mean those buttons and controls (i.e. player1start == "1" and player1joyup == uparrow || USBjoystick1up || other OS joystick1up)
  
• It looks up what (on the cp) what the directions and buttons tranmit to the computer.
  
• There has to be a mechanism to hightlight those controls and put on labels.

The biggest difference between what you discribed and what I am trying to dscribe is the extra italicised step.

I agree with the rest of your post, but you know more about FEs than I do.

[SteveJ34]

I am pleased with the enthusiasm and thought processes demonstrated in the follow up posts to my original inquiry.

Many have followed my concept of multiple databases being drawn against to create the desired end result to include utilizing efforts from multiple parties with each having something to contribute.

I think the first effort is to document all the games, the number of buttons, joys, player positions, and what they are for, ie: fire, move, jump, punch, etc.

One approach would be to design a database and a web front end which allows several parties to contribute to the data collection process.

I have some energy about getting this initial level of information collected. With this collected there are multiple ways this data resource could be implemented by combining with other info and expertise for graphic creation and display.

I see KLOV as one resource for the cp function definition.

Perhaps this info could be harvested and parsed, cross referenced to the mame .zip filenames, and formed into a starting point for an initial database.

If I were to devote some resources to this concept in the form of web space with db backend, have one of my developers put together a database interface front end (or perhaps a fellow mamer would like to contribute), how many hands might raise who would be interested in moving forward with this data collection project?

I look forward to any and all replies.

Steve

[u_rebelscum]

I think the first effort is to document all the games, the number of buttons, joys, player positions, and what they are for, ie: fire, move, jump, punch, etc.

I think more details are needed.  The info you listed might be enough for the generic 4way or 8way joystick + buttons games (what, 80%?).  But for games like dotron (joy + spinner), ssprint (spinner + pedal), primal rage (start button also an action button), and gauntlet (elf action button labeled different from other's action button) it wouldn't work as well.

I don't think just the number of buttons in a game is enough info.  I think a list of buttons with mame's internal names is needed.

The number of joys is not enough either;  I believe a list of each joystick is needed; one example: some games like john elway quarterback have two normal joysticks + that spring-back joystick only for one player.

For each button/joystick listed, it should include it's the label, like you said.

One approach would be to design a database and a web front end which allows several parties to contribute to the data collection process.
[snip]
If I were to devote some resources to this concept in the form of web space with db backend, have one of my developers put together a database interface front end (or perhaps a fellow mamer would like to contribute), how many hands might raise who would be interested in moving forward with this data collection project?

I look forward to any and all replies.

Steve

I would raise mine, and get the list of all mame's games inputs, as described above.  Of course, with you designing the db and not me, you have the right to deside how much detail is needed.

I can make, do a primary review of, and get the list to you by next week, if you want (and let me know soon enough ).

I can change the list's format I submit, but I was thinking something like:

gamename, controller/button mame type, driver supplied label (if any), Input1 (if not standard), Input2 (if not standard)

If you want, I could also list the mame standard inputs in each row for that type of input, but this can be found in mame\ctrlr\std.ini already, and adding it would really balloon the file size.

[SteveJ34]

I think more details are needed.

[csbelli]

I would be happy to offer my services for creating the frontend if the database will be Access 2000. I am an internet programmer by trade and this would be pretty simple. Let me know if you would like the help.

csbelli

[neuromancer]

game,cpnumplayers,p1joy2,p1joy4,p1joy8,p1spinner,p1button1.p1button2,......p2joy2,p2joy4

(need to define all the possible control types to include yokes,steering wheel, etc).

Robotron I guess would create the need for joya and joyb for each joy type to cover the bases. Tank games are like that as well. In essence they are (2) 2-way joys with up/down defined for each, ie: P1joy8a,p1joy8b

Steve

There are many games that have odd controls that never had more than one of them, so we don't need to have P1-P4 for every single type of control; I'm thinking of Qbert with the diagonal stick, Major Havoc with the Roller, The special thruster for Lunar Lander, and the handlebars for Paper Boy. Oh, and obviously the Push/Pull spinner for DOT.

For the frontend, one would idealy want the ability to map controls to other types of controls. For instance, with asteroids and space invaders, one might want to map left and right to an 8way stick.

I would be willing to help with this project, but I'm not sure in what  capacity. Maybe checking button functions versus labels or drawing up some of the graphics for the frontend. I don't know much about programming. My database experience is split between applications in FileMaker Pro and designing things that others implement in Clipper.

Bob

[SirPoonga]

game,cpnumplayers,p1joy2,p1joy4,p1joy8,p1spinner,p1button1.p1button2,... ...p2joy2,p2joy4

NO NO NO.  Bad design!  Hehe.
Need it more generic, it will make life easier (especially if you want this to work with other emus to.
The DB would have many tables.
One table would store the game name, game index, otherstuff.  The important part is game index.
Let's say it has these records:
game index|game name
232|Robotron
362|Mr .Do!
467|Discs of Tron
483|Street Fighter

Then you would have a controls table. The records that show the controls for the above game would be like:
game index|mame control|cp control|label
232|2joy8way|joy1|
232|2joy8way|joy2|
362|joy4way|joy4way|
362|1button|P1B1|Fire
467|dial|up/down spinner|
467|joy8way|tronjoy|
467|button1|tronjoybtn1|Fire
467|button2|tronjoybtn2|Shield
483|joy8way|joy1|
483|joy8way|joy2|
483|button1|p1b1|Weak Punch
483|button2|p1b2|Punch
483|button3|p1b3|Hard Punch
483|button4|p1b4|Weak Kick
483|button5|p1b5|Kick
483|button6|p1b6|Hard Kick
483|button1|p2b1|Weak Punch
483|button2|p2b2|Punch
483|button3|p2b3|Hard Punch
483|button4|p2b4|Weak Kick
483|button5|p2b5|Kick
483|button6|p2b6|Hard Kick

Now, this is assuming you have a control panel with a seperate 4way joystick, an up/down spinner, and a tron style joystick.
The 'cp control' field is the label you give the control in the FE, that will get highlighted somehow when that game is selected.  When you select a game in the FE, it will get the game index from the games table and retrieve all the records for that index in the controls table (easily done in one SQL command).  Then go through each of those records highlighting the control and putting in the text for the label of that control.  It can actually be less complicated, but you get the idea.  The controls should go in a seperate table and be looked up for ease of use, and ANY control can go in there.  With one huge record like you suggested you may not get all controls or future controls that pop up.

Actually, thinking about it, the above example is way more complicated than it needs to be.

The other way I could think up is have a lookup table that lists all the mame controls and the FE label for the control (the represents a control on your cp).
Like:
mame control|cp control
player1button1|p1b1
joy8way|p1joy8way
joy8way|p2joy8way
dial|Spinner
paddle|Spinner
trackball|trackball

Then in the FE the FE would look up the controls in the -listinfo and then correspond them to the above table looking up which FE control to highlight.
Now, if you make a cp designer for your FE when you add a control to the cp a drop down box would appear with all the possibilities for mame controls.  Then a text box for a cp control label (like p2joy8way).  That gets added to the above table.

Now, you have to correlate say player 1 button 1 to Fire or some other text label.  That's a DB like my first example will come in handy.  You list all the games and give it an index, then you have another table with all the controls for that game (the mame controls that you get from listinfo) and any label for that control (like button1 is jump)

[Howard_Casto]

I agree with sp... that way people could submit "control panel" files that would be read externally.  Then the fe would take the other two tables and make some kind of graphic however it chooses.  This is a really good idea but someone needs to start making some kind of engine for this now.  If we had something to test these on as we go then people could go ahead and get started making the files. And with the exception of special case games and classic games, it would go fairly quickly.  

Think about it.  90% of capcom games are street fighter clones.  You would only need one file for all of those games.  Also 90% of all platforms have the same setup.  Button 1=punch/fire button 2=jump button 3=special  And all of your beat-em-ups follow this pattern too.    Then if you look at dataeast games alot of them have the leftpunch/fire jump rightpunch/fire setup.  And guess what all of the doubledragon games use this style too.  Even racing games... x axis is for steering, y is for gas/break, button one is usually a turbo button, and any other buttons control the view or the radio.  I think you'll find that anything made after about 1987 is VERY standardized when it comes to button order and their functions in their most generic form.  If we remove specialized terms like "use potion" and replace them with "special" then things would go alot quicker.

Just something to think about.    

[u_rebelscum]

Need it more generic, it will make life easier (especially if you want this to work with other emus to.
The DB would have many tables.
One table would store the game name, game index, otherstuff.  The important part is game index.
Let's say it has these records:
game index|game name
...
game index|mame control|cp control|label
...
mame control|cp control
...

Now, if you make a cp designer for your FE when you add a control to the cp a drop down box would appear with all the possibilities for mame controls.  Then a text box for a cp control label (like p2joy8way).  That gets added to the above table.

Yes, yes, that's the way!  How about these changes:

game index|game name
-1|default
1234|spyhunt
4321|smashtv
666|xybots

game index|mame control|label
-1|mp1b1|button 1
...
1234|mpedal|gas
1234|mp1b1|fire
...
4321|mp1leftjoyup|move
4321|mp1leftjoydown|move
4321|mp1leftjoyleft|move
4321|mp1leftjoyright|move
4321|mp1rightjoyup|fire
...
666|mp1b3|P1 Twist Right
666|mp1b2|P1 Twist Left

+ two changes to the last table:

game index|mame control|computer control
-1|mp1b1|LCTRL
-1|mp1b1|Joy1Button1            /*multiple inputs for mp1b1*/
-1|mp1b1|Mouse1Button1
-1|mp1leftjoyleft|S               /*almost all cp's remap this to the same as mp1joyleft*/
-1|mp1joyleft|LEFTARROW
-1|mpedal|LCTRL
...
666|mp1b2|Z      /*driver remapping*/
666|mp1b3|X
...
1234|mpedal|Joy1Up      /*personal game remappings*/

+ one more table:

computer control|control panel control
LCTRL|cp1b1
LATL|cp1b1
UPARROW|cpjoy1
DOWNARROW|cpjoy1
...
Joy1Button1|cJoy1Button1    /*only needed for cp with hacked joystick buttons or*/
Mouse1Button1|cMouse1Button1 /*hacked mouse buttons*/

(the 'm' in mp1b1 shows it refers to mame's player1 button 1, the 'c' in cp1b1 refers to the control panel's player 1 button 1)

That last table will have a default almost mirroring the prior table default game index # settings (but doesn't include the game index #), except the joystick and mouse inputs stay seperate from key inputs.
This table is needed for people who built their own control panels not exactly to the same layout to key assignments, or for cp's with a combination of mouse, joystick, and keyboard buttons.  For these people, they edit the table as needed.  Also, the table can be trimed to include only the parts on the control panel if wanted.  
Then FE still builds the cp layout with (cp) player1button1, etc type objects.

[SirPoonga]

Yeah, you guys are getting the idea.
urebel, that's more of what I meant, the more you can organize and split up tasks the easier it will be to change in the future if needed.

This actually sounds like a project that several of us could work on and CVS the source or sourceforge it.
The question is how generic do you want it, want to run in DOS, windows, linux, macs, etc?

I'd help out abit after I get my cabinet done.

This table is needed for people who built their own control panels not exactly to the same layout to key assignments, or for cp's with a combination of mouse, joystick, and keyboard buttons.  For these people, they edit the table as needed.  Also, the table can be trimed to include only the parts on the control panel if wanted.  
Then FE still builds the cp layout with (cp) player1button1, etc type objects.

Actually, if you make a really good GUI to make the CP for the FE it should do that all for you as you edit the cp layout on screen.



Here's another problem.  People like me with multiple control panels.
Here's what I'd have my FE do.  For games that used steering wheels, yokes, pinball controls (are there mame game like that) I'd display the third cp of mine.  My second CP should cover games like ikari warriors, dotron, battlezone, things that didn't follow the stand joystick and buttons.  It would be nice to know if you have to change panels.  But there are not "that" many people who do that compared to just living with one cp so I wouldn;t worry about that right now, just keep it in mind when designing that it would be nice to design it so that would be easy to add if something came up.

[1UP]

It seems to me that we're getting a bit carried away with all these databases.

[1UP]

Here's another problem.

[u_rebelscum]

It seems to me that we're getting a bit carried away with all these databases.  For one, the "re-mapping" DB seems to be unnecessary. [snip]

... if we have a GUI for laying out the controls, we could also tell it which buttons are connected to which input (which key it is mapped to).  If we had a basic 1 stick, 3 button panel, we could create a BASE control panel image that would look like this:



It would seem that we could somehow have the FE take the button labels from the Mame code, cross referencing their mappings in the Mame menu (i.e. "1 Player Start = 1", "P1 Button 1 = LCtrl" etc.):
[snip]

What do you think?

I agree that remapping table is a little much (even though I'm sort of "pushing" it).  It's there mostly because lots of people think: "that's my control panel's player 1 button 1" and not "that's LCTRL".   [shrug]  I am all for dropping that table and letting the FE graphically map "LCTRL", "Left Arrow" instead of the "cp1b1' and 'cp1joy' stuff.

[SirPoonga]

Right, you don't need to know the key stroke a button on your CP uses.

[1UP]

I see, so you're just making friendly names from the get-go!  Sounds good to me.  I don't know what I can do besides donating graphics, but I'd love to see this implemented ASAP!

[)p(]

dkong
"P1 Button1" = "Jump"

This would simply substitute a different label for "P1 Button1" in the image.

What do you think?

I agree with 1-up a simple label substituting database is all we need. Because all the relevant stuff comes directly from mame itself it will be much easier to maintain the database...

peter

[u_rebelscum]

I see, so you're just making friendly names from the get-go!  Sounds good to me.  I don't know what I can do besides donating graphics, but I'd love to see this implemented ASAP!

I think the FE should handle parent/clones.  It would cut the table size greatly.

Here's a tab delimited text file with this format:

gamename [tab] mame input name [tab] label, if any (driver given name)

notes:
1.  The list includes all inputs, including cheats & custom inputs, for all games.

2.  If the input is a cheat, "CHEAT" is added to the third column.  If it's a cheat with a driver given name, the "CHEAT" is added to the end of the string.  Example: an cheat input given the name "super speed" in the driver, will have "super speedCHEAT" in the label column.

3.  If the input is a custom input, mame does not have an internal name for it.  In these cases, the second column contains "custom".  Most custom inputs have a label, and are mostly from mahjong games.

4.  If the input uses the default name in mame, the third column is blank (except item 2 condition).  Mame uses the same name listed in the second column, so no need to repeat it.  These are the ones that need the labeling.

5.  The file is >1.3 megs (~185kB zipped) with 59311 total inputs listed.

example lines:
pacman      P1_JOYSTICK_UP      
pacman      P1_JOYSTICK_LEFT      
pacman      P1_JOYSTICK_RIGHT      
pacman      P1_JOYSTICK_DOWN      
pacman      COIN1      
pacman      COIN2      
pacman      P2_JOYSTICK_UP      
pacman      P2_JOYSTICK_LEFT      
pacman      P2_JOYSTICK_RIGHT      
pacman      P2_JOYSTICK_DOWN      
pacman      START1      
pacman      START2      
defender      P1_BUTTON1      Fire
defender      P1_BUTTON2      Thrust
defender      P1_BUTTON3      Smart Bomb
defender      P1_BUTTON4      Hyperspace
defender      START2      
defender      START1      
defender      P1_BUTTON6      Reverse
defender      P1_JOYSTICK_DOWN      
defender      P1_JOYSTICK_UP      
defender      custom      Auto Up
defender      custom      Advance
defender      custom      High Score Reset
defender      COIN1      
defender      COIN2      
defender      P1_JOYSTICK_RIGHT      CHEAT
defender      P1_JOYSTICK_LEFT      CHEAT


more notes:
1.  I think parent/clone handling in the FE would be a Good Idea:  most clones have the exact inputs as the parent.  This makes a lot of the data in this file redundant, and adding labels to the parent & each clone is extra work.  The clone should only have its own list if it has different inputs than the parent (example: cabal uses trackballs, but the bootleg version uses 8way joysticks + one more button, so should have its own inputs listed).  The code I used to generate the list does not check for this in any way; all inputs for all games are listed.

2.  The source changes are available in the same zip as the list.  All changes were in src/info.c, and replaces the -listinfo output, so should only be used on a mame that you don't need the normal -listinfo list.  Quick compile suggestion: make temp folder and copy makefile, src folder, and obj folder into it.  Replace temp/src/info.c with the supplied info.c.  Type make.  Rename the resulting temp/mame.exe to something else (example: InputListMame.exe).  Move the new named mame into normal mame folder.  Delete temp folder.

3.  To get the list, type [InputListMame] -listinfo > filename

4.  The changes work for both dos and windows mame, and should work for all ports.

5.  It would be nice to make this as a new option instead of replacing -infolist.  

[neuromancer]

I think the FE should handle parent/clones.  It would cut the table size greatly.

Cool. Here's an Idea. We could use this type of list, but number the layouts. Then assign layout numbers to the games. There are only a limited number of layouts required, so all 2 player 8way 3 button games can have the same layout. All pacman clones would share one layout, ect. It would really cut down on the work of labeling the buttons. I think for someone who never played gauntlet before, knowing that one button is called "Magic" could really help.

I still like the idea of a stand alone app that takes the game name, the panel layout, and draws .jpg files that you can place in the marquee folder of any frontend (like ArcadeOS).

Bob

[SteveJ34]

......snip

example lines:
pacman

[u_rebelscum]

I like the data layout that is being proposed with the
mod listinfo from urebel.

1. Does the info extract represent a complete dump for all games through mame .60?

Yes.  all mame.60 supported games are in that list, straight out of the mame drivers.  Problem is there is too much info as some non "action" buttons were included if the type (action vs. service vs dipswitch, etc) was not specified.

2. Would a "next step" be to begin documenting the functions (fire, jump, kick) etc for all the games?

That or cleaning up the extra data:  Clone/parent relations, extra buttons that shouldn't be there, and such

I am ready to jump in and begin documenting what I can but of course, do not wish to duplicate efforts so that the parts might complete the whole big picture.

Perhaps we setup a web page that has a web page front end to the basic |game|control|function| table that allows multiple parties to access and update?

Easiest for multiple people helping, but extra work for however sets it up.

I would be happy to contribute documenting efforts and web space if someone can aid the front end. I believe someone indicated they would be happy to contribute that.

How do the rest of you feel about this as an approach, ie: to allow multiple parties to aid the controls function definition process?

Watch out for conflicting ideas, but that's possible anytime more than one person works on a project. [shrug]

I'll help as I can.

I think we have some interest and momentum behind this concept and from reading the various inputs, a good starting diagram for what we collectively believe would be something cool to accomplish.

What say thee oh wise ones?

As always, I look forward to any and all replies.

Steve

LOL, I'm not a wise one, but I say let's do it!  Haven't any experence in making/editing FE's, so I wouldn't be much help there.    I can help on other stuff, but what else is needed?

[csbelli]

As I mentioned above, I would be happy to make the web front end in ASP that stores the data in Access 2000 if someone provides the web space.

I would need a list of all the fields that everyone agrees the database should have and the an idea of any specific wording for the frontend to make data entry as simple as possible.

Once I receive all the information I can have it all ready within 2-3 days. It does not take that long to do but I have to fit it in with my regular work.

Once that is ready, someone should assign a block of letters for certain people to start documenting to prevent overlap. If someone gives me a list of all the zip file names, we can use a drop down box to pick the game you want to document. If it has all ready been documented, the information will show up so that there are no duplicates.

If you would like my assistance, contact me at csbelli@hotmail.com.  I think this would be a great project and documenting everything is a great start.

csbelli

[dknight]

I just wanted to add that I think this is a fantastic idea and I am volunteering to help in the data collection process.  Sign me up for a letter!

-Dave

[SteveJ]

Yes.

[SirPoonga]

Sounds like a project that deserves it's own website.  I was looking at featureprice.com, not a bad deal.  This site is on that.  PlanetJay does do some subdomaain selling if he has any open spots, could talk about it....

[SirPoonga]

For example, it shows galaga using an 8 way joy.

What's with that?

I don't know if you figured it out or someone told you.  8way is a joystick that you can do the diagnals too.  Hence 8 direction you can  use.  A 4way is just up/down left/right like pacman.

[SteveJ]

I don't know if you figured it out or someone told you.

[Trenchbroom]

I was part of the original discussion back in March, and I am very excited to see the enthusiasm this time around!  I'm posting my original quote from that discussion because I still think ICPD is a good reference:

"Actually here's another idea for the esteemed programmers among us (certainly not me, and thanks for the hard work BTW).

Make a program like ArcadeFX's ICPD where someone could easily setup his own contol panel layout and save it as a picture in the FE itself.  Then, when each game is highlighted on the menu have the picture of the control panel highlight what each button does in that particular game.  The user would have to input the controls for each game, of course, although many games could use a more generic layout that the user indicates as such (i.e. all Donkey Kong clones would use the "DK" button layout, all Street Fighter the "6 button fighting" layout, etc.) ."