Game Controls viewer?

[stigzler]

Can I just check before I dive down a 2 year rabbit hole, has anyone written or are there plans by the devs to write a CPWizard style controls viewer for Launchbox? 

[JoeViking245]

There's a Pause Theme floating around that will display the Controls Information image.  (Don't recall if it's generic controls, game specific, or both)  Similar to CPWizard's MAME pause feature.  But not as a 'menu item'.  It simple shows the image in with the Theme.

I've also seen a modified Startup Theme that does the same thing.

I've seen an AutoHotkey script that's used in leu of MAME as the emulator that will show a full screen 'splash' of your game-specific Controls Information image, until you press a key.  After the key press, MAME is started, loading your ROM as normal.  This one takes a little bit of "creative licensing" to work. But viable none-the-less.

Of course, all 3 of these require that you already have all the control images.

 

How far are you willing to go?  Well, 2 years, I guess. lol  I know one (or several) users have created Console (vs Arcade) specific controller images to go with the Pause Theme above.  Are you wanting to create something that will auto generate on-the-fly, images?  I think CPW may have done that [for Arcade].  Hmm... maybe not on-the-fly.  But the auto generate is (was) cool!

I'm intrigued to see where your idea takes you.

[haimbilia]

this gets asked all the time, i know many that started and gave up very early.
the problem is they attack the problem from the wrong angle, making images is a wasted effort. what we need is a moves-list database.
the images can be photoshop-batched in whatever style of control-panel/gamepad you want
but what we really need is the list of moves for every game so we can make these images quickly.
we don't have to start from scratch, there's the keyb2joypad project that covers most dos games, and also https://strategywiki.org/wiki/Category:Game_move_lists
i made a request to include it in the LBDB: https://bitbucket.org/jasondavidcarr/launchbox/issues/6994/feature-request-a-moves-list-metadata 
it can also help with automatic button mapping for every controller.. 

[stigzler]

Thanks for the answers. I'll have to check my settings as didn't get notified of them. 

@JoeViking245 - I think I saw this once. If memory serves - isn't this just standard mapping for all games - not game specific mappings? As for how far I'm willing to go - well I've kinda gone the whole hog on a prototype already over a number of years. Think CPWizard but extended and for all systems. It also allows for different game modes (think sets of button mapping for different modes of game controls - eg. on horseback, on foot, in menu). It's totally mappable to you rig control (e.g whether you have an arcade cab, or whether you use a controller) and also accommodates in game remaps and in-emulator per-game remaps. I kinda had to warp the space-time continuum to get it working, but it does somehow 🤷🤷 I dev'd it on another FE as wasn't using Launchbox at the time and needed an FE to feed the game info and artwork forward. Can post some vids once get it released.

On 8/3/2022 at 11:13 PM, haimbilia said:

this gets asked all the time, i know many that started and gave up very early.

I have a funny feeling I should have given up about 6 years ago, but I won't rest until my cab has dynamic per-game controls being fed from a community driven database!!

Which drives me back to my original question. I do have the means to author this and make it happen for the community. I would have preferred to have done this for the retro gaming community at large, but by god, why haven't we all agreed on a single standardised ID yet for all games, or indeed, systems? Human nature at work...

Thus, I have to pitch my tent somewhere. I'm noticing Launchbox are hiring lots of new staff more recently, so it's getting bigger. I'm very happy to contribute, but I would rather know if the devs have this feature in mind for future development rather than spending two years doing something as a solo developer that a team of a few bring out a few months before I do at half the effort and for free! 🤣🤣

What's the best way to find that out?

[JoeViking245]

10 minutes ago, stigzler said:

isn't this just standard mapping for all games - not game specific mappings?

I don't recall. I kind of made (modified actually) a pause theme of my own to show the game specific controller image.  But just for Arcade.  The control panel images are stored in \Images\Arcade\Arcade - Controls Information\.   And I bind them using   Source="{Binding SelectedGame.ArcadeControlsInformationImagePath}"

For all other Platforms I do have a 'standard mapping' image.  But I don't really use those anywhere.   But I do know that you can create (if it doesn't exist) an \Arcade - Controls Information\ folder under any platforms image folder (i.e.  \Images\Nintendo GameCube\Arcade - Controls Information\) and bind the image the same way.

[megashub]

On 8/1/2022 at 9:13 AM, JoeViking245 said:

I've seen an AutoHotkey script that's used in leu of MAME as the emulator that will show a full screen 'splash' of your game-specific Controls Information image, until you press a key.  After the key press, MAME is started, loading your ROM as normal.  This one takes a little bit of "creative licensing" to work. But viable none-the-less.

Do you happen to remember where you found this? I've been trying to conceptualize writing one myself... but I have no knowledge or experience with pulling the button mapping data from MAME on a per-game basis, so I've been trying to figure out where to begin on that front. I have my CP's image assets created, so now it's really just a matter of writing up the Gui commands to dynamically position and display them when/where I want them. 

I've already written code to display/hide instruction cards for virtual pinball tables when I press and hold a button (gui destroys when you let go of the button). So I was planning on reusing that for MAME to simply listen for a specific button combo and send a pause button command to MAME, then pop the dynamic controls on the screen while the button is held, and then destroy the gui and unpause the game when the button (or button combo) is released. 

If the script you're referring to handles the pulling of MAME's game-specific controls configs into variables I can reference, that would cut out a lot of the work. 

[JoeViking245]

1 hour ago, megashub said:

Do you happen to remember where you found this?

I found this particular script in the folder where I saved it after I was done creating it. 

 

1 hour ago, megashub said:

If the script you're referring to handles the pulling of MAME's game-specific controls configs into variables I can reference, that would cut out a lot of the work.

lol  Don't take this wrong but, dream on.  I'm not saying I have that and won't share.  I'm saying that would be a PITA to incorporate.  Anyway, somewhere 'out there', there is/was a controls.dat (or controls.xml?) that listed button_1 = "Run", button_2="Jump" and so on, for quite a few arcade machines.  But it was created a long time ago, but in a galaxy not so far away.  And as far as I know, hasn't been updated since a long time ago.

There is more recently "mame-portnames" on GitHub.  It was last updated 4 years ago. (And yes. I did say more recently)  It has the same info but in individual json files for each game.  Either of these can be parsed to gather games-specific controls for reference.

 

The script I was referring to just shows an existing image.  It doesn't "create" them.  (CPWizard created them for me)  It was written quite a while ago, is kind of cheesy and somewhat primitive.  But was really cool when I wrote it. lol  Oh, and it messes up LB's Pause Screen.  But that didn't matter to me.

Fow what it's worth, here's that emulator script.

Spoiler

;*****************************************************************************************
;       Display an image file full screen corresponding to the selected MAME ROM.
;   
;       Image name and ROM name must be the same.  
;           dkong.zip  and  dkong.png  will work
;           dkong.zip  and  dkong_01.png  will not
;*****************************************************************************************

#SingleInstance force

;*****************************************************************************************
;       Adjust the following only:
;       MAME directory
;       The MAME executable file
;       ROMS directory
;       Images directory
;       Duration to show image in seconds.  1000 = 1 sec (Optional)
;*****************************************************************************************

SetWorkingDir, F:\Emulators\MAME
MAMERun = mame.exe -keyboardprovider dinput
RomDir = G:\Roms\MAME NonMerged
ImageDir = F:\LaunchBox\Images\Arcade\Arcade - Controls Information
ShowForSec = 7000

;*****************************************************************************************
;       Save it. Run it. Play.
;*****************************************************************************************

Process, Exist, %MAMERun% ; check to see if MAME is running
If (ErrorLevel = 0) ; If it is not running
    {
        IfExist, %ImageDir%\%1%.png
        {
            Gui, -Caption +ToolWindow
            Gui, Margin, 0, 0
            Gui, Color, Black
            Gui, Add, Picture, w%A_ScreenWidth% h-1, %ImageDir%\%1%.png
            Gui, show, x0 y0 w%A_ScreenWidth% h%A_ScreenHeight%, NA
            
            ;**** Optional****
            ;sleep, %ShowForSec%

            ;*** Wait for cab button 1, 2 or 3 press, or joystick movement
            Input, SingleKey, L1, {LControl}{LAlt}{LShift}{Left}{Right}{Up}{Down}
            
            Gui, Destroy
            Run, %MAMERun% "%RomDir%\%1%", , Hide
        }
        Else
        {
            Run, %MAMERun% "%RomDir%\%1%", , Hide
        }
    }
Exitapp

 

[megashub]

2 hours ago, JoeViking245 said:

lol  Don't take this wrong but, dream on.  I'm not saying I have that and won't share.  I'm saying that would be a PITA to incorporate.  Anyway, somewhere 'out there', there is/was a controls.dat (or controls.xml?) that listed button_1 = "Run", button_2="Jump" and so on, for quite a few arcade machines.  But it was created a long time ago, but in a galaxy not so far away.  And as far as I know, hasn't been updated since a long time ago.

yeah no, the only thing I really care about is which inputs are in use for a given game, not necessarily what each one does. That's a problem for future me that I don't know if I care enough to ever solve. So, for example, if my 2-player 8-button with spinners CP is being used to play a game with 3 of the 8 buttons active and it uses the spinner and not the joystick, then I want to be able to show a controls image with all but those specific enabled controls inactive and the those specific controls show their active image instead. 

Edited August 25, 2022 by megashub

[stigzler]

5 hours ago, megashub said:

Do you happen to remember where you found this? I've been trying to conceptualize writing one myself... but I have no knowledge or experience with pulling the button mapping data from MAME on a per-game basis, so I've been trying to figure out where to begin on that front. I have my CP's image assets created, so now it's really just a matter of writing up the Gui commands to dynamically position and display them when/where I want them. 

I've already written code to display/hide instruction cards for virtual pinball tables when I press and hold a button (gui destroys when you let go of the button). So I was planning on reusing that for MAME to simply listen for a specific button combo and send a pause button command to MAME, then pop the dynamic controls on the screen while the button is held, and then destroy the gui and unpause the game when the button (or button combo) is released. 

If the script you're referring to handles the pulling of MAME's game-specific controls configs into variables I can reference, that would cut out a lot of the work. 

The prototype I've just written can do this. It leverages controls.dat, pulls from the default mame controls layouts, pulls from controls.dat and then generates all the mame game layouts (+ button colors if you want them). It can also do a bunch of other stuff like choosing which default group control you want to show (e.g. driving games can have paddle or spinner etc). The per-game controls is easily coded - can't remember exactly now, but mame store per-game configs in a folder - the app would jsut read from these for each game and remap controls - the ore code is already there. As above, I'll post some vids of it in action when I have more time. I'm keen to start developing something over the winter, but want to get it done properly - so would want to scope this out fully with the launchbox community first - e.g. futureproofing + integration (e.g. with the launchbox database). 

Edited August 25, 2022 by stigzler

[megashub]

24 minutes ago, stigzler said:

The prototype I've just written can do this. It leverages controls.dat, pulls from the default mame controls layouts, pulls from controls.dat and then generates all the mame game layouts (+ button colors if you want them). It can also do a bunch of other stuff like choosing which default group control you want to show (e.g. driving games can have paddle or spinner etc). The per-game controls is easily coded - can't remember exactly now, but mame store per-game configs in a folder - the app would jsut read from these for each game and remap controls - the ore code is already there. As above, I'll post some vids of it in action when I have more time. I'm keen to start developing something over the winter, but want to get it done properly - so would want to scope this out fully with the launchbox community first - e.g. futureproofing + integration (e.g. with the launchbox database). 

I don't know though that the LB/BB devs have the cycles to spare to partner with you on the pre-planning and futureproofing assurance work you're asking for. Historically, they've taken a very crowd-sourced approach to features/functionality prioritization but otherwise seem to keep to themselves. So while the user and plugin dev community is given a voice ~once a year, it's still pretty opaque what's coming, when and why, most of the time (from my perspective anyhow). 

Regardless, I'm very excited to hear you're willing to put in time and effort toward solving this problem. Consider me a willing beta tester and QA guy.

[C-Beats]

We've looked into the possibility of doing something like this before, but as @JoeViking245 stated there just isn't any good data out there that is up-to-date, and the data that IS out there is ONLY for Arcade/MAME and wouldn't help with other consoles. Be cool to see if some one solves that problem, but right now is a bit of a chicken and egg scenario, and that doesn't even begin to take into consideration the fact that emulation makes it possible for buttons to be mapped anywhere so making something like that which matches your exact setup becomes even more difficult and cumbersome. It'll be interesting to see what @stigzler comes up with.

[stigzler]

On 8/25/2022 at 11:21 PM, megashub said:

I don't know though that the LB/BB devs have the cycles to spare to partner with you on the pre-planning and futureproofing assurance work you're asking for. Historically, they've taken a very crowd-sourced approach to features/functionality prioritization but otherwise seem to keep to themselves. So while the user and plugin dev community is given a voice ~once a year, it's still pretty opaque what's coming, when and why, most of the time (from my perspective anyhow). 

Regardless, I'm very excited to hear you're willing to put in time and effort toward solving this problem. Consider me a willing beta tester and QA guy.

Ah yeah. I wasn't really expecting much time/participation from them and tbh I'm more of a solo flier anyway. However, I am a believer in smart collaboration and for a bit of this at the start planning dovetailing of this into any future plans of theirs could benefit lunchbox largely (eg. I think there's some kind of controller function in lunchbox? Thus preserving ids etc). After all, it could be of commercial interest to them whilst I would be providing something potentially of value for nothing (not that I'm expecting anything for that, just making a point why a consideration of a post at this stage may be helpful). I'd do know how busy they are with dev and keeping the community happy, though.

The barest minimum that would be helpful to me is a straight yes or no about whether they are planning on developing this themselves in the future, saving me a lot of work. Even if just via IM. However, also realise future feature releases may be super secret! I realising I'm writing cheques without any credit in the lb community ATM, so will post some vids of the prototype in action over the next couple of weeks when I get chance in between work. 

My other option is to make it stand alone and generic and to work off rom names alone using the screenscraper database ids as the standard game reference which would x ref rom names (which would also loose the launchbox systems and game standard by default). So many design choices!

Thanks for the offer of beta testing. Always deffo needed and will take you up on it!

 

 

 

Edited August 27, 2022 by stigzler

[stigzler]

On 8/26/2022 at 1:44 PM, C-Beats said:

We've looked into the possibility of doing something like this before, but as @JoeViking245 stated there just isn't any good data out there that is up-to-date, and the data that IS out there is ONLY for Arcade/MAME and wouldn't help with other consoles. Be cool to see if some one solves that problem, but right now is a bit of a chicken and egg scenario, and that doesn't even begin to take into consideration the fact that emulation makes it possible for buttons to be mapped anywhere so making something like that which matches your exact setup becomes even more difficult and cumbersome. It'll be interesting to see what @stigzler comes up with.

You're right. In all reality, it'd be building the default system, default system controller, default system controller controls and default system controller game functions (including game modes) databases from scratch. Thus the need for true community collaboration from the start.

Eg.

 

System: Sony PlayStation

Controller: DualShock V1

Controls: Cross,Circle,Triangle,R3 (etc)

Tekken 3:

GameMode: Fight

Control: Cross

Function: Low kick

GameMode: Menu

Control: Cross

Function: Select

Edited September 12, 2022 by stigzler

[stigzler]

Here's a video showing my prototype in action. It shows how you setup controls for cabs and gamepads, map them to emulators and how MAME mappings work. It's a bit long as it's a tutorial, but you could skip through to get an idea:

I wrote it essentially as a prototype for the bigger project. I'm really deliberating over the best approach to authoring a specific tool. The ultimate goal will be to build and display game controls layouts for all games on all systems (including different modes within each game (eg. walking, flying, in menu etc) and maybe special moves sets for things like Tekken etc). The database would be community populated. I'd also like to future-proof it. Those of you who have been around in this hobby long enough know that things come and go, but well designed things last (like poonga's controls.ini/dat/xml for MAME) so that has me thinking about the best approach to giving it longevity. The other thing that would be desirable would be that any controls layout display software would also integrate any other game/system specific assets in an integrated fashion (as per the vid above) - so it would need to integrate seamlessly with any source software. 

The benefit Sir Poonga had with Controls.dat was that Mame had standardised names for mameroms (essentially, each mame game has a standardised unique reference). These don't exist of course for games more widely, of course. So what I'm considering is this. Games will have a new unique ID (I know, I know) for the Game Controls Database. However, each will also have a list of known roms gleaned from the excellent Screenscraper database, the Launchbox game ID if it has one and any other Front End ids. I would link with Launchbox as the main front end for its development and invite community development of the Games Controls Database. There would be a plugin for Launchbox which would communicate with the stand alone application, share data with it such as the rom filename, LaunchboxID, assets etc etc etc which could then construct controls displays on the fly from the game controls database. 

For those of you who don't know Screenscraper's work, check this link here. They basically catalogue all known roms for all games, alongside game descriptions and titles and numerous other metadata for regions etc. A truly great archiving effort:

https://www.screenscraper.fr/gameinfos.php?gameid=19939&action=onglet&zone=gameinfosroms

I'll give you an example of why this might be necessary in practice. I have the rom "100 Star (Europe).rar" in my Playstation collection. Launchbox does not scrape this correctly and thus does not give it a launchbox ID. However, if you search this on Screenscraper.fr, then it is identified as "Popstar Maker" Now, there's two things here. I could author the plugin to update Launchbox from Screenscraper to the new details (bonus!). But, also, I now know that the Launchbox ID for Popstar Maker (if I've pre-scraped the Screenscraper db). Thus, syncing two databases. 

There would be a piece of publicly available software for updating the Game Controls Database so it can be updated as new roms are discovered/released. It would be up to the community to version control this (insert inane laughter here)

I don't know if that makes any sense. Essentially, I think it would be best to make any Game Controls database front-end agnostic whilst still offering the best outcomes to those who would contribute the most. Thus the intention to develop this first for Launchbox user via the Launchbox plugin which would interface with the stand-alone application. 

I'd welcome people's ideas 

Edited September 12, 2022 by stigzler

[megashub]

17 hours ago, stigzler said:

Here's a video showing my prototype in action. It shows how you setup controls for cabs and gamepads, map them to emulators and how MAME mappings work. It's a bit long as it's a tutorial, but you could skip through to get an idea:

I wrote it essentially as a prototype for the bigger project. I'm really deliberating over the best approach to authoring a specific tool. The ultimate goal will be to build and display game controls layouts for all games on all systems (including different modes within each game (eg. walking, flying, in menu etc) and maybe special moves sets for things like Tekken etc). The database would be community populated. I'd also like to future-proof it. Those of you who have been around in this hobby long enough know that things come and go, but well designed things last (like poonga's controls.ini/dat/xml for MAME) so that has me thinking about the best approach to giving it longevity. The other thing that would be desirable would be that any controls layout display software would also integrate any other game/system specific assets in an integrated fashion (as per the vid above) - so it would need to integrate seamlessly with any source software. 

The benefit Sir Poonga had with Controls.dat was that Mame had standardised names for mameroms (essentially, each mame game has a standardised unique reference). These don't exist of course for games more widely, of course. So what I'm considering is this. Games will have a new unique ID (I know, I know) for the Game Controls Database. However, each will also have a list of known roms gleaned from the excellent Screenscraper database, the Launchbox game ID if it has one and any other Front End ids. I would link with Launchbox as the main front end for its development and invite community development of the Games Controls Database. There would be a plugin for Launchbox which would communicate with the stand alone application, share data with it such as the rom filename, LaunchboxID, assets etc etc etc which could then construct controls displays on the fly from the game controls database. 

For those of you who don't know Screenscraper's work, check this link here. They basically catalogue all known roms for all games, alongside game descriptions and titles and numerous other metadata for regions etc. A truly great archiving effort:

https://www.screenscraper.fr/gameinfos.php?gameid=19939&action=onglet&zone=gameinfosroms

I'll give you an example of why this might be necessary in practice. I have the rom "100 Star (Europe).rar" in my Playstation collection. Launchbox does not scrape this correctly and thus does not give it a launchbox ID. However, if you search this on Screenscraper.fr, then it is identified as "Popstar Maker" Now, there's two things here. I could author the plugin to update Launchbox from Screenscraper to the new details (bonus!). But, also, I now know that the Launchbox ID for Popstar Maker (if I've pre-scraped the Screenscraper db). Thus, syncing two databases. 

There would be a piece of publicly available software for updating the Game Controls Database so it can be updated as new roms are discovered/released. It would be up to the community to version control this (insert inane laughter here)

I don't know if that makes any sense. Essentially, I think it would be best to make any Game Controls database front-end agnostic whilst still offering the best outcomes to those who would contribute the most. Thus the intention to develop this first for Launchbox user via the Launchbox plugin which would interface with the stand-alone application. 

I'd welcome people's ideas 

I really like where this is headed. Is it able to parse your default controls mapping file from MAME? So I go through and map all my buttons on all my controllers to various functions in MAME and those get used by default on every MAME game unless I customize some of then for a specific game. If this tool can be made aware of those existing relationships, then adding them in a new layout could be simplified. 
 

Further, could you automate the adding of a button by listening to the devices and waiting for a button or key press? If I clicked 'add button' and selected 'listen' from a submenu, then hit a button, the app could just auto-create a button with the name included. And if the device source of that event mapped to something known to MAME, it could even offer to use the same mapping, especially if I'm creating a new layout for a system associated with MAME as the emulator. 

Example: I hit the button already configured in MAME as my start button, and since I'm in a layout associated with MAME emulator and it knows where to find my MAME config files, it looks and sees that the button I pressed is mapped to Start, so it simply adds the button labelled Start. Rinse and repeat for all remaining buttons/sticks/mice/analog inputs. Then, when the layout is used in practice, when I've selected a specific game, the app looks for a rom-specific controls config file, and if found, uses those mappings instead.

There's a lot going on in this video, so I'd almost need to get my hands on it and try to make it work before I could provide much more useful feedback. 

[stigzler]

Not quite sure what you're saying, but the likely answer is yes.