Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
LordMeow

PSX Doom performance

Recommended Posts

I have been reading the Jaguar Doom sources and tinkering a little with the Doom ports of the era, and a question has arised...

If I am not mistaken, PSX Doom is more or less a port of Jaguar Doom, and inherits the cuts made to the maps in order to be renderable at reasonable speeds... but the question is... what limitations were in the PSX so that the cutted maps were needed? Would they have made without being as cutted as the Jaguar one, and therefore, the devs used the Jag ones to cut time?

PSX is a pretty reasonable 3D system for its era, I don't really understand why the maps had to have so much cuts, and I am sure that it has nothing to do with colored lighting or other enhancements, since the hardware would help on that side...

Any hints on this? Does anybody tech-savvy enough have an answer for this?

Share this post


Link to post
LordMeow said:

Any hints on this? Does anybody tech-savvy enough have an answer for this?

There are three main factors that inform the design of the PlayStation's engine, in order of importance:

  • RAM
  • Drive access times
  • CPU time
Out of these three, the second was solved pretty trivially in various ways by Williams - primarily by creating compact compressed files which hold the resources needed at the beginning of each level. For example, all the sprites from the IWAD are duplicated in a different file for each map which contains only those sprites needed pre-arranged to fit into VRAM.

The first and third however remain, and out of those two, the first is the absolute most arduous for the PSX. You may have heard that the system has 2 MB of RAM. That's already half of what PC had to deal with. Now, that 2 MB is for *everything*. There's not a bunch of extra banks of different kinds of RAM that aren't counting toward that limit.

PlayStation Doom is BARELY squeezing itself into these limits, particularly in terms of textures (wall, floor, and monster sprites). This is why it suffers frequent breakdowns, such as "TEXTURE CACHE OVERFLOW" when firing the BFG. It's just sitting right on the edge of feasibility in this regard. To be fair, there were opportunities for further optimizations which Williams could have done and did not - using a translation to turn Barons into Hell Knights for example (which they did do for Doom 64, where cart space demanded it).

In terms of CPU speed there's not that much to work with either. A 32-bit MIPS RISC @ 33 MHz, about a third in terms of clock speed of what was guaranteed to provide a smooth experience on PC. On top of that, the compiler they used was completely boneheaded. There's massive inlining of functions throughout the program, but absolutely nowhere it would actually matter for performance (I am fairly confident it is significantly degraded, in fact, by this). There's no actual hardware mul or div on R3000A either - they're macro instructions that explode into 12 to 13 instructions each, so the compiler goes way out of its way sometimes to avoid them, and then when it didn't/couldn't, you have this huge sequence of seemingly nonsense operations that are logically equivalent to a single "mul" on x86 - whether they're really faster or not, as MIPS certainly liked to claim, is up for CPU historians to argue, but I have a feeling they're not, particularly when cache is considered.

So in short, I believe this: PlayStation Doom could be optimized a bit more and probably handle many of the PC maps, but I believe some of them would still be no go and some retexturing and restricted monster deployment at the least would be critical (ie. no 3 or 4 versions of STAR* in one map, or Spiderdemons in a map with anything wider than a baron). It really is pushing the system as it is.

Share this post


Link to post

Thanks for the detailed explanation, Quasar, it really clarifies many things.

I can't imagine how they squeezed Quake 2 in there, though... it looks pretty good, though it's been quite some time since I last saw it in action on PSX:

Share this post


Link to post
Quasar said:

The first and third however remain, and out of those two, the first is the absolute most arduous for the PSX. You may have heard that the system has 2 MB of RAM. That's already half of what PC had to deal with. Now, that 2 MB is for *everything*. There's not a bunch of extra banks of different kinds of RAM that aren't counting toward that limit.


Actually, that's not entirely true: there's 1 MB of dedicated VRAM for graphics, and 512 KB of dedicated RAM for sounds. With some clever programming, it should certainly be possible to place resources on the appropriate types of memory and leave the -premium- main RAM as free as possible, and even obtain some effects (like the animated backgrounds) "on the cheap", by clever use of the texturing hardware. The sound and music, actually, were technically superior to those of an average PC of the time: the PSX used dedicated sound RAM, hardware mixing and DSP. The closest to that on a PC would be a GUS...but most people had a Soundblaster, which meant AdLib FM music + software-mixed 8-bit 11 or 22 kHz sound. Meh.

But yeah, to have an "uncut" PC-like experience, you really need 4 MB of flatly addressable general-purpose RAM, AND the ability to dynamically load/unload data on the fly. Below that, you have to make heavy compromises and/or rewrite the engine completely.

As for the CPU, yeah, if taken in terms of raw MIPS it wasn't better than an entry-level 486 DX2/66 of the time (which was actually being phased out in favor of the Pentium, by 1996...), but the PSX had true 3D hardware acceleration that could play in its favor, so the CPU didn't have to do nearly as much as a full "software mode" Doom implementaion would have (e.g. the 32X was essentially this).

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×