A Closer Look at the Super NES Doom Source Code Release [video] | Hacker News Reader

A Closer Look at the Super NES Doom Source Code Release [video]

youtube.com

95 pointszdw35 comments

Modern Vintage Gamer makes excellent videos, all are worth watching if you have any interested in the history of video game tech.

He wrote a lot of the emus for Xbox 1. Guys a lesser treasure of computing.

I'm a big fan of his videos, and he's a really great educator. But he didn't wrote those emulators (and never claimed to) - he ported existing ones.

I don't say that to reduce his contributions (hell, I did my share bit of porting code to more exotic platforms, and a proper port is tons of work), but to give credits to original authors who did most of heavy lifting of writing actual emulators.

He literally has a video titled “I wrote the Emulators and Homebrew YOU played on the Original Xbox”

https://youtu.be/x7FmelyC70Y

Don’t get wrong, I love MVG’s content, and I’m not a big gamer or even much of a YouTube viewer.

I remember playing the Bleem demo as a kid, and then a decade later thinking back and wondering "wait a minute, how was that emulation performance possible in 1999?"

And as if that wasn’t impressive enough, Randy Linden also had a copy for the Sega Dreamcast, Bleemcast, where you could boot the emulator then load a PSX game. I think they had 3 or 4 versions for Gran Turismo, Tekken and a couple of other big games. It blows my mind how talented that guy is.

Q1 2000 was the 1Ghz intel release. The PS1 had a 33MHz CPU.

Bleemcast on a 200MHz CPU is more impressive.

I still was impressed at the time for the PC version, not only for getting it to work on a PC but the amount of reverse engineering that he was able to do with zero information.

Connectix Virtual GameStaton ran on the original iMac which was 233MHz or so

I mean, whatever PC I had in 1999 was definitely already several years old and probably wasn't top of the line at the time of purchase. So it was probably closer to 200 MHz than 1GHz.

Pretty sure when Bleem came out I was still rocking the 166Mhz 64MB family computer running windows 95 or 98. If memory serves, I was able to play Crash Bandicoot at not-quite full speed.

I owned a laptop shortly after that which was somewhere in the 200mhz-400mhz range that played PS games at full speed.

Yeah, I actually owned Bleem even though I had a PlayStation. I think I still have the CD.

What gets me is how even though today we do not have totally perfect emulation of a lot of systems. Probably the closest to perfect is the byuu emulation of the SNES system. My amazement is some of this stuff still runs. I have over the years tracked down many one liner bugs in my own code. I also remember people in the alt Amiga groups arguing about perfect emulation before that system would even boot and 30GHZ computers. Yet it all still kinda worked.

The MAME guys are adding in netlist bits to get rid of those wav files they have used for years for sounds. They had to go back and re-model the circuits component by component which is obviously not great on CPU. Which is how much of it was able to run on older computers. They took massive shortcuts. If something took 500ms on the actual hardware they would do it in 30 and give the time up to something else that needed it. Whereas maybe some very oddball bit of software would rely on that 500ms. The funny thing is most dont. The other way holds true too. Those circuits emus they are adding in eat massive amounts of CPU time to calculate. But on the real hardware finish nearly instantly.

I still am amazed some of this software works. For some bits of software you do need that deep understanding. But so much of it just blts junk from one area to another and polls on the controls. When you get to those weird effect where the developer was squeezing the console/computer on scanlines and store/load boundaries you need that but so much of it just works...

For a (long) and in depth and information packed video about this from the original author (Randy Linden) in the form of an interview check out this video. https://www.youtube.com/watch?v=P5PknJvplKg

Fantastic video. For those in the industry, how does a game get ported?

Do you figure out all the constraints of the target system, fork the original, adjust, and compile? Is it an involved process? Do the original dev's (Carmack in this case) get involved or is it "second tier" sort of work?

> Do you figure out all the constraints of the target system, fork the original, adjust, and compile? Is it an involved process?

For most games, yes, but this particular game was written in assembler (as were virtually all games on that system), while the original game was written in C (probably with some x86 assembler as well, also incompatible with the console). So it had to be essentially a complete rewrite.

Writing DOOM in assembler sounds like a...gargantuan task. Is it a case where you can compare assembler output from the original or a start-from-scratch sort of thing?

Probably mostly a start from scratch. Even if you felt like disassembling and trying to grok the PC executable, it wouldn't be especially helpful - the SNES' 65816 CPU (and its SPC700 APU, and the Doom cart's Super FX coprocessor) are completely different than an x86; especially for a performance-intensive game like Doom, you'd likely need to rearchitecture the whole thing.

id software, primarily Carmack, wrote the Atari Jaguar port of Doom.

As someone who worked in that era, it really varied on how much support you would receive from the original authors. In this case he worked mainly from the reverse engineering of the data (WADs) that was available and used his own experience to recreate the game. When I was doing ports of games from Japanese companies or other people doing arcade ports for example often all you got was a copy of the game. I remember having to get so good at the game in order to be able to finish it to recreate it correctly! Best case scenario you get the original source code, art assets and audio. Worst case you have to work it all out and reverse engineer everything. Usually at least you would get some art and audio assets.

MVG has a recent video up where he ports Heart of Darkness to the original Xbox which gives a bit of insight - https://www.youtube.com/watch?v=f4rNhTTwGgk

And in the case of SNES Doom, Randy didn't see any of the Doom source code. He found an online guide describing the Doom WAD files and then wrote a Doom prototype from scratch, on an Amiga using his own tool set. Insanely talented guy.

> how does a game get ported?

There are many options. A few points:

- Some "ports" are done by running the original game in an emulator.

- If you don't have source code or it can't be compiled for the target platform, you may have to rewrite from scratch (as was done in the case of SNES Doom apparently).

- Depending on how different the programming environments are (e.g. operating system, threading primitives, graphics/sound APIs, memory - consoles often have exotic memory layouts), significant rewriting may be needed in order to get the game running on the target platform at all.

- Once you have something that runs, it may perform like dog crap. In this case the porting job turns into an optimization and re-tuning exercise. This may involve not only optimising code, but also changing the quality of graphical/sound assets (artist work may be needed!), chopping off parts of the game (the SNES Doom does not have all levels, textures or animations for example, as the video says).

- Many bugs may crop up with the rewrite, or bugs in the original game may be exposed by running it on a different platform. General debugging skills are very likely to be required.

All but the simplest ports are likely to be an involved process, unless the two systems are very similar: for example, porting a game from Windows PC to Linux PC is likely to be relatively simple, compared to porting a game from PC to a primitive console.

I've been involved in some ports recently, from really old systems into modern ones(like, PS1 games into current/next gen) - it's basically

1) import the whole thing into Visual Studio solution

2) Add the desired target platform

3) hit build

4) keep resolving compilation errors until the game builds.

5) keep resolving linking errors until the game links

6) try running the game until it starts on the target system and doesn't crash immediately.

7) congrats, now you have something that most likely runs without any video, sound or input

8) spend X amount of time re-writing the renderer for the target system, add input support, add sound. This step can take any amount of time

9) congrats, now you have a game that "runs". It probably runs like absolute garbage right now. Now spend time understanding how all subsystems work - how is the data loaded? If it was a PS1 game, it was probably optimized for loading from the disc - can we now change it to have a more straightforward loading sequence. Can we just load the whole thing into ram on startup and be done with it?

9) do as many tweaks and optimizations as the time and budget allow - make sure it renders in 4K, supports 3D audio, rumble for controllers etc etc etc etc.

Again, step 9 can take any amount of time, depends what your production allows.

We were lucky in that the original programmers who worked on these games 20+ years ago still work at the same company - so it was quite fun for them to revisit that old code. But yeah, don't expect people to remember the code they wrote 20 years ago, you end up ripping out entire sections still marked as "fixme before launch(date: 12/1998)".

As for porting between current platforms(like a game simultaneously launching on Xbox and Playstation) - it's usually built for both from the start. In the rare cases where a platform gets added later, it's basically the same process as above - add the target, try building and running until it does. People who have experience doing it can progress much faster than people who don't - same as everything.

From my (very limited) understanding of how really old systems often had very unique hardware features and games that were full of intricate hacks to use these to improve performance, it seems to me that steps 4 and 5 could already take "any amount of time".

Well, yes, but in most cases it was like "oh, it's using some exotic library(and hardware) to do physics? cut this whole segment out then". Then once you have something that builds you can figure out how to reproduce the functionality in some other way.

Oh, one other thing - for instance, one game we worked on that was done for PS1 was made in C, but with a lot of maths methods written in hand-crafted assembly. Things like matrix operations, vector maths etc. None of that code can even build on x64, so it was just removed and replaced with STD calls when possible, or local platform equivalent. The only places which were giving us a headache were methods written in assembly that had no clear purpose(like "ProcessData" with no comment what the "process" part actually did). We had to sit down and actually try to understand what the assembly code did before rewriting it in C++.

If you were lucky you’d get the source code and assets for the game.

But many home computer ports and early console ports weren’t so fortunate. You might have access to an arcade machine, or maybe just a video recording of a play through.

It was up to the developer to mimic what they saw. Of course, the target system would limit what you could do.

Wow. I really thought of myself as a Super NES fan, but I learned two things today:

1. Doom was released on the Super NES. (I enjoyed the DOS version but never played it on the SNES).

2. the Super NES supported multiplayer for some games (including DOOM) via the XBAND modem.

some more info:

https://doomwiki.org/wiki/Super_NES#:~:text=Doom%20for%20the....

https://en.wikipedia.org/wiki/XBAND

I will never forget seeing the advertisement for the NES Teleplay modem [0] in Nintendo Power. It never launched, but one did launch for the Famicom [1].

You probably know about SNES banking already, but if not, see [2]

[0] https://en.m.wikipedia.org/wiki/Teleplay_Modem

[1] https://en.m.wikipedia.org/wiki/Family_Computer_Network_Syst...

[2] https://boingboing.net/2016/07/14/online-banking-for-nintend...

I remember seeing info about XBAND in hardcore (import) gaming magazines like GameFan and Electronic Gaming Monthly, but hardly any info in more mainstream mags like GamePro. Never heard much of anything in Nintendo Power, but it’s a glorified first-party game ad vehicle.

https://en.wikipedia.org/wiki/GameFan

http://www.hardcoregaming101.net/gamefan/GameFAN.htm

https://archive.org/search.php?query=GameFan

https://www.polygon.com/2014/9/29/6867993/egm-electronic-gam...

http://alifewellwasted.com/2009/01/23/episode-one-the-death-...

There's an excellent retrospective on YouTube about the xband and how it was built. It was a product ahead of its time.

For example, the way they got games that weren't built for laggy multiplayer to work was unbelievable: they recognized the cartridge and patched the code. Yes, that means every game that worked was a result of a custom built patching of that game's code at run time!

https://youtu.be/k_5M-z_RUKA

That’s a great video, thanks for posting it. I remember hearing it was similar to how a Game Genie worked, but that’s a lot more work than expected. Very impressive for 1993-1994.

That was really nice to watch and I think I could watch a whole series on this kind of source code analysis from the 16-bit era. I had the link opened next to a dozen tabs during the whole day and I kind of lost track where it came from so thanks for sharing it!

Check out Coding Secrets. There are probably a number of videos on this channel that you might enjoy. Some of it is newer and in the 3D era but it goes back into the 8 + 16 bit days as well.

https://www.youtube.com/c/codingsecrets/videos

And his original Game Hut channel. https://www.youtube.com/channel/UCfVFSjHQ57zyxajhhRc7i0g

And of course, even though this is Playstation the extended interview with Andy Gavin is fascinating. https://www.youtube.com/watch?v=pSHj5UKSylk

Another phenomenal channel is Retro Game Mechanics Explained: https://www.youtube.com/channel/UCwRqWnW5ZkVaP_lZF7caZ-g

The most insane part to me, who’s not a hardware person, is hacking a Starfox cartridge (because it had the SuperFX chip) as a dev system for the Doom port.

Reply on news.ycombinator.com