> All of this just to let Dolphin play online with real Wii consoles in a game whose official servers are since long dead and whose replacement servers have a peak of only 15 concurrent online players.
Knowing there's people out that who have such absurd levels of dedication makes me so happy.
Imagine what humanity could achieve if we worked together. If robots/AI work out and we do have 100% spare time then you’d hope there would be more of this sort of thing.
Such a shame that it’ll probably just mean more inequality, at least in the short term.
> If robots/AI work out and we do have 100% spare time then you’d hope there would be more of this sort of thing.
If robots/AI work out we will need to use 100% of our spare time to work what few jobs are still available to humans so we can earn enough money to pay rent.
No, that's an example of robots/AI not working out. Yes, this means that "making robots/AI work out" is a political and economic problem, not just a technical one.
If the game is fully or even partially unplayable due to an a bug in the emulator, this really impacts the ability for future generations to experience these games, or these modes in these games.
As you said, its fantastic that people care this much.
The most interesting part to me is how often emulator development turns into discovering that the original games were doing something deeply strange but completely intentional
I’ve been decompiling for the past (almost) two years, and it’s fun to see the bugs, compiler quirks, programmer superstitions, things that coincidentally work because of compiler behavior not because of correctness, as well as the things modern tooling would have caught that 30-year old versions of GCC hadn’t gotten around to yet.
There were even things I thought I had to manually optimize in the early 2000s that the GCC optimizer was already taking care of in the mid-90s.
There's not really an exact science to it, but manually-optimised code is usually more structured/systematic to make it easier for the human author to manage the dependencies and state across the board, while automatically-optimised code is free to arrange things however it would like.
As an example of the kinds of optimisations that the best human programmers were doing before compilers took over, see Michael Abrash's Black Book: https://www.phatcode.net/res/224/files/html/index.html - you can intuit how a human might organise their code to make the most of these while still keeping it maintainable.
Heh. Today I found thanks to the 9front people that some GB games used carts' sram as 'swap'.
games/gb didn't save the sram in the emulator save files, so upon restoring the snapshot and saving in the cartridge memory you got a mismatch. It got fixed really fast, the emulators are really simple plan9 C compared to anything else.
I always love reading the dolphin progress reports. They do a good job of explaining how things work and parsing it out into something easy to understand
Agreed. They've been consistently high quality for the 12 years they've been put out at this point. I'm glad they stopped trying to force them into the "monthly update" mold because so many ended up being like "April/May/June/July Update!"
Dolphin is a rare example for really smart development. Instead of it becoming ever bigger and also slower, it moved from using all 4 cores of an old machine of mine to run Metroid Prime, to using 25% of the cores, for the same game a few years later, just by being smarter (much smarter) about JIT and emulation. The efficiency improvement was an outstanding achievement. Whenever I read about emulators, I am reminded of this.
On the topic of Dolphin progress reports, one of the people who author them has written an interesting blog post on the state of open source emulators and the kind of community problems they deal with: https://emucross.com/rethinking-open-source/
TL;DR if you open source a project prone to hype before you are established with a community, identity, and results to speak for, you risk entitled and uninformed users demanding more than you can deliver. Others may take your half-baked feature branches and release them (to fanfare from users who were able to use it with the exact one game it worked with), taking your credit.
Running these projects ain't easy and the Dolphin team deserves a lot of credit for doing it with a level of professionalism I'm sure many in here don't even see at work. The social work involved in this kind of project should not be taken for granted either.
It's got to be a major struggle maintaining motivation in the face of aggressive and ungrateful users. It's bad enough when they're giving you money, it must be much worse when they're not.
As far as I know it is mostly more immature emulators that struggle with straight out "stolen work" - something tells me the triforce branch is more a matter of "let's get triforce to work and then we can get it working well with the main branch again afterwards"
In the discussion of the Triforce arcade compatibility, there's some discussion of "IC Card" support needing to be implemented, and doing so unlocking a lot of missing functionality.
I think this is referring to the Japanese rail payment cards? I know you can use them on things like vending machines, but from the article it seems like the Triforce cabinets let you save game progress on them too, which would be a great feature I've never seen in US arcades.
> Triforce games can support two types of cards for saving: Magnetic Cards (magcards) and Integrated Circuit (IC) cards. Magcards are cheaper, fragile, and can only survive so many writes before failing. They have the added bonus of having a printable side, where the game can print a player's achievements and more. IC cards are more like old credit cards with a thicker plastic. They weren't printable, but were much sturdier.
It's referring to memory cards. This is the Triforce feature, almost every game on it uses cards for savegames. The arcades you're thinking of almost certainly had a version of Mario Kart Arcade GP - you may just not have played it.
It exists in US arcades. It's a similar concept as an AIME card which you use to authenticate when playing maimai, chunithm, dance dance revolution, dance around, beat mania, etc. Triforce IC cards store data instead of just being for authentication.
> Thankfully, the game's community narrowed down the issue and eventually found that the fnmsubs CPU instruction was implemented incorrectly in Dolphin's JIT but worked correctly in our interpreter.
Sounds like a good opportunity for differential fuzzing!
Dolphin is bringing back support for the Triforce arcade cabinet that was jointly developed by Nintendo, Sega and Namco that was dropped by Dolphin in 2016.
Notably games includes F-Zero AX (not to be confused with F-Zero GX on Gamecube) and Mario Kart Arcade GP 1 and 2.
Though I don't know if you can count it as a "buried lede" if the first paragraph of the article is dedicated to it, with a big clickable banner, haha!
Nintendo's lawsuits they won against emulator projects in the past had donation systems as one of, if not the sole main point they drove to win the case.
FWIW, while Dolphin doesn't accept donations, the non-profit foundation behind it has been collecting money for almost 15 years via ads and referrals. All of the financials are transparent: https://opencollective.com/dolphin-emu
From a practical perspective, they "won" in their recent attacks on emulation by shutting big projects down, but we can't know what would have happened at trial because they never got that far.
NoA sued the Yuzu devs and settled out of court, with the devs paying $2.4 million and shutting down the Yuzu and Citra projects. The $2.4 million was noted as being a reasonable estimate of what Nintendo's lawyers would have billed if the case went to trial, not a reflection of Yuzu's collection of donations.
NoA used some combination of carrot-and-stick to get the Ryujinx developers to shut that project down as well, but we won't know what that combination was because they never filed a lawsuit, so there are no public records, and there was likely an NDA.
I suspect you would quickly attract a lot of the wrong kind of “developers” the moment a financial reward appeared. Especially now that it’s so easy to use AI to make something that looks slightly plausible.
Although I suspect the other sibling comment is the real reason.
What is the most reliable place for ROMs these days? Is there any sort of checksum that can accompany them to ensure safety? While I trust Dolphin, I don't trust most ROMs.
In all my years of emulation, I've never come across a malicious ROM for a major console.
Dolphin runs its own VM. Obviously anything is possible, but developing some kind of breakout-ROM which would infect the host machine is just way more engineering than I could imagine ever being worth it. The vector is just too complex, and the target (nerds downloading retro games) just isn't worth the squeeze.
Archive.org actually hosts a good chunk of the major Gamecube ROMs. Good luck!
There's tons of options, no-intro, redump, tosec, mame are all doing DAT files with file checksums.
That said, ROMs are basically never a malware vector as they have to exploit an issue in the emulators themselves and historically that hasn't really been seen. Typically malware related to roms happens with files included in the zip archives or by sites offering "downloaders" with embedded malware.
I've had pretty good success with CleanRip https://wiibrew.org/wiki/CleanRip#Wii_DAT_download for acquiring ROM files. With it, I was able to backup my entire personal collection with minimal fuss, and can now enjoy that collection in HD with Dolphin's various enhancements.
For verification you generally want the Redump database, which has checksums for most disc-based console releases. Unfortunately they seem to be offline at the moment, or I'd share a canonical link. Look around for that.
It's been done, the ZSNES and Project64 emulators have both had exploits which allowed a malicious ROM to run arbitrary code on the host. ZSNES is written mostly in assembly so that was kinda asking for trouble though.