Main > Main Forum
Button Mapping Graphic Display
Howard_Casto:
--- Quote ---
No no, I don't mean button 1 on the control panel, i mean button 1 in mame.
--- End quote ---
u_rebelscum:
--- Quote ---Exactly. You would need a skin exactly Like Rd uses.... [snip]
--- End quote ---
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.
--- Quote ---
I think table 1 can be made (without the "fire"/"jump" type labels) with a few changes in mame source.
--- End quote ---
u_rebelscum:
--- Quote ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.[/list]
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