MGL files what do they do and what interesting use cases do they provide?

[redsteakraw]

MGL files what do they do and what interesting use cases do they provide? I don't know the features of the MGL files, can you set cheats can you set any other options?

[RegalCutlass]

They allow launching a game directly from the Core menu (without loading its respective core first and then selecting the ROM), and also allow easily loading games from the command line.

One use case is having a list of favorite games you can access quickly. Another is Super Attract Mode, which currently has to go to a great deal of trouble in order to load ROMs; it needs to know about each core's games folders, which ones support zips, create a symlink of the game in a fixed location, extract it if it's inside a zip, and send emulated keypresses to navigate the menu. With MGLs, SAM could just pick a random MGL from a folder and load the game in a single line of shell code, and the game would load faster too.

I've read some discussion about the possibility of applying patches on the fly without keeping multiple copies of the same ROM but that's not currently a feature.

[rhester72]

@RegalCutlass All true, but on the flip side (at least for consoles), you'd have the PITA of having to sync MGLs with each user's ROM structure (compressed and uncompressed), which would likely be a bigger pain than the way it's done today and far more trouble than it's worth.

[Drexl]

If nothing else, I like how it makes the interface seem more like what you would expect from an appliance, and less like you're browsing a file manager on a computer. You can keep the rom names with all of their extra info like the full title, region, revision number, etc. but just have the title of the game in the menu . I had been renaming ROMs, but that still didn't hide the file extensions. Now, I can name the MGL file what I want to show up in the menu.

[RegalCutlass]

@RegalCutlass All true, but on the flip side (at least for consoles), you'd have the PITA of having to sync MGLs with each user's ROM structure (compressed and uncompressed), which would likely be a bigger pain than the way it's done today and far more trouble than it's worth.

That's a much easier problem to solve, plus it only needs to be solved once but would benefit anyone that uses MGLs and not just SAM users. I've spent a ton of time writing non-trivial bash, C and Rust code to get SAM to do half the things MGLs allow out of the box. I could write a script to generate MGLs of my games in 1 hour.

Plus, other projects that attempt to provide a "frontend" to the MiSTer would benefit from MGLs as well. For example, tatsutron's mistercon android app

Currently any project that wants to load games programmatically has to include MiSTer Batch Control somehow and has to do extra work to handle zipped ROMs since MBC doesn't support them. Plus, the MGL is just plain faster even without taking unzipping into account. MiSTer Batch Control has to actually navigate the core menu and select the ROM which not only takes additional time, it's kind of distracting in the SAM usecase.

[rhester72]

I hear you, but having looked at SAM in pretty good detail, I still can't help but feel that MGL is a targeted solution that now seems to be looking for a general problem. *shrugs* I don't have skin in the game either way, I just think the idea of requiring users to scan their entire game library every time something is added or deleted in order to resync MGLs is a huge step backwards from where we are today in terms of overall usability (well beyond SAM).

[mrchrister]

SAM uses MGL now in the test branch. Anyone care to try it out?
Uncomment #branch="test" in MiSTer_SAM.ini and update through running MiSTer_SAM_on.sh