Button Mapping Graphic Display

[simpleman46]

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

[cdbrown]

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.

[)p(]

I was part of the original discussion back in March, and I am very excited to see the enthusiasm this time around!

[csbelli]

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

[)p(]

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

[SteveJ34]

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

[csbelli]

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

[neuromancer]

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

[Nohup]

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

[u_rebelscum]

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.

[SteveJ34]

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.

[1UP]

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.

[u_rebelscum]

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

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

[SteveJ34]

Has anyone yet investigated the idea of pulling the info from the Mame configs for each game?

[1UP]

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.

[u_rebelscum]

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.

[darkmanx]

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.

[SirPoonga]

Anyone start anything yet?

[mrC]

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

[slug54]

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

[SteveJ]

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

[jeremu]

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.

[StephenH]

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.