Emulation support

[DecDuck]

The server needs to be aware and be able to track ROMs for certain emulation targets. Unlike desktop platforms, there are a LOT of ROM emulation targets, so we might need to look at some way to collapsible/hide ROM targets that aren't being used.

Ideally, to avoid having to maintain a really long list of all ROM targets, we should try to hook into the emulators we support and fetch the list of valid platforms from then. Something like libretro supports over 200 different "cores".

I'd love some input on how users would expect this functionality to work, I'm not very well versed in ROMs.

[Beethoven-n]

genuinely, don't have 200 targets for each console type.
just have an "emulated" version, then have a field for which emulator to put in the launch args before {}

[DecDuck]

What I thought is that the targets and their metadata (ROM file extensions, detection algorithms, etc etc) all exist on the backend, but only show up in the web UI if you actually import a version with that platform.

So if you only import GameBoy games, it'll only show GameBoy as one of the platforms.

[DecDuck]

The reason we'd do it like this, is so the client can auto-download and configure the emulator, especially when we integrate the emulator's networking with Drop's.

[proatgram]

Here's how I picture this working:

You’d upload emulators to the server just like any other game in the library. For example, if we have Visual Boy Advance, we’d add it like a normal game. Then, we’d upload a ROM (say, pokemon_crystal.gbc) the same way.

At this point, the server's structure would look something like this:

library/  
  - VisualBoyAdvance/  
     - v1.x.x/  
        - vba.exe  
  - PokemonCrystal/  
    - v1/  
       - pokemon_crystal.gbc  

The key difference from the current system would come when importing the ROM. Instead of just selecting an executable (since most ROMs don’t have one), you’d set Visual Boy Advance as a dependency for Pokemon Crystal (or any other compatible emulator available on the store, maybe even making it optional, but requiring at least one).

Once that’s set up, the Game Version import menu would let you:

• Select an executable (if the ROM somehow has one, which is rare)

• OR point to the emulator (the dependency) as the executable target

• Specify any necessary command-line arguments (like loading the ROM)

In short, linking a dependency to a game would let you use files from that dependency (like the emulator) to run the game, which is perfect for ROMs that don’t have their own executables.

If the store supports multiple emulators, we could even configure a ROM to work with any of them. Just add each emulator as an optional dependency, then set up different launch options depending on which one the user picks.

Furthermore, this would allow us to have a single emulator target/version, we just specify which emulator we're using as the dependency(ies) when we import and configure it.

[proatgram]

Another feature which I would find very useful is the ability to essentially "overlay" different apps, such as addons for a game. For emulators, my mind goes to specifying BIOS's for consoles, as some consoles, like I believe the Wii requires additional BIOS files in order to function.

And this is how I envision this working:

Say we have Dolphin, the Wii emulator which requires BIOS files in {install_dir}/bios (arbitrary, not sure if that's accurate). We can have another "game" on the server, that includes the root /bios directory, and we can configure that to install over the Dolphin emulator's install_dir, so that the bios directory gets populated and Dolphin is good to go.

Something that was mentioned was a system similar to Steam Workshop, which I feel could be similar to this overlay system.

What are your thoughts on these opinions?

[Beethoven-n]

You’d upload emulators to the server just like any other game in the library.

what if your user already has an emulator installed, and wants to use that?
also, what about supporting different OSes with your chosen emulator?
also, downloading duplicate copies of the listed emulator for each game is going to add up real fast...

[UtkarshVerma]

Three are some cases where we can just use EmulatorJS as well. It will emulate completely in the browser and supports a lot of retro targets.

[quexeky]

This has been what I've thinking about / my issue with it for a while. My thought was we could instead set up some system where we can register emulators to use them in a similar way to umu. Then you can add a specific emulator from some kind of dropdown as a requirement for the game itself. It wouldn't really work with @proatgram 's approach, but it feels like the most sensible approach because you're right about how

downloading duplicate copies of the listed emulator for each game is going to add up real fast

The way that I imagine it happening is that you set the target as "emulated", which gives you a dropdown of supported emulators, which themselves are akin to how umu is required for proton games

[proatgram]

what if your user already has an emulator installed, and wants to use that?

I believe that would be handled by the user's installed emulator, because Drop I don't believe would have or should have control over software installed by the user, only software installed by drop. I mean, how would Drop tell the users installed emulator, "Hey, this is where the ROM is!"

also, what about supporting different OSes with your chosen emulator?

Currently, you can just have different versions for a game, so just have a version for each platform (this was discussed elsewhere, having a platform version for each game, I believe in the Discord somewhere). Then, import versions of the ROM using each platform, or just have the dependency be platform agnostic, have a simple named target that runs the executable of whatever platform they are on.

For example, we have a version of VBA for Windows and Linux. We set that as a dependency of some GBC game, and we set the command run string as {dependency:VBA} SomeGame.gbc, this way we aren't referencing a specific platform, but a generic game target.

also, downloading duplicate copies of the listed emulator for each game is going to add up real fast...

It wouldn't be downloading duplicate copies of the emulator each time. The structure would look like this:

 - VBA/
    - vba
 - GBCGame1/
   - gbc_game_1.gbc
 - GBCGame2/
    - gbc_game_2.gbc

Both of those games would use the same emulator, it wouldn't be downloaded multiple times, only once, and can be used for multiple games.

The dependencies wouldn't bundle with the ROM or the dependent, it would still just be a target in the clients library

[proatgram]

I like @quexeky idea about doing it similar to umu, and I think this could work for using an emulator already installed on the host system. The system I was explaining allowed for the admin to upload emulators to the store to for the clients to use and optionally depend on. A combination of this could allow flexibility for including an emulator in the store, while also giving the ability to use one already on the client system?

[DecDuck]

I want the system to be as magic as possible for users that don't know what they're doing, while allowing flexibility for those who do.

I think the best option is to allow admins to set up emulators as a redistributable component, which means it will only be downloaded once for all games. And then users, when downloading, can let Drop download and configure the emulator for them, or can check it as "Bring my own", and then they just have to configure a launch command.

This lets us have full control for users who don't want to mess around with it, and shift the responsibility entirely onto users who do.

[proatgram]

I believe the redistributable system is what I was trying to explain, have the emulator stored on the server, and have it downloaded once to the client, and have the rom depend on the redistributable? Maybe slightly different but that's exactly what I was aiming to explain

[monkeyx-net]

Might I suggest ES-DE. I've previously been using RomM. But I want a project that does more than just emulation.

ES-DE gives paths for roms and the emulators provide paths for bios etc.

I've also done some work on Retroarch that's uses config files for the emulators to centralise bios files etc.