Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: Button Mapping Graphic Display  (Read 12181 times)

0 Members and 1 Guest are viewing this topic.

SteveJ34

  • Trade Count: (+9)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 806
  • Last login:February 23, 2018, 02:46:08 am
Button Mapping Graphic Display
« on: May 30, 2002, 08:14:18 pm »
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





« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

neuromancer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 446
  • Last login:May 10, 2006, 04:26:57 pm
  • Can I Play?
Re: Button Mapping Graphic Display
« Reply #1 on: May 31, 2002, 02:30:02 pm »
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Steve Johnson

  • Guest
  • Trade Count: (0)
Re: Button Mapping Graphic Display
« Reply #2 on: May 31, 2002, 03:59:02 pm »
Quote

<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



« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #3 on: May 31, 2002, 06:03:04 pm »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

Carsten Carlos

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 579
  • Last login:June 28, 2014, 05:06:25 am
  • Projects: Centipede extended, Asteroids
    • Carlos' Centipede-extended
Re: Button Mapping Graphic Display
« Reply #4 on: June 01, 2002, 03:56:48 am »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »



ErikRuud

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1710
  • Last login:July 09, 2017, 06:44:20 pm
  • I'll build a cab for only 99.99.99!!!
    • Erik's humble video game page
Re: Button Mapping Graphic Display
« Reply #5 on: June 03, 2002, 10:05:22 am »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Real Life.  Still a poor substitute for video games!       
American Laser Games Wrapper
O2em Rom Utility

neuromancer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 446
  • Last login:May 10, 2006, 04:26:57 pm
  • Can I Play?
Re: Button Mapping Graphic Display
« Reply #6 on: June 03, 2002, 01:06:13 pm »
Quote


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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #7 on: June 03, 2002, 08:45:10 pm »
Quote


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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

neuromancer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 446
  • Last login:May 10, 2006, 04:26:57 pm
  • Can I Play?
Re: Button Mapping Graphic Display
« Reply #8 on: June 04, 2002, 10:43:49 am »
Quote

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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #9 on: June 04, 2002, 12:06:40 pm »
Quote



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

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17230
  • Last login:Today at 02:31:40 am
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Button Mapping Graphic Display
« Reply #10 on: June 04, 2002, 06:51:11 pm »
Quote


No no, I don't mean button 1 on the control panel, i mean button 1 in mame.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #11 on: June 05, 2002, 01:14:35 am »
Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #12 on: June 05, 2002, 09:20:10 am »
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #13 on: June 05, 2002, 05:28:22 pm »
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.

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.

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. ;)
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

SteveJ34

  • Trade Count: (+9)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 806
  • Last login:February 23, 2018, 02:46:08 am
Re: Button Mapping Graphic Display
« Reply #14 on: June 05, 2002, 08:32:41 pm »
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #15 on: June 06, 2002, 12:57:59 am »
Quote
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.

Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

SteveJ34

  • Trade Count: (+9)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 806
  • Last login:February 23, 2018, 02:46:08 am
Re: Button Mapping Graphic Display
« Reply #16 on: June 06, 2002, 01:41:20 am »
Quote

I think more details are needed.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

csbelli

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • Last login:March 02, 2018, 07:42:59 am
  • I want to Build My Own Arcade Controls!!
Re: Button Mapping Graphic Display
« Reply #17 on: June 06, 2002, 11:37:24 am »
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

neuromancer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 446
  • Last login:May 10, 2006, 04:26:57 pm
  • Can I Play?
Re: Button Mapping Graphic Display
« Reply #18 on: June 06, 2002, 01:53:11 pm »
Quote



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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #19 on: June 07, 2002, 02:32:42 pm »
Quote
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)
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Howard_Casto

  • Idiot Police
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 17230
  • Last login:Today at 02:31:40 am
  • Your Post's Soul is MINE!!! .......Again??
    • The Dragon King
Re: Button Mapping Graphic Display
« Reply #20 on: June 07, 2002, 06:36:41 pm »
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.    
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #21 on: June 07, 2002, 09:39:42 pm »
Quote

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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #22 on: June 07, 2002, 11:24:55 pm »
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.

Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: Button Mapping Graphic Display
« Reply #23 on: June 08, 2002, 02:13:52 am »
It seems to me that we're getting a bit carried away with all these databases.

Free resource for building your own rotating control panels!

My other job...


1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: Button Mapping Graphic Display
« Reply #24 on: June 08, 2002, 02:33:47 am »
Quote
Here's another problem.

Free resource for building your own rotating control panels!

My other job...


u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #25 on: June 08, 2002, 05:52:43 am »
Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #26 on: June 08, 2002, 11:31:27 pm »
Right, you don't need to know the key stroke a button on your CP uses.

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: Button Mapping Graphic Display
« Reply #27 on: June 09, 2002, 02:19:57 am »
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!
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Free resource for building your own rotating control panels!

My other job...


)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re: Button Mapping Graphic Display
« Reply #28 on: June 10, 2002, 07:53:40 am »
Quote
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #29 on: June 10, 2002, 04:17:17 pm »
Quote
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.  
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

neuromancer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 446
  • Last login:May 10, 2006, 04:26:57 pm
  • Can I Play?
Re: Button Mapping Graphic Display
« Reply #30 on: June 12, 2002, 10:53:38 am »
Quote


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

« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SteveJ34

  • Trade Count: (+9)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 806
  • Last login:February 23, 2018, 02:46:08 am
Re: Button Mapping Graphic Display
« Reply #31 on: June 12, 2002, 11:28:45 pm »
Quote


......snip

example lines:
pacman
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #32 on: June 13, 2002, 02:29:02 am »
Quote
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.

Quote
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

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

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

Quote
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?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

csbelli

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • Last login:March 02, 2018, 07:42:59 am
  • I want to Build My Own Arcade Controls!!
Re: Button Mapping Graphic Display
« Reply #33 on: June 13, 2002, 06:06:45 am »
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

dknight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 10
  • Last login:June 13, 2003, 09:51:52 am
  • I want to Build My Own Arcade Controls!!
Re: Button Mapping Graphic Display
« Reply #34 on: June 13, 2002, 06:23:44 am »
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
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SteveJ

  • Guest
  • Trade Count: (0)
Re: Button Mapping Graphic Display
« Reply #35 on: June 13, 2002, 08:54:47 am »
Quote


Yes.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #36 on: June 13, 2002, 11:06:20 am »
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....
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #37 on: June 13, 2002, 11:09:33 am »
Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SteveJ

  • Guest
  • Trade Count: (0)
Re: Button Mapping Graphic Display
« Reply #38 on: June 13, 2002, 01:57:22 pm »
Quote


I don't know if you figured it out or someone told you.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Trenchbroom

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 276
  • Last login:November 26, 2016, 06:17:24 pm
  • Wampus? Get over here!
Re: Button Mapping Graphic Display
« Reply #39 on: June 13, 2002, 04:55:04 pm »
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.) ."
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

simpleman46

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 19
  • Last login:December 29, 2003, 10:54:47 pm
  • Nummy Goodness
    • From Rocks
Re: Button Mapping Graphic Display
« Reply #40 on: June 13, 2002, 06:09:40 pm »
Lots of interesting reading in this thread.  On a related note- I dug up this older thread.  
Check it out:
http://www.arcadecontrols.org/cgi-bin/yabb/YaBB.cgi?board=software;action=display;num=1016481463
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

cdbrown

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1242
  • Last login:October 16, 2017, 09:52:03 pm
  • Bowowow
Re: Button Mapping Graphic Display
« Reply #41 on: June 13, 2002, 06:56:49 pm »
Quote

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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re: Button Mapping Graphic Display
« Reply #42 on: June 13, 2002, 11:34:21 pm »
Quote
I was part of the original discussion back in March, and I am very excited to see the enthusiasm this time around!
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

csbelli

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • Last login:March 02, 2018, 07:42:59 am
  • I want to Build My Own Arcade Controls!!
Re: Button Mapping Graphic Display
« Reply #43 on: June 14, 2002, 08:55:16 am »
CDBrown-

I received the spreadsheet and I think that will be a great starting point. I will transfer that information to a database and begin building a web interface. Thanks for sending it.

For everyone-

The spreadsheet currently has fields for:
Rom Name
Game Name
Number of Players
Controls Used
Number of Buttons
Number of Coins.

What fields would you like to see removed from this list or added to this list?

Thanks,
csbelli
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

)p(

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 964
  • Last login:March 27, 2009, 03:38:15 am
  • We are the Galaxians...
    • Emulaxian:cabinet and frontend
Re: Button Mapping Graphic Display
« Reply #44 on: June 14, 2002, 09:06:29 am »
Quote
CDBrown-

I received the spreadsheet and I think that will be a great starting point. I will transfer that information to a database and begin building a web interface. Thanks for sending it.

For everyone-

The spreadsheet currently has fields for:
Rom Name
Game Name
Number of Players
Controls Used
Number of Buttons
Number of Coins.

What fields would you like to see removed from this list or added to this list?

Thanks,
csbelli


game name is not relevant and can be removed I think...rom name is ideal as unique identifier for the game...

Peter
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SteveJ34

  • Trade Count: (+9)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 806
  • Last login:February 23, 2018, 02:46:08 am
Re: Button Mapping Graphic Display
« Reply #45 on: June 14, 2002, 09:16:45 am »
Quote
CDBrown-

I received the spreadsheet and I think that will be a great starting point. I will transfer that information to a database and begin building a web interface. Thanks for sending it.

For everyone-

The spreadsheet currently has fields for:
Rom Name
Game Name
Number of Players
Controls Used
Number of Buttons
Number of Coins.

What fields would you like to see removed from this list or added to this list?

Thanks,
csbelli


I believe this should include "clone of" and then be cross referenced by rom name to the list that urebel has done, ie:

rom | control | function

In this manner once we populate the a game that has several clones we can just propigate this to the other games.

See earlier posts for a link to that data.

Again, I will be happy to donate the webspace for this. I was even considering acquiring a domain name to put it up under, like mameprojects.com or mameteam.com or ???

Is someone is interested in aiding the website design and setup for this?

I am a single dad with three kids and a full time business so my available time can be sparse at times but I don't mind footing some expenses in order to create a "playground" if others have some time to put into it.

I will be happy to provide documenting help.

As always, I look forward to all replies.

Steve


« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

csbelli

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 8
  • Last login:March 02, 2018, 07:42:59 am
  • I want to Build My Own Arcade Controls!!
Re: Button Mapping Graphic Display
« Reply #46 on: June 14, 2002, 09:59:01 am »
SteveJ-

I think the clone idea is excellent. I will also look for the link to the data URebel did.

I am a web programmer so I can help with the website. I am not a designer though so if you are looking for creativity, maybe someone else can help. As long as we are talking about ASP and HTML and Javascript, I am your man. Let me know what I can do. Thanks for donating the webspace. I think that will be a real help.

csbelli
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

neuromancer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 446
  • Last login:May 10, 2006, 04:26:57 pm
  • Can I Play?
Re: Button Mapping Graphic Display
« Reply #47 on: June 14, 2002, 11:00:02 am »
Quote
SteveJ-

I think the clone idea is excellent. I will also look for the link to the data URebel did.

I am a web programmer so I can help with the website. I am not a designer though so if you are looking for creativity, maybe someone else can help.
csbelli


I think instead of "clone of" it should be "same controls as" There are tons of games that use the same controls that are not clones. the project will be even easier that way.

While we're still in the design phase, I like the idea of categorizing controls in chronological order, instead of alphabetic. That way the *first* game with a single 8way stick and one fire button gets "recognition"

I can do some design, artwork, type, and editing.

Bob
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Nohup

  • Guest
  • Trade Count: (0)
Re: Button Mapping Graphic Display
« Reply #48 on: June 14, 2002, 04:13:30 pm »

If "number of players" is to be included in the database,  I would like to suggest that the number of SIMULTANEOUS players be somehow coded into the mix.

I mean there will be a difference between 2-player pac-man, and 2-player street-fighter...  

If this is somehow taken into account in the button mapping section, then no problem.  But if all we record  is...

2 player, 8wayJoy,3 buttons, then we don't know if we need 2 sticks, 6 buttons or just the 1 stick and 3.

I plan on putting some games into the database as soon as it's online, and just want to make sure everything works right the first time...   :)
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #49 on: June 14, 2002, 06:25:40 pm »
Quote
The spreadsheet currently has fields for:
Rom Name
Game Name
Number of Players
Controls Used
Number of Buttons
Number of Coins.

What fields would you like to see removed from this list or added to this list?

Thanks,
csbelli

I like the suggestions of adding a "clone of" or "control like" field.

I also like the idea by Nohup to add "Number of Controls" field.  But how will one player at a time cocktail games be numbered?  Or games can be be either 2 player, 1 player simultaneous, 1 control game, or a 2 player, 1 player simultaneous, 2 control cocktail game by a switch of a dipswitch?

One thing to note:
if the spreadsheet got the data from mame -listinfo, some of the data might not be true.  Specifically the "Controls Used" and "Number of Buttons" fields are not exactly what -listinfo outputs.  Fields with data from -listinfo output are closer to:
"one of the control types used by this game" instead of "Controls Used (by this game)", and
"highest mame button type ( 1-8 only ) used by this game driver" instead of "Number of Buttons (used by this game)".

I say drop the those two fields and use an edited (rom | control | function) list crossref'ed instead.  

list download.  It's a zipped tab delimited text file.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

SteveJ34

  • Trade Count: (+9)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 806
  • Last login:February 23, 2018, 02:46:08 am
Re: Button Mapping Graphic Display
« Reply #50 on: June 14, 2002, 08:02:43 pm »
Quote

I like the suggestions of adding a "clone of" or "control like" field.

I also like the idea by Nohup to add "Number of Controls" field.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: Button Mapping Graphic Display
« Reply #51 on: June 17, 2002, 12:56:02 pm »
Has anyone yet investigated the idea of pulling the info from the Mame configs for each game?  Even if -listinfo has incorrect data, the settings within each game usually has the correct number of buttons and stick directions.  That way your database only includes the fields for games that you actually have.

Also, as I mentioned above, when a button is remapped, it could automatically be updated to the right position on the CP graphic.

My 2 cents.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Free resource for building your own rotating control panels!

My other job...


u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #52 on: June 17, 2002, 09:36:49 pm »
Quote
Has anyone yet investigated the idea of pulling the info from the Mame configs for each game?  Even if -listinfo has incorrect data, the settings within each game usually has the correct number of buttons and stick directions.  That way your database only includes the fields for games that you actually have.

Using the cfg/*.cfg files would be pretty hard; I've seen people (including me) suggest parsing the info out of them even since I learned of mame a year ago, and very little more than talk.  

The new ctrlr/*.ini files are much easier to parse.  These new files, however, aren't part of dos mame yet, and the old cfg/*.cfg files are still the files editted (in both win & dos) when the settings are changed in game (for now, at least).

That being said, the list I submitted earier is as accurate as the cfg/*.cfg files in number of buttons, type(s) of controler(s) used, ect.  My list is an easy to read tab delimited text file (vs .cfg binary files), but doesn't include the actual keyboard/joystick input settings.  Any errors in my file will also be in cfg/*.cfg files too, because the information was gleaned from the same driver data used to build the cfg/*.cfg files.  (And yes, there are errors in both, but not as many is in -listinfo.)

Quote
Also, as I mentioned above, when a button is remapped, it could automatically be updated to the right position on the CP graphic.

My 2 cents.

Yes, this is the reason to use these cfg/*.cfg files.  Except two small things: the new ctrlr/*.ini files, and "default" settings.  

There is a special input setting, "CODE_DEFAULT", used in the cfg/*.cfg files that basically means "input settings are not saved here, just use the settings already there".  As most inputs are marked as "default" in the cfg/*.cfg files, the input data is actually saved in the default.cfg (again, only if not "default"), then ctrlr/*.ini (if specified, win v.60 only), and finially the standard mame settings.  

Mame maps the inputs as follows: standard inputs, over written by ctrlr/*.ini files (if referenced to, win v.60 only), over written by non-default inputs in cfg/default.cfg file, over written by non-default inputs in cfg/*.cfg file.  So to see changes made in a ctrlr/*.ini file ("ctrlr hotrodse" for example, for us hotrod users), the FE will need to be able to read ctrlr/*.ini files.  I suggest (for a windows FE, at least) parsing mame.ini for the ctrlr name setting, that name folder/zip file, and gamename.ini for input settings.  Much easier to parse because they are standardized text files.  (cfg/*.cfg files are semi-standardized binary files.)

I also think (hope) the old cfg/*.cfg files will be superseeded by ctrlr/*.ini equivalents, and if this is true, any reading of the old cfg files would need to be changed anyway.

The FE will combine the ctrlr data with mame's standard input settings and do the mapping.  Adding reading cfg/*.cfg files, IMO, should not be a priority, because who knows if mame.61 will stop using the .cfg file, until it comes out.


BTW: the reason -listinfo says 2way joysticks are 8way is because, to mame, there is no difference.  Even if the input is declared as a "2way" joystick in the driver, mame compiles 2ways and 8ways with the same id:
[snip from source]

#define IPF_8WAY       0
#define IPF_4WAY       0x00080000
#define IPF_2WAY       0
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

SteveJ34

  • Trade Count: (+9)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 806
  • Last login:February 23, 2018, 02:46:08 am
Re: Button Mapping Graphic Display
« Reply #53 on: June 17, 2002, 09:39:37 pm »
Quote
Has anyone yet investigated the idea of pulling the info from the Mame configs for each game?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

1UP

  • Token Junkie
  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2081
  • Last login:November 11, 2014, 01:37:18 am
  • Yes, that is a joystick in my pocket.
    • 1UPArcade
Re: Button Mapping Graphic Display
« Reply #54 on: June 17, 2002, 11:28:51 pm »
Quote


If I follow what you are saying, I believe this is the approach that urebel has taken to create the dump for which a link thereof is posted in a previous message.

This gives the controls by game....from which we will need to map the functions for (ie: fire, punch, etc) but gives a good starting point).

He modified the -listinfo function and recompiled to produce the results.

If I am off target to what you are saying, please type some more.

Steve



I dunno...this all makes my head hurt!  :(  I'll leave it to the techies, they seem to be on the right track.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

Free resource for building your own rotating control panels!

My other job...


u_rebelscum

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3633
  • Last login:April 21, 2010, 03:06:26 pm
  • You rebel scum
    • Mame:Analog+
Re: Button Mapping Graphic Display
« Reply #55 on: June 18, 2002, 04:20:05 am »
Quote
I dunno...this all makes my head hurt!  :(  I'll leave it to the techies, they seem to be on the right track.

Sorry, my answers are always waaay too long. :-/

Recap: the cfg files are hard to read, and the only data they have that my file doesn't is: that user's non-standard input settings at run time.  A good reason for the FE to use the cfg files when mapping the buttons, but not to build the original DB.

And what SteveJ34 said too.  Now I shut up and keep the answer short. :-X
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
Robin
Knowledge is Power

darkmanx

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 175
  • Last login:May 29, 2003, 04:46:57 am
  • I want to Build My Own Arcade Controls!!
Re: Button Mapping Graphic Display
« Reply #56 on: June 18, 2002, 05:09:40 am »
Im no expert or anything, but I do have another idea which seems simpler to me.. I dont know what language FE's are usually coded in or anything but.. I do know visual basic.

Now say you create your form with a layout of pretty much any control someone would conceivably have represented by a picturebox or label or whatever you want for each control. If you want it simple you could do that with a generic layout, or you could make it so the user could add/remove/move any control type they want.

The info would be stored in an .ini file or something. To show which controls are used for each game you simply have one picture of the control dimmed, and another lit up to show it as used in that game; also you could have a label for each that tells what it does. Of course the biggest part is gathering all the info for so many games.

But once you get past that it seems simple to me. When a person clicks the name of the rom it highlights the controls for that game and also calls up the description of what the control does from the .ini. also, you could just have a generic "type" of layout as some of you have suggested already.

One thing im not sure of how to do but could probably be figured out without too much trouble is.. entries in the .ini to save the positions and labels for all the buttons. probably not too hard but surely tedious. but anyway,  this is just a brief example of what the code could be like, bare with me if it seems confusing. explaining code isnt as easy as writing it.

first people set thier custom controls.. a section in the ini (programmable through the GUI of course..:

[default controls]
picture1= butn1
picture2= butn2
etc...

after they select all thier buttons and whatnot they can be referenced in the ini later on..

ok say this is for street fighter..
you have info in your ini for each game name like:

[streetfighter]
butn1=xx
butn1label= fierce punch
butn2=xx
butn2label= medium punch
etc.. for each input the person has.

then when the list is clicked, it will call up each setting from the .ini file. if there is no setting for a particular button, it is dimmed. if there is it gets highlighted and the label is applied.

also, a seperate program could be writtin to input the default entries into the ini file.

well i dunno its just an idea. any thoughts or questions about it feel free to let em fly.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »
WHELP! As if you knew what an eternity was. Grovel before your true master!

SirPoonga

  • Puck'em Up
  • Global Moderator
  • Trade Count: (+1)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 8176
  • Last login:September 05, 2017, 09:45:52 am
  • The Bears Still Suck!
Re: Button Mapping Graphic Display
« Reply #57 on: June 27, 2002, 08:56:51 pm »
Anyone start anything yet?
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

mrC

  • Guest
  • Trade Count: (0)
Re: Button Mapping Graphic Display
« Reply #58 on: June 27, 2002, 10:56:13 pm »
..Second that...

This is such a cool idea and you've all gone so far
towards a logical solution! Pleeeease makes this happen...  ;)

As a big fanboy of this thread I'd love to see this project
come to fruition. But, alas, as I have no db or programming skills, I will just keep up high hopes.

*crosses fingers* 8)

« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

slug54

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 225
  • Last login:June 12, 2014, 09:00:21 pm
  • Man, I hope this cab fits through the door way!
    • Arcade Extreme
Re: Button Mapping Graphic Display
« Reply #59 on: June 27, 2002, 11:54:42 pm »
Just thought I would put up a couple of screenshots of
the front end I'm designing for my cab.
Thought it might give somebody some ideas or help with visualising this project.
The mouse pointer doesn't show in these screen captures but when the mouse moves over a button for a game the screenshot changes and the control panel graphics change to match the game. It also will show any special instructions you want for each game.
I don't pull the info from mame or anything
I just go into the configuration menu and use drop down menus to select the controls that are used for each game and also use drop down menus for the controls descriptions IE shoot , turn, Punch or you can type whatever you want for a label like "Rotate Claw"
for tempest. I only show my top 75 favorite games
with this format at the momemt. If you wan't to play
something different I have a button that will launch mame32 for all the remaining games.

the graphics are pretty crude for the C-panel at this point, I've been working more on the functionality of it.
This is definitely not ready for prime time.

Here are the pics.

http://home.insightbb.com/~anson66/tempest.gif

http://home.insightbb.com/~anson66/defender.gif

http://home.insightbb.com/~anson66/centipede.gif

http://home.insightbb.com/~anson66/configure.gif

Yeah thats a modified Arcade Jukebox Skin if anyone was wondering.

If anyone has any questions or comments just let me know


                                Slug54
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

SteveJ

  • Guest
  • Trade Count: (0)
Re: Button Mapping Graphic Display
« Reply #60 on: June 28, 2002, 09:10:36 am »
Quote
Anyone start anything yet?


Being the "starter of this thread" which has generated quite a bit of enthusiasm/following in combination with my offer to put up a web which will host the collection of information and provide a playground for us all to work in as we mold this along, I believe everyone is "waiting" on me.

I have organized the full contents of this thread, had some email exchanges with varying individuals offering different areas of talent, assembled a list of those participants, assembled some notes and outlines regarding data/graphics, how we might use them based on different input, and that's about where it sits.

I am more than happy to spend some $ to host a web and I think from the materials I have put together from the crowd, we have a good starting point. We have several programmers in the group, some wishing to support the web, some willing to support the graphics, some willing to support the "front end graphics generation", many that will support the data collection process, etc etc.

Being a single dad with three kids out of school for the summer and going in three different directions at the same time, what I have lacked is available time to pull all these pieces together.

I had hoped to find time to at least get this "off the ground" during the month of June and get a basic web up but it is now almost July.

I believe its important that the person(s) who will aid the actual game front end and/or graphics generation application from the data assembled be a part of the early database design. I think we have a very good outline which gets us about 90-95% of where we need to be to "get started".

From here we need to put up a web access to the shell database that will allow multiple people to update data for each game.

Once we have a small sample of data assembled and we can agree on the graphics that will be incorporated, someone can begin work on that.

My thought would be that we would first design an app that would take the assembled data, some graphics, and generate graphic files so that in this way the resulting control panel graphic for each game could be incorporated into any front end that supports a graphic display associated with a game.

From this point, we might take it a step further and customize an actual front end ourselves but there are several good ones out there that each individual has their own preference for.

I will say this: If one or more of you has more available time than I and wishes to "be the leader" on this project, I will be happy to fund the web space. Just because I posted the idea and have assembled some of the starting points of data and interest, I have no problem passing the reigns over to someone else.

I will be happy to support the project and provide other resources as we collectively deem them necessary.

Sorry for the long winded post but that's an overview of "what I have done" over the last couple of weeks to at least try and move the process along.

I have a high level of interest in supporting this project and look forward to taking next steps.

Steve
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

jeremu

  • Guest
  • Trade Count: (0)
Re: Button Mapping Graphic Display
« Reply #61 on: June 28, 2002, 08:57:57 pm »
Quote
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.
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »

StephenH

  • Guest
  • Trade Count: (0)
Re: Button Mapping Graphic Display
« Reply #62 on: June 28, 2002, 10:28:46 pm »
What about building a dual-monitor cab (or buying one like Punch Out!!!, Playchoice-10, Sega Mega Tech, etc)?

I like the idea of "graphical" instructions.   This is a great idea.    However, to make it look authentic is another matter.

My idea for this is a dual monitor cab, and the top monitor displays the instructions.    The way to accomplish this would be to write a frontend that supports dual monitors, and incorporates a Bitmap, GIF, PNG, or other image format (I do not recommend JPEG, because of Lossy compression).  

Basically, when a game is launched, an image for that game is sent to the top monitor, while the monitor at eye level is cleared, and MAME takes over with the game.  
« Last Edit: December 31, 1969, 07:00:00 pm by 1026619200 »