Controls Database (FE programmers inside, please)

[potatojin]

Hello everybody.  I've been lurking here at BYOAC for a while now as I've been getting my cabinet built.  It's pretty much all done and I'll post pictures soon.

As I've been researching FE's and thinking about making my own or trying to contribute to an existing one, I got an idea that I was wondering if the community would be into (or that might have already been done).

I've been spending lots of time figuring out or explaining to friends what buttons do what in various games and have really been itching to have some quick way to communicate which buttons do what in all my games.

So I was wondering if there already is, or if we should try to build, a database somewhere that contains all the button mappings for every emulated game.  I'm imagining an end product that looks something like a big xml file that contains the rom name and then mappings (with descriptive names) of each of the game's controls to the mame virtual buttons (Player 1 Button 1, etc).  Something like this:

<MAMECONTROLS>
 <ROM NAME="mslug3">
    <BUTTON NAME="Player1Button1" DESCRIPTION="Shoot">
 </ROM>
</MAMECONTROLS>

That's just off the top of my head, but you should get the idea.  The file would be available to FE authors and could be tied into your favorite image generation software to output control panel diagrams for every game and display them in the FE.  This would go great with something like ArcadeFX's flash-based control layout app, so FE users could configure the generated diagrams to look exactly like their own control panel.

Alternatively, this could just be maintained as a separate application that would be distributed with FE's and would populate another folder like /controlsnaps that FE authors could just pull PNG files from.

I'm imagining the population part of this project, where we actually get all the information about what button does what would involve a moderated database-driven website.  Volunteers could come to the site and see which games still need control information and fill it in.  FE authors or whoever could download the latest version of the control database xml doc.

What does everybody think?  Sorry about the long first post, but I had one of those taking-a-shower epiphanies and I wanted to see if what people thought.

potatojin

[Dr. Jay]

Not a programmer, but it sounds nice.
 This is what I did though.  I made a nice looking graphic of my keyboard layout, and I display it in my frontend instead of having a flyer pic.  I've got the marquee at the top, screen shot next, and the control layout on the bottom.  Once the template was done, I just edited the text for each button.  Having a universal sounds nice, but what about everybody's crazy control panel layouts, and different keymappings?  Like I said, I'm not a programmer, but it sounds interesting.

[potatojin]

I got started thinking about this by looking at building a system for myself that would add control panel information to snaps, but I think the universal system would not be that much more work and would be something everybody could use.

As far as crazy control panel layouts go, I was thinking that the client-side application would come with a template builder, like what you did for your layout.  Then the app could just pull in the info from the universal file and change the text under each of the custom-placed buttons.  Keymappings may be something I underestimated though.  I might have to go back to the drawing board on that.

[u_rebelscum]

I like the idea, but would like some more info added to it (or parallel to it).

Joystick/spinner/pedal information.  Mame already has the bases for this with "mame -listinfo", but only list the primary input.  
Examples:
1. a racing game might list a spinner ("dial") for input with "mame -listinfo", but doesn't list wheather it has one or two pedals.  
2. DOTron doesn't list that it needs both a spinner and an 8way joystick, but instead lists a trackball as the input!

I'm just too lazy and unknowledgable to do it myself.

[simpleman46]

Sounds like a great idea.  Could be very useful inside a FE.  If this ever gets off the ground, I would be more than willing to help assemble data from games.

[ArcadeFX]

The database I use with ArcadeFX has the following alrady entered for every MAME game.

"gamename","gamedescription","gameyear","gamemanufacturer","gamecloneof","gameromof","gamecategory","gameversion","videoscreen","videoorientation","videox","videoy","videocolors","videofreq","soundchannels","inputplayers","inputcontrol","inputbuttons","inputcoins","driverstatus","drivercolor","driversound","drivercolordeep","available","favorite","favorite2","favorite3","favorite4","favorite5","counter"

The last 7 fields are specific for each user and not taken from the listinfo.

I am not sure how usefull a database would be of key mappings since each cabinet could have their own mappings.  Anyone who did any custom key mapping in MAME might not find it very useful.

[Howard_Casto]

It sounds like a cool idea, but other than telling you which games have spinners (which we can already get) and some interesting eye candy, what purpose would it serve?

Here's a thought, same idea, but use it for a totally different purpose.  Me and lilwolf were talking about making a on-the-fly key remapper.  Now if you gave all button functions a generic name (fire 1 fire 2 fire 3, ect)  then it could be useful for that.  

Just a thought, keep at it.

[Trenchbroom]

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.)

[SirPoonga]

"favorite","favorite2","favorite3","favorite4","favorite5"

WHAT!!!  A limited amount of favorites with a database design:)
hehe, mt FE has unlimited categories and favorites:)  Oh wait, I'm not really going to release it to the public for pblic use anyway, just release it and use it at your own risk:)

[potatojin]

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.

This is pretty much exactly what I was originally thinking about.  In response to Howard, I was thinking it would go beyond eye candy by reminding me and telling my friends exactly what each of the 7 buttons on my control panel do when I load up a game.  You'd only see it before loading the game, but it might be better than nothing.

I'm still trying to hash out the technical feasibility re: key mappings.  I'd rather not have a solution that requires a huge amount of special coding by individual FE authors.  I haven't tried parsing the mame config files and don't know how hard anyone else has tried.

[SirPoonga]

There is a big downsdie to this, it'd take alot of time.
Someone would have to go through each game, find out what it's controls are, and enter them in a db.

Like with mvsc you'd have to put in what fierce punch is and such.

AND some people (like me) change their buttons so button 1 isn't always the same from one game to the next.

It's be cool, but difficult to do.

NOW, why might be better is if people could get pictures of instruction cards for games like their is marquees, flyers, and other artworks....

[Howard_Casto]

I'm still trying to hash out the technical feasibility re: key mappings.

[u_rebelscum]

As for mame config... it's in some type of format other than text.... I haven't had much luck parsing it.

Those dang .cfg files! ;p
They are mostly a binary file.  (Units in the file are 8 bit hex pairs, integer(16 bit) = 2 hex pairs, word(32 bit) = 4 hex pairs.)
First are 7 chars ("MAMECFG" to be exact), followed by the version of the config file in hexadecimal ("0x08" currently).  After that comes all the driver's default input settings, followed by all the current input settings. Small stuff after that (Coins entered each coin slot, then sound settings).

Each input setting goes (in hex):

input_type {integer, or 2 pairs},
input_mask {word, or 4 pairs},
input_default value {word},
input_sequence {word, + x# integer(s)}.  

type is the input type, such as joystick_left, button1, or spinner. (two hex pairs)
mask contains info like which player #, auto_center, and other stuff. (four hex pairs)  
default value is used mostly by analog inputs, and is the "starting" value, or the value centered toward if the mask includes auto_center. (four hex pairs)
sequence starts with the length of the sequence (four hex pairs).  The value can be from 0x00 to 0x10 (0-16), depending on how many inputs you have mapped to that input.  That number of inputs, represented by two hex pairs, follows.  For example, if you had joyButton 0, key "ctrl", and mousebutton 0, mapped to the same input, I think you would have a length of 14 hex pairs: starting with 0x05 {word} followed with: {integers} the 3 inputs separated by 2 "CODE_OR"s  (or in pseudocode: input_sequence_length_5 {word}, joybutton0 {integer}, OR {integer}, "ctrl" key {integer}, OR {integer}, mousebutton0 {integer}).

The translation of the numbers to inputs is done in inptport.c, input.c, and [OS]/input.c.  The biggest problems are that each input setting can very in length, and each .cfg files can vary which inputs are saved.

We are mostly interested in reading/editing the second set of input settings, as those are the settings used in the games.

Hope this helps anyone.

[potatojin]

...lots of computer stuff...

Rebelscum, that was very helpful.  I imagine all this stuff is available at mame.net, which is my next stop as soon as I have some time.

For whatever reason, I still think this might be a good idea.  Let me summarize what I think I'm talking about and if everyone thinks it's a stupid idea, I'll think of something else or go cry:

- A database that contains all control information with friendly names for the functions of the inputs.  This db can be dumped to xml and downloaded to users' machines.
- A "control layout" mini-application that lets users create a graphic template of their control layout.
- An application which batches the job of populating this template with the friendly names from the db for each game.  This app will check against the .cfg files for each game so the button mappings are correct.
- A directory full of .png files that contain the finished product: one png file for each game, named by rom, that looks like the user's control panel layout, with descriptions of each buttons function.

That's it in a nutshell.  Let's set aside feasibility for a moment (I think it would be a lot of work, but would be doable), and just everybody tell me what they think about this idea.

Thanks.

[potatojin]

There is a big downsdie to this, it'd take alot of time.

It would take a lot of time, but I'm thinking we could rely on a little internet magic to speed it up.  I'm thinking of a web-based db that's fed by the community, like the IMDB, with a moderator or two checking to make sure the info is consistent.

This community seems full of people itching to volunteer for things, and it wouldn't take that long to go to the control db site, find out which games don't have descriptions yet, and spend 10 minutes filling out five of them.

Work-in-progress database dumps could be made available so the most popular games, which will probably be filled out first, can start working as soon as possible.

The moderator can deal with control replication, like sf2->msvc->sfa3, etc. through an admin interface to further speed things up.

[SirPoonga]

It would take a lot of time, but I'm thinking we could rely on a little internet magic to speed it up.