Show HN: Emulator-Backed Remakes, a new way to make classic game remakes
gabrielgambetta.com
gabrielgambetta.com
I've done it. Making the emulator, debugger, and hooks to extend games is the easy part. The really hard part is getting people to then go back and enhance games.
In my case, I created some new I/O registers for the SNES. One set is called MSU1, which lets you read in up to 4GB from a data file, and also lets you mix in CD-quality audio (which you can use for voice acting, or replacing audio tracks while keeping sound effects.) Particularly nice about the MSU1, was that it was designed to be possible on real hardware. And a flash cart called sd2snes implements it.
Here's an example of Legend of Zelda: A Link to the Past with a remastered audio soundtrack: https://www.youtube.com/watch?v=HnAg2T7d6uU
And here's an example where the Playstation full-motion video intro was inserted into the SNES version: https://www.youtube.com/watch?v=Gn_jXf7FHGA (yes, that full motion video really is possible on a real SNES.)
Not an enhancement, but d4s ported Road Blaster (a full FMV game) to the SNES, even: https://www.youtube.com/watch?v=THJvsIezXrQ
Another I/O register set I put in place was called HSU1. This one lets your SNES game send and receive network packets. I've used it to implement a high-score leaderboard in Campus Challenge '92 and Powerfest '94. You play the game in the emulator, and your score shows up on a website. But it's bi-directional. You could take this concept a lot further, with dynamic content in games, special events on certain days, etc.
I've also toyed with adding rumble support to the controllers. Although I was beaten to the punch there by some patches a guy made for the Xbox port of ZSNES a few years prior.
Lastly, in our community, we have some pretty sophisticated OpenGL pixel shaders. One person implemented a real-time map display of Super Metroid where the shader read in the player position from the SNES' RAM. You could utilize that concept to show any kind of additional information to the player.
I really had no idea any of this existed before writing mine, and so far people have pointed out several instances of this applied to consoles (which I haven't explored at all), but none about PC games. I wonder why is this? Do consoles have higher-level APIs you can hook into that makes this more reusable across games - more similar to adding hooks to a game engine vs an individual game in the PC world?
More along the lines of your example, my emulator core is completely abstracted to its own library and is GPL, so it would be quite easy to hook routines as you have to do things like hires textures even on the SNES. But there are some more extreme challenges to that than just identifying key functions, as the SNES renderer is very elaborate.
I can't say I've specifically enhanced PC games, but I've definitely worked on translations of them from Japanese to English. There's definitely lots of fun tricks you can do outside of emulation, still. I usually write a debug process launcher that uses DLL injection, which is then followed by installing trampolines in various functions.
We worked on a game called Heroine Anthem, where the movie file format was entirely custom. So we ripped the movie with screen capture software, subtitled it, encoded it to XviD (this was a while ago), and then ran our own DirectShow window to play back the movie in place of the originals.
We also patched an online multiplayer game, Fuurai no Shiren, to add a new dialog to configure the server you connect to. We reverse engineered their protocol (their "encryption" was a strtr function on streams of hex values. Quite laughable.) and then created our own PHP server, called OpenShiren, so that people could run their own instances. Especially useful once Chunsoft shut their servers down.
I've done far, far crazier things with manipulating others' applications, but since they weren't games, I won't elaborate on those here.
The author worked with the original binary to maintain the original logic of the game. The game first was converted from CGA to VGA and then he wrote a translator to covert the the original 16bit DOS code to 32 bit Windows with DirectDraw and DirectSound using only assembler all the time.
Was this what was used for the Star Ocean translation? I seem to recall that the translation hack for that was quite complex.
Star Ocean has the SDD1 for graphics decompression and memory mapping, but I wouldn't say it was technically more difficult to translate than other SNES RPGs.
Star Ocean was a 48mbit (6MiB) game, which was tied with Tales of Phantasia for the largest game ever officially released. But Star Ocean took things further than ToP, by using the SDD1 to allow DMA to transparently decompress data read from the ROM. The compression wasn't stellar in terms of size reduction, but it was wonderful in terms of having no CPU impact, as the SNES was a very slow CPU.
The issue was that it was a really weird compression format. It uses golomb codes and prediction. So the ZSNES/Snes9X teams took a shortcut: they logged every time a DMA from ROM occurred with the SDD1 decompression flag set. Then John Weidman ran the same DMA transfers through his custom setup on real hardware and dumped the decompressed data to files. They packed that together and that's what was called a "graphics pack". The emulators then simply grabbed that already decompressed data. Think of it like using a giant 1000x1000 multiplication table instead of just learning how to multiply yourself.
When it comes to translation, this wasn't any kind of a problem. If you needed to modify one of these graphics, you could bypass the SDD1 and transfer it as normal tile data. But for the most part, fonts and text weren't compressed in this way anyway.
Eventually, Andreas Naive cracked the compression algorithm, and emulators today actually decompress the data without graphics packs.
On that note, the same thing was done for the SPC7110 (used by Far East of Eden Zero), which took many years longer than the SDD1 to crack. Since that was cracked a while after the final release of ZSNES, they still need those graphics packs there.
Now let's talk about the size: yes, Star Ocean was big. But space has never really been a limitation for SNES fan translations. Even without a memory mapper, it's very easy to fit around 96mbit (12MiB) of ROM data into the available memory map. You could very, very easily do 64mbit (8MiB) without any effort at all. It's honestly a bit of a mystery why some of the SNES coprocessors had any MMCs (memory mappers) at all, as they were wholly unnecessary.
That said, you will often hear certain SNES fan translators mention the lack of space in games. And I will never understand it. They seem to want to enforce an artificial limitation on themselves to fit their entire translation back into the original game space; often sacrificing script fidelity, using stronger compressions that hinder game performance, etc. It really makes no sense to me. Yet the person who hacked Star Ocean was one such individual.
If you want a fun anecdote about Star Ocean: I was the first to hack the game for an English fan translation, and was working with the person who ultimately translated the script. Unfortunately, I was an ignorant 14 year old kid and freaked out on him when I found out his translations weren't 100% literal (which in retrospect would have made for a terrible script), so he rightly told me to go fuck off. I eventually grew up, and we worked together much later on to produce the Mother 3 fan translation. But it's too bad, I would have really liked to have finished Star Ocean myself, but I wasn't mature enough to work with other people back then.
Here's where most of the development happens: http://www.emutalk.net/forums/110-N64-Textures
https://www.youtube.com/watch?v=CGpTfb8HUCY&list=UUs-pFQ5_s3...
I'm sort of opposed to the idea of "better art" as something that can be achieved on a technical level, though, especially considering the example used in the article (Monkey Island SE), which I personally think looks a lot worse than the original game. If you want better art you need a better artist.
On a technical level, the possibly increased resolution and color depth that can be achieved using this method will certainly impose less limitations on the artist in exactly those terms, but in my opinion that doesn't necessarily mean that they will make it easier to produce good art.
On the other hand, it doesn't mean it's easier to produce good art; the idea is that it makes it possible to modify the art at all. This is supposed to be used for games where you don't have the source code.
Sure they usually do not employ emulators, but still often afaik they place themselves between the game and the API, translating it to something more modern in passing.
and how do you deal with the somewhat more complicated NES games where "sprites" are often constructed of multiple conjoined hardware sprites? there's no "draw sprite" method there, it's just manipulating x,y registers in obj ram!
His bit on the legality of this sort of thing when done without permission should be ignored, though (to be fair, he does offer the standard IANAL disclaimer). If you made graphics/sound/music that were totally unique, you'd be fine, but if you made higher resolution versions of what already existed that is clearly a derivative work and puts you in copyright violation trouble, if the copyright owner cares to go after you.
Also, as you mentioned this method wouldn't work that great for all platforms; basically any older console or older console-like computer (eg. Amiga, Atari ST) tends to have much more complicated interplay between the graphics being drawn and the hardware (real or emulated) in terms of timing (eg. to vsync/vblank), having the graphics actually be low-level commands to a coprocessor, etc. Once you get to the PC era where games are generally using a relatively straightforward memcpy-type bitblt you're fine, but before that all bets are off, at the very least the code you are patching in is likely to be much more complex and fragile, if it could be made to work at all.
NES - no idea, I've only done ZX Spectrum and PC. But you should still be able to read the emulated RAM and make a new renderer from that data.
However, in the NES example you could perhaps embed a NES emulator and hook into its drawing code instead. But that does mean that the emulator itself doesn't introduce any glitches or flaws of its own, of course. At least you'd be able to get some decent timing information from the emulator to properly handle sprite multiplexing and whatnot.
For a platform that doesn't quite viciously depend on perfect timing (or some of the simpler NES and C64 games), say like the MSX, the concept of sprites and tiles could instead be a very useful abstraction for this kind of remake. No need to deeply examine the code; just capture VRAM and video register writes.
You wouldn't want to apply it to the entire screen, but rather to individual sprites and background images separately. The design of the graphics hardware on the NES and SNES should make that mostly possible for the majority of games.
Anyone have any idea if Christian Whitehead's Retro Engine[1] (used in the recent Sonic 1/2/CD remakes) does something like this?
I worked on this for about a month before I dropped it for other side projects. I ran the Windows version of X-Wing and used a utility called Cheat Engine. I found the locations in memory for the throttle, power settings, laser and shield power levels, remaining torpedoes, etc. My next step would be learning how to do DLL injection, and using a debugger to find a good place to inject code.
I wouldn't have to do any of this if LucasArts would release remakes of X-Wing and TIE Fighter that supported custom controls and displays, or open source the old code. But the market for that is small, and now they might have to coordinate with EA since they granted them the license to make Star Wars games.
We're obviously from the same country. Have we met before?
I was always sad it never really caught on, I think it's a great way to revitalize old games while preserving gameplay.