Not only am I always impressed by Dolphin, but by how interesting and detailed their blog posts are! If only other software projects could do the same. I don't even really play games much anymore, especially Nintendo games, but somehow I always come away with delight when I read the Dolphin progress updates and so on.
I recently wanted to play the original Paper Mario, but sadly it's not available on Switch, only Wii U. So I decided to go the emulator route. Dolphin is so good that Paper Mario runs better as a Wii U Virtual Console ROM under Dolphin than it does as an N64 ROM under Project 64.
Project 64 is pretty dated, though. Surprisingly, it looks like it's now open source, but I'm pretty sure that wasn't always the case, and it sat unimproved for several years. Someone can correct me on this, but that's my understanding. (that isn't to say there wasn't a time where PJ64 was hands down the best N64 emulator)
Mupen64plus, in my experience, has been far superior to PJ64 for a long time. These days the emulators have come along enough that the differences can be somewhat trivial, but a decade ago Mupen64plus ran better for me on lower-end hardware and had way fewer idiosyncrasies than PJ64.
I feel like that makes a lot of sense. You're getting the N64 emulation for free from Nintendo there. Of course, Dolphin has to be good enough to emulate the emulator correctly, but somehow seems easier than emulating a complex native GC/Wii game.
I'm not sure how it works technically under the hood. I got Paper Mario as a ".wad" file instead of the normal .iso that you see for GC/Wii/WiiU games, and Dolphin was able to load the .wad file.
Ah, you are probably right, my mistake. Unfortunately I can't edit my original comment now. I was under the impression it was a Wii U file since I downloaded it from a reddit link I found that said it was a Wii U Virtual Console title. But, doing some research it was also released for the original Wii VC at some point, so it's likely that's where the file came from.
My understanding is that `wad`s are specifically for the Wii (and Google seems to back me up on that), so regardless of where they got it from the fact that it was a `wad` means they were playing the Wii version. If it was an actual Wii U version it would be some other format.
> 5.0-14120 - Fix Out of Bounds Texture Coordinate Behavior
> More surprisingly, the originally intended effect is never shown on console either! Players have instead been seeing a different kind of blur effect created by this undefined behavior. In all likelihood, this bug went unnoticed by developers because the effect they achieved looked pretty good and they simply didn't realize that anything was wrong. While implementing the undefined behavior in Dolphin, pokechu22 also fixed Nintendo's bug so that we could see what could have been.
Nah, it looks wrong with the original "bug" fixed—it's supposed to look like a painting! The developers may or may not have known what happened, but I bet if not for the quirk they would have gone with something else entirely.
And it's fraught with problems if the Dolphin team were to use any of the information from those Nintendo links that they can't prove they determined/discovered/developed independently. Most emulator developers are avoiding those even if there might be useful documentation in there. These blogposts are informative as hell but they also do the job of covering their asses by showing their original work.
>This was thankfully a lot less strict than on iOS devices, which strictly forbid mapping memory as executable whatsoever and made iOS untenable for us to officially support. Apple even provides documentation for helping developers port JITs to macOS on ARM. Skyler used a method described in the documentation that would change the mapped memory between Writeable when emitting code to Executable when executing code. Since Dolphin wasn't designed for this, there were a few hiccups along the way, but eventually everything was massaged into working with the new restrictions.
How expensive is changing memory mapping modes? Does it involve a system call? Does it need to happen often?
It's just an mprotect(2) call to change the page from R+W to R+X. It needs to happen between the JIT being done creating a hunk of code and the first execution. Basically: allocate a page, write generated machine code to the page, change page to executable, patch page in (so the code gets invoked instead of either interpretation or a baseline compiler).
I'm sure you can be smarter about it and involve locks such that you track how full "code pages" are and switch non-full pages back to writeable in order to update their content.
it's possible the old mprotect call will work if you use the appropriate initial mmap flag to get a jit region, but I would be surprised. The rules for rwx regions are already very restrictive compared to mmap/mprotect/etc APIs on other platforms.
I don't have an M1 Mac to test myself, but the "faster" mechanism doesn't involve anything in the pagetables, so I think toggling pagetable walks into the existing restrictions on RWX allocations.
I haven’t tested on a Mac recently, but I’m pretty sure that mprotect will change the base page permissions but SPRR will continue to apply (and you’ll need to call pthread_jit_write_protect_np).
Changing memory modes on osx/m1 is cheap, it doesn’t involve a syscall, and it has to happen any time you want to make a change to generated code (unless you do code on a separate thread from execution)
Yeah, they are wizards. I love reading emulator source code. It's helped me have a better understanding of electronics. I still don't know anywhere near enough though...
Wii U keeps the original Wii/Gamecube GPU. It has another chip behind it that scales it to HDMI.
This is also why Wii 240p doesn't work on the Wii U. Instead old VC games will be a slightly blurry 480p at best.
If you want the clearest 480p, the original Wii will do. With component cables and a compatible TV, it should be just as clear as DreamCast VGA.
[Edit: seems like you're talking about Dolphin. flatiron upthread mentioned a Wii U so that's what the question you replied to is about.]
Wii U's max HDMI output is 1080p. Also I have not seen any information that it does upscaling at all, so if you have a source for that, I'd like to know it.
> Many games work in 16:9 widescreen also (Gamecube was originally 4:3).
There are a handful of GameCube titles that were 16:9 native widescreen on the original console. The one that comes to mind for me is Serious Sam: The Next Encounter
F-Zero GX has a widescreen option as well. It's probably one of the better looking games when you can pump it at 1080p or higher, but I don't think a Pi is quite ready for that level of abuse yet. Maybe another 2-3 generations of new Pi hardware.
Not as such, but there are a lot of YouTube videos where people test a series of games on a particular phone. There are some general rules though. Snapdragon always outperforms other platforms of a particular generation due to driver issues. More popular games like Mario and Zelda will run better because they get more developer attention. There are multiple forks with different goals, eg, Dolphin MMJR has much higher performance than official Dolphin at the cost of stability and accuracy.
Snapdragon 845 is the entry level where you can play maybe 50 percent of games at full speed, and a few at full speed and higher than native resolution. If you want to run at double or triple native gamecube resolution I'd recommend at least an 865.
Also keep in mind some phones like Pixels disable video out. Get an HDMI+PD adapter to keep your phone charged while outputting to a TV. If your phone's USB port is limited to USB 2.0 speeds you'll have to get a DisplayLink adapter.
If you have specific games in mind you can often find comparable test results for similar hardware on the game's wiki page. https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Z... (you can click "expand" to get a ton more results but they may be on very old versions and not representative of current performance).
The Raspberry Pi 4 is on the order of 10 - 20X more powerful than the Gamecube's 20 year old, single core ~400 Mhz 32-bit CPU. The GPU is a bit more difficult to compare, but I'd guess a well optimised emulator with JIT/code translation ought to run very well on Pi 4 hardware.
It actually struggles to hit 30 FPS in most GC titles still. Accurate emulation between vastly different platform stacks generally does not care about the raw performance ratio rather how "lucky" some of the hardware functionality can be efficiently mapped.
Yes, in terms of Dolphin's performance today, I don't doubt it. There are probably many more optimisations that can be made: Dolphin's AArch64 JIT is still pretty incomplete and inefficient compared to the x86-64 JIT, for example.
My point is in theory, given enough time and effort, the Pi 4 should have more than enough power to emulate a 20-year old device. I'd argue that it's certainly not "way way too weak" as the reply above suggested.
To elaborate a bit more on the GPU peak FP32 perf:
> VideoCore VI @ 500MHz: 500 [MHz] x 2 [slice] x 4 [qpu/slice] x 4 [processor] x 2 [op/clock] = 32 Gflop/s
which is the RPi4 config.
compared to a Snapdragon 800: 147.9Gflops FP32, and that's still a very old part.
And about the Wii itself:
> With the Wii, Nintendo opted to go with an innovative control scheme, rather than to focus on processing power. It offered 12 gigaflops, which represents a 1.27x improvement over its GameCube predecessor
The margins are way too slim when counting emulation overhead.
My understanding is that the VideoCore architecture was initially designed as more of a "media codec coprocessor", and was incidentally able to grow enough matrix math throughput to be pressed into service as a GPU.
It was probably a sane technical choice for them. RPi4 is made on the same node as the Snapdragon 800 (28nm), but with a much more recent (and bigger) CPU complex, using the Cortex-A72.
The differences aren't just raw CPU and GPU power though. The GC, Wii, and Wii U had a couple different high bandwidth and low latency RAM[0] types in the GPU. The low latency and speed likely led to access patterns that are harder to emulate with a Pi's unified and relatively slow DRAM.
I figured with Rpi improvements (kernel/settings) and dolphin improvements, it was time to ask if it's going better now. Everyone seems negative (without data) here though.
It might be instructive to flip the question around: what would Nintendo sue for? For which works of authorship is Dolphin infringing the copyrights? Which Nintendo patents or trademarks does Dolphin infringe? If the angle is contributory infringement based on users running illegally copied games, how does Dolphin fail to pass the "substantial non-infringing uses" test?
The only emulator project I know of that was apparently successfully stopped by Nintendo wasn't an emulator of a Nintendo system at all. It was actually a Neo Geo Pocket emulator that had "Pokemon" in its name (for stupid reasons that are not relevant to this discussion) and was threatened for trademark infringement on that basis.
And yet, so many amazing emulator projects have been sued out of existence. Remember Bleem, the Windows program that played contemporary Playstation games? Bleem actually won the court case, but the legal costs forced them out of business.
And then there was the time Sony sued Connectix for their emulator. Sony got an injuction, and while Connectix won in appeal, they also ran out of money and closed.
Nintendo, on the other hand, focuses less on suing emualator developers and more on suing distributors of ROMS for old, unavailable titles, like LoveROM.
I'm not convinced that many emulators have been sued out of existence; do you have more examples? Over the past quarter-century, there have been countless emulators released, at least a couple dozen of which achieved considerable fame. Of the examples mentioned so far, only one (Connectix) actually hinged on an issue that was substantially related to emulation (copies of the PS1 firmware used for reverse engineering during development). The bleem! case was primarily about commercial use of screenshots, and the NGP emulator matter was about the emulator's name containing an unrelated trademark (and, to my knowledge, never actually went to court).
