[GH-ISSUE #189] Emulation support #95

New Issue

2026-02-17T17:06:06-05:00

yindo commented

2026-02-17 17:06:06 -05:00

Originally created by @DecDuck on GitHub (Aug 15, 2025).
Original GitHub issue: https://github.com/Drop-OSS/drop/issues/189

Originally assigned to: @DecDuck on GitHub.

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.

Originally created by @DecDuck on GitHub (Aug 15, 2025). Original GitHub issue: https://github.com/Drop-OSS/drop/issues/189 Originally assigned to: @DecDuck on GitHub. 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.

yindo added the feature confirmed labels 2026-02-17 17:06:06 -05:00

yindo commented

2026-02-17 17:06:06 -05:00

@Beethoven-n commented on GitHub (Aug 15, 2025):

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 {}

@Beethoven-n commented on GitHub (Aug 15, 2025): 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 `{}`

yindo commented

2026-02-17 17:06:06 -05:00

@DecDuck commented on GitHub (Aug 15, 2025):

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 commented on GitHub (Aug 15, 2025): 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.

yindo commented

2026-02-17 17:06:06 -05:00

@DecDuck commented on GitHub (Aug 15, 2025):

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.

@DecDuck commented on GitHub (Aug 15, 2025): 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.

yindo commented

2026-02-17 17:06:06 -05:00

@proatgram commented on GitHub (Aug 16, 2025):

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 commented on GitHub (Aug 16, 2025): 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.

yindo commented

2026-02-17 17:06:06 -05:00

@proatgram commented on GitHub (Aug 16, 2025):

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?

@proatgram commented on GitHub (Aug 16, 2025): 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?

yindo commented

2026-02-17 17:06:06 -05:00

@Beethoven-n commented on GitHub (Aug 16, 2025):

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...

@Beethoven-n commented on GitHub (Aug 16, 2025): > 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...

yindo commented

2026-02-17 17:06:06 -05:00

@UtkarshVerma commented on GitHub (Aug 16, 2025):

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.

@UtkarshVerma commented on GitHub (Aug 16, 2025): 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.

yindo commented

2026-02-17 17:06:06 -05:00

@quexeky commented on GitHub (Aug 16, 2025):

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

@quexeky commented on GitHub (Aug 16, 2025): 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

yindo commented

2026-02-17 17:06:07 -05:00

@proatgram commented on GitHub (Aug 16, 2025):

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 commented on GitHub (Aug 16, 2025): > 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

yindo commented

2026-02-17 17:06:07 -05:00

@proatgram commented on GitHub (Aug 16, 2025):

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?

@proatgram commented on GitHub (Aug 16, 2025): 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?

yindo commented

2026-02-17 17:06:07 -05:00

@DecDuck commented on GitHub (Aug 16, 2025):

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.

@DecDuck commented on GitHub (Aug 16, 2025): 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.

yindo commented

2026-02-17 17:06:07 -05:00

@proatgram commented on GitHub (Aug 16, 2025):

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

@proatgram commented on GitHub (Aug 16, 2025): 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

yindo commented

2026-02-17 17:06:07 -05:00

@monkeyx-net commented on GitHub (Aug 25, 2025):

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.

@monkeyx-net commented on GitHub (Aug 25, 2025): 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.

yindo commented

2026-02-17 17:06:07 -05:00

@DecDuck commented on GitHub (Aug 25, 2025):

I was planning to implement various different emulation backends depending on the kind of ROM used, because most of the multi-platform emulators I've seen target retro consoles.

I want to be able to support anything in a flexible way, without being locked into one way of doing things.

ES-DE looks good though, but I haven't really looked around for solutions.

@DecDuck commented on GitHub (Aug 25, 2025): I was planning to implement various different emulation backends depending on the kind of ROM used, because most of the multi-platform emulators I've seen target retro consoles. I want to be able to support anything in a flexible way, without being locked into one way of doing things. ES-DE looks good though, but I haven't really looked around for solutions.

yindo commented

2026-02-17 17:06:07 -05:00

@proatgram commented on GitHub (Aug 25, 2025):

If we want to support flexibility, then why not allow the admin to upload emulators to the server as games, and then upload ROMs to the servers as games as well, and have the ROMs use the emulator app that's stored on the server?

This way, we don't have to define multiple backends for different emulators, as that method might lock users to these specific backends (there may be an emulator or configuration of some sort that this doesn't support).

This allows for flexibility, adding any emulator to the server without the need for tying a backend into that specific emulator (at most we'd probably just have an 'emulator' backend), and also would prevent the devs from having to implement a backend for every emulation type (and disappointment if an admin/user tries to use something we don't have a backend for)

For example, you (the admin) upload VBA to the server, and then a bunch of GBA ROMs. A client will download one copy of VBA (or really any emulator that you have on the server capable of running the ROM) and will use that to run the ROM.

In the game import wizard, we can have a game type of "emulator" and "ROM". When we import a type emulator, we can define what console it's for (like a tag) and then other information such as command line arguments and stuff if necessary to allow the ROMs to run. And then when we import a type ROM, we choose from a list of those console types we have (tags I mentioned before) that can execute the ROM.

I feel this allows the most flexibility, because with this method you can pretty much configure any emulator and any rom, without hard coding anything into the software, it's all mostly done through server configuration.

@proatgram commented on GitHub (Aug 25, 2025): If we want to support flexibility, then why not allow the admin to upload emulators to the server as games, and then upload ROMs to the servers as games as well, and have the ROMs use the emulator app that's stored on the server? This way, we don't have to define multiple backends for different emulators, as that method might lock users to these specific backends (there may be an emulator or configuration of some sort that this doesn't support). This allows for flexibility, adding any emulator to the server without the need for tying a backend into that specific emulator (at most we'd probably just have an 'emulator' backend), and also would prevent the devs from having to implement a backend for every emulation type (and disappointment if an admin/user tries to use something we don't have a backend for) For example, you (the admin) upload VBA to the server, and then a bunch of GBA ROMs. A client will download one copy of VBA (or really any emulator that you have on the server capable of running the ROM) and will use that to run the ROM. In the game import wizard, we can have a game type of "emulator" and "ROM". When we import a type emulator, we can define what console it's for (like a tag) and then other information such as command line arguments and stuff if necessary to allow the ROMs to run. And then when we import a type ROM, we choose from a list of those console types we have (tags I mentioned before) that can execute the ROM. I feel this allows the most flexibility, because with this method you can pretty much configure any emulator and any rom, without hard coding anything into the software, it's all mostly done through server configuration.

yindo commented

2026-02-17 17:06:07 -05:00

@monkeyx-net commented on GitHub (Aug 25, 2025):

99% of my emulation needs are met via RetroArch. I think the best front end for emulators is ES-DE. It does not change any underlying emulator on anyway. So you can still use the underlying emulator's) too.

It's a great way to see and play games though. With integration to several scrapers for meta data, manuals, video clips etc

I personally don't want to several hundred retrogames outside of ES-DE or the emulator. But this can be done as ES-DE only support emulators with cli launch options.

I was planning to implement various different emulation backends depending on the kind of ROM used, because most of the multi-platform emulators I've seen target retro consoles.

I want to be able to support anything in a flexible way, without being locked into one way of doing things.

ES-DE looks good though, but I haven't really looked around for solutions.

@monkeyx-net commented on GitHub (Aug 25, 2025): 99% of my emulation needs are met via RetroArch. I think the best front end for emulators is ES-DE. It does not change any underlying emulator on anyway. So you can still use the underlying emulator's) too. It's a great way to see and play games though. With integration to several scrapers for meta data, manuals, video clips etc I personally don't want to several hundred retrogames outside of ES-DE or the emulator. But this can be done as ES-DE only support emulators with cli launch options. > I was planning to implement various different emulation backends depending on the kind of ROM used, because most of the multi-platform emulators I've seen target retro consoles. > > I want to be able to support anything in a flexible way, without being locked into one way of doing things. > > ES-DE looks good though, but I haven't really looked around for solutions.

yindo commented

2026-02-17 17:06:07 -05:00

@DecDuck commented on GitHub (Aug 25, 2025):

The current plan is to allow games to launch via a redistributable. Essentially redistributables will be locked to actual operating systems (Windows Mac Linux), and then you can configure games to use the redistributable to launch.

So in the admin UI, you add "yuzu.exe --rom {rom}" as the launch executable for the redistributable, and add .rom or whatever as the supported extensions.

And then when importing a game, Drop will detect the ROM and let you set the redistributable as the platform.

The client will then execute the configured launch command, substituting in the template values.

We're also planning an "DLC" system, which are filesystem level modifications to both redistributables and games, so you can configure BIOSs for emulation, but also DLCs and stuff for regular games.

Should cover most, if not all, use cases.

@DecDuck commented on GitHub (Aug 25, 2025): The current plan is to allow games to launch via a redistributable. Essentially redistributables will be locked to actual operating systems (Windows Mac Linux), and then you can configure games to use the redistributable to launch. So in the admin UI, you add "yuzu.exe --rom {rom}" as the launch executable for the redistributable, and add .rom or whatever as the supported extensions. And then when importing a game, Drop will detect the ROM and let you set the redistributable as the platform. The client will then execute the configured launch command, substituting in the template values. We're also planning an "DLC" system, which are filesystem level modifications to both redistributables and games, so you can configure BIOSs for emulation, but also DLCs and stuff for regular games. Should cover most, if not all, use cases.

yindo commented

2026-02-17 17:06:07 -05:00

@zontreck commented on GitHub (Aug 25, 2025):

I like this idea, as it would have everything all in one place. And, I could then just offload my entire emulation library onto my server, and only keep what I actively need downloaded. Plus, it would enable me to sync between devices easier. Currently, I use NextCloud to sync my ROMs between devices.

@zontreck commented on GitHub (Aug 25, 2025): I like this idea, as it would have everything all in one place. And, I could then just offload my entire emulation library onto my server, and only keep what I actively need downloaded. Plus, it would enable me to sync between devices easier. Currently, I use NextCloud to sync my ROMs between devices.

yindo commented

2026-02-17 17:06:07 -05:00

@DecDuck commented on GitHub (Aug 26, 2025):

Kind the vibe I'm going for.

@DecDuck commented on GitHub (Aug 26, 2025): <img width="1028" height="1442" alt="Image" src="https://github.com/user-attachments/assets/d75704a9-de0e-40af-b2fc-bfdec1d0d390" /> Kind the vibe I'm going for.

yindo commented

2026-02-17 17:06:07 -05:00

@DecDuck commented on GitHub (Aug 26, 2025):

One potential issue with this approach is it limits Drop's ability to have tight integrations with projects without modifying them, at least slightly. For example if we want to enable multiplayer features on supported emulators, we'd have to patch in the feature to the emulator's source code rather than doing it externally.

@DecDuck commented on GitHub (Aug 26, 2025): One potential issue with this approach is it limits Drop's ability to have tight integrations with projects without modifying them, at least slightly. For example if we want to enable multiplayer features on supported emulators, we'd have to patch in the feature to the emulator's source code rather than doing it externally.

yindo commented

2026-02-17 17:06:07 -05:00

@BenMcLean commented on GitHub (Aug 27, 2025):

Here's what would be my dream of how this would work.
RetroArch compiles to WASM and so it already runs in the browser.
It would be configured to make every time the program needs to do file operations, all of those file operations would be implemented as web requests.
ROMs and savestates and cheats and settings and everything would be stored on the server.
You just open your web browser, navigate to the site you're hosting for this, click the game, and RetroArch opens right in your browser with all your save states and cheats and settings and whatever right there, saving and loading all of it through the browser. You do not need to install anything to run all games supported on the web version of RetroArch.
Ideally, it would also work seamlessly with desktop RetroArch being able to make those same web requests. This is desirable because of course desktop RetroArch will have better performance than web RetroArch. If you just want to play an old 8-bit turn based RPG, that'd work just fine in the browser but for a more demanding 3D action game on a newer platform, performance might suffer on web if it runs at all, so the web RetroArch isn't a silver bullet to solve everything but it sure would be nice to have.
I know there are other emulators in the world of course, but RetroArch is the most important by far as it includes most of the others.
This is a dream that a number of other projects have pursued over the years but have all failed to get real momentum for various reasons.

In addition to RetroArch, it'd be nice to get a WASM version of Dosbox like the Internet Archive uses to do the same thing, except, like I said, with file operations implemented as web requests.

@BenMcLean commented on GitHub (Aug 27, 2025): Here's what would be my dream of how this would work. [RetroArch compiles to WASM and so it already runs in the browser.](https://web.libretro.com/) It would be configured to make every time the program needs to do file operations, all of those file operations would be implemented as web requests. ROMs and savestates and cheats and settings and everything would be stored on the server. You just open your web browser, navigate to the site you're hosting for this, click the game, and RetroArch opens right in your browser with all your save states and cheats and settings and whatever right there, saving and loading all of it through the browser. You do not need to install anything to run all games supported on the web version of RetroArch. Ideally, it would also work seamlessly with desktop RetroArch being able to make those same web requests. This is desirable because of course desktop RetroArch will have better performance than web RetroArch. If you just want to play an old 8-bit turn based RPG, that'd work just fine in the browser but for a more demanding 3D action game on a newer platform, performance might suffer on web if it runs at all, so the web RetroArch isn't a silver bullet to solve everything but it sure would be nice to have. I know there are other emulators in the world of course, but RetroArch is the most important by far as it includes most of the others. This is a dream that a number of other projects have pursued over the years but have all failed to get real momentum for various reasons. In addition to RetroArch, it'd be nice to get a WASM version of Dosbox like the Internet Archive uses to do the same thing, except, like I said, with file operations implemented as web requests.

yindo commented

2026-02-17 17:06:07 -05:00

@BenMcLean commented on GitHub (Aug 28, 2025):

I looked into my proposal a little more and was able to rule this out as not feasible. Even if it wasn't completely outside the scope of what Drop is attempting, there are glaring technical issues stonewalling any attempt to implement RetroArch's synchronous file operations as asynchronous web requests. On top of that, it would need caching to be performant at all, which adds another layer of complexity. But by looking into it, I was able to learn about the challenges of why no one has done this and isn't likely to. I apologize for the distraction of such a completely out of scope idea.

@BenMcLean commented on GitHub (Aug 28, 2025): I looked into my proposal a little more and was able to rule this out as not feasible. Even if it wasn't completely outside the scope of what Drop is attempting, there are glaring technical issues stonewalling any attempt to implement RetroArch's synchronous file operations as asynchronous web requests. On top of that, it would need caching to be performant at all, which adds another layer of complexity. But by looking into it, I was able to learn about the challenges of why no one has done this and isn't likely to. I apologize for the distraction of such a completely out of scope idea.

yindo commented

2026-02-17 17:06:07 -05:00

@DecDuck commented on GitHub (Aug 29, 2025):

It would not be impossible to implement it as a third party application to Drop, without substantially changing Drop in any way. I do think web-based players built into the Drop is out of scope for us, at least in the short-medium term.

@DecDuck commented on GitHub (Aug 29, 2025): It would not be impossible to implement it as a third party application to Drop, without substantially changing Drop in any way. I do think web-based players built into the Drop is out of scope for us, at least in the short-medium term.

yindo commented

2026-02-17 17:06:07 -05:00

@BenMcLean commented on GitHub (Sep 13, 2025):

It looks like another team is doing essentially what I had suggested as a separate app: https://romm.app/

Might be nice to explore some kind of integration with them, like a shared accounts system perhaps for the convenience of people hosting both apps.

@BenMcLean commented on GitHub (Sep 13, 2025): It looks like another team is doing essentially what I had suggested as a separate app: https://romm.app/ Might be nice to explore some kind of integration with them, like a shared accounts system perhaps for the convenience of people hosting both apps.

yindo commented

2026-02-17 17:06:07 -05:00

@laylafogiel-hash commented on GitHub (Oct 6, 2025):

There's also retrom, which has very similar goals to drop, but different priorities. Currently more focused on emulation, still needs some improvement in playing native games, still did not implement users/authentication but has support for video embedding, external links and loads images automatically to game pages (#57, #123) etc. Maybe some kind of collaboration is possible.

@laylafogiel-hash commented on GitHub (Oct 6, 2025): There's also [retrom](https://github.com/JMBeresford/retrom), which has very similar goals to drop, but different priorities. Currently more focused on emulation, still needs some improvement in playing native games, still did not implement users/authentication but has support for video embedding, external links and loads images automatically to game pages (#57, #123) etc. Maybe some kind of collaboration is possible.

yindo commented

2026-02-17 17:06:07 -05:00

@BenMcLean commented on GitHub (Oct 6, 2025):

Yeah I think it would be really nice if we could get RetroArch, EmulatorJS, RomM, Gaseous, Retrom, Drop and anybody else to just combine their efforts into one standard instead of everybody reduplicating the same work like this in so many different projects.

@BenMcLean commented on GitHub (Oct 6, 2025): Yeah I think it would be really nice if we could get RetroArch, EmulatorJS, RomM, Gaseous, Retrom, Drop and anybody else to just combine their efforts into one standard instead of everybody reduplicating the same work like this in so many different projects.

yindo referenced this issue

2026-02-17 17:06:26 -05:00

[PR #99] [MERGED] Sign out functionality #95 #212

yindo referenced this issue

2026-06-05 14:21:08 -04:00

[GH-ISSUE #95] Sign out functionality #51

yindo changed title from ~~Emulation support~~ to [GH-ISSUE #189] Emulation support

2026-06-05 14:21:23 -04:00

yindo closed this issue

2026-06-05 14:21:24 -04:00

yindo commented

2026-06-05 14:21:24 -04:00

@DecDuck commented on GitHub (Feb 25, 2026):

If we want to support flexibility, then why not allow the admin to upload emulators to the server as games, and then upload ROMs to the servers as games as well, and have the ROMs use the emulator app that's stored on the server?

We went with design for v0.4.0.

@DecDuck commented on GitHub (Feb 25, 2026): > If we want to support flexibility, then why not allow the admin to upload emulators to the server as games, and then upload ROMs to the servers as games as well, and have the ROMs use the emulator app that's stored on the server? We went with design for v0.4.0.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Drop-OSS/drop#95