'Legend of Zelda: A Link to the Past' Reverse-Engineered for Linux, Switch, Mac, and Windows (neowin.net) 41
More than 30 years ago Nintendo released the third game in its Legend of Zelda series — appropriately titled, "A Link to the Past."
This week Neowin called it "one of the most beloved video games of all time," reporting that it's now been reverse-engineered by a GitHub user named Snesrev, "opening up the possibility of Link to the Past on other platforms, like Sega's 32X or the Sony Playstation." This reimplementation of Link to the Past is written in C and contains an astonishing 80,000 lines of code. This version is also content complete, with all the same levels, enemies, and puzzles that fans of the original game will remember.
In its current state, the game requires the PPU and DSP libraries from LakeSNES, a fast SNES emulator with a number of speed optimizations that make the game run faster and smoother than ever before. Breaking from the LakeSNES dependency, which allows for compatibility on modern operating systems, would allow the code to be built for retro hardware. It also offers one of the craziest features I have seen in a long time; the game can run the original machine code alongside the reverse-engineered C implementation. This works by creating a save-state on both versions of the game after every frame of gameplay, comparing their state and proving that the reimplementation works.... Snesrev now works alongside 19 other contributors.
Despite the immense amount of work that went into this project, the result is brilliant. Not only does the game play just like the original, it also includes a number of new features that were not present in the original. For example, the game now supports pixel shaders, which allow for even more stunning visuals. It also supports widescreen aspect-ratios, giving players a wider field of view, making the game even more immersive on modern displays. Another new feature of this reimplementation is the higher quality world map. The new map is much more detailed and gives players a better sense of the world they are exploring....
The amount of time, effort, and talent that went into creating this is simply astonishing.
Thanks to Slashdot reader segaboy81 for sharing the article.
This week Neowin called it "one of the most beloved video games of all time," reporting that it's now been reverse-engineered by a GitHub user named Snesrev, "opening up the possibility of Link to the Past on other platforms, like Sega's 32X or the Sony Playstation." This reimplementation of Link to the Past is written in C and contains an astonishing 80,000 lines of code. This version is also content complete, with all the same levels, enemies, and puzzles that fans of the original game will remember.
In its current state, the game requires the PPU and DSP libraries from LakeSNES, a fast SNES emulator with a number of speed optimizations that make the game run faster and smoother than ever before. Breaking from the LakeSNES dependency, which allows for compatibility on modern operating systems, would allow the code to be built for retro hardware. It also offers one of the craziest features I have seen in a long time; the game can run the original machine code alongside the reverse-engineered C implementation. This works by creating a save-state on both versions of the game after every frame of gameplay, comparing their state and proving that the reimplementation works.... Snesrev now works alongside 19 other contributors.
Despite the immense amount of work that went into this project, the result is brilliant. Not only does the game play just like the original, it also includes a number of new features that were not present in the original. For example, the game now supports pixel shaders, which allow for even more stunning visuals. It also supports widescreen aspect-ratios, giving players a wider field of view, making the game even more immersive on modern displays. Another new feature of this reimplementation is the higher quality world map. The new map is much more detailed and gives players a better sense of the world they are exploring....
The amount of time, effort, and talent that went into creating this is simply astonishing.
Thanks to Slashdot reader segaboy81 for sharing the article.
And it's gone (Score:1)
This will get taken down so fast you won't know what happened.
It's almost certainly made from decompiled original code. Nintendo gonna set fire to yo ass.
Re:And it's gone (Score:5, Informative)
The Ars article mentions this at the end;
While projects based on a Nintendo property are often killed by legal threats just as they come to attention, this reverse-engineered project, which specifically makes no use of any original game assets, has a good chance of staying alive. Reverse-engineered code for Grand Theft Auto III and Vice City remains online after Github agreed to a Digital Millennium Copyright Act counterclaim. Courts have previously struck down reverse-engineering-based projects based on end-user license agreements (EULAs). But fully decoupled projects from the likes of the Zelda Reverse Engineering Team march on, giving hope that even more games get their shot at modern tuning.
https://arstechnica.com/gaming... [arstechnica.com]
Re: (Score:2)
It says it's reverse engineered, that leaves a lot of room for interpretation. Nintendo absolutely could make a stink about it but it's certainly not a slam dunk like hosting a ROM or even a traditional port of the original code.
I certainly don't put it past them to just be dicks about it htough.
Re: (Score:2)
Well, I just cloned the repository and built it. It certainly doesn't contain the ROM, but it certainly does require the ROM, for those assets.
Part of the build process requires two python scripts to be run, one to extract resources from the ROM, and another to compile them.
Anyways, I'm impressed, this is everything the story claims it to be. regardless of the stink Nintendo may or may not kick up, it's legitimately cool. =)
Re: (Score:3)
Python? Ugh... If that's the level of competence we're dealing with, I'm not interested.
You're annoyed because python is part of the build process?
The other 93% of the repo is C, according to their Github stats.
https://github.com/snesrev/zel... [github.com]
Re: (Score:1)
Python is trash, there's reason to be annoyed.
Re: And it's gone (Score:1)
Re: (Score:2)
II know right?
I shouldn't continue to be shocked by this sort of thing, but it's funny to me that the thing I was actually responding to was the discussion about whether or not Nintendo owned assets were being used. And in this case, they clearly are.
So, we go from.. "confirmed, Nintendo assets are required to build, for now anyway, but they are not included with the source", to fixating on the fact that python is used...
anyway, why do we hate python? I don't really work with it, but as far as I can tell,
Re: (Score:3)
why do we hate python? I don't really work with it, but as far as I can tell, it's pretty solid. is this because it doesn't use braces?
That's one reason, but the piss-poor performance and the total botch of the move from 2 to 3 are also reasons.
Re: (Score:2)
Re: (Score:2)
It extracts the assets from a cartage dump... So hell yes its using the game assets like artwork !
There's a BIG difference between "hosting the assets of the game in GitHub" and having to "run a script to extract the assets at build time from the original ROM". So yes, technically the final product uses the original game's assets, but those assets must be provided by YOU from an original ROM. There is no copyright violation here because the repo on GitHub has zero assets from the original ROM hosted there.
Re: (Score:2)
If they used a clean room design to reverse engineer it, it would technically be legal. Doubt that would stop Nintendo and their lawyers, but would be legal.
Re:Something strange about this article (Score:5, Informative)
Sometimes there were also errors that you wouldn't have noticed, but were there. In Zelda Link to The Past, during the intro scene, the Tri-Force would actually spin more times that it should on real hardware.
Things like LakeSNES won't do these hacks and work-arounds for games, making them "run faster and smoother than ever before".
A reddit post (https://www.reddit.com/r/RetroArch/comments/on9x93/comment/h5qhss7/?utm_source=share&utm_medium=web2x&context=3) best explains it as:
"SNES9X was designed to be an emulator that focused on maximum library compatibility with moderate PC hardware. While it allowed users to use weaker hardware (like 350 Mhz Pentium II processor with 256 MB of RAM) at the cost of execution accuracy by utilizing some shortcuts that can cause some unintended randomness or glitches in games, but is "close enough" for most users. There can also be some incompatibility with some SNES games that utilize some more niche chips or complex game code that the emulator may not properly handle consistently (giving some graphical glitches or something), but the majority of games will work just fine (hitting like 97.000 - 99.999% compatibility -- You can see a list of some issues at https://github.com/snes9xgit/snes9x/issues/53 as an example). Such types of emulators (which includes ZSNES, which is the common alternative to SNES9X) are typically popular options since they provide a lot of options & features while being accessible to most hardware. This "Good Enough" approach is why this emulator has become prominent & effectively the "Gold Standard" for SNES emulators.
BSNES (& Higan) was designed to be a "cycle accurate" emulator that tries to mimic the SNES hardware as closely as possible without any shortcuts. While this provides a more consistent experience between users, it comes at the cost of extremely high system requirements. The first release version of BSNES required a 4.0 Ghz processor, but later releases may have been able to reduce this requirement while the mainstream processors caught up a bit. The upshot is that it the emulator hits the magical 100% compatibility rating with the SNES & Famicom library. Due to the high requirements, it becomes the "Platinum Standard" for SNES emulators as it blurs the line between software & hardware execution... which only the purists would want."
Re: (Score:1)
ZSnes and Snes9x had to use hacks and work-arounds to get many games to run "as fast as native SNES hardware" though.
...On your 486. A naive implementation in JavaScript can run any game "as fast as native SNES hardware" because computers aren't slow as fuck like they were 25 years ago.
BSNES (& Higan) are just poorly written. I've seen a lot of emulator code. It's not always written by the best and brightest.
Remember kids: If it's hard to follow, it's probably not because it's super complicated. Odds are good that the person writing it was just really stupid.
Re: (Score:2)
The thing that is confusing to me is that LakeSNES describes itself as, even when rewritten in C, as 'Performance, although much better than my JS version, is still quite bad though, especially when compared to emulators like BSNES '.
So if it's even slower than bsnes, what is it about it that would call for "faster and smoother than ever before"?
LakeSNES may make for an interesting project, and I think even the primary authors represent it for what it is, but I think someone is getting a bit carried away in
Re: (Score:2)
As a wild guess - it seems like good sound emulation is a difficult thing to get right for NES emulators. It's usually not until an emulator is pretty thoroughly mature that the sound starts getting accurate. I want to say it's something about a specialized audio chip that's unusually difficult to emulate on PC hardware?
Anyway, it may run code lockstep with the original - but there's no code capable of playing audio through a modern OS. A pixel buffer is a pixel buffer, but recreating the same audio on co
5 minutes and it is running flawlessly (Score:3)
Re:5 minutes and it is running flawlessly (Score:4, Interesting)
Re: (Score:2)
What about exceptions for interoperability? Basically, you're running the cartridge on alternate hardware. So what if the ROM is ripped for _temporary_ local caching to work with different hardware? That may leave open the question of just how long the ROM copy can be kept on the local hard drive, but there seems to be no question of RAM vs. local HD since most systems are going to use disk cache as memory anyway.
Re: (Score:2)
Interoperability is well defined in the copyright law, and it doesn't involve 'alternate hardware'. The exact wording is "the term “interoperability” means the ability of computer programs to exchange information, and of such programs mutually to use the information which has been exchanged."
So basically, if a program is using something like a file format or network protocol, which you have no other way of figuring out, you are allowed to reverse engineer the program so that you can figure out t
Re: (Score:2)
Interoperability is well defined in the copyright law, and it doesn't involve 'alternate hardware'. The exact wording is "the term “interoperability” means the ability of computer programs to exchange information, and of such programs mutually to use the information which has been exchanged."
Since there's absolutely nothing in copyright law or any other law that I am aware of requiring you to use any particular hardware/software to view a copyrighted work, then interoperability as defined covers that just fine.
So basically, if a program is using something like a file format or network protocol, which you have no other way of figuring out, you are allowed to reverse engineer the program so that you can figure out the format.
So, maybe you can reverse engineer the game to figure out the save file format, so that you can create another, independent, program that can create or use save files, but you can't reverse engineer the game to figure out how to get copyrighted data out of the ROMs.
Your last part there doesn't even make any sense. You can't reverse engineer the game to figure out how to get copyrighted data out of the ROMs? What does that even mean? What are you thinking you would need to reverse engineer in order to do a bytewise copy of the ROM into a file on your
Re: (Score:2)
OK, I'll bite. How does porting a game to alternate hardware allow 'mutual exchange and use of information between programs' (which is what the interoperability exception requires)?
The 'interoperability exception' applies to reverse engineering, that is all. You can reverse engineer a program (if the info is not readily available any other way) to figure out how to interoperate with it. Such reverse engineering, even for interoperability, does not permit you to otherwise violate copyright.
So I put the la
Re: (Score:2)
I'm a little confused how you would think it necessarily wouldn't Consider this as a thought experiment. You have an SNES running Super Mario world. There's a power surge and the console CPU and memory fry. You take those components from another broken SNES you keep around for parts. You play the game there, thereby porting it to different hardware. You might have violated the manufacturers warranty, but are you committing copyright infringement and is the excemption triggered?
Now, same scenario but, you ge
Re: (Score:2)
I still don't see what information you are claiming is being mutually exchanged.
What are you claiming are the two programs here, and how are they mutually exchanging information? Is the first program the console, and the second program the emulator, and the 'information' is the ROM? That doesn't make sense, because neither the console nor the emulator is creating information to be exchanged with the other.
'Interoperate' means to work in conjunction with each other. An emulator is not 'interoperating' wit
Re: (Score:2)
I still don't see what information you are claiming is being mutually exchanged.
Sorry, how are you defining "mutually exchanged", can you give some examples? In the example I provided, for example, you can have game code that is read from the ROM and the copyrighted game program runs on an emulator, the program itself and its output are input to the emulator and, simultaneously some of the outputs of the emulator are inputs to the program. So programs mutually exchanging information. So what narrow definition are you following where that isn't the case?
...neither the console nor the emulator is creating information to be exchanged with the other.
That is completely not the case.
Re: (Score:2)
The interoperability exemption (which only applies to reverse engineering of computer programs) is for situations like this. Say you have a program which creates a spreadsheet. You do not document the format of the spreadsheet file. Per the interoperability exemption, it is not a copyright violation for me to reverse engineer your program in order to figure out the file format (a file format can not be copyrighted). Then, I am allowed to create an independent program, not using any of your code, which p
Re: (Score:2)
The interoperability exemption (which only applies to reverse engineering of computer programs)...
Well, it's an exemption to copyright law, so it makes sense that it would only apply to things that are copyrighted. While a specific, fixed hardware design can theoretically be copyrighted - where it's not simply mechanically derived from basic principles - it is pretty easy to provide the same hardware experience without direct copying of the original design. So there's generally no real need for an exemption on the hardware side. Where there are copyright questions, it is important to remember that hardw
Re: (Score:2)
Same, only difference being that it builds on linux just fine.
Time to run round the side of the castle and fall into the cellar.
Re: (Score:2)
same here on Linux. I also tried the rom for Parallel Worlds, but as expected that didn't work.
I have bought the game a few times, including on the SNES mini, and on the DS3. If they released it on the switch similar to what they did with Link's awakening I'd buy it again on the day of release.
I really never got into the 3d Zelda's and keep playing the old ones and custom roms.
Re: (Score:2)
I didn't get into the other Zeldas, something about the artwork in a link to the past had appeal to me that others didn't. This and Super Mario World seemed to be 16bit at its height.
Re: (Score:2)
Actually is still 'grey' unless you happen to have the means to dump your own rom image.
"Despite" (Score:5, Insightful)
> Despite the immense amount of work that went into this project, the result is brilliant.
I don't think you know what that word means.