ok.... my mind is spinning and can't get off this topic....

the following is what I think about the database setup...
TABLE:
ROM_NAME
FIELDS:
ROM, UNIQUE_ROM
This table will allow multiple versions of the same game using the same data....
sample lines in this table:
sf2, sf2
sf2asia, sf2
TABLE:
MAME_DESC
FIELDS:
UNIQUE_ROM, CTRL, DESC
This table stores for each game, what controls are used and a brief description....
sample lines just for the game sf2:
SF2, J1, Player 1 - 8 way
SF2, P1B1, Jab
.....
SF2, P2B6, Round House
(in here... J1 means Joystick 1 and P1B1 means Player 1 button 1... etc...) we'll need to define standard naming so that everyone (or most of us...) can agree on....
but of course, with different people has different unique things on their panels.... different options can be added on....
like spinner, trackball, or TB1, TB2,... LGun... trigger sticks etc.
TABLE:
CTEL_PANELS
FIELDS:
PANEL, SIZE_X, SIZE_Y
For most of us, we'll have only 1 line here....
(but for swappable panels, and rotating panels... they'll have multiple lines here...) size is just a pixel size.... (something I jsut thought of....)
sample line:
MY_PANEL, 600, 300
TABLE:
PANEL_LAYOUT
FIELDS:
PANEL, CTRL, POS_X, POS_Y
This table shows what is on each panel... the controls are placed where posx and posy are the pixel position... (or something like that....)
sample line:
MY_PANEL, J1, 100, 150
MY_PANEL, P1B1, 120, 100
MY_PANEL, P1B2, 150, 100
....
MY_PANEL, J2, 400, 150
....
and so on....
-----------------------
ok......
if the database is setup like this... then once we get the bcast rom name, we'll be able to get the Unique_rom and knows what controls they are using.....
then cross check with the panels, and panel_layout, we can decide which panel has the "most available functionalities"...
then we can highlight the appropriate controls that are available and gray out the others.... and / or also list the missing controls.... etc.
sounds reasonable so far ??....
