Not a comment on the quality of this application, but rather a tangential topic: there should be some way of auditing the accuracy of emulators in general. If a genuine homebrew scene wants to exist (not just getting old games to work), new programmers who have little-to-no access to the original hardware need some practical way of knowing their software will work properly across different emulators. In the old days, most platforms had one good emulator that everyone used, and these emulators were supported by communities like AtariAge. In the Web 2.0 world, those communities are fractured or even gone completely, and often not easy to find in search engines. There are now much more platforms that emulators can be run on.
Hardware emulation isn’t a solution. An FPGA emulator isn’t intrinsically more accurate than a software one, and documentation and schematics that are used to implement emulators can be incorrect and don’t specify ‘undefined behavior’ which was very much used reliably by software developers.
The approach adopted by MAME has proven to be the only reliable: you have to measure some output on a real working system and compare it to the emulator behavior, but this can be impractical and becomes moreso over time as systems become more difficult to operate. (E.g. I can’t even operate most 8-bit computers without some kind of mod because I don’t have a CRT television anymore).
there are emulation test suites. the fact you throw out 'there should be auditing' without acknowledging the literal _years_ of documentation and research leads me to believe you know nothing on the topic, rather just want complain on hacker news about something you have no involvement in.
MAME literally scans the dies to read the chips and understand their logic. FPGAs faithfully recreate this as well. and no, you can still run a 8bit micro on whatever display you want. Projects like dolphin and BSNES documented the hell out of everything they do with a goal of accuracy in mind.
No disrespect intended. I just want to make sure people are aware of these issues.
Recognizing a problem doesn’t put down the developers who will have to work on it, rather it highlights how important their jobs are and how valuable they are as a resource!
There are roms that test accuracy. Hardware will return 100% and emulators will receive less.
I believe there are some psx test Roms that no emulator gets 100%. I know for a fact there are n64 test Roms that don’t get close on an emulator.
You point on hardware emulation stands regarding it doesn’t automatically mean more accurate emulation. Although it lends itself to be more accurate due to you “can’t make a software thread for each discrete component” software problem as well as “how do I take controller input and when” as well which are wayyyy easier on fpga than software.
Timing can only be as accurate and precise as the system that is running the emulation. Accuracy can be expressed in relation to limited bounds. For example, loading software through a filesystem instead of a physical cartridge slot is inaccurate, but practically meaningless, so we don’t take that account in a metric for accuracy.
Until you find that one weird game that relied on some obscure or undefined behavior that only exists with the cartridge ;p
Not a popular game, but the cartridge for Morita Shogi 64 had a built in RJ-11 jack and allowed online multiplayer.
Plenty of SNES games included a SuperFX graphics coprocessor in the cartridge. Star Fox is probably the most popular example. SuperFX games were popular enough that it was quickly emulated successfully. But you can't treat the cartridge as just a file system abstraction on SNES.
Whether the cartridge contains ROM, a processor, or a connector, we can’t emulate the physical aspects of it (unless we use some kind of VR). Loading a file is a simulation of inserting a cartridge. There is fundamentally a difference. That’s what I was trying to get at. The question is if the difference matters. We usually can’t answer that. For example, we are finding that many video systems have to be displayed on the scanline level, rather than as a framebuffer, to be correct. Something like the Apple II will probably have to be done on the pixel clock level (at least). There always seem to be corner cases that require you to go ‘lower level’.
Your observations is correct, but it also depends on other factors.
The instruction timing and such fiddly low-level details is most visible in systems programmed in low level, such as older consoles.
Modern systems tend to be programmed in higher level languages, which works much better to HLE (high-level emulate), since they tend to be programmed in a way that cares less/not at all about underlying hardware fiddly details.
So when you are emulating the NES, these details matter way more than when you are emulating the Switch for example.
Web 2.0 has made it so fractured that massive communities exist on /r/EmuDev, Emulator 101 is a well known source for new learners, nesdev.org is the reference for NES stuff, a shitton of the data we have is from the Web 1.0 days and is just as fractured, and we even have repos like https://github.com/marethyu/awesome-emu-resources that collect a shitload of useful stuff (including the test ROMs that other commenters have mentioned, that will only work if you perfectly emulate the target system).
As well as that, many people are decapping entire chips and games, just for exact emulation. So, no, you're talking out your ass, sorry.
Sounds great. It really does. Question is who would be brave enough to provide such a cool thing. I don't think even 30+ year old MAME roms are not considered abandonware, as obtainable as they've been for the last 20+ years.
Your GF was doing that really doesn't change what's going on today. Back in 90's I was able to download FULL mame without writing and begging on strange forums to find out what's needed for the particular game. It is a gatekeeping community and hard to play mame games today. I bet your GF cannot download a single game by googling today and can start to play from scratch within 1 hour after downloading mame. Or not even the same day. It takes time to find these things today.
I dig the Netflix style navigation, I'm curious if there are plans to support arbitrary ROMs for classic games. Probably can't host them, but maybe an easy way to load one from local?
edit: should have scrolled down in the readme more, they say in the non-goals section:
Directly playing locally stored game content (ROMs, etc.)
(Technically possible by using a local web server, but not a primary use case)
I recently integrated the self-hosted EmulatorJS (https://github.com/EmulatorJS/EmulatorJS) into my Web Desktop daedalOS (https://github.com/DustinBrett/daedalOS). Has worked really well with controls on mobile and added a ton of emulator support to my "OS". All the emulators are wasm/asmjs ports from Libretro, I believe.
There are open tickets for a self-hosted option (there's already a Dockerfile, etc.), and requests for multiple platforms. And yes, the demos on the public site (https://play.webrcade.com) seem to be ports and indie games. Pretty amazing altogether.
When navigating the menus, the browser back button doesn't seem to work, and nor is the way to go out of a particular menu obvious. I ended up just refreshing the page to get out of stuff.
Same here - feels very unintuitive to have to click the name of the page you're currently on to go back to the parent - feels like it should display 'Parent > Current' rather than just 'Current'. And probably respect browser back behaviour if possible.
Curious that the description seems to be laden with buzzword-bingo words.
It could be made less Corporate-Powerpoint, for example:
> WebЯcade is a web-based front end for playing games within the browser on many platforms (Xbox Series X|S, iOS, Android, Windows, macOS), with gamepad (Bluetooth and USB) support.
Try enabling JIT, AFAIK on Chromium you need JIT on to run WASM. Not sure if the grapheneos browser has it off, but it seems like the kind of thing they'd do.
It is highly likely that quite some people in particular in East Germany considered the Я to be the Ya letter since they learned Russian in school.
But this is not the only confusion: As a child when I was learning English in school, the first association that the "Toys [a]R[e] Us" brand awaked was "wrong grammar". Don't the native speakers of English who came up with this brand name know the grammar of their mother tongue?! No wonder that the German Wikipedia article about Toys R Us also explains this point.
I'm not Russian or Slavic. But I'm interested in typography and hence learned the Cyrillic alphabet. Helped me loads when I travelled through Slavic countries! But ever since, posters with "Russian" word plays have been ruined for me lol.
Hardware emulation isn’t a solution. An FPGA emulator isn’t intrinsically more accurate than a software one, and documentation and schematics that are used to implement emulators can be incorrect and don’t specify ‘undefined behavior’ which was very much used reliably by software developers.
The approach adopted by MAME has proven to be the only reliable: you have to measure some output on a real working system and compare it to the emulator behavior, but this can be impractical and becomes moreso over time as systems become more difficult to operate. (E.g. I can’t even operate most 8-bit computers without some kind of mod because I don’t have a CRT television anymore).