Emulation catch-all

Since we don't seem to have one, a thread for news and posts about emulation. I assume it will mostly be used for game emulation, but anything goes. If it's about running software for one system on a different one, feel free to put it here.

I created this thread because I didn't see any good place to put this:

Dolphin Progress Report: May 2017

The most interesting bit, and the thing that prompted me to post, was this:

One of Dolphin 5.0's headline features was a brand new D3D12 backend, but as of 5.0-3774, we have decided to remove it. What we learned from the D3D9 backend helped us make that decision. Like D3D9, D3D12 had some core flaws we let slide under promises that it would continue to be maintained and fixed up. When that didn't happen, it was decided we did not want another deprecated backend hanging around, blocking features and enhancements that require work within each backend.
 
Let's not make any mistakes, the D3D12 backend was a tremendous gain for Dolphin, and what we were able to learn helped us know what to do when designing the Vulkan backend. Unlike the D3D12 backend, the Vulkan backend is actively maintained and does not have the design flaws that made D3D12 harder to work with. Removing D3D12 support also makes it easier for people to tinker with and compile Dolphin on Windows, along with the added bonus of reduced compile times.
 
Going forward, we're going to continue to optimize the existing graphics backends. In our testing, the Vulkan backend was as fast as, or nearly as fast as the D3D12 backend in every benchmark. While different drivers and graphics cards will not all perform identically, we're confident that moving forward the Vulkan backend will be able to handle the burden of users seeking the benefits of the newer graphics APIs.

I'm unclear on whether they're saying that D3D12 is the problem, or the backend is the problem. Regardless, they're yanking that out and going with Vulkan.

Ok, this month's progress report is freaking fascinating.

Ubershaders: A Ridiculous Solution to an Impossible Problem

They write it up way better than I ever could, but my best attempt at a tl;dr: one of the big usability problems in Dolphin is when the emulator needs to compile a new shader. The Wii's 3D engine isn't like a PC's, so when an effect needs to be done, a small program needs to be written to duplicate what would happen instantly on the Wii. Compiling that program can happen within a single frame in some cases, so you never notice. Much of the time, it can take awhile, sometimes even a second or two, and the emulator freezes solid every time this happens. When the emulator barely ran, this wasn't a high-priority issue, but it's gotten so good in so many areas that the hitching from shader compiles has turned into possibly the largest remaining annoyance.

A dev named Tino came up with a forked branch of Dolphin with an interesting solution: run the shader process asynchonously, to just not render an object for awhile until its shader was ready. This gave the emulator perfect fluidity, but lousy fidelity in many cases, and outright broke at least one game, one that rendered Mii heads only one time, and then used the texture copy over and over. Either you render it right the first time, or it's never rendered, and all the Miis are headless. So this wasn't acceptable to the dev team, as much as some users liked it. They figured this would be a support nightmare, and an ongoing festering mass of bugs. (and were probably right.)

So they finally tackled the problem from this angle: what if they wrote one gigantic shader that covered everything the Wii hardware could potentially do? In essence, they were writing an emulation program that lived on the GPU, one which just directly ran a program sent to the Wii's graphic unit, with no translation step. The developer "phire" got a long way with this, but eventually burned out, as it was a mountain of work and he pushed really hard on getting 5.0 out the door in a reasonable state. So it sat for more than a year, slowly rotting; as the writeup puts it, it was 90% done, which meant there was 90% of it left to do.

Finally, Stenzek picked it up and started pushing forward with it again. This is the guy who wrote the Vulkan backend, one of only two or three people on the team who are capable of working at this level. And, lo and behold, it worked! Suddenly, stutters were gone. And are gone. Dolphin with ubershaders doesn't do shader stutter anymore.

But, there are some caveats. This puts a big load on the GPU, so it can wreck your framerates at higher resolutions. They also discovered some fairly nasty NVidia bugs; for whatever reason, shaders compiled in OpenGL mode run about half the speed of shaders in D3D mode. They regard this as a major bummer, as they view OpenGL as their reference standard, and the big performance problems on the NVidia side of the fence bum them out pretty severely.

So, they came up with another workaround. They decided to implement the idea of deferred shader compilation, where whenever they have a dedicated shader available, they use that. But, instead of freezing while they wait for a new compile, if an object needs to be rendered and has no shader ready, they hand it to the ubershader. It's still slow in some modes and on some hardware, but it's fast enough to handle a few objects each frame, even on relatively poor-quality hardware. Voila, you now have 'hybrid' ubershader mode; draw things the old way, but use the ubershader to avoid hitching.

At this point, there are three settings: off (no ubershader), hybrid (use it when necessary), and exclusive (use it always). I've been testing with Exclusive mode on my 970, and it's been gorgeous so far, but I've only run Super Mario Sunshine, and only at native resolution. That said, this game appears absolutely flawless to me; I'm not aware of even the tiniest hitches while playing. (I imagine it might get a bit testy if I cranked the resolution up, as the 970 is pretty fast, but hardly a monster.)

I think the next thing to try would be Super Paper Mario, which used lots of shader effects, and was very prone to framerate issues.

Anyway, I thought this was worth pointing out. It's a fun read. The Dolphin team has the best writeups of any open source project I know.

So with another hour or two of testing: I tried moving to 1080p internal res, and Super Paper Mario showed some trouble early on in Exclusive mode in OpenGL. (garbled sound, like the emulator wasn't quite keeping up.) Switching to Hybrid mode fixed it right up, and it runs gorgeously smoothly.

I can't believe I never tried upscaling in Dolphin before. Things look so much better. I always just ran at native res out of some idea of being faithful to the original. Man, that was dumb. Both Super Paper Mario and the earlier title, The Thousand Year Door, run flawlessly at 1080p; they even upscale their text and everything. Both play beautifully, and look so damn good, way better than the original console ever did.

I used to see hitching when TYD did the 'paper rollup' transition between scenes, and the elevator rides in SPM were usually hitchy. That improved a lot when I moved from the 2600K to the 4690K, but the hitching/garbling was still there a little. In Hybrid ubershader mode, the games are absolutely flawless, at least to my eyes. It's exactly like running the games on real hardware, except at much, much higher resolution.

This is a HUGE improvement, probably the biggest I remember in Dolphin.

I was fiddling around with Dolphin a couple of months ago, mostly out of curiosity. Need to try it again now I have a decent GPU and see the improvements. SPM ran surprisingly well, even on integrated graphics.

That ubershaders article is something else. They definitely got the subtitle right. That is a ridiculous solution. Now I'm curious how difficult programming proto-shaders for the Gamecube TEV was.

I gotta say, the new version of Dolphin is ridiculously good. For the first time, it is unambiguously better than the real hardware. It used to be "better, but with some problems".... now it's just, flat, better.

This is a fascinating thread. Thanks for starting it.

Can anyone recommend a good MAME front-end for Windows 10? Ideally, something I can associate roms with in Windows that I can then make a folder full of shortcuts to launch a game full screen. Either that, or a nice launcher with built-in artwork.

I know I can probably go command line, but it's been a loooooong time since I've fooled around with MAME.

I've always just used MameUI, which is a reasonable front end on the base binary. It's more or less a plugin into the main source tree, making a single unified program.

From a blurb at the bottom of the page, it looks like it may not be perfectly synced with the main releases, though. They make it sound like it's often slightly newer, and with the way the MAME team constantly adjusts ROM formats, that could give you some (probably minor) hassles.

I believe that IV/Play, on the same page, is a more traditional front end, in that it drives the console version for you. That should prevent the possible slight version mismatches, but I imagine won't be as nicely integrated. MAMEUI has its tentacles pretty deep into the MAME source code, where IV/Play would just be driving it from outside.

I think MAMEUI died somewhat recently? They started shipping a GUI recently in MAME which I think is partially responsible for it's death? It's certainly not the nicest GUI (it's not using any sort of native windowing stuff as best I can tell) but it's functional. The only downside is that like Malor says you might need to spend some time looking around for updated files due to changes in the drivers for each game if it's been a while since you've fiddled with MAME.

I hadn't heard about that; the mamedev file is 1.88, and so is MAMEUI, so if it's been discontinued, it's very recent.

MAME does have some kind of other UI now, although I haven't really used it.

I've done some searching, and I don't see anything about MAMEUI being discontinued. Do you remember where you saw that news?

My bad, I was thinking of MAMEUIFX not MAMEUI. Someone on another forum mentioned MAMEUIFX had been discontinued a while back which I was confusing with MAMEUI (which as you mention has not been discontinued)

PaladinTom wrote:

Can anyone recommend a good MAME front-end for Windows 10? Ideally, something I can associate roms with in Windows that I can then make a folder full of shortcuts to launch a game full screen. Either that, or a nice launcher with built-in artwork.

I know I can probably go command line, but it's been a loooooong time since I've fooled around with MAME.

I have been messing with LaunchBox lately. I haven't added any MAME ROMs to it yet but it is very nice for the systems I have tried so far.

I started playing around with a bunch of emulators and kind of got sucked in pretty hard. I've now "built" a pretty nice emulation system on my television PC.

IMAGE(http://i.imgur.com/RM1nv9A.png)

All of the game system desktop shortcuts open up a folder full of shortcuts which seamlessly launch the appropriate emulator in full screen mode.

IMAGE(http://i.imgur.com/5UO8O4V.png)

All of the shortcuts have their icon set to the original game box which was a bit of a pain because Windows icons are square and the game art isn't. I've had to edit the images to add transparency before I created the icons. Right now, I have every emulator up and working except MAME and Dolphin. (I'm not sure if I'll set up Dolphin though as I still have my Wii set up with my wireless WaveBirds.) I also only have a game or two set up for each system right now. The NES folder is the only one so far that is more-or-less complete.

Lastly, I picked up an 8BitDo NES Pro controller and used XPadder to map profiles for every emulator including quick save/load when supported. It works perfectly! (I'm now seriously considering grabbing an Arcade Stick when it launches.)

I'm really impressed with these emulators. The quality of these programs are amazing.

Sounds like you have recreated the base functionality of LaunchBox. I used it a bit over the weekend and it works quite well. I will probably end up dropping the $20 so I can get the access to Big Box mode (full screen controller optimized interface).

I noticed that it had issues with finding info on one of my ROMs just like every other front-end type thing I have tried does. The ROM is Shanghai II: Dragon's Eye which is a nice little mahjong game for the SNES with a neat two player mahjong game called Dragon's Eye (one player is trying to fill the board and the other is trying to empty it). I own the cart for this game and it doesn't seem to be super rare or anything but neither LaunchBox, EmulationStation (which doesn't have the greatest info scraper to begin with), or OpenEmu (Mac) seem to be able to find this game despite it being in their databases.

I had never heard of LaunchBox before now. That looks great. I messed around with RetroArch before giving up. It was way too unintuitive and kludgy.

I'll probably check it out anyway, but do know how it handles emulators? Does it just key off Windows file associations or do you have to use "compatible" programs?

Of all the NES-themed RaspPi cases, this one seems by far the slickest:

https://www.amazon.com/dp/B073ZC4TZY...

Wish it didn't have the Engrish "Retroflag for all of us" slogan on the front but eh. Now if it would only ever come back in stock (hopefully without the price doubling again).

One thing that does concern me a little about it is that the power and reset buttons are not "safe" shutdowns, they just directly cut the power. I know enough to shut down the Pi from within Emulation Station and then I can use the power button to turn it back on when I want to use it again, but I'm worried some people who don't know of the risk of SD card corruption from pulling the power will use the buttons a lot when it would have been safer for their Pi to just be left on.

PaladinTom wrote:

I had never heard of LaunchBox before now. That looks great. I messed around with RetroArch before giving up. It was way too unintuitive and kludgy.

I'll probably check it out anyway, but do know how it handles emulators? Does it just key off Windows file associations or do you have to use "compatible" programs?

It opens the ROMs in whichever emulator you specify via the commandline. This sadly means you have to configure the options and input in each emulator when you first set them up. It is a very nice front end but not quite an end-to-end solution. A lot of the tutorials actually show them using RetroArch as the backend for this.

Just heard about the Mister project. Anybody using this?

Baron Of Hell wrote:

Just heard about the Mister project. Anybody using this?

I'd love to hear from someone who owns one of the Analogue systems.

Also this made me straight up squee, and I am not prone to squee-ing.

https://www.analogue.co/pocket/

I admit I really struggle to understand what that hardware is doing. It's like a... blank slate chip?

That people program to behave like the actual hardware?

No Saturn support in the works though, but if anyone has the new "tube" Shield TV, I'd be curious if it can run Saturn emulators. My regular Shield TV can, but it's not really travel friendly. Apparently the tube only runs 32-bit apps, so I'm curious if that will matter (no Dolphin).

If I had money and space to put them I’d love to load up on these. I ordered the New PocketGo so I’ll be interested to see how that goes. It’s meant to be good up to PS1.

Anybody see any emulation benchmarks for the Athlon 3000G yet?

Mr GT Chris wrote:

If I had money and space to put them I’d love to load up on these. I ordered the New PocketGo so I’ll be interested to see how that goes. It’s meant to be good up to PS1.

Lots of interesting new hardware out. I haven’t paid attention to the scene for a long time. I still use a PSP.

ccoates wrote:

I admit I really struggle to understand what that hardware is doing. It's like a... blank slate chip?

It looks like that's using FPGAs, Field Programmable Gate Arrays.

As I understand it, this means that the chip has a dense grid of hundreds of thousands to millions of components. And, critically, each component can be changed, into one of several different types. This allows designers to build custom hardware circuits to accomplish particular tasks; in essence they're making a single-purpose chip. There are libraries available for different FPGA types, for instance, implementing a range of different processors; I'm aware of a Motorola 68060 emulator on FPGA, one that's vastly faster than any real chip that was ever shipped. (the Vampire V2 accelerator for the Amiga uses this, for instance, giving physical Amiga computers plugin CPU replacement boards that run about fifty times faster than any real 68K Amiga that ever shipped, while also offering a ton of very fast RAM and even HDMI output for some graphic modes.)

And because the components can be remapped into new configurations, sometimes even on the fly, you can "download" new components onto your FPGA. There's an FPGA Amiga emulator that can also be an Atari ST, for example.

However, just because it's an FPGA doesn't mean it's correct. Implementation quality can vary. For instance, there's an FPGA C64 emulator, but the SID implementation apparently isn't all that great, yet. It may look the same to the virtual 6502, but doesn't produce sound that's quite right compared to the original chips. It's being worked on, and the nature of FPGA boards means that improving the circuit is easy and free. However, it's much harder to write and debug an FPGA chip implementation than to emulate it in software. Once it's working, at least theoretically it can be very near zero latency, almost exactly like the original machines were. But getting it working takes a lot more effort than traditional software approaches.

The next step after an FPGA is an actual custom chip, an ASIC. But fabbing an actual 6502 or an actual SID chip would be ferociously expensive, because the tooling to do so costs a damn mint. It might cost hundreds of thousands or even millions of dollars to start production on new 6502s, and the market just isn't big enough to support the necessary volume.

So, they implement it in FPGA instead. It's quite wasteful in terms of power budget compared to ASICs, and the per-chip cost is very high (FPGAs are pricey), but they get almost the same performance and operational characteristics, and can support small-volume operations like emulation.

They can buy FPGAs in tens to hundreds, and sell them for $200 each or whatever. With an ASIC, they could sell them for $25 each, but they'd need to move like a million units to make back the tooling costs.

I have a Mister, it’s an awesome piece of magic when the cores are working right, I love the arcade stuff the best. Food Fight is such a good game.

Middcore wrote:

Anybody see any emulation benchmarks for the Athlon 3000G yet?

Somebody just did a video on it:

bobbywatson wrote:
Middcore wrote:

Anybody see any emulation benchmarks for the Athlon 3000G yet?

Somebody just did a video on it:

Yep ETA Prime's review is what I was champing at the bit for.

Malor wrote:
ccoates wrote:

I admit I really struggle to understand what that hardware is doing. It's like a... blank slate chip?

It looks like that's using FPGAs, Field Programmable Gate Arrays.

As I understand it, this means that the chip has a dense grid of hundreds of thousands to millions of components. And, critically, each component can be changed, into one of several different types. This allows designers to build custom hardware circuits to accomplish particular tasks; in essence they're making a single-purpose chip. There are libraries available for different FPGA types, for instance, implementing a range of different processors; I'm aware of a Motorola 68060 emulator on FPGA, one that's vastly faster than any real chip that was ever shipped. (the Vampire V2 accelerator for the Amiga uses this, for instance, giving physical Amiga computers plugin CPU replacement boards that run about fifty times faster than any real 68K Amiga that ever shipped, while also offering a ton of very fast RAM and even HDMI output for some graphic modes.)

And because the components can be remapped into new configurations, sometimes even on the fly, you can "download" new components onto your FPGA. There's an FPGA Amiga emulator that can also be an Atari ST, for example.

So, to summarize. There's a tiny wizard inside of it and when you load one of the cores Jonny's referring to he casts a magic spell to try and shapeshift it into a specific system's chip. Gotcha.

ccoates wrote:
Baron Of Hell wrote:

Just heard about the Mister project. Anybody using this?

I'd love to hear from someone who owns one of the Analogue systems.

Also this made me straight up squee, and I am not prone to squee-ing.

https://www.analogue.co/pocket/

I admit I really struggle to understand what that hardware is doing. It's like a... blank slate chip?

That people program to behave like the actual hardware?

No Saturn support in the works though, but if anyone has the new "tube" Shield TV, I'd be curious if it can run Saturn emulators. My regular Shield TV can, but it's not really travel friendly. Apparently the tube only runs 32-bit apps, so I'm curious if that will matter (no Dolphin).

I have the Super Nt and I love it. It made sense for me because I have 60-70 actually SNES carts. The main drawback with it so far is that it is only for SNES games even with the jailbroken firmware. I really wish it could run NES ROMs or carts with an adapter.

I have been looking into MISTer stuff and I am totally wanting to build an arcade cabinet using it. The project seems to be very active right now. I have been looking for some of the components though and it isn't always clear where you can get them from. The main FPGA board is on Amazon, but many places that sell the RAM upgrade are out of stock.