Just had a thought about PSX Doom

[MajorRawne]

A random thought just popped into my head about PSX Doom. If they'd cut out some of the animation frames and angles that we see monsters and objects from, could they have made a more faithful port? As in, one that includes the Arch-Viles, and didn't chop about 2,000 Barons out, and had more monster variety per level?

 

Unfortunately we'd have ended up with an advanced version SNES Doom, where everyone is always facing you and incoming rockets fly arse-first.

 

Would anyone have wanted that? Personally, I don't miss the Arch-Vile (or the unfortunate Barons) and think they did the best possible job they could at the time. But it's an interesting thought.

[Nights]

In my opinion, yes and no. 

From my understanding, the Playstation was much more capable than what we got in PSX Doom, especially with the creation of games like Crash Bandicoot and Spyro the Dragon after it. So in a way, we definitely could have gotten a more faithful port of the original game.

I remember hearing that because the Jaguar port was so influential, that ports like PSX used the Jag map layouts, even when it wasn't necessary. So we could have had the entire game unchanged (for the most part)

[Nights]

1 hour ago, MajorRawne said:

A random thought just popped into my head about PSX Doom. If they'd cut out some of the animation frames and angles that we see monsters and objects from, could they have made a more faithful port? As in, one that includes the Arch-Viles, and didn't chop about 2,000 Barons out, and had more monster variety per level?

 

Unfortunately we'd have ended up with an advanced version SNES Doom, where everyone is always facing you and incoming rockets fly arse-first.

 

Would anyone have wanted that? Personally, I don't miss the Arch-Vile (or the unfortunate Barons) and think they did the best possible job they could at the time. But it's an interesting thought.

And yeah, I have to agree, I never missed the Arch Vile. Or the Icon of Sin in Doom 2

[Boaby Kenobi]

7 hours ago, Kanzen said:

we could have had the entire game unchanged (for the most part)

 

There is a plethora of information regarding PSX Doom here - https://fabiensanglard.net/doom_psx/index.html

 

"The archvile had twice as many frames of animation as any other monster, and we just couldn’t do him justice on the PSX. Couldn’t lose his attack, and couldn’t lose his resurrecting power. He was just too big to include"

[Dark Pulse]

14 hours ago, MajorRawne said:

A random thought just popped into my head about PSX Doom. If they'd cut out some of the animation frames and angles that we see monsters and objects from, could they have made a more faithful port? As in, one that includes the Arch-Viles, and didn't chop about 2,000 Barons out, and had more monster variety per level?

 

Unfortunately we'd have ended up with an advanced version SNES Doom, where everyone is always facing you and incoming rockets fly arse-first.

 

Would anyone have wanted that? Personally, I don't miss the Arch-Vile (or the unfortunate Barons) and think they did the best possible job they could at the time. But it's an interesting thought.

Not really, no.

 

For one, any non-monster object only has one facing direction anyway, and they did cut out a bunch of those (though not really for RAM reasons - they could've fit them all on the CD with room to spare and let a level designer decide what ones to use, they just... didn't have them).

 

For two, Doom itself technically only has five rotation directions anyway - directly behind, behind facing 45 degrees away, perpendicular, forward facing 45 degrees away, head-on; the turn direction is counter-clockwise by the spritework and mirrored for when the sprite is facing your right. Even PC Doom does this - open an IWAD in SLADE; you'll see.

 

You obviously can't chop the cardinals (behind/side/front), meaning the only ones you theoretically could chop are the ordinals. At that point, your monster looks like it's crabwalking anytime it took an ordinal. Would it have saved RAM? Yes, a little. Would it have saved enough? Probably not unless it was a monster with a very small memory footprint (think Lost Souls, assuming you're not using a Pain Elemental).

 

The main thing dragging it down, put simply, is the PS1's RAM. It's got about 2 MB total, which is obviously half what the PC version needed. The game executable takes up north of 400 KB of that, the level data another few hundred, and the amount that's left is what the sprite data and such must all fit in.

 

Then the VRAM itself is even smaller - 1 MB. This is what actually imposes most of the practical limits. The screen buffers, HUD graphics (face, etc.), CLUTs, wall/flat textures, etc. all live here. The bulk of the space is actually dedicated for paging sprites to and from VRAM on an as-needed basis from what's stored in the main RAM.

 

Doom 64 never had this issue for two reasons - one, the console has twice the RAM (and it's a unified memory architecture - the first-ever in a console, so there is no separate VRAM, etc.); second, the load time to/from ROM on a cartridge is usually on the nanoseconds scale, whereas a CD-ROM would need 300 milliseconds just to seek to an arbitrary point on the disc - and that was before reading the actual data it needed, pushing it to RAM, etc. I asked Kaiser about this himself and he said that Doom 64 pages nearly everything - every texture, every flat, every sprite, unlike on PSX where it's only the sprites being paged and all textures are statically loaded into RAM. This, along with the higher amount of RAM, is why Doom 64 can have all the monster types and lots of textures on the map at one time and still play just fine.

 

Lastly, in terms of RAM usage, what matters more are the types of monsters, not the amount. If you have no Barons, you don't need the Baron sprites. If you have one Baron, you do. If you have fifty Barons, you still only need the one set of Baron sprites, and a miniscule amount of RAM to store the attributes of a unique Baron (Health, position, projectiles it's fired, etc.) Pretty sure you could build an (admittedly fairly simple) map with 2000 Barons and it'd run just fine - albeit I'd imagine you'd want to deal with there being too many sprites on the screen at once, and I'd imagine dozens of fireballs being flung will make the CPU absolutely cry. :P

Edited August 19, 2021 by Dark Pulse

[Koko Ricky]

@Dark Pulse, you mentioned Doom 64's nanosecond-scale buffering allowing more enemy types on-screen, but keep in mind Midway still cut out four entire enemies--archvile, chaingunner, spiderdemon and revenant, and obviously the IOS if you want to count it as an enemy. I did a pretty elementary calculation, and if they had kept the original scale of the sprites, rather than the 150% or so scaling they went with for players/monsters, you'd have enough room for maybe four or five extra enemies. That would probably have been just enough for all enemies to be present, albeit with possibly fewer frames for the archvile, who has an unusually large number of frames for his attacks.

 

As far as the PS1 goes, there are a few possible solutions that might have freed up enough RAM to allow for the archvile, but they're not particularly sexy:

1) Reduce color palette of each sprite (loss of color detail)

2) Reduce scale of each sprite (loss of overall detail)

3) Reduce frames of animation (loss of certain angles and/or motion frames)

4) Use 3D models in place of sprites (would have likely looked out of place)

5) Use fewer unique textures within a map (less distinction in map aesthetic)

 

I actually find the prospect of PS1-era 3D models interesting, and if they had been done in the Quake 2 style--decent number of polys, with interpolated animation and damage skins--they may have actually looked compelling. But then they would appear rather flat, their lighting only operating on a per-model basis contingent on sector lighting. If you wanted proper contrast, you'd have to replace sector lights with gouraud shading, which might have actually looked pretty good considering Doom's simplistic architecture, though the renderer would probably need to use the affine texture mapping method, which has no z-depth information and thus would make texels wobble and distort, including the models, but would significantly increase framerate. 

 

Really what this thread is doing is conjuring up thoughts I've had about the PS1 version for a long time, in terms of optimization. The game was using the Jaguar code as its base, which was poorly optimized for the superior architecture of the PS1. If hindsight had been present, or at the very least, if an original engine had been developed for that version, we might have seen consistently high frame rates and more of the original architecture left intact.

Edited September 9, 2021 by Koko Ricky

[Dark Pulse]

1 hour ago, Koko Ricky said:

@Dark Pulse, you mentioned Doom 64's nanosecond-scale buffering allowing more enemy types on-screen, but keep in mind Midway still cut out four entire enemies--archvile, chaingunner, spiderdemon and revenant, and obviously the IOS if you want to count it as an enemy. I did a pretty elementary calculation, and if they had kept the original scale of the sprites, rather than the 150% or so scaling they went with for players/monsters, you'd have enough room for maybe four or five extra enemies. That would probably have been just enough for all enemies to be present, albeit with possibly fewer frames for the archvile, who has an unusually large number of frames for his attacks.

Yeah, though that was for reasons of cartridge space, like you more or less alluded to. In technical terms, if all those enemies were still present, Doom 64 would've handled showing them all in-scene just fine - there's nothing inherently that would prevent it, and even if it could theoretically overflowed, it's something that alterations in map design could almost certainly fix.

 

Basically by "enemy types" what I mean is that due to that paging ability, and the higher amount of RAM the N64 has (it's the first console with a unified memory architecture, so there is no separate VRAM), basically a lot more stuff could be held onscreen at once. On PSX Doom, even if you have enough RAM to hold a bunch of enemies, too much sprites in the VRAM will still cause an overflow. This can actually be done pretty easily on the stock game with the BFG9000 in areas where there's a lot of different sprites onscreen at once.

 

Doom 64 is more a limit of the cartridge's ROM size - 8 MB was pretty beefy for a console cartridge back in 1996 (unless you happen to be the Neo-Geo, and if you are, go play with Goenitz and his tornados and enjoy getting Koko desu ka?'d to death), and obviously the improved graphics was a big part of the deal. The high-rez sprites certainly looked better, but that space taken up was the tradeoff, and in some cases they actually did shrink things down a bit (Zombiemen and Shotgun Guys are now palette swaps... and very poor ones at that, for example) but still only barely fit them in.

 

1 hour ago, Koko Ricky said:

As far as the PS1 goes, there are a few possible solutions that might have freed up enough RAM to allow for the archvile, but they're not particularly sexy:

1) Reduce color palette of each sprite (loss of color detail)

2) Reduce scale of each sprite (loss of overall detail)

3) Reduce frames of animation (loss of certain angles and/or motion frames)

4) Use 3D models in place of sprites (would have likely looked out of place)

5) Use fewer unique textures within a map (less distinction in map aesthetic)

1. When it comes to PS1 games, you basically have four means of color display, but only two of them use color lookup tables. This means that the sprites could be either 256 colors, or 16. Needless to say, Carmack's philosophy was always to cut stuff out rather than to give a substandard version of the game in terms of presentation, so that option is out.
2. Sprite reduction would have allowed more sprites in RAM in general as well as VRAM, yes, but Doom's sprites were already pretty small. Something like the Cyberdemon (84x109 in CYBRA1) or SPIDA1D1 (195x110), sure, but something like SKULA1 (44x47) is much harder to shrink. If you just blindly halved them all you'd wind up with a Lost Soul facing sprite that's a mere 22x24 pixels. That's nearly nothing. You could maybe shrink only the larger ones, but then you'd need to somehow stretch them to compensate for the scale, and it'd look like crap. So this once more fits into Carmack's dictat - better to cut things out and preserve the core experience than to compromise on the experience.
3. Angles aren't really cuttable. I mean, okay, you could potentially cut the diagonals, but that'd save a relatively small amount of VRAM space, and Doom really only animates five angles anyway, as I said in my last post.
4. 3D models would have impacted the game experience. And even then, it's not like things are "Free" there. You'd have to store a model's textures, for example, and that takes up a fair chunk of space unless the textures are pretty small. I don't think many PS1 games went past 128x128 textures for their models. (256x256 was the top limit due to a paltry 2KB texture cache.) Capturing all those details would not have been easy.
5. This is actually not even a factor. Textures are stored in a totally separate (and dedicated) area of VRAM. The only way something like this would work would be if you dedicated more VRAM to sprites than wall textures, but yes, then you would have less map aesthetics. And believe me, even with the current limits, I have to make some pretty tough choices...

1 hour ago, Koko Ricky said:

I actually find the prospect of PS1-era 3D models interesting, and if they had been done in the Quake 2 style--decent number of polys, with interpolated animation and damage skins--they may have actually looked compelling. But then they would appear rather flat, their lighting only operating on a per-model basis contingent on sector lighting. If you wanted proper contrast, you'd have to replace sector lights with gouraud shading, which might have actually looked pretty good considering Doom's simplistic architecture, though the renderer would probably need to use the affine texture mapping method, which has no z-depth information and thus would make texels wobble and distort, including the models, but would significantly increase framerate. 

And Carmack was dead against affine mapping texture swim - it's what originally killed the OG Saturn renderer that Jim Bagley had cooked up. Could do 60 FPS, was lightning fast... but affine texture swim. Carmack vetoed that. He did concede that in hindsight he should have let Jim experiment to see how to reduce the swim, but in the end, that was that.

 

Realistically speaking, there probably are ways to optimize the PSX renderer further. Something like what PSX Q2 does (essentially LoD where the triangles on a wall increases as you approach the wall to reduce the swim) would be a good example. The major reason the game is slow, after all, is that it's abusing the polygon renderer capabilities to render a bunch of pixel-wide polygonal strips to mimic the original renderer, and the PS1 GPU gets pushed to its limit as a result.

 

1 hour ago, Koko Ricky said:

Really what this thread is doing is conjuring up thoughts I've had about the PS1 version for a long time, in terms of optimization. The game was using the Jaguar code as its base, which was poorly optimized for the superior architecture of the PS1. If hindsight had been present, or at the very least, if an original engine had been developed for that version, we might have seen consistently high frame rates and more of the original architecture left intact.

Well, since the original game was Objective-C, really the work that would have been done would've been the code for the specific chips per-console, while most of the logic should just have "worked" when compiled with the right instruction set. Again: It's not really the CPU side of things that is killing the game performance here, it's how the PS1 renderer works.

 

The biggest speed booster would be, hands down, reworking the renderer. If you can figure out a way to keep affine swim to a minimum while reducing the amount of polys that need to be drawn every frame, you'll get a huge speed boost.

Edited September 9, 2021 by Dark Pulse

[Koko Ricky]

I don't think there's a better method than the LOD subdivisions in PS1 Quake 2. PS1 games were known for using subdivision to make affine swimming less noticeable, so having the number of subdivisions increase as you get closer to a polygon is extremely clever. I think that could have easily gotten us 30+fps stability even in the larger maps. With that method I bet you could even add more detail to environments, truly making it an enhanced edition.

[MajorRawne]

Some fascinating stuff here. Thanks everyone!

 

So just to check my understanding, the PSX not only has a limit to what each map can contain, but how much of this content it can show (render) at once? So even if you manage to include a variety of monsters, you can still crash the game by rendering them all at once?

 

And there is a separate limit to how many sprites can be displayed at once, even if they are the same monster type? This being due either to design limits or hardware limits?

[Gez]

On jeudi 19 août 2021 at 3:19 PM, Dark Pulse said:

For two, Doom itself technically only has five rotation directions anyway - directly behind, behind facing 45 degrees away, perpendicular, forward facing 45 degrees away, head-on; the turn direction is counter-clockwise by the spritework and mirrored for when the sprite is facing your right. Even PC Doom does this - open an IWAD in SLADE; you'll see.

Not entirely accurate.

 

While it's true for many animations, it's not true for all. Take the demon, for instance. While it has only 5 angles for walking around, using mirroring, it does have all 8 rotations for its attack animation. Likewise for the revenant and the archvile. The cyberdemon and the chaingunner have all eight rotations for all frames (except death animation). Something else to note is that for walking animations, while they originally went for simple mirroring, they eventually got a better scheme going on that still involves mirroring but in a smarter way. Compare the barons and the knights: baron walk sprites go A2A8, B2B8, C2C8, D2D8, while knight walk sprites go A2C8, B2D8, A8C2, B8D2. In plainer words, when the baron moves its right leg forward, it's gonna turn into the left leg forward depending on view angle. While for the knight, it'll be the right leg forward regardless of view angle, so it's more consistent. The arch-vile also uses this scheme for its walking animation (though extended to six frames in total, using A/D, B/E, C/F pairs).

[OldDoomer]

9 hours ago, MajorRawne said:

So just to check my understanding, the PSX not only has a limit to what each map can contain, but how much of this content it can show (render) at once? So even if you manage to include a variety of monsters, you can still crash the game by rendering them all at once?

 

And there is a separate limit to how many sprites can be displayed at once, even if they are the same monster type? This being due either to design limits or hardware limits?

 

Correct. There's only 640k VRAM allocated for everything displayed onscreen in the play area, including textures, sprites (including repeats), and skies. If it is exceeded the game will fatally crash. You can test some of the limits of PSX Doom by playing the later Doom 2 levels and going to places where not only a lot of monsters are present at one time but also constant moving projectiles and player -generated projectiles (think non-hitscan items) are displayed simultaneously. Examples include Suburbs, The Courtyard, any sort of later Doom 2 level that not only has a large outdoor environment but also lots of monsters simultaneously. It may take a few tries, but you can easily force a crash on those levels if you allow monsters to congregate. On the other hand you could also play the PSX Doom for years upon years and never actually see a fatal game crash. One typically has to really force it, and a casual player in those aforementioned later levels such as Suburbs and The Courtyard is unlikely to maneuver where alive monsters will congregate to force a game crash.

 

You can also potentially crash the game by using the Lost Soul bug, which can generate a similar problem of exceeding the VRAM. If you're unaware of it, killing a Pain Elemental will sometimes spawn Lost Souls outside of the play area. In normal gameplay, such a Lost Soul will simply hug the walls trying to reach you. If you then fire a rocket at a wall to "push" a Lost Soul, it will continue until it reaches the extremes of the play area (they are normally supposed to be stopped by a linedef, but are not). When this occurs, the game will start corrupting each time the Lost Soul continuously moves around the play area. You can test this as early as Level 1 entering a weapons cheat code and playing on Ultra Violence but it's much more apparent in some of the later levels with more Lost Souls generated. Linedefs and sections will rearrange themselves until exceeding memory and crashing.

[Dark Pulse]

10 hours ago, Gez said:

Not entirely accurate.

 

While it's true for many animations, it's not true for all. Take the demon, for instance. While it has only 5 angles for walking around, using mirroring, it does have all 8 rotations for its attack animation. Likewise for the revenant and the archvile. The cyberdemon and the chaingunner have all eight rotations for all frames (except death animation). Something else to note is that for walking animations, while they originally went for simple mirroring, they eventually got a better scheme going on that still involves mirroring but in a smarter way. Compare the barons and the knights: baron walk sprites go A2A8, B2B8, C2C8, D2D8, while knight walk sprites go A2C8, B2D8, A8C2, B8D2. In plainer words, when the baron moves its right leg forward, it's gonna turn into the left leg forward depending on view angle. While for the knight, it'll be the right leg forward regardless of view angle, so it's more consistent. The arch-vile also uses this scheme for its walking animation (though extended to six frames in total, using A/D, B/E, C/F pairs).

Yeah, that's fair. I did forget about certain animations/things like that.