> I did some research and this seems to be an original idea. Why hasn’t anyone tired this before?
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.
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.)
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?
Well, having a game under emulation gives you more control over what you can do, certainly. You now control the software and hardware. But I think most people also don't want to make enhancements that only work on a single emulator. And getting emulator authors to cooperate is like herding cats (which is why we are still using the woefully inadequate iNES header format in 2014.) So I could have made MSU1 run some 1080p video mode with a 2GHz simulated x86 processor, but it was important to me that the protocol be as simple as possible and exist in a physical implementation that worked on the real system.
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.
There is a PC remake which follows similar approach: Abadia Del Crimen [1].
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.
No, that translation was completed before I started on my emulator.
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.
I just thought of that because I remember reading how they couldn't fit everything into the ROM. Everything in that game was compressed and they couldn't find any extra room and it had to rely on an external graphics pack with emulator support is how I remember it.
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.
Fascinating history, thanks. The one who translated M3... that would be Tomato, right? I found out he had the same assembly language professor I did (Lance), albeit several years apart.
I know :) I spent quite a while waiting for M3 to be translated after having so many fond memories of Earthbound. He had a blog of his progress going, detailing all the issues he was having with the hack and we chatted there in the comments quite a bit.
The N64 emulation scene has been doing this for quite a while. There's several finished retextures of N64 games like Djipi's Zelda: Ocarina of Time retexture, bringing a cel-shaded look to the game https://www.youtube.com/watch?v=lnYyK3vflb4.
Very interesting concept. The least daunting way to "remake" a game in this way could be something like changing the color palette per level, kind of like how the Super Game Boy does to some Game Boy games; an effect reminiscent of the color filters used in Nosferatu.
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.
I'm not sure I understand your thoughts about "better art". My idea is to reuse the game logic with entirely new art - with a better artist, as you say. But MISE falls exectly into this category - completely new art, not done by technical means (even if you don't personally like it).
My point is that "better art" could as well be achieved by replacing the original art without modifying the game code or hooking it into an emulator, sticking to the original restrictions. I don't think that the process described in the article necessarily facilitates the possibility of "better art".
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.
Fan patches for various games can go pretty far in this direction too. For example here is one guy making a D3D10 renderer for Unreal (the original one): http://kentie.net/article/d3d10drv/
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.
That's very interesting! However, by injecting your code at that level you can draw prettier polygons but still the same number of polygons as before, right? For these cases I was thinking hooking at a higher level (the "render model" method vs the "render triangle" method), for the things you can't do at the driver level.
I haven't delved in game reverse engineering in depth, but I'd imagine that most games would handle 3d models (and textures) in a fairly opaque blob manner which quite naturally allows upgrading them without code change if the rendering engine is capable of handling increased load. So instead of upgrading the data on the fly you would replace the data files with upgraded ones.
this is way cool. I wonder if there's an easier way to find those entry points. For videoram for instance, isn't it possible to set a break point on a write to some spot in vram, and then dump stack at that point- one of the functions on the stack is going to be your "draw tile" function, no?
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!
Yeah, this is really cool and the poster did a great job of writing it up and making everything available.
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.
About the legality, for "totally new art", sure, but if I play an X-Wing remake I want Darth Vader to look like Darth Vader... and as you say, a higher-res Darth Vader would probably infringe something.
Yes, I was thinking of adding "pixel breakpoints" (a specialized form of the regular memory watches, with some logic to convert pixel coordinates to VRAM). I didn't get around to actually doing it, but I did add a command to fill the VRAM with random data, so I could stop before a CALL, random the VRAM, execute the CALL, and see what that particular routine was doing.
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.
Any machine that draws without a framebuffer (NES, C64, Atari 2600) would be pretty complex if you'd have to manually handle these timings.
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.
Minor correction, the C64 does frame buffering. Timing and accuracy is still a major concern for all these platforms, though (especially the 2600, where even horizontal sprite positioning is based on the relative speeds of the pixel clock and the CPU).
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.
Sorry, I should have been more accurate. I was indeed trying to refer to all the crazy raster-level tricks that people would do, to multiplex sprites, change palettes, etc
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.
Unfortunately, applying an effect separately to sprites versus background layers isn't as useful as it sounds; a lot of games use non-animated sprites to touch up the grid-like nature of background tiles (so treating them separately would look weird), or use multiple sprites to make up a larger character (so treating sprites individually would look weird). I think one of the NES MegaMan games even has a boss battle where the boss is actually a background, and the platforms MegaMan stands on are sprites.
Excellent proof-of-concept. I want to say Nintendo had a patent that implied something like this for the Wii Virtual Console, but they never delivered on it.
Anyone have any idea if Christian Whitehead's Retro Engine[1] (used in the recent Sonic 1/2/CD remakes) does something like this?
The Sonic 1/2/CD remakes were actually done from scratch in his Retro Engine (which is just a regular game engine that focuses on Retro-style 2D games). They aren't emulator-backed or anything.
I've been thinking about doing the same thing with X-Wing. My goal is to build a control panel for the game with levers and switches, and indicator lights for power levels and status, and video screens for radar and craft identification. After that, I'd replace the cockpit window display with a high resolution screen and more detailed models.
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.
In the OpenPandora (and other F/OSS gaming console) scenes, there is already a bit of this going on to a degree - for example, MAME and NES emulators have different rendering modes that can be configured to make the graphics less pixelated and more vector'ized, giving a new and appealing boost to the look and feel of the older games. This has definitely been advantageous - my kids don't like to play "those games where you can always see the pixels", but when I turn on smooth-render/vector mode, they're like "oh, that's much better, now we can play Mario Bros!" ..
I think the first place I saw this technique used was in EmuDX, which had swapped-out graphics for Pac-Man, Ms. Pac Man, Galaxian, Frogger, and Donkey Kong. This was around 1999 or 2000. Its site no longer exists, but here's a mirror: http://www.arcadeathome.com/emudx.phtml.
I was always sad it never really caught on, I think it's a great way to revitalize old games while preserving gameplay.
I first saw this type of thing with http://www.manfreda.org/i-robot John Manfreda's I,Robot emulator where he takes parameters sent to the Atari mathbox/rasterizer and sends them to D3D instead. This gets you classic I,Robot with much higher resolution for the polygons.
It's not exactly new. I remember a thing from the 90s that was basically a specialized Pac-Man emulator, but hooked the graphics routines in the ROM and displayed its own, higher color depth graphics instead. It is a cool way to get gameplay fidelity with enhanced graphics and sound though.
I'd classify that as a "new edition"... since they own the code and assets, I'd suppose they just rewrote the bindings between the old game logic and the new game engine, not that they patched it at the binary level.
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.