Which system emlator should I use? I only want to play "Space Invaders"

[chavatar]

@dankcushions

All the fancy mame names are derived from a simple cross reference
Can I ask how this works a little more? Genuinely trying to get my head around it!

[Riverstorm]

@dankcushions said in Which system emlator should I use? I only want to play "Space Invaders":

we're dealing in hypotheticals here, really. mame might have ways of handling loading sets via command line (i can't find any), but you also need our forks of mame (advmame, lr-mame*) to pass the same commands, and the frontend/runcommand to provide an interface to let the user choose. right now you're stuck with renaming.

Good point but most MAME forks have the same core functionality plus whatever "extra" features they want to add. I would imagine if it works in MAME then all the forks would port the code over too.

I was more curious rather than a wanted feature. I've been using MAME since the first year of it's release and I've never used merged sets except for quick and dirty testing. I basically stick to non-merge or split. They just come with the territory when doing ROM management.

After typing it all out it's really a straight forward question that maybe I can post on a MAME forum to get a better understanding of their purpose and how to use them. Usually they have good creative reasons for what they had in mind or where trying to accomplish, usually! ;)

[chavatar]

@chavatar PS Ignore the formatting, and don't dumb it down ;)

[caver01]

I don't know if this helps or hurts the discussion, but for those of us who would rather manage a subset of ROMs on our systems (saves space, cleaner--no clones), I have always just generated non-merged archives as needed.

For example, I typically play Joust (Solid, Red Label). This is, of course, a specific clone. From a split set, you can't play joustr.zip unless you also have joust.zip (parent). But I don't want both of these in my menu. Solution: simply create a non-merged archive by unzipping both and copying the files from joust.zip into joustr.zip. Re-zip. Delete the parent. Done. Now, ES sees only Joust (Solid Red Label) and when launched, MAME finds the parent ROMs inside too.

If you have a merged archive (joust.zip with ALL clone components) You don't have to stop and rename it when you want to play a clone--just make a copy and give each copy the name of the clone/parent that you want to play and they will both be in the ES menu.

[caver01]

I think the points in my example have already been made, but even if MAME could launch a specific clone based on command line params, it wouldn't matter because you still need to represent the specific clones to ES which builds the menu based on the ROMs it finds. In other words, you'd have to drop an archaically-named file into the ROMs folder anyway, so it might as well be an actual ROM with the merged parts inside.

[Riverstorm]

@dankcushions said in Which system emlator should I use? I only want to play "Space Invaders":

right now you're stuck with renaming.

It does indeed work. I just finished building a 0.78 set (lr-mame2003) and merged dkong3.zip, dkong3j.zip and dkong3b.zip into one archive. When using -verifyroms switch it does indeed see 3 working versions.

C:\Temp\MAME\mame078b>mame -verifyroms
dkong3b : dk3b-c.1d        512 bytes ROM NEEDS REDUMP
dkong3b : dk3b-c.1c        512 bytes ROM NEEDS REDUMP
dkong3b : dk3b-v.2n        256 bytes ROM NEEDS REDUMP
romset dkong3b [dkong3] is best available
3 romsets found, 3 were OK.

All 3 games run fine. The US and Japan version work with no issues. The bootleg on Donkey Kong Jr. hardware complains of needed ROM redumps but does run with improper colors from the Donkey Jr. color pallete (this has nothing to do with what we were trying to test but the bootleg hardware it runs on).

The only file present in the ROMs folder is the parent dkong3.zip but when I run mame dkong3j or mame dkong3b they work like a champ.

With that information we know MAME is aware and can use all variants of the parent without the "physical" file being present. Now it's just a question of populating the game directory list (not necessarily with files) as it knows to look to the parent automatically when the proper clone/child name is passed.

It could cut down on directory entries if you use a lot of variants by combining a parent and maybe a clone or regional version you might like to play.

[caver01]

@Riverstorm said in Which system emlator should I use? I only want to play "Space Invaders":

The only file present in the ROMs folder is the parent dkong3.zip but when I run mame dkong3j or mame dkong3b they work like a champ.

That's actually a great test and good to know it works that way. To take advantage of the simplified directory, you now need a way to edit the menu list displayed in ES, and I think this is where practicality will win in the end. It's going to be easier in the long run to "manage" the menu by way of the files present in the ROM folder.

[dankcushions]

@Riverstorm said in Which system emlator should I use? I only want to play "Space Invaders":

@dankcushions said in Which system emlator should I use? I only want to play "Space Invaders":

right now you're stuck with renaming.

It does indeed work. I just finished building a 0.78 set (lr-mame2003) and merged dkong3.zip, dkong3j.zip and dkong3b.zip into one archive. When using -verifyroms switch it does indeed see 3 working versions.

C:\Temp\MAME\mame078b>mame -verifyroms
dkong3b : dk3b-c.1d        512 bytes ROM NEEDS REDUMP
dkong3b : dk3b-c.1c        512 bytes ROM NEEDS REDUMP
dkong3b : dk3b-v.2n        256 bytes ROM NEEDS REDUMP
romset dkong3b [dkong3] is best available
3 romsets found, 3 were OK.

All 3 games run fine. The US and Japan version work with no issues. The bootleg on Donkey Kong Jr. hardware complains of needed ROM redumps but does run with improper colors from the Donkey Jr. color pallete (this has nothing to do with what we were trying to test but the bootleg hardware it runs on).

The only file present in the ROMs folder is the parent dkong3.zip but when I run mame dkong3j or mame dkong3b they work like a champ.

With that information we know MAME is aware and can use all variants of the parent without the "physical" file being present. Now it's just a question of populating the game directory list (not necessarily with files) as it knows to look to the parent automatically when the proper clone/child name is passed.

no, we know that mame current can cope, but with retropie we're using 10+ year old versions of mame, and forks of them to boot, with their own command line interfaces. so you're stuck with renaming in retropie :)

[Riverstorm]

@caver01 said in Which system emlator should I use? I only want to play "Space Invaders":

In other words, you'd have to drop an archaically-named file into the ROMs folder anyway, so it might as well be an actual ROM with the merged parts inside.

I suppose you could store all the files in the parent and have a empty file for the variant but gosh it seems like all the pieces are there it's just getting the front-end in the know.

I pretty much always use non-merged as some the "main" versions from our region are clones. That way I don't have to pull in extra versions with a split set. I am sure the MAME devs have a method to how they designate the master/parent.

[Riverstorm]

@dankcushions said in Which system emlator should I use? I only want to play "Space Invaders":

no, we know that mame current can cope, but with retropie we're using 10+ year old versions of mame, and forks of them to boot, with their own command line interfaces. so you're stuck with renaming in retropie :)

That's why I posted the version (0.78) which is 13 years old and it works fine. It's not the emulator that needs tweaking it would be the front-end as the functionality is already in place and has been for well over 10 years. I'm not saying ES will have it anytime soon or ever. I was just pointing out that it does work after doing some testing.

[dankcushions]

@Riverstorm but that's still not what we're using. we're using LR-mame2003, which does not use that command line interface. libretro/retroarch is its own interface.

[dankcushions]

@chavatar said in Which system emlator should I use? I only want to play "Space Invaders":

@dankcushions
All the fancy mame names are derived from a simple cross reference
Can I ask how this works a little more? Genuinely trying to get my head around it!

here's the cross reference in the code - https://raw.githubusercontent.com/Aloshi/EmulationStation/master/es-app/src/MameNameMap.cpp

[Riverstorm]

@dankcushions said in Which system emlator should I use? I only want to play "Space Invaders":

@Riverstorm but that's still not what we're using. we're using LR-mame2003, which does not use that command line interface. libretro/retroarch is it's own interface.

Retroarch is a front-end that interfaces with the Libertro API. I would assume it's safe to say they are using the source files from 2003 that already had that functionality built in. They did not rewrite the emulator from scratch. You can find every version of the open source files over at mamedev.org. As you said:

all emulationstation does is pass run a command line which is basically (for a libretro emulator):
/some/dir/retroarch -L /some/dir/libretro-core.so /roms/mame/gamename.zip

I am not sure why you feel a need to flex. I thought we had a nice discovery of knowing merged sets work fine on these old versions. I would bet on forks like AdvMAME it would work too. Possibly in the future the devs could tweak the front-end utilizing that knowledge if they wanted. I am not in a contest with you about who knows more. I was trying to further/improve the cause and let the devs decide what they may or may not do in the future. It was simply a discovery that we didn't know about yesterday. As Herb says anything is possible it's just currently not a feature.

You said:

we know that mame current can cope, but with retropie we're using 10+ year old versions of mame.

You do know that each version of MAME is separate and written from the year of release hence lr-mame2003 is 13 years old and probably uses the 0.78 code with some tweaks then compiled? As lr-mame2010 is 5 years old, etc. I was using old binaries for testing so yes I do know it's 10+ years old and it worked!

[dankcushions]

@Riverstorm said in Which system emlator should I use? I only want to play "Space Invaders":

@dankcushions said in Which system emlator should I use? I only want to play "Space Invaders":

@Riverstorm but that's still not what we're using. we're using LR-mame2003, which does not use that command line interface. libretro/retroarch is it's own interface.

Retroarch is a front-end that interfaces with the Libertro API.

that's why i asked what you meant by 'frontend' in this situation :) you said emulationstation.. well, now it's retroarch? :)

I would assume it's safe to say they are using the source files from 2003 that already had that functionality built in. They did not rewrite the emulator from scratch. You can find every version of the open source files over at mamedev.org. As you said:

all emulationstation does is pass run a command line which is basically (for a libretro emulator):
/some/dir/retroarch -L /some/dir/libretro-core.so /roms/mame/gamename.zip

right, but by implementing it in libretro you abstract all that stuff away - there are NO mame-related command line functions used in libretro mame cores. any functionality previously accessed via command line has to be mapped to a retroarch core option, which is sometimes trivial if it's an on/off function, but this isn't that sort of scenario. it could be done, of course, but i don't see anyone proposing to code it :)

I am not sure why you feel a need to flex. I thought we had a nice discovery of knowing merged sets work fine on these old versions. I would bet on forks like AdvMAME it would work too. Possibly in the future the devs could tweak the front-end utilizing that knowledge if they wanted. I am not in a contest with you about who knows more. I was trying to further/improve the cause and let the devs decide what they may or may not do in the future. It was simply a discovery that we didn't know about yesterday. As Herb says anything is possible it's just currently not a feature.

i'm not flexing! i'm not saying it couldn't work at all! i was just saying that you couldn't achieve this with emulationstation changes, which is why i specifically asked what you meant by 'frontend' before i dismissed this idea :)

You said:

we know that mame current can cope, but with retropie we're using 10+ year old versions of mame.

You do know that each version of MAME is separate and written from the year of release hence lr-mame2003 is 13 years old and probably uses the 0.78 code with some tweaks then compiled? As lr-mame2010 is 5 years old, etc. I was using old binaries for testing so yes I do know it's 10+ years old and it worked!

yeah, you've already told me you were using an old version of mame.. great! it still doesn't make much of a difference :)

ideas are cool! i don't want to be negative, i'm just trying to manage expectations :)

[chavatar]

@dankcushions Thanks. Ok, sorry, but I'm looking at my 8.3 convention 0.37b5 romset. I can see sselph's scraper picking up different things (versions more than games), if at all...

I'm a real mame noob and ran into this problem with Alex Kidd - see here [http://www.gamesdbase.com/mame-rom/alexkidd1.aspx] - look at the naming history. What am I missing? How to you keep track of that moving target?

[dankcushions]

@chavatar said in Which system emlator should I use? I only want to play "Space Invaders":

@dankcushions Thanks. Ok, sorry, but I'm looking at my 8.3 convention 0.37b5 romset. I can see sselph's scraper picking up different things (versions more than games), if at all...

i guess if you use a scraper then that populates the metadata. i think those names i linked above are just for when emulationstation doesn't have any metadata? just my guess...

I'm a real mame noob and ran into this problem with Alex Kidd - see here [http://www.gamesdbase.com/mame-rom/alexkidd1.aspx] - look at the naming history. What am I missing? How to you keep track of that moving target?

the filenames are a different thing to the scraped/es names - the filenames are static for a particularly mame romset. in your case 0.375b. that history there is showing that the filenames and stuff were renamed/moved around throughout the history of mame versions - but that's ok for you, as you only care about 0.375b :)

[chavatar]

@dankcushions Cool, thank you.

but that's ok for you, as you only care about 0.375b :)

Gotta start somewhere! And they weren't saying that 16 years ago...but yeah, time to move on? :)

[Riverstorm]

@dankcushions

You originally brought up Retroarch and Libretro but yeah I was originally referring to ES because it's a front-end too! I am not sure what your point is here except to make an attempt to discredit. How all the moving parts work together I am definitely not 100% sure.

I do apologize if you're a developer with the knowledge to code the proper changes to incorporate merged sets. You seem quite comfortable in your knowledge of how everything works and what would be manageable-able expectations and what wouldn't but you clearly missed some fundamental points on how things work.

I did go to college originally for programming but flipped over to Network Engineering and stuck with that the past 25+ years but I would love to hear your logic on why "this isn't that sort of scenario". I might not follow all of it but would love to hear your logic.

As far as anyone not proposing to code it that is a completely arbitrary statement. This isn't supply and demand not even necessity isn't going to facilitate it. I would imagine there are only a handful of guys that can do it on these forums in a timely fashion that spend countless and thankless hours working on something they love. There are a lot more users than developers I would guess.

I'm sorry but you come across as some representative for RetroPie based on what you deem a reasonable expectations of what to except in future releases. The devs can trump or prioritize any feature they want at any time.

All I was doing was trying to figure out how merge sets work and now I know. I do feel quite satisfied I learned something today. Even something small like this. I'm quite ok if it don't make a difference to you but it sure don't seem right that you come off telling others to manage their expectations whether indirectly, implied or insinuated. I don't need you to manage my expectations.

If I share a piece of information you deem impertinent or irrelevant it doesn't feel so great to have someone keep picking at it like you're doing. I was quite happy with the find and hope in the future it might be useful. I would rather you just left it alone instead and let others who might find value in it comment and further the conversation together so as to not waste time and energy with whatever it is you're trying to prove to the community.

[dankcushions]

@Riverstorm discussions are good! all i'm saying is that it would take a non-trivial code change to get the lr-mame2003 core (and retroarch) to cope with letting the user control loading individual games from a merged set.

here's the best idea i can come up with: something like how lr-fba-next dynamically builds core options around inputs, based the game. it's feasible that you you could dynamically generate a list of clones for each game, and then let the user select, and save it as a unique core option. BUT you'd have to reset the game for the desired clone to loan. this change is possible but for me it's complex, and i don't see huge value in it.

either way, it's retroarch and libretro changes that are required to solve this problem, because all ES can do is send command-line arguments, but retroarch/libretro have to interpret them. that's all i was really trying to say.

i learnt how mame deals with merged sets, so i'm happy! sorry if i'm being negative.. i'd absolutely love for more people to get engaged with making changes. it's fun!