The reveal comes from X user @ChrisMack32, who posted a video showing them unplugging a Super Nintendo controller – connected via USB – at one of the...
That team writes emulators that run directly on Nintendo consoles, so they would likely test it on development versions of those consoles the same way actual console games are developed and tested. Otherwise they would be testing a Switch version of an SNES emulator running inside a Switch emulator on a Windows PC that would introduce it’s own errors.
The Switch is ARM and uses several components from FreeBSD and Android. It would not be surprising to learn that they have the ability to compile system components like Virtual Console for an ARM Linux with stubs for Switch-specific stuff.
The SNES Classic is also ARM, and has much less going on than the full Switch OS (Horizon). That could be the core of what they use for the museum displays, considering there’s an ARM version of Windows too.
Either way, devs gonna dev. If you can’t get feedback at your workstation and always have to deploy to your target platform to test anything, you’re gonna move too slow to catch and fix bugs or build flexible enough systems to prevent them.
So much of dev testing is about trade-offs between rapid iteration and thorough fidelity. You need access to both.
From my own experience, I’ve done stuff like:
built mobile apps that can also be deployed as desktop apps or web apps for the sake of dev testing
built testing tools for car systems that fake out sensor input
built HTTP wrappers for cloud-deployed services to allow them to be run locally
faked out camera feeds for AR apps
It can get janky, cuz not everything works the same way, but most of what you work on is not platform-specific anyway and a good architecture will minimize the portion of code that only works on the target platform.
They don’t need to, they have their own studio that makes all their emulators called NERD: https://en.m.wikipedia.org/wiki/Nintendo_European_Research_%26_Development
Those emulators most likely have always worked on Windows since they need to be tested somewhere.
That team writes emulators that run directly on Nintendo consoles, so they would likely test it on development versions of those consoles the same way actual console games are developed and tested. Otherwise they would be testing a Switch version of an SNES emulator running inside a Switch emulator on a Windows PC that would introduce it’s own errors.
The Switch is ARM and uses several components from FreeBSD and Android. It would not be surprising to learn that they have the ability to compile system components like Virtual Console for an ARM Linux with stubs for Switch-specific stuff.
The SNES Classic is also ARM, and has much less going on than the full Switch OS (Horizon). That could be the core of what they use for the museum displays, considering there’s an ARM version of Windows too.
Either way, devs gonna dev. If you can’t get feedback at your workstation and always have to deploy to your target platform to test anything, you’re gonna move too slow to catch and fix bugs or build flexible enough systems to prevent them.
So much of dev testing is about trade-offs between rapid iteration and thorough fidelity. You need access to both.
From my own experience, I’ve done stuff like:
It can get janky, cuz not everything works the same way, but most of what you work on is not platform-specific anyway and a good architecture will minimize the portion of code that only works on the target platform.