Dissecting Sega Saturn Doom

One thing I've seen written before is that Carmack nixed using the hardware functions "because of affine mapping."

@PeterBridger @JimBagley69 I hated affine texture swim and integral quad verts, but in hindsight, I probably should have let experiment.

— John Carmack (@ID_AA_Carmack) October 8, 2014

Which doesn't even make sense because I'm not sure what it even means to arbitrarily affine-map a rectangle - how do you possibly keep all parallel lines remaining parallel? Also because the Saturn seemed to handle arbitrarily transforming quads just fine, like in this tech demo:

I wonder if this is related to the tendency of pre-N64 hardware to not have perspective correction...

Here's what I've figured out so far about the sound effects of this version. I would like to say upfront that I don't have much prior knowledge as to how game system's sound chips normally work, so I have no clue as to how "normal" Saturn Doom's process might be. With that being said, the Saturn's sound processor is a Motorola 68EC000 capable of 32 different sound channels. For Saturn Doom, sound effects seem to "flood" these channels in a random pattern, with a sound effect being left in that channel after it has been used. Once all have been filled up, they are then written over with other SFX. For example, leaving the chainsaw running will fill up the sound channels with 31 instances of the same chainsaw idling effect.

Through Yabause, I was able to extract whatever is in one of the Saturn's 32 sound channels and extract it to a WAV. These WAV files are in 2 channel stereo. When the game is set to mono, the sound effect plays equally out of both channels. But when set to stereo, the sound can either be isolated just to one channel leaving the other channel completely silent, or it can be "balanced". The sound comes out of both channels, but is played at different volumes to give a better sense of "direction". The stereo sound is broken in this version, and it is currently unknown as to how a sound effect is given it's sense of direction.

I've also looked through Yabause's memory editor and have come up with some interesting finds.
⦁ There seems to be A LOT left over from the PSX port, with both Lights and Leafs lumps still being referenced. For example, LOADLEAFS is referenced at A751AC10 as well as P_LOADLEAFS. LIGHTS along with PLAYPAL.PAL are referenced at A75216D0.
⦁ Texture Cache Overflow is still referenced as well. Messages about the link cable multiplayer mode are also still mentioned at several points as well.
⦁ There appears to be a credits screen that is never shown during actual gameplay, it reads out as follows:

Rage Special Credits: Thanks to Jacqui Henderson for Support for co-programming for producing.
Sega Special Credits: Ed Hollingshead for tech. support
John NG. for 3rd party help
Tamar Tashin for the hardware

Finally, Hell Beneath has to be the buggiest level I've encountered so far in this version. The issue is mainly with the NIN secret room. The walls that rise up after the secret is triggered are almost always textured incorrectly. They either feature a random texture from elsewhere in the level, a plain black texture, or simply no texture at all which allows you to see through the walls out into the rest of the level.

I wonder how much John Carmack knew about the Saturn's hardware before making his decision on nixing hardware acceleration. Perhaps he just made a quick assumption about the system's hardware without really seeing what the system was capable of?

Sounds like it's unoptimized as shit. There's your problem, leave Carmack alone!

As somebody who's hacked PSX extensively I am very interested in this. And I'd love to hear any more info Jim has to offer; his resurfacing with the aforementioned Carmack tweet was helpful to us on the wiki for explaining why the Saturn port was less stellar than expected and probably had a chance to be better than it was.

There's also of course the off chance he could have the source code and be willing to share it ;)

Slightly unrelated, but, something else we need to rediscover unfortunately is the compression algorithm used for PSX Final Doom's map files. A guy on these very forums wrote a tool that could decompress them, but never published the source code. So, the algorithm is lost again.

Quasar said:

Slightly unrelated, but, something else we need to rediscover unfortunately is the compression algorithm used for PSX Final Doom's map files. A guy on these very forums wrote a tool that could decompress them, but never published the source code. So, the algorithm is lost again.

I see 5 possibilities:
1. The guy was on the PSX/Saturn team - unlikely.
2. He had the source code - unlikely.
3. He disassembled the compiled code - maybe.
4. The data's not really compressed, merely "optimized" - more likely.
5. The compression algorithm is standard, and can be deduced from the data - more likely.

If I had the ROM dump, I'd look at it. See if there's any repeated patterns throughout the whole data block. If prominently true, it's probably #4, otherwise consider #5. Cause, otherwise, it's pretty difficult/borderline impossible to derive the algorithm from just the data.

Mattfrie1 said:

For Saturn Doom, sound effects seem to "flood" these channels in a random pattern, with a sound effect being left in that channel after it has been used. Once all have been filled up, they are then written over with other SFX. For example, leaving the chainsaw running will fill up the sound channels with 31 instances of the same chainsaw idling effect.

From what it sounds like, this bad sound coding could be eating up a ton of processing cycles. I don't know much about emulation on this platform, but is it possible to shut the whole sound system down and still run the game? In my streaming sessions I always change the sound output to mono, since the broken stereo drives me nuts. It would be nice to have a clear reason why the port runs so badly, though my bet is still on the sloppy use of the two processors. All the wasted memory on functions that aren't even in the game probably doesn't help either.

Honestly the other biggest problem I see here is the port clearly being based on the PSX version, and not the Jaguar (which at least had 2 CPUs) or even the crappy 32x like someone mentioned already. The PSX and Saturn had very, very different architectures and starting with it's version would be just a really stupid idea.

Linguica said:

* Reality: have an array of 512 cels where for EACH PIXEL COLUMN/ROW OF EACH SEG / FLOOR SPAN / SPRITE, you create a 1 PIXEL WIDE CEL with the little sliver of texture. If you chew through the array, dump the 512 cels you already have to a bitmap and keep making new cels until you're done.

Yikes. That sounds pretty inefficient, BUT it could be done that way to make it easier to implement vanilla's depth cueing. Alternatively it could be to minimize the amount of modification to the R_DrawColumn() and R_DrawSpan() equivalents; never underestimate the programmer-on-a-deadline factor. :)

Urban Space Cowboy said:

Yikes. That sounds pretty inefficient, BUT it could be done that way to make it easier to implement vanilla's depth cueing. Alternatively it could be to minimize the amount of modification to the R_DrawColumn() and R_DrawSpan() equivalents; never underestimate the programmer-on-a-deadline factor. :)

Probably this because the C version of the Jag code that 3DO is based on was still a column- and span-based renderer. Only on Jag, the columns and spans are objects that go into the PPU's hardware draw list during the final stages of rendering.

I haven't made it that far in reversing the code in Calico yet, but given that there are still R_DrawColumn and R_DrawSpan functions that were for testing the game under NeXT, it must be largely compatible with them right before the final stage. I'm praying at least, because otherwise it's going to be interesting trying to get Calico to draw anything at all to a buffer.

VGA said:

Sounds like it's unoptimized as shit. There's your problem, leave Carmack alone!

Hmm.

VGA said:

I wish Carmack would pop in some day to tell us to get the fuck over the Saturn port or something haha

Seems you're the one with something they have to get over.

Jaxxoon R said:

Hmm.
Seems you're the one with something they have to get over.

Deeeerp, there have been 5 other people that mentioned Carmack in this thread except me.

Out of curiosity, are there any notable differences between the North American and Japanese versions of the game? There's been a long-standing rumor that the Japanese version runs (marginally) better.

Shadow Hog said:

Out of curiosity, are there any notable differences between the North American and Japanese versions of the game? There's been a long-standing rumor that the Japanese version runs (marginally) better.

I've seen the videos but I'd have to see them side-by side. Regardless of whatever marginal differences they both still run like ass-on-wheels.

VGA said:

Deeeerp, there have been 5 other people that mentioned Carmack in this thread except me.

That wasn't my point, it was how you've made it apparent that you seem to really dislike it when people bring up his contribution toward the Saturn port's lack of quality, even when it is done as part of constructive discussion. What you're doing is essentially the equivalent of telling paleontologists to get over the fact that the dinosaurs died.

Quasar said:

Probably this because the C version of the Jag code that 3DO is based on was still a column- and span-based renderer. Only on Jag, the columns and spans are objects that go into the PPU's hardware draw list during the final stages of rendering.

I haven't made it that far in reversing the code in Calico yet, but given that there are still R_DrawColumn and R_DrawSpan functions that were for testing the game under NeXT, it must be largely compatible with them right before the final stage. I'm praying at least, because otherwise it's going to be interesting trying to get Calico to draw anything at all to a buffer.

I wonder if, when you are done with Calico, you or someone else will be able to attempt to port the source to the Saturn. Yes, it would lack the bells and whistles of the PSX based port, but with the code being converted from assembly to c, it might provide for a better Doom experience on the Saturn.

I'm pretty sure the SlaveDriver could do it with ease considering the SS port of Duke 3D that used it had colored lighting just like Psx version of Doom and had levels at least as complex, albeit toned down from what the PC Duke 3D levels provided. You could probably get something resembling the Psx version, albeit with texture warping.

DN3D always had coloured lighting, it was just limited to blue and orange.

Hi guys, what do you want to know?

Some answers, to things you might want to know for starters.

1. No, I don't have the old source to the released version.
2. I don't have anything of the approval version.
3. I don't even have a saturn dev kit, ( I do have a fully working saturn though )
4. I originally wanted to port Doom1 and Doom2 direct from PC, due to Carmack knocking it back we went with PSX version for speed, as that one was approved, and the levels were already reduced to fit in console memory.
5. Be thankful I didn't do the rendering using the heavily bottlenecked DSPs that Carmack suggested, it would have been a lot slower having to transfer data in and out constantly through the 2K+2K DSPs
6. PSX could use the hardware to render in columns, the Saturn had no chance.
7. Audio was audio tracks on CD for speed, as we'd already used time up doing the approval submission, then had to start again with a different approach.

⦁If you went with porting straight from the PSX version from the start, would it have been possible to utilize some of the special features that were in that version? (i.e. colored lighting, reverb sound effects)

⦁I noticed that all the resources for the colored lighting are still on the disc and referenced in the system's memory. Is it possible that the system is still trying to render the colored lighting even though it isn't being displayed?

⦁Why is the animated fire sky replaced with the Doom II cityscape background on the levels that are supposed to take place in Hell?

⦁Common rumor is that the Japanese version runs smoother than both the US and European versions. Did you go back and optimize the code for this version?

⦁Do you remember how the music was acquired? The tracks included in the Saturn version differ both in length and sound from their PSX originals.

⦁The stereo sound is completely broken in the finished product. Was the mono sound option added at the last minute to compensate for this?

⦁Do you remember how much time you had to "redo" your whole approach before the scheduled release date?

⦁Do you remember how much of the PSX code got optimized for the Saturn? I've noticed that at least the sky textures got reformatted to take advantage of the Saturn's VDP2 chip.

Thanks for being willing to open up and discuss this version. Despite all the flak that this port gets I still find it quite enjoyable.

Thank you very much for taking the time to chat about this. As a Saturn fan and a Doom fan I've always been a bit irritated this version didn't seem to get the care it deserved, though having massive time constraints on development wouldn't be the first time a game has suffered as a result.

Baggers said:

4. I originally wanted to port Doom1 and Doom2 direct from PC, due to Carmack knocking it back we went with PSX version for speed, as that one was approved, and the levels were already reduced to fit in console memory.

How far along were you with this idea for is was axed? How would you have designed the port differently? Would it have been catered better to the Saturn's hardware?

Baggers said:

6. PSX could use the hardware to render in columns, the Saturn had no chance.

What do you mean by 'no chance'? Because of time? Was the renderer simply too different to get working the same way? Hexen for instance runs quite well on the Saturn using a later version of the Doom engine, even at full screen size it stays consistently playable throughout the whole game.

Baggers said:

7. Audio was audio tracks on CD for speed, as we'd already used time up doing the approval submission, then had to start again with a different approach.

I assume then the rest of the broken sound system is also a result of having to start over. As noted above, the stereo effects don't work at all and the sound channels are flooded with redundant data.

I guess my main question is still this, what exactly is the chief culprit behind the game's terrible performance? The PSX port as a base? No time to properly optimize the game?

Yeah, I want to know about the Japanese version of Saturn Doom also. Rumors are that it runs better and that even a different company (Softbank) did the port.

Linguica said:

Which doesn't even make sense because I'm not sure what it even means to arbitrarily affine-map a rectangle - how do you possibly keep all parallel lines remaining parallel?

On the Playstation at least, large polygons close to the camera would be tessellated in real-time to reduce the distortion, creating a jagged effect that approximated perspective correction.

GoatLord said:

The point of mentioning Spyro was that it was a full 3D game with really huge worlds. I just find odd that Doom ran so poorly on consoles that could clearly handle larger amounts of detail. Maybe the 2.5d thing was awkward to implement.

Spyro had an interesting engine. Each level had two meshes, one built of large untextured polygons with vertex shading, and a second tesselated mesh with a little more detail, textures and vertex shading. The texture mipmaps typically faded to a flat white, so the vertex colour became dominant and blended into the untextured mesh at a distance.

Shame to hear about the code, wouldn't be surprised if it is lost entirely at this point. I always figured the PSX was making polygons out of drawsegs, to hear that it is column based is interesting to say the least. One polygon per column/span?

EDIT: Kaiser was able to confirm this with an emulator, amazing. The PSX drawing process is almost the same as for PC, but using quads as the bottom level primitives. Thats' a lot to push every frame.

Special thanks to Quasar for uploading it.

Here's the video demonstrating PSXDoom's rendering of wall segs and subsector leafs:

That's A LOT of quads to draw, but seeing how poorly the PSX handles texture mapping, drawing the game via columns was probably the right thing to do.

Quasar said:

EDIT: Kaiser was able to confirm this with an emulator, amazing. The PSX drawing process is almost the same as for PC, but using quads as the bottom level primitives. Thats' a lot to push every frame.

That would explain why levels like Perfect Hatred actually struggle a bit, that's gotta be quite a bit of quads it's pushing out.

Texture mapping still looked crappy though. At close range the texels bunch up. Prolly wouldn't have looked much worse with standard texture rendering.

Linguica said:

Which doesn't even make sense because I'm not sure what it even means to arbitrarily affine-map a rectangle - how do you possibly keep all parallel lines remaining parallel? Also because the Saturn seemed to handle arbitrarily transforming quads just fine, like in this tech demo:

There is no perspective correction. In that demo you can't tell that well, because the quads are quite big.

Left is what happens on the Saturn if you would move the poly on the right in perspective. The distances stay the same.


You can also see it really well on the textures of this screenshot of Radiant Silvergun. Note how the textures seem to stretch as they go back. Which is because the actual distances remain the same. No perspective correction.


Also on the Saturn all polygons have to be planar quads. You can fudge triangles, but as you can see in that demo you linked, the triangles are solid colour, because if you put a texture on that it would look really distorted because in actuality it is still quads with 2 points either overlapping or just really, really close.

There is an interview of Jim Bagley on The Retro Hour podcast Ep 14.  And the week that Romaro was away was the week that the initial Saturn port was reviewed by Carmac, who said to do the game in software not hardware.

 

Years later Jim caught up with Romaro and found out about this, and Romaro would have green lit the versionusing hardware.  

Carmack has tweeted about how affine texture mapping would have been the best route in terms of the tradeoff between speed and performance. I think it would have been just fine, and we could have gotten much "fuller" version of the maps. Contrarily, I think the way many of them were altered and re-textured looks very interesting and in some cases improves the look of some maps.

So I've decided to do a little digging into Saturn Doom again to see if I can uncover any other fascinating things about this flawed port. Here's a few more interesting things that I missed on my first examination:

 

- The DOOMTONE.BIN file is indeed the file that houses all of the game's sound effects. Opening the file as raw data in Audacity under the correct settings reveal all the sound effects laid out in one long "chain". Sounds are also sampled at the extremely small sample rate of 2500 hZ. I'm assuming that the DOOMMAP.BIN file serves as an indexing file, telling the system where each specific sound effect starts and ends in the DOOMTONE file, as well as each sound's duration. This is yet another way that this port inefficiently utilizes system memory, since the game most likely has EVERY in game sound stored in memory at all times.

 

- I also feel the need to point out that since the Saturn uses an entirely different sound engine from the PSX version, there was no possible way that this port could have supported sound reverberation effects, especially since the reverberation effect was a feature of the PSX's sound processor. As far as I know, the Sega Saturn's sound processor had no equivalent feature.

 

- Right after P_LoadSectors is mentioned in 0.BIN (the game's main program file), the code makes mention of F_Sky immediately followed by %s.CHR and %s.MAP. This shows how the Saturn port has extra code added in for the "new" skies utilized by the Saturn's VDP2 chip that appear in the SKYS folder. This of course means that the sky textures included in JIMSDOOM.WAD are redundant since they appear to be coded to never appear in game, and are overridden by the new sky files.    

 

- All of the .CHR files are in the tile format of 8BPP, which is common for tiling backgrounds and such. Sadly not many tile editors currently support 8BPP, but the tile editor in the Windhex program can display a garbled view of the file. I still can't tell what SKY20 and SKY21 are supposed to be, but the STATS.CHR file is where all the tile data exists for the new status bar, the status bar face, the font for all in game text and the loading graphic. INTERPIC.CHR (in the disc's main directory) is used for the the game's main menu and intermission screen, and is scaled slightly differently from the very similar image used for the PSX's main menu.

 

- All of the map files for the Saturn port are the same exact file size as the map files for the PSX port, and examining the files in a hex editor reveals absolutely NO difference between the files as well. Since the files are an exact match, I wonder if all the information about colored lighting and sound reverberation are still included in the Saturn files...

 

- All of the files on the Saturn Doom disc contain the date of 1/29/97. GameFAQs states that Saturn Doom was released in the US on 3/31/97, only a 2 month period from the game being compiled to it being out in the stores.

 

- In a previous post I made specific mention to the NIN secret in Hell Beneath and how the walls after the secret is activated are almost always buggy. Ultimately, I believe I've discovered a reason and a pattern to this phenomena. First off, the walls to this secret are NEVER drawn correctly in this version. Instead, the game seems to texture the wall with what ever texture data was last "occupying" the area of memory that the correct texture is supposed to be in. Curiously enough, loading the level from scratch after you start the system via password yields the game to draw a blank wall that is completely see-through. Otherwise, the game will draw a texture from the previous level that was loaded.

 

- I've compiled a video sampling what this bug looks like. The first clip shows what the blank wall looks like, and the second clip shows what the wall looks like after warping to the level from Club Doom. After that shows some of the "highlights" that I found messing around with this bug, enjoy: