[HN Gopher] Show HN: RomM - An open-source, self-hosted ROM mana...
___________________________________________________________________
Show HN: RomM - An open-source, self-hosted ROM manager and player
RomM is a self-hosted app that allows you to manage your retro game
files (ROMs) and play them in the browser. Think of it as Plex or
Jellyfin for your ROM library: it automatically fetches metadata,
artwork, and game information from online metadata sources to
transform your folders into a browsable collection. You can play
games directly in the browser for consoles like the N64, Game Boy
Advance, Nintendo DS, and PlayStation 1, using the integrated web
emulator (https://emulatorjs.org/). Members of the community have
released integrations for Playnite (Windows), muOS (Anbernic
handhelds) and Decky Loader (Steam Deck), with many more in the
works. The team has been working on RomM for just over two years
now, and we're incredibly proud of what we've built so far. There's
no company behind the project, just a bunch of friends building
something together that we've wanted for a long time. And of
course, the code is open-source and AGPLv3 licensed. Check out the
(kinda slow) demo running on an ultra-cheap VPS:
https://demo.romm.app/
Author : gassi
Score : 223 points
Date : 2025-06-11 14:25 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| atrus wrote:
| Thank you for being AGPLv3, and an _extra_ big thank you for
| clearly laying out the needed directory structure. Sometimes it
| 's not always clear. The docs in general are great!
| gassi wrote:
| Glad to hear it!
| garrettjoecox wrote:
| Could you explain the benefits of using this over retroarch,
| lakka.tv, emulator station, EmuDeck (steam deck wrapper around
| some of these), etc.
|
| Playing through a browser seems like a downside for me personally
| zurdi wrote:
| This is a self-hosted solution, unlike all those sofware you
| mention. You will install this in your server through docker
| and you will manage your ROMs library with a clean interface.
| Being able to play in the webUI itself is an extra since we
| just integrated emualtorjs (from emulatorjs.org)
| garrettjoecox wrote:
| I think I might just be too far from the target audience to
| understand this. I don't see any of the other options as non
| "self hosted", they aren't backed by some cloud
| infrastructure owned by a company, those are all locally
| running apps on your device
| gassi wrote:
| Another way to put it is that those apps are only installed
| on a single device at a time, whereas with RomM setup on a
| server, so you can access your library from any device with
| a browser. There's a future where ES-DE and EmuDeck can
| pull games from, and push saves to, a central RomM server.
| zurdi wrote:
| As Gantoine said, the main difference is that you can't
| access any of those tools from other device, only from the
| one where it's installed
| gassi wrote:
| Ideally you would use both, and the community would build
| integrations that allow, say, EmuDeck to pull games from the
| server onto your Steam Deck and sync saves back to the server.
|
| I usually play on Windows with Playnite
| (https://playnite.link/), and the plugin
| (https://github.com/rommapp/playnite-plugin) allows Playnite to
| pull and display the list of games for each system, after which
| I can install the ones I want to play onto my PC.
| mingw__ wrote:
| Seeing the integration with RetroAchievements is especially
| appreciated!
| UI_at_80x24 wrote:
| I'm not really understanding the usecase here.
|
| Is it MAME but for playing in a browser?
| gassi wrote:
| At it's core it's a system for organizing and displaying your
| collection of retro games (ROMs). Instead of navigating through
| folders or manually moving games from a hard drive to whatever
| system you want to play on, you can load them into RomM,
| navigate to the app and download them from the browser.
|
| You can share it with your friends so they can access your
| library, use the plugins to download games directly onto some
| platforms (without a browser), or play older systems in the
| browser for a quick session.
|
| At some point we'd like to handle save file sync between
| devices so you can stop playing on one device and pick up where
| you left off on another!
| bane wrote:
| Is there anyword on integration with Batocera, ES-DE, or
| Retroarch? Those mega systems would get supercharged with it.
| The homelab community would likely catch on very quick.
| zurdi wrote:
| Right now we have a playnite plugin, a muOS/portmaster app
| and a on-going decky plugin for steam deck. We have plans
| to integrate with RetroDeck. No luck with Retroarch since
| it doesn't support plugins, but you can always use
| something like syncthing for those where we don't have
| integration yet purpose.
| gassi wrote:
| Not a plan but we wrote this up a while back as an
| exploration into which systems/platforms we can target.
| We're really hoping the community continues to step up with
| more plugins and integrations so we can focus on the core
| service.
| bane wrote:
| Not thinking about you guys needing to write these
| integrations, but if there's interest on their sides for
| building it themselves?
| gassi wrote:
| Depends on the project, the muOS team is keen to
| integrate RomM directly in a future release, and the
| Retrodeck team is willing to partner on support.
| mortos wrote:
| I saw this project some months ago and it looks awesome, just
| haven't set it up yet.
|
| How does it handle modern games? I have a lot of DRM free
| games and small indie projects I've collected/archived and I
| want a way to neatly display them and download them
| zurdi wrote:
| You can display almost anything pretty well. For DRM free
| games, just upload them as a zip or put them in your
| library as a folder with everything inside and RomM will
| display them as everything else. You can do it under the
| "win" folder so RomM knows those are PC games
| mortos wrote:
| Awesome! I also see RuffleRS is supported too for flash
| archiving. I'm jumping on this now
| bane wrote:
| RomM is a great project! I've so excited to see the integrations
| coming along.
|
| As somebody who's setup a lot of little retroboxes, the idea of
| doing it once and having my collection served off of my homelab
| to all my other devices is incredibly appealing. Web-based
| emulation has come a _very_ long way. Still I prefer to play off
| of my individual devices many of which don 't have good browser
| support.
|
| Setting those systems up can take hours each, but being able to
| point something like a Batocera instance or an ES-DE setup at a
| server and have it self populate with roms, bios files,
| screenshots, etc, would be a dream. It sounds like this might be
| the future of the emulation ecosystem and it sounds amazing!
| gassi wrote:
| I love your vision and enthusiasm! You seem to have a solid
| setup already and a great use case for a future version of
| RomM.
| johanyc wrote:
| This is so cool and you can play it directly on the browser
| gassi wrote:
| You can thank the EmulatorJS team for that, they're really
| killing it: https://github.com/EmulatorJS/EmulatorJS
| bogwog wrote:
| I had an idea once but not the time nor motivation to build it: a
| database of game design with links to gameplay snippets.
|
| So for example an article on "2D platforming" that discusses the
| implementation in Super Mario, and includes a "demo" button which
| launches a web emulator with a save state that demonstrates a
| specific jumping section of the game.
|
| Legally perilous maybe, although my non-lawyer brain sees that as
| fair use, especially if the emulator doesn't let you play the
| full game. Idk, but it'd be a unique thing on the internet.
|
| Edit: this is awesome btw, im definitely setting up a personal
| instance soon
| gassi wrote:
| Cool idea, would be a fun POC or weekend project. The team
| behind EmulatorJS (https://emulatorjs.org/) has made it stupid
| easy to inject the player into a static website (or multiple
| players with iframes), with a preloaded game and custom
| settings.
| Arelius wrote:
| > Legally perilous maybe, although my non-lawyer brain sees
| that as fair use, especially if the emulator doesn't let you
| play the full game. Idk, but it'd be a unique thing on the
| internet.
|
| IANAL, but I think what a lot of people don't understand is
| that "fair-use" is a defense. Which basically means you have to
| be prepared to argue in in court. A lot of potential fair-use
| is quashed before it gets to that point.
|
| It's also a balancing test, which means that it's very
| fact/context dependent, and subjective, which results in for a
| lot of cases, you really won't know until you actually get to
| court.
| gassi wrote:
| This is incredibly relevant to projects in this space, and we
| continue to hold discussions about what is and isn't
| tolerated in our community, and what features we should avoid
| building, in order to protect ourselves from legal attacks.
| One thing you'll never see integrated into the RomM is a way
| to pull/download ROMs from cloud services or website; you'll
| always need to provide the games to RomM directly, after
| sourcing them legally of course.
| anthk wrote:
| MAME/MESS just used GIF files for that.
| TomatoCo wrote:
| I think you could make your fair-use defense a lot stronger by
| stripping the ROM. Shouldn't even be that hard! Only let it run
| for a few seconds, record all the memory accesses, zero
| everything that wasn't hit.
| kaunta wrote:
| This idea was explored by Joel Franusic and Adam Smith:
|
| "Playable Quotes for Game Boy Games" -
| https://www.youtube.com/watch?v=z9JYOZWLMlo
| MyPasswordSucks wrote:
| The database idea is neat, but I'm not really sure what the web
| emulator part adds besides bloat. Either an animated .GIF or an
| HTML5 object with buttons to click to demonstrate, e.g.,
| standing horizontal jump trajectory vs running horizontal jump
| trajectory would not only be less overhead, but much more
| immediate.
| reactordev wrote:
| Reminds me of a "steam" inspired version of hyperspin. Cool!
| Great work. Still looking for a good hyperspin replacement that
| runs on Linux that I can use for my machines.
| gassi wrote:
| I've been working on integrating RomM into Lutris
| (https://lutris.net/) for a while, but it's not ready yet since
| I haven't had time to finish it. Not as a plugin but directly
| in the main Lutris repo:
| https://github.com/gantoine/lutris/tree/romm-game-service
|
| It would allow you to store your games on the server, sync the
| list in Lutris, and install them when you want to play them.
| I'd like to get a working POC to demo to the Lutris team soon-
| ish. Oh and if anyone sees this and would like to help get us
| there, contributions are always welcome!
| entropicdrifter wrote:
| I would love to see this working in Pegasus Frontend or
| Heroic Games Launcher, personally
| gassi wrote:
| Pegasus can use Lutris as a game source, so if we build the
| Lutris "plugin" we get Pegasus support for free!
| https://pegasus-frontend.org/docs/user-guide/meta-sources/
| VonGuard wrote:
| Been using this for a while. It's evolving rapidly and the team
| behind it is very responsive and passionate. Very excited to see
| this evolve over time! The only thing that it really needs going
| forward is more Retroarch cores ported to JavaScript, but that's
| an upstream problem.
| zurdi wrote:
| Thank you for your kind words! And yeah, the emulation part is
| more in the emulatorjs team roof, they are doing a great job
| too
| gassi wrote:
| We just added support for Doom and Amstract CPC in today's
| patch release! It's been available upstream for a while now so
| we just had to enable it. There's also a new update for
| EmulatorJS coming soon (currectly in beta testing), and I've
| been thinking of releasing a custom image with the nightly/beta
| build for testing...
| roger_ wrote:
| Been tracking this for a while and it really needs support for
| renaming and validating ROMs (e.g. with .dat files) to be called
| a "ROM manager".
| gassi wrote:
| 1000% agree, and we're planning to do just that with Hasheous
| (https://hasheous.org/), a "free service that matches MD5 or
| SHA1 hashes of ROMs and digital games with metadata providers".
| There's a cloud version hosted by the project creator, or you
| can spin up your own instance and source the .DAT files.
| roger_ wrote:
| Great, looking forward to it!
|
| I've used RomCenter and other tools in the past and I'd love
| to see similar, comprehensive functionality in something more
| modern.
| papercrane wrote:
| Your comment piqued my interest, as that would be a required
| feature for me to use something like this.
|
| It looks like they do support integrating with a tool called
| Igir to handle validating and naming ROMs using DAT files.
|
| https://docs.romm.app/latest/Tools/Igir-Collection-Manager/
| sumtechguy wrote:
| Have to dig and see if it handles retool items. Unfortunately
| retool has been basically abandoned. IGIR looked interesting
| until I realized it could not do parent/clone for redump like
| retool.
| papercrane wrote:
| Looks like it does support 1G1R with the --single option
| and can infer parent/clone information if it's not
| provided, like with redump DATs. You could also use retool
| to create a DAT with that information based on your
| preferences, but as you said that's probably not viable
| longterm since retool is no longer maintained.
|
| https://igir.io/dats/processing/#parentclone-inference
| sumtechguy wrote:
| Yeah. The base problem is redump doesnt have parent
| clone. Some of MAME has it, retool has the currently
| basically static version. The name inference is ok for
| some of them because they are just basically the same
| name but diff regions. Others are in the native language
| or just totally different names but same game. Then there
| is TOSEC. That is a monster I have been trying to figure
| out what to do with and has similar problems as redump.
| No-intro and MAME are pretty good with its relationship
| metadata. The other two not so much. Some websites have
| it for particular systems but kinda not a cool move to
| scrape them. One of the cool parts I liked out of retool
| was its compilation part where there could be three games
| and it is in another 'game' thigs like '5 in 1'. Which is
| where p/c falls apart.
| gassi wrote:
| Igir is great! We've been sponsoring them for the last few
| months since many of our users find it helpful. There are
| docs on both ends for getting it to output a folder structure
| that's compatible with the app
|
| https://docs.romm.app/latest/Tools/Igir-Collection-Manager/ |
| https://igir.io/usage/desktop/romm/#
| haolez wrote:
| This would be super cool if it becomes a smart TV app. Couldn't
| be too far off, right?
| gassi wrote:
| If/when someone builds an Android app we could easily port it
| to Android TV with some tweaks for controller and remote
| support. However playing the games gets a bit tricky, as the
| built-in player might struggle with the low-end hardware used
| in many consumer smart TVs.
| zunk wrote:
| This might be a stupid question. But can you have a general
| import folder were you just dump a rom and the app IDs it and
| moves it to the correct system folder?
|
| I have this installed on my unRAID instance and haven't yet
| figured this out..
| gassi wrote:
| That's not possible (yet), you can upload a ROM from the web UI
| (button in the navbar) but you need to select the platform it
| belongs to. When we implement hash-based matching with Hasheous
| (https://hasheous.org/) you'll be able to upload a bunch of
| ROMs, or throw them into an import folder, and the ones that
| are detected correctly will be moved to the "right" platform
| folders.
| asmor wrote:
| I use igir for this. It's a bit of work to setup though.
|
| (Pro tip: Use the {datName} template token instead of --dir-
| dat-name if you use clean with single DAT files, or the "only
| delete from folders we touched" rule doesn't apply, learned the
| hard way).
| pdntspa wrote:
| Can we collectively stop using the word "beautiful" for app
| descriptions. It is so overused and now effectively meaningless.
| Besides, beauty is supposed to be in the eye of the beholder, not
| the creator trying to put words in other peoples' mouths.
|
| If you are aiming for 'beauty' (whatever that actually means),
| then build it to a high standard and let other people find the
| words on their own accord.
| gassi wrote:
| We're building this app for us, our friends and our community,
| and if we collectively find it beautiful, then it's objectively
| beautiful. :)
| pdntspa wrote:
| No love for understatement, I see
| zurdi wrote:
| We put a lot of effort in making it responsive and
| aesthetically beautiful dude! Sorry to sorry to hear that you
| dislike it
| pdntspa wrote:
| All I'm saying is to not contribute to rendering the word
| meaningless by putting it in other peoples' mouths. If what
| you built is truly beautiful then people will call it as such
| without your prompting.
| zurdi wrote:
| Respectable opinion, but not accurate from my point of view
| because we could say the same for powerful or any other
| adjectives!
| pdntspa wrote:
| Yes, they are overused as well. I would love it if people
| would tone it down with the adjectives.
| bityard wrote:
| Could be worse, it could be "blazing fast!"
| dawnerd wrote:
| I'm using it mostly as a way to keep my copies of GOG games
| organized. I could use GOG's app, but the point of having fully
| offline copies is to not have them under the control of the
| people you bought them from.
|
| Romm works really great for this too.
| M95D wrote:
| Fetching anything from the internet means some cloud knows what
| games I'm playing. It's a privacy risk. Games played are very
| revealing to personality type, and probably lots of other
| individual info, and that means the temptation to gather this
| data and sell it to advertisers is very high.
| doubled112 wrote:
| It is optional. If you don't configure the integrations it
| won't fetch anything from the internet.
|
| It looks much less impressive without cover art though.
| gassi wrote:
| Even if we could bypass calling the API directly, just
| fetching, storing or loading images from IGDB or SSFR would
| "leak" some data in those calls. In theory you could block
| the container's access to the web, then identify and upload
| cover art for every game by hand.
| gassi wrote:
| What fortunate timing! Our next release will including a new,
| local-only "API" that uses Launchbox's GamesDB
| (https://gamesdb.launchbox-app.com/) as the metadata source.
| The entire database is loaded into Redis and games are matched
| on exact file names, so no data is ever sent to any cloud
| providers.
|
| https://github.com/rommapp/romm/pull/1515
| wolrah wrote:
| > Fetching anything from the internet means some cloud knows
| what games I'm playing. It's a privacy risk. Games played are
| very revealing to personality type, and probably lots of other
| individual info
|
| It seems like OP already replied with an upcoming feature to
| entirely eliminate your concern, but I would also point out
| that this doesn't mean the cloud service knows what games
| you're _playing_ , they just know what games you _have_ which
| for many gamers are two very different things.
|
| That's especially true for those with a large enough ROM
| collection to be interested in tools to manage and simplify
| access to their libraries. I'd be willing to bet that the
| majority of potential users have collections that are
| exponentially larger than the list of games they actually play,
| in many cases some variety of a "complete" collection.
| udev4096 wrote:
| Use a goddamn VPN or Tor if you don't like being profiled. We
| live in the era of mass surveillance. It is obvious that
| everyone is being profiled all the time. It's a meta-data
| aggregating player, how the fuck do you think that works?
| 1oooqooq wrote:
| retroarch downloads entire db of assets.
| pipes wrote:
| Looks lovely. Thanks for creating this.
|
| If you have time:
|
| Does it (or can it) run emulators natively? I'm trying to get my
| head around js emulator, how is that libretro? Is libretro
| compiled to wasm?
|
| Is it running retro arch underneath or have you managed to
| implement the libretro API?
|
| I love and hate retroarch. Its menus are ridiculous but it's
| still easier than managing multiple emulators.
| gassi wrote:
| The project that powers the in-browser emulator is EmulatorJS,
| which use RetroArch's libretro cores compiled to WASM. More
| info on the process here:
| https://emulatorjs.org/docs4devs/buildingraw
|
| I believe it's running RetroArch, as when you load a corrupt
| file or start without selecting a game it displays the RA menu.
| If you want to dig deeper you can check out their github or ask
| in their Discord, the team have been wonderful to work with.
| jfinnery wrote:
| Any way to run the Docker version without the external DB
| requirement? I have a bunch of things running on my home server
| and so far every one is a single image with no external
| requirements, which is very nice. Everything that needs a DB just
| uses sqlite, makes it operationally very simple, and nothing I do
| even comes within the same universe as the kind of usage that'd
| cause sqlite to become a bottleneck (and this doesn't look like
| it would, either).
| zurdi wrote:
| Sadly no. We had sqlite support long time ago but it became way
| too hard to maintain as our database arquitecture grown, so
| right now we only support mariadb and postgres
| jfinnery wrote:
| Thanks so much for the response! I get it, that's cool, just
| making sure. Will be giving it a try regardless.
| Gamemaster1379 wrote:
| I get the impression the authors are monitoring the thread. I'm
| not home to check this out but I like the idea. A few questions.
|
| 1. Does the web interface allow you to download your ROMs in a
| similar fashion to Plex letting you download your files? I could
| see myself using this to fetch from my libraries and would like a
| nice GUI box art interface to grab a game I'm looking for. 2. How
| does this work with ROM hacks? How is the metadata pulled?
| Filename? Header? How could I set custom metadata where it
| doesn't match. 3. Does this have an accessible and documented API
| if I want to build extensions to it (or am I forced to use the
| interface?)
| zurdi wrote:
| Of course! we are excited about the post and we want to answer
| any question regarding RomM. Answering you:
|
| 1. That's exacty what RomM (among other things) does. You will
| have a Jellyfin/Plex interface from where download your games
| 2. Right now we match using the name of the file, but we are
| planning to add match by hash thaat will increase the accuracy
| even more. If it doesn't match anything, you are able to match
| it manually from the interface in a very user friendly way. 3.
| Yes, our API docs are integrated into RomM itself, so any RomM
| instance you can access will show the docs. It can be your own
| instance, or the demo site one for example
| (https://demo.romm.app/api/docs) or
| (https://demo.romm.app/api/redoc)
|
| Apart from that, we have some integrations with different
| systems, like a plugin for playnite or an app for muos or
| portmaster to avoid download from the browser itself but from a
| native client
| (https://docs.romm.app/latest/Integrations/Playnite-plugin/)
| and (https://docs.romm.app/latest/Integrations/muOS-app/). A
| lot more integrations are in the works
| Gamemaster1379 wrote:
| Thanks so much for the answer! This is a really cool project!
| I'll definitely check it out once I'm back.
| shitloadofbooks wrote:
| I made my own really mediocre version of this 2 years ago just
| for PS4 and Switch ROMS, also using IGDB etc. Glad to see
| something so polished and professional looking.
|
| For the maintainers, does this pull the metadata (e.g Title ID or
| PKG ID) from the (supported) ROM files directly, or only from the
| filename? I skimmed the README and Docs and couldn't find a clear
| answer.
| zurdi wrote:
| Hi! for some platforms like switch where the games have a Title
| ID we first try to match against a static file RomM already has
| loaded and fallback to metadata providers (igdb, screenscraper
| and mobygames for now) searching by filename
| zahlman wrote:
| My first thought was, what does it mean for a program like this
| to be "hosted" in the first place?
|
| My second thought was, for people who play a lot of ROMs, they're
| either doing it because they know more about those games than
| typical online metadata sources do; and/or a big chunk of them
| are modded or even completely homebrew.
| TOGoS wrote:
| I assumed it meant that the emulator is written as a ROM that
| loads itself.
|
| But that's probably not what it means. Kids throw words around
| meaning all sorts of strange things these days.
| gassi wrote:
| Not sure what you mean by this, but in this context it's
| hosting and managing applications on your own servers instead
| of consuming from cloud/SaaS providers.
| TOGoS wrote:
| Back when I was a lad we called that "a computer program"
| zahlman wrote:
| Back when _I_ was a lad, we called that a "web site".
| And a "computer program" was something that just ran on
| your local device (which was almost certainly a desktop
| computer), using its CPU, and directly gave you what you
| wanted, no network required.
|
| And if it used a GUI at all, it implemented its own GUI
| directly using the API provided by the OS (or some
| library built on that; originally quite obnoxiously thin
| ones, but nowadays you can get some very nice
| abstractions). It didn't delegate HTML or CSS rendering
| to a web rendering engine, because those basically didn't
| even exist outside an actual dedicated web browser. Nor
| did it _express_ the GUI layout in those terms at any
| point; it was expressed in terms of widgets again defined
| by whatever SDK, specifically for the purpose of creating
| GUIs - not hacks on top of the hypertext model.
|
| You know, much like what had to be done to make the ROMs
| in the first place (although using SDKs oriented around
| receiving input from a controller, rather than a mouse
| and keyboard; and around displaying things like scrolling
| tile grids rather than movable windows).
|
| (And it turns out it's still completely possible to make
| things this way, and I still do.)
| gassi wrote:
| Hosted as in self-hosted, as in run on a server with
| Docker/Proxmox/Unraid and accessible via a web browser, as
| opposed to running locally on a single device.
|
| The solution isn't ideal for those who hoard entire romsets,
| but it's great for those of us who curate their collections
| down to a more manageable size. That can be anywhere from a
| couple hundred to a couple thousand games, and the metadata
| sources are fairly robust at that scale.
| zahlman wrote:
| I guess the subtext was lost. I was stunned by the idea that
| anyone would want such a thing to be "accessible via a web
| browser" at all. Self-hosting is the improvement you
| implement over letting someone else host it, but hosting it
| at all was an idea that would never have crossed my mind had
| it not been brought up. And it creates the impression that
| such hosting is somehow necessary to use the software.
|
| It's a sort of complexity that seems, to me, completely
| beyond what the target audience - people who collect ROMs -
| would be interested in. After all, they're explicitly
| preserving software that itself works in a far more primitive
| way, because they have a personal interest in software that
| works in primitive ways.
| plokiju wrote:
| That's funny. I come at this from the opposite direction. I
| like to run stuff on my home server, and I started a ROM
| collection because of Romm. If you're used to managing a
| media collection using jellyfin/Plex, adding roms feels
| pretty natural.
|
| Maybe this project is appealing to a totally different
| audience than most ROM managers
| typh00n wrote:
| killer feature for me at least would be to be able to net-play
| co-op games via emulatorjs in the browser. :)
| oersted wrote:
| Side note: for those with large PC game libraries, Playnite is a
| godsend!
|
| It has a similar UX as RomM, in fact it seems to be inspired by
| Playnite and has a plugin for it. It also uses most of the same
| metadata sources.
|
| Playnite is quite mature and powerful now, with a rich ecosystem
| of extensions, data sources and themes. And even though I am not
| much of an emulator user, it was easy to hook up to any emulator
| and local ROM, like Breath of the Wild with Cemu or Pokemon
| Emerald on VBA.
|
| Not to in any way suggest that you should use Playnite instead of
| RomM, it looks like a great app, just thought it would be
| relevant to mention.
| gassi wrote:
| I use both, Playnite and RomM are better together!
| indigodaddy wrote:
| Tried the first NES game off the demo. Surprisingly
| playable/enjoyable on mobile (Android chrome)! I feel like even a
| few years ago that the experience in mobile browser on some
| random retro game site was not even close to this good? Is
| emulatorJS pretty new or does this project just have all the
| pieces working perfectly?
| 1oooqooq wrote:
| used on the archive.org rom files for more than a decade.
| gassi wrote:
| EmulatorJS.org is a complete, open-source rebuild of the
| closed-source emulatorjs.com, and has now surpassed the
| performance and feature set of the original emulator. Their
| team continues to make strides with the experience on mobile,
| and we'll make sure to keep RomM updated as new releases come
| out.
___________________________________________________________________
(page generated 2025-06-12 23:01 UTC)