Build Your Own Arcade Controls Forum
Main => Software Forum => Topic started by: jlfreund on August 21, 2006, 01:03:36 am
-
Hi, I am new to MAME and have looked at a few front ends but can't get them to work the way I want. Can anyone tell me if there's a front end that can do the following:
- Allow 1 or more "categories" or "folders" of roms. I'd like to be able to navigate between "classics", "smups", "fighting", etc
- Customize the list of roms to not include sub-parts. For example, instead of "Gameblah1 - B" + "Gameblah1a [US]" + "Gameblah2", I'd just like to have one menu item for "My Game Name". BTW, what's all that about anyway? Why aren't games distributed as single zip files?
-
They are single zips if you have an unmerged set. However, you'd still need the parent rom in the same directory.
-
Most of the FE's can do what you want.
You don't change the the rom arrangements/directories. Leave the roms where they are.
Instead you make custom game lists and name the games the way you want.
EG
http://mala.arcadezentrum.com/malagamelist.html (http://mala.arcadezentrum.com/malagamelist.html)
-
So, can someone explain are there a set of standard inputs used by front ends for the menus? I presume that the menu of emulators or categories is generated differently for each front end, but what about the list of games?
Does that come from mameinfo.dat? Is there a standard XML format for a list of games? Or does each front end need to process the ROM directory to build it's own custom list?
Also --
- Is there a viewer for mameinfo.dat so you can browse all the information -- or can you only see certain fields in mame32 or other front ends?
- I still don't understand why some games are distributed as multiple zips? Is there a reason why they can't be combined? It seems ridiculous for every user in the world to have to customize their front end game list menu to hide unusable zip files.
- What are some good (free) front ends that support categories?
-
The best place to get all your questions answered is the wiki:
Wiki Main (http://wiki.arcadecontrols.com/wiki/Main_Page)
Wiki Front Ends (http://wiki.arcadecontrols.com/wiki/Front-Ends)
Me, I'm an AtomicFE user, and it will do all the things you are looking for. You can check it out here:
AtomicFE (http://atomicfe.com/EN2/)
-
- I still don't understand why some games are distributed as multiple zips? Is there a reason why they can't be combined?
They can be combined. And used combined. Or not: "merged" (what you're talking about), "split" (the most common), and even "non-merged". You can merge your zips if you want. (I'd use cmpro instead of doing it by hand.)
The reason the most common distribution is "split" is it takes up less bandwidth in two ways: files (ROMs) shared between two parent/clone games only need to be downloaded once (in the parent zip file), and you don't need to download any of the clones if you don't want them. Also, if just one of the versions has one of the ROMs changed (fix a bad dump, for example), the whole merged zip would need to be changed, instead of one smaller zip file of just that version; effecting any internet caches that might hold them (I'm not talking local caches, but ones that help speed up comcast, ect).
Not having to download the clones is the biggest reason split is used so much, but you can find merged sets out there.
It seems ridiculous for every user in the world to have to customize their front end game list menu to hide unusable zip files.
I think you're mixing different concepts, and blaming mame's multiple zips.
A. By "unusable", I think you mean ones you don't have? Whether a FE displays all the possible games (6100+) or just the ones you have by default is up to the FE not mame, nor if you have merged sets or not.
B. If all versions of a game were in a single zip file (aka "merged"), many FEs would still show all the versions unless you set it differently. (I can't tell if this is a problem for you.)
C. "Mame is not about playing the games; it's about documenting the hardware. Playing is a nice side effect." This mameDev's official stance, not my personal view. This means any complaints about how hard mame is to use will not be listened to by those who count the most in mame's development.
D. If the arcade game had different versions with significant differences, mame will (try to) emulate all of them. The "user" reason is person A remembers playing version B, while person X remembers version Y. The real reason is there were different versions in the arcades, and mame wants to document all of them.
-
I think you're mixing different concepts, and blaming mame's multiple zips.
A. By "unusable", I think you mean ones you don't have? Whether a FE displays all the possible games (6100+) or just the ones you have by default is up to the FE not mame, nor if you have merged sets or not.
B. If all versions of a game were in a single zip file (aka "merged"), many FEs would still show all the versions unless you set it differently. (I can't tell if this is a problem for you.)
C. "Mame is not about playing the games; it's about documenting the hardware. Playing is a nice side effect." This mameDev's official stance, not my personal view. This means any complaints about how hard mame is to use will not be listened to by those who count the most in mame's development.
D. If the arcade game had different versions with significant differences, mame will (try to) emulate all of them. The "user" reason is person A remembers playing version B, while person X remembers version Y. The real reason is there were different versions in the arcades, and mame wants to document all of them.
By "unusable" I mean zips that rely on others, show up in a front end menu, but aren't themselves playable. Or maybe I misunderstood what splits are about. Is everything in a frontend menu playable? For example, when you see "set 1" and "set 2", are both always playable?
If everything displayed is always playable -- and these set1, set2 options are just two different playable versions of the same game, then it's not as big a deal as I thought. It would just be confusing if front ends are listing partial sets and you can't tell which menu items are playable (of course, ignoring the case where a front end displays games that haven't been downloaded yet -- that's different).
-
Is everything in a frontend menu playable? For example, when you see "set 1" and "set 2", are both always playable?
If everything displayed is always playable -- and these set1, set2 options are just two different playable versions of the same game, then it's not as big a deal as I thought. It would just be confusing if front ends are listing partial sets and you can't tell which menu items are playable (of course, ignoring the case where a front end displays games that haven't been downloaded yet -- that's different).
Sometimes not everything is playable. However, this is where filtering comes in. AtomicFE, for example, has the ability to remove the unplayable games from your displayed list.
-
By "unusable" I mean zips that rely on others, show up in a front end menu, but aren't themselves playable. Or maybe I misunderstood what splits are about. Is everything in a frontend menu playable? For example, when you see "set 1" and "set 2", are both always playable?
If everything displayed is always playable -- and these set1, set2 options are just two different playable versions of the same game, then it's not as big a deal as I thought. It would just be confusing if front ends are listing partial sets and you can't tell which menu items are playable (of course, ignoring the case where a front end displays games that haven't been downloaded yet -- that's different).
Again - you are mixing concepts and it depends on your frontend. I will use EmuLoader as an example here.
I would say in 95% of the cases, if you have the parent rom set and the set 1 and set 2 set available, all three games should show up in the front-end and be playable.
Some FE's will filter on Working/Non-Working, but this is based on a flag in MAME's XML and is less accurate than you would hope - i.e. the game may lock up on Level 15, but be flagged as non-working, or it didn't work 5 version ago, but now does and they didn't remove the flag. In other cases, the game may not be flagged at all, but when you run it, you get a message the the protection is not broken yet and there are working clones. This is sloppy on MAMEdev's fault, but as Urebel said, they are mainly about accurate emulation and documenting working/non-working flags is somewhat secondary.
Also, most FE's will search your roms and list available/unavailable and let you filter on these. In EmuLoader's case, it just checks your Rom folder and if it finds Bzone2.zip in your ROMS folder (even an empty file), it assumes the game is playable and will list it. EmuLoader assumes you either have a good rom set or that you run a utility like ClrMAME or RomCenter first. Other frontends will actually check whether all the required files are available before filtering the list, but this makes it a much longer process.
Hope this helps.
-
By "unusable" I mean zips that rely on others, show up in a front end menu, but aren't themselves playable. Or maybe I misunderstood what splits are about. Is everything in a frontend menu playable? For example, when you see "set 1" and "set 2", are both always playable?
If everything displayed is always playable -- and these set1, set2 options are just two different playable versions of the same game, then it's not as big a deal as I thought. It would just be confusing if front ends are listing partial sets and you can't tell which menu items are playable (of course, ignoring the case where a front end displays games that haven't been downloaded yet -- that's different).
Again - you are mixing concepts and it depends on your frontend. I will use EmuLoader as an example here.
I would say in 95% of the cases, if you have the parent rom set and the set 1 and set 2 set available, all three games should show up in the front-end and be playable.
What I still don't understand is if everything that appears in the front end menu _could_ be playable (assuming you downloaded the ROM, and assuming the ROM works). Putting aside the fact that FE's can use different heuristics for constructing a list -- do any front ends display a menu item for something that can never be played because it belongs to a set?
I've tried MameWah and a couple others and see most games have "... set1" "... set 2", or "... 1a", "... 1b", or "... (World)", "... (Japan)", etc. Are all of those unique games (ie different versions of the same game that _could_ be playable, or are there sometimes partial sets listed as separate menu items that don't belong on the menu?
Thanks,
Jason
-
I'm not following you - Using EmuLoader again - MAME 0.108 (not 0.108u1) supports 6242 games (some of these are BIOS files like the Neo-Geo Bios or the CVS Bios, so clicking "Hide Bios" leaves 6216 games.
So if you had a complete 108 rom set, you would be able to launch 6216 games (so of them won't work, though b/c the drivers are not completed or MAME has a bug in this version), and this list would include all of the "set" games.
Does this help, or are you still confused?
-
What I still don't understand is if everything that appears in the front end menu _could_ be playable (assuming you downloaded the ROM, and assuming the ROM works). Putting aside the fact that FE's can use different heuristics for constructing a list -- do any front ends display a menu item for something that can never be played because it belongs to a set?
If you mean will a FE display a clone, if it's parent romset doesn't exist, then probably some will and some wont. Speaking for Mamewah, with the exception of the _vs_verifysets list generation methods (now redundant as -verifysets was removed from Mame), Mamewah will show a clone rom even if it's parent doesn't exist. My thinking is that one should ensure the romsets are all in good order by using ClrMAME or other, before running from a FE...and originally to reduce time taken to generate a list. Realistically with todays hardware I doubt adding the extra check would increase the time by much, but there will still be people who's parent roms are bad ;)
I've tried MameWah and a couple others and see most games have "... set1" "... set 2", or "... 1a", "... 1b", or "... (World)", "... (Japan)", etc. Are all of those unique games (ie different versions of the same game that _could_ be playable, or are there sometimes partial sets listed as separate menu items that don't belong on the menu?
The 'parent' rom is required to play any 'clone' of it. It isn't always clear which version is the parent, but if you unsure then MAWS is a decent place to look: http://www.mameworld.net/maws/
-
The 'parent' rom is required to play any 'clone' of it.
Assuming you are using split sets.
(Actually, if you are using merged sets, the parent rom is also required, but you won't have a clone rom. If you are using not-merged sets, then only the clone rom is required, but you'll have a large rom directory size).
Just for clarification.
-
Actually it's always clear which rom is the parent.
In the listinfo entry for that game, the cloneof entry tells you the parent name.
You need to be running split-non merged sets btw, in which case you need a parent rom.
-
Actually it's always clear which rom is the parent.
In the listinfo entry for that game, the cloneof entry tells you the parent name.
You need to be running split-non merged sets btw, in which case you need a parent rom.
Clear to me and you, yes, but if simply running in a FE (which may not display this info) then it is not clear from just the game description.
-
Well it is in dk... Press the gameinfo button and a screen comes up with all the game's stats, including parent rom. I put it in because I found it very useful to me when troubleshooting my own rom sets.
-
Well it is in dk... Press the gameinfo button and a screen comes up with all the game's stats, including parent rom. I put it in because I found it very useful to me when troubleshooting my own rom sets.
Similarly I have a romname (& clonename if applicable) display in Mamewah....but some (me included for my cab) like to hide this. Your method is a good idea...best of both worlds.