The thing that is lacking in PSX Doom even compared to Jag Doom

[Orchid87]

I am sure there are other examples through the game. Is this because of limited ram as opposed to loading from the cart?

[Dark Pulse]

Very much so.

 

In short: the PS1 CD-ROM is, at most, a 2x speed drive. That means a maximum sustained data transfer rate of 300 KB/sec, and that comes at a ~300 millisecond seek time just to begin to read data. The system does have 2 MB of RAM, but the game EXE itself is some 400-odd KB, and of course a bunch of other data must be maintained, so effectively each level has to run in approximately 1 MB of RAM space, and there's only about 1 MB of VRAM as well (which is where all the textures, sprites, screen buffers, etc. are stored).

 

The Jaguar also has 2 MB of RAM, but only 4 KB of internal RAM on the chip that does most of the graphics processing, and all graphical effects are software-based and not hardware-accelerated like on the PS1. However, it has one advantage the PSX does not: It's on a ROM cartridge, and ROM access times are on the nanosecond scale - several orders of magnitude faster, being perhaps 200ns for a read. That would be 0.0002 milliseconds. As a result, you can just easily set up a texture paging scheme, dynamically allocating textures when they're needed, and swapping them out extremely quickly when they aren't needed anymore. The ultra-fast access speed makes this virtually seamless, and you only really need a relatively small amount of RAM needed to store basically what's just currently in view and maybe a little bit extra for stuff you recently saw. Anything else can be freed up and re-allocated when some texture that's not currently in view is about to be drawn.

 

The PS1 has no prayer of this. Every texture (flat and sidedef) must be stored in VRAM, ready to go, because if you have to go hunting for even a single texture, you're talking a third of a second just to get to a point on the disc where it could be read, then even longer to do the actual read. And since it must all be stored in VRAM, you're ultimately limited by the capacity of your RAM and VRAM.

 

This is also why in the Jaguar version, you could, for example, have a Spider Mastermind and Cyberdemon duking it out. Those of us who've worked on the GEC Master Edition project for the PS1 know there is absolutely no prayer of us being able to do that. We simply do not have the RAM space for it; a Cyberdemon takes up about 500 KB of the main RAM space alone, and then all sprites must fit into approximately a 384 KB dynamic window (and they are the only thing that can essentially be paged, unlike textures - but this comes at the cost of having to all be loaded into RAM first), so very little other sprites can be in-view along with it or you will literally bomb out with a "Texture Cache Overflow" error.

 

Ditto for having to compromise on level textures - it will be impossible for us to 1:1 texture the levels like the PC version. Partially because not all the same textures are included, but even if they were by us adding them back in, we simply do not have enough VRAM space to do all of them. We can't do more than 16 flats per-level, and while texture space does vary depending on what size textures you pick (in PS1 Doom, they are all 128 high, and either 16, 64, 128, or (skies only) 256 wide), essentially you can think of the wall texture space as being approximately 768x256. So you have to mix and match, and work like a jigsaw puzzle, fitting in as much of the main textures as you can, and compromising when you begin to run out of room.

 

 

It's an interesting challenge. But it means any cartridge-based version will be absolutely superior in that respect.

Edited December 20, 2020 by Dark Pulse

[Gez]

Also the fire sky was a cheat because it's much smaller than a normal sky texture.

[Dark Pulse]

11 minutes ago, Gez said:

Also the fire sky was a cheat because it's much smaller than a normal sky texture.

I've heard some people say it takes up more VRAM though, due to the animation. I myself have no idea if that's true or not.

[Kroc]

Are the monster sprites stored as-is; that is, with lots of wasted transparent space around them? I can see why the Cyberdemon would occupy so much room if that's the case. If I had to attempt to rectify this, I would split the monster sprites into 8x8 tiles and omit the entirely transparent parts, re-assembling the monsters on-screen as a tilemap of 8x8 sprites (the PSX's sprite blitting is very fast)

[Dark Pulse]

3 minutes ago, Kroc said:

Are the monster sprites stored as-is; that is, with lots of wasted transparent space around them? I can see why the Cyberdemon would occupy so much room if that's the case. If I had to attempt to rectify this, I would split the monster sprites into 8x8 tiles and omit the entirely transparent parts, re-assembling the monsters on-screen as a tilemap of 8x8 sprites (the PSX's sprite blitting is very fast)

Yes, they are. Thing is, the PS1 also doesn't do its drawing as a tile-based system, either. Pretty sure any 2D elements are still rendered as quads.

Edited December 20, 2020 by Dark Pulse

[Gez]

23 minutes ago, Dark Pulse said:

I've heard some people say it takes up more VRAM though, due to the animation. I myself have no idea if that's true or not.

That's the beauty of it -- contrarily to the texture pack for ZDoom, which had to brute-force the effect by using a hundred frames, the Doom firesky on its native consoles is not an animation. It's the same memory that's used for every frame, the effect works by modifying the pixels in memory.

 

It's the same kind of trick as these waterfall textures in old platformers that were not animated, but palette-shifted, so it looked like there was an animation when in fact the pixels were just looping through index values linearly in a small range. Everything to shave off some precious bytes of memory from the program's footprint.

[Dark Pulse]

1 minute ago, Gez said:

That's the beauty of it -- contrarily to the texture pack for ZDoom, which had to brute-force the effect by using a hundred frames, the Doom firesky on its native consoles is not an animation. It's the same memory that's used for every frame, the effect works by modifying the pixels in memory.

 

It's the same kind of trick as these waterfall textures in old platformers that were not animated, but palette-shifted, so it looked like there was an animation when in fact the pixels were just looping through index values linearly in a small range. Everything to shave off some precious bytes of memory from the program's footprint.

Welp, time to let that person know, then! Palette shifting is what I thought it was as it would just make a lot more sense.

[Gez]

It's a little more elaborate than palette shifting here, but the basic idea of editing the texel values in memory is there.

Here's Kaiser reconstruction of it, translated to JavaScript so you can see it in your browser: https://codepen.io/svkaiser/pen/xXmOvY

As you can see, it occupies a 64x128 footprint. One fourth of a regular sky texture! Let's not even talk about the extravagance of PC Final Doom's 1024-wide wraparound skies.

There's a more in-depth explanation from Fabien Sanglard: https://fabiensanglard.net/doom_fire_psx/index.html

 

 

[Dark Pulse]

2 hours ago, Gez said:

It's a little more elaborate than palette shifting here, but the basic idea of editing the texel values in memory is there.

Here's Kaiser reconstruction of it, translated to JavaScript so you can see it in your browser: https://codepen.io/svkaiser/pen/xXmOvY

As you can see, it occupies a 64x128 footprint. One fourth of a regular sky texture! Let's not even talk about the extravagance of PC Final Doom's 1024-wide wraparound skies.

There's a more in-depth explanation from Fabien Sanglard: https://fabiensanglard.net/doom_fire_psx/index.html

Yeah, Fabien's explanation is why I didn't get why people thought it consumed more VRAM than the regular skies.

 

Another point was brought up though: The animation can apparently introduce some (slight) jitter in the playsim. I've personally never noticed it myself though. I don't see how if it's just modifying addresses in RAM to do the effect though.

[Roebloz]

Personally I'm working on Doom 32x: Delta with @TheLesha and I've made some interesting discoveries of my own. First, DeHacked is possible on 32x making it already superior in terms of modifiability, although you can't change States themselves (You can change which states monsters use though) This allowed us to create a modified Baron of Hell as the boss of Episode 2, and have unique death animations by making the original Baron thing use the Shotgunner's Gib animation (Albeit modified) and make the Shotgunner use the Zombieman's gib animation as well, considering how similar they are.

 

Anyways. The game doesn't seem to have a limit for flats and textures in one level (Allowing the ported levels to use the textures of the PC version) except for when Z_Malloc fails. Also, 32x Doom doesn't actually need TEXTURE1 and/or PNAMES! That's right, you can delete them and textures work perfectly regardless, as all textures are single patches. (Obviously for editing its easier to have TEXTURE1 and PNAMES) One interesting thing is that there is a texture limit on the cartridge, but instead of space taken it seems to be a number limit. (This includes flats by the way) After the number has exceeded, the WAD importer stops working with the oversaturated WAD, and if it manages to import, the textures seem to break the Doom rendering engine (And physics engine as well) as shown by these screenshots. https://imgur.com/a/E2WgZ5J

 

One funny thing is that while fire skies are used in PSX Doom as a cheat to avoid having to have the sky texture in VRAM, when it is actually still in those same levels but gets superseded with the flames, essentially wasting VRAM. Awesome.

https://tcrf.net/Doom_(PlayStation)

 

Anyways, the VRAM thing explains why Doom from the Sega 32x can do what Playstadon't.

[Dark Pulse]

3 hours ago, Roebloz said:

Personally I'm working on Doom 32x: Delta with @TheLesha and I've made some interesting discoveries of my own. First, DeHacked is possible on 32x making it already superior in terms of modifiability, although you can't change States themselves (You can change which states monsters use though) This allowed us to create a modified Baron of Hell as the boss of Episode 2, and have unique death animations by making the original Baron thing use the Shotgunner's Gib animation (Albeit modified) and make the Shotgunner use the Zombieman's gib animation as well, considering how similar they are.

The caveat to this is that PSX Doom got reverse-engineered, so technically something like this would now be possible if someone wanted to do the coding work.

 

That said, I think the 32X version is built off the JagDoom source. There's an IFDEF for "Mars" in there - Mars being the codename for the 32X. Theoretically if you enable that and try to compile, it should spit out a 32X ROM.

 

4 hours ago, Roebloz said:

One funny thing is that while fire skies are used in PSX Doom as a cheat to avoid having to have the sky texture in VRAM, when it is actually still in those same levels but gets superseded with the flames, essentially wasting VRAM. Awesome.

https://tcrf.net/Doom_(PlayStation)

Errr... you misread that. It's saying that texture was the sky texture used for Inferno maps on the Jaguar. On the PSX, those got replaced by the animated fire texture and is mostly unused, but it is used in one level on PSX Final Doom.

 

There is no "wasted VRAM," because we can see what's in the VRAM. That texture is never loaded in my conversion of E3M8: Dis for the GEC project for example, and I used the fire sky there.

 

Also, the VRAM thing doesn't really explain why the 32X can do things the PSX can't - the fact you're able to read from ROM that is literally 10,000x faster than a CD seek is what lets you do that stuff. You've got less space but incredibly fast data transfer; CD has the huge data capacity but an access speed on that data that is way slower, and so it necessitates more RAM. If there were more RAM and VRAM, it'd be able to do a lot more - 4 MB RAM would get things up to about PC in terms of complexity, and doubling the amount of VRAM would also bring things much closer in line.

 

Remember, this, the Saturn version, and the 3D0 version were the only ones made on primarily optical media while the game was modern; they'll all be beholden to the limitations of working around disc-based media. Of course there's stuff like the XBox version, but by then home consoles had more than enough RAM and space to do a 1:1 port.

[Roebloz]

7 hours ago, Dark Pulse said:

That said, I think the 32X version is built off the JagDoom source. There's an IFDEF for "Mars" in there - Mars being the codename for the 32X. Theoretically if you enable that and try to compile, it should spit out a 32X ROM.

It seems to be based off the Jaguar code but not entirely as earlier prototypes of Doom 32x did in fact include the PC textures and didn't use the Jaguar maps. My theory is that is uses a mix of Jaguar code and DOS code to run. And has anyone actually compiled the Mars thing from the JagDoom source?

[Orchid87]

3DO Doom has the texture intact though, despite having the same 2MB RAM + 1MB VRAM setup. Maybe it used a better compression?

Also random thoughts, since PS1 Doom has no streaming music, maybe some kind of data streaming could be implemented in the source code for better texture variety, like what was used by Crash Bandicoot games?

[Gez]

Data streaming from a CD only makes sense if you can expect the data access to be predictable and consistent. Don't think it'd work too well with Doom's free-roaming, non-linear exploration.

 

I only really had PC games so I don't know anything about the gameplay of Crash Bandicoot, but to me, data streaming brings to mind the likes of Megarace or Rebel Assault.

[Dark Pulse]

4 hours ago, Roebloz said:

It seems to be based off the Jaguar code but not entirely as earlier prototypes of Doom 32x did in fact include the PC textures and didn't use the Jaguar maps. My theory is that is uses a mix of Jaguar code and DOS code to run. And has anyone actually compiled the Mars thing from the JagDoom source?

It and JagDoom were developed in tandem, and of course the released JagDoom source is only going to have the ultimate results of that. Carmack basically started with a straight (but slow) port, and began having it pared back for console considerations and limits, replacing PC code along the way.

 

That said, I admittedly don't know if it does compile a working ROM or not, but it would be your starting point regardless.

4 hours ago, Orchid87 said:

3DO Doom has the texture intact though, despite having the same 2MB RAM + 1MB VRAM setup. Maybe it used a better compression?

Also random thoughts, since PS1 Doom has no streaming music, maybe some kind of data streaming could be implemented in the source code for better texture variety, like what was used by Crash Bandicoot games?

Possibly due to a different hardware setup; the 3D0 had two custom processors that could handle texture mapping, rotation, scaling, etc. I'm not sure how it handled it though. I do know that wall texture rendering is entirely redone to take advantage of the 3D0's cell engine, but flats are drawn in software (and the primary reason the game is so slow).

 

Also, you've clearly never played MAP59: Club Doom. That's streamed CD-DA, my friend.

 

There's really no major need for texture compression on the PS1 version. The PS1 version of Doom is only about 277 MB; Final Doom is even smaller at 238 MB. We could fit all the texture choices with room to spare. The problem is VRAM, and VRAM will always be the limit with how the renderer is. In short, the renderer would have to be entirely reworked, and even then, how to avoid seeking and such is necessary. It's a lot easier to do that with an engine coded with that purpose than something like Doom where it's a mostly static sim.

 

The closest thing I could think of to even get something like that to work would be some sort of thing where it's like REJECT, where we check what sector the player is in, load the sectors they could look into as well, and begin reallocating depending on where the player's position is. But that takes up more processing time (i.e; slower framerates), and it might still not be possible to make work, since players can move as they please - Crash was, for all intents and purposes, on rails.

Edited December 21, 2020 by Dark Pulse

[intacowetrust]

3DO Doom has a few additional tricks up its sleeve which help save on memory. A lot of the resources are stored in lower bit depths like 4-bit (16 color), 5-bit (32 color) and 6-bit (64 color) instead of the 8-bits per pixel (256 colors) which PSX Doom always uses. All wall textures for example are 4-bits, flats are 5-bits and most in-game sprites are 6-bits. A lot of UI artwork is either 4 or 5 bits. This could explain the difference on this particular map - 3DO Doom needs less memory overall because the resources are crunched down more than the PSX version.

[Optimus]

5 hours ago, intacowetrust said:

3DO Doom has a few additional tricks up its sleeve which help save on memory. A lot of the resources are stored in lower bit depths like 4-bit (16 color), 5-bit (32 color) and 6-bit (64 color) instead of the 8-bits per pixel (256 colors) which PSX Doom always uses. All wall textures for example are 4-bits, flats are 5-bits and most in-game sprites are 6-bits. A lot of UI artwork is either 4 or 5 bits. This could explain the difference on this particular map - 3DO Doom needs less memory overall because the resources are crunched down more than the PSX version.

 

Walls are in 4bit color, but in reality flats are using 8bit mode, which really uses only 5bits for color and the other 3bits are not used (in 3DO hardware they are sometimes used for other purposes). The reason flats prefer to use 8bit mode it's because it's easier and faster for the software renderer. While the walls are still using the CEL hardware to vertically stretch columns, the floors will render horizontal stripes with the CEL but unscalled, then software render inside the texture of the CEL. It's easier to read/write a byte for a pixel in the software renderer there.

[Optimus]

An interesting fact on the 3DO, the textures needed for a single level will always be preloaded once in memory at level start up, all the sound fx are preloaded at start regardless if they are used in the level (e.g. you don't need to load certain monster or weapon sound fx in first few levels, they are all loaded nevertheless), but the sprites are loaded on demand. Some of the most common enemies and things are preloaded once at start up, but later on if you say open a door and there is a new monster or if memory is low it will release a resource and reload the new resource from CD-Rom. This results especially in the later levels in some horrible pauses during gameplay, especially if your CD-Rom has trouble reading. I had this problem and some people also complain about it when testing OptiDoom. It exists on original Doom but maybe harder to get with commercially printed CD. When I print out the remaining memory at level start up it seems to be from 300k to 700k depending on the map. It seems there is plenty of space but that could be misleading, Doom 3DO is using it's own memory resource management system, so I don't know what it reports how close it is to reality.

[Quasar]

On 12/21/2020 at 1:53 AM, Dark Pulse said:

That said, I think the 32X version is built off the JagDoom source. There's an IFDEF for "Mars" in there - Mars being the codename for the 32X. Theoretically if you enable that and try to compile, it should spit out a 32X ROM. 

I wish. Unfortunately all the Genesis/32X specific stuff is missing. This includes for example the code for the status bar, which is being drawn using the Genesis' tiling hardware.

[Dark Pulse]

1 hour ago, Quasar said:

I wish. Unfortunately all the Genesis/32X specific stuff is missing. This includes for example the code for the status bar, which is being drawn using the Genesis' tiling hardware.

Well, I guess the other way would be to get someone who knows 68000/SH-2 Assembly and get cracking on reverse-engineering it.

 

There's a couple other FPS candidates that would be good to do that with though if those people exist. (Bloodshot and Zero Tolerance, specifically.)

Edited December 22, 2020 by Dark Pulse

[intacowetrust]

17 hours ago, Optimus said:

Flats are using 8bit mode, which really uses only 5bits for color and the other 3bits are not used

 

Oh interesting, thanks for clarifying! I missed this little detail because Phoenix Doom is pretty heavily modified from the original code at this point. It pre-converts all textures to a single 16-bit format to make things easier on the renderer.

 

I guess the memory savings are only going to be on the walls and sprites then, but since it's doing the flats in software would that cause it to use more main/system RAM instead of VRAM? Maybe this helps the 3DO version provide more texture variety?

[Optimus]

2 hours ago, intacowetrust said:

 

Oh interesting, thanks for clarifying! I missed this little detail because Phoenix Doom is pretty heavily modified from the original code at this point. It pre-converts all textures to a single 16-bit format to make things easier on the renderer.

 

I guess the memory savings are only going to be on the walls and sprites then, but since it's doing the flats in software would that cause it to use more main/system RAM instead of VRAM? Maybe this helps the 3DO version provide more texture variety?

 

On 3DO generally, the VRAM can be used as RAM. The VRAM must hold your framebuffers. But the CEL textures can be allocated anywhere in RAM or VRAM, it doesn't matter.

There is a little bit more waste of memory for a buffer with the flats software renderer. The buffer has is the max screen size in bytes, 280*160 = 44800 bytes. That's besides the flat textures being 8bit in some other place in memory. The software render for a single scanline will sample bytes from a flat texture and write back linearly to this buffer, for each scanline in a visplane. Then the CEL will render 1x (no zoom at all, like regular sprite) this scanline to the vram at the exact position this scanline should appear on screen. Another cool thing with the CEL rendering though is, the shading of the colors (because of depth light diminishing) will happen with the pixel processor of the CEL engine which is faster, than if you also did on software rendering. The software render will simply interpolate lit up texture scanlines without any extra processing (and still suffers in the slow CPU despite the code being hand optimized unrolled assembly). The 3DO Doom engine is kind of a Hybrid really between software rendering and hardware, mimicking the column and row rendering of the original in various ways.

 

There are places here and there where memory waste happens but to optimize things. I guess 3DO Doom doing the loading on demand the sprite resources saves from that, I am surprised there is still memory left. Some other things have been reduced though, the visplane number is 64 down from 128 on PC. And printing the visplanes in my tests I usually don't go over 32, so I have the option on menu to start with lower visplanes (and also try not to crash but skip rendering if they are higher at some player view) to release some more memory.

[Dark Pulse]

So then basically, 3D0 reduced color depth in order to cram more texture variety in, and overall has a more flexible memory scheme (since, again, the rendering is 100% software, so VRAM and RAM are basically one and the same). The tradeoff is, of course, the 3D0 rendering speed is atrocious. :)

 

The PS1 version, on the other hand, went for the same 256-color fidelity as the PC version has, but this along with limited RAM/VRAM means that the texture variety has to be compromised.

 

I'm still wondering if the renderer can be rewritten somehow. This was *VERY* early in the PS1's lifecycle, after all (Doom was released about 3 months after the US launch, and within about a year of the PS1's December 1994 launch in Japan), well before most devs had fully tapped the power of the hardware. Carmack did give some hints about how there might be a better way - while mentioning how he got around the problem via lots of 1-pixel poly strips that then get layered up like the software renderer, he said that it turned out not to be the approach most PS1 games used to deal with the problem, which was polygonal LoD tessellation.

 

If the renderer is rewritten, perhaps there would be ways to break these limits and be able to create versions that are more faithful to the originals? Even if we can't increase texture limits, at the very least, something like this might provide a significant speed boost on actual Playstation hardware.

[Optimus]

4 hours ago, Dark Pulse said:

So then basically, 3D0 reduced color depth in order to cram more texture variety in, and overall has a more flexible memory scheme (since, again, the rendering is 100% software, so VRAM and RAM are basically one and the same). The tradeoff is, of course, the 3D0 rendering speed is atrocious. :)

 

If the renderer is rewritten, perhaps there would be ways to break these limits and be able to create versions that are more faithful to the originals? Even if we can't increase texture limits, at the very least, something like this might provide a significant speed boost on actual Playstation hardware.

 

I wouldn't call it 100% software rendered, it's a hybrid. Walls are columns stretched completely with the CEL, floors are CEL textures as a canvas to software render inside (and still the shading in both cases ends up happening with the CEL pixel processor).

 

I've been giving some thought on how to replace the floor/ceiling on the 3DO with polygons, and hopefully when I get motivated again I'll work on this one, it's quite a lot of work possibly. And there is a simple problem. The CEL renderer is a forward texture renderer and does not support texture coordinates (this is why the flat rendering per scanline couldn't be easily replicated with the CEL). The full texture or at least a square portion of it will be rendered with the CEL. Because the player never rotates on the roll axis, the wall texture columns are always linear vertical stripes on the bitmaps (or horizontal stripes as the textures are pre-rotated 90 degrees anyway). But if you map a scanline on the floor and the player rotates a bit around it's vertical axis, the texture samples are not linear in the bitmap but in an arbitrary diagonal direction. That can't be emulated even per scanline with the CEL.

 

Interesting fact, the PS1 is not having big polygons for walls/flats. It also, like every console port, simulates rendering of the vertical 1 pixel thing columns for walls and horizontal scanlines for flats/visplanes. There was a video showing the wireframe about that, I also tested it in an emulator. So, it does that with many many thin quads made of two triangles. It seems like pretty wasteful but PS1 does it fast. Now,. on the floor, since texture coordinates are supported by the PS1, you can map an arbitrary interpolation over the texture, you can simulate the way the PC renders per scanline in the way the 3DO cannot simply simulate with the CEL.

 

The solution would be to scrap this method and break the floor/ceiling visplanes (or subsectors, not sure) into bigger quad polygons, then 3D transform and project. The problem is that the edges of the polygons will map a full texture, I still won't have a good way to control texture coordinates. So, it's still a bit of a problem even if I manage to replace with the quads. This will mean scrapping the visplane process which is also a CPU hog. Reading an article from Fabien https://fabiensanglard.net/doom_psx/index.html this is what the PS1 does too (but it ends up rendering the flats in horizontal scanlines using thin triangles anyway, probably to have perspective correct mapping). That's the next step but could possibly fail, and not sure if it gives performance, I already did some polygon subdivision on the walls which is easier and almost gained nothing, it seems Doom in general steals your CPU from all places and I can't say that there is one part responsible in the code for the low performance. For example, removing the software rendering on the floor will give some speed but in some other views I will be the same 6-8fps regardless if texture is on or off.

[Kroc]

4 hours ago, Dark Pulse said:

The PS1 version, on the other hand, went for the same 256-color fidelity as the PC version has, but this along with limited RAM/VRAM means that the texture variety has to be compromised.

 

Are you sure this is the case? In the PSX VRAM screenshot below we can see that the status, flats & textures are narrower than the screen buffers (e.g. compare Doom-guys face in the rendered frame, vs in the status textures). On a PSX, textures that appear narrower indicate that they are stored at a lower bit-rate. VRAM is always 1024px wide (at 8bpp), so images in lower bit-rates appear narrower. The emulator is correcting the colour in the VRAM dump for you, otherwise they would appear discoloured due to two 4-bit pixels being interpreted as one 8-bit pixel.

 

On 12/20/2020 at 9:59 PM, Dark Pulse said:

 

Perhaps another approach to saving VRAM without altering the vertical-strips rendering would be to store sprites as vertical strips without the leading/trailing transparent pixels and have those vertical offsets provided by a table in RAM.

Edited December 23, 2020 by Kroc
Add example regarding Doomguy's face

[Dark Pulse]

49 minutes ago, Kroc said:

Are you sure this is the case? In the PSX VRAM screenshot below we can see that the status, flats & textures are narrower than the screen buffers (e.g. compare Doom-guys face in the rendered frame, vs in the status textures). On a PSX, textures that appear narrower indicate that they are stored at a lower bit-rate. VRAM is always 1024px wide (at 8bpp), so images in lower bit-rates appear narrower. The emulator is correcting the colour in the VRAM dump for you, otherwise they would appear discoloured due to two 4-bit pixels being interpreted as one 8-bit pixel.

A lot of the graphics are actually stored in VRAM natively as 256-color objects, yes, complete with a CLUT (Color Look-Up Table).

 

Basically, graphics on the PS1 will be one of four formats for the most part - 4-bit (16) or 8-bit (256) color graphics which use CLUTs, 16-bit (65k) color, and 24-bit (16.7m) color, though the 24-bit color mode was apparently really only ever used fairly rarely.

 

A more "raw" version of this is found in Fabien Sanglard's deep dive on the PSX Doom renderer. The rainbow colors are all due to the use of CLUTs, and the amount of colors makes quite clear this is no 16-color object.

 

Edited December 23, 2020 by Dark Pulse

[intacowetrust]

10 hours ago, Dark Pulse said:

I'm still wondering if the renderer can be rewritten somehow. This was *VERY* early in the PS1's lifecycle, after all (Doom was released about 3 months after the US launch, and within about a year of the PS1's December 1994 launch in Japan), well before most devs had fully tapped the power of the hardware. Carmack did give some hints about how there might be a better way - while mentioning how he got around the problem via lots of 1-pixel poly strips that then get layered up like the software renderer, he said that it turned out not to be the approach most PS1 games used to deal with the problem, which was polygonal LoD tessellation.

 

One method might be to deal with traditional triangles but split them up at fixed screen space scanline intervals, like say every 8th or even 16th scanline or so. That way you could be doing your perspective correction every 8/16 scanlines to combat the affine texture warping. Using that approach also, walls which are more orthogonal to the player (and hence would need less perspective correction) would automatically be split up less as an added benefit. Using fixed screen space rows to subdivide on should also help with seams to make sure walls and floors join up nicely, since they will be split at the exact same place. One downside though, the light diminishing effect might need to be adjusted somewhat to play nicely with this method (since each row/column will no longer be individually shaded) or perhaps removed entirely.

 

Just an idea but it might work. Kind of inspired by what Quake 1 does with its renderer, where it only does the perspective correct divisions every 8 or 16 pixels or so (see 'Quakes Texture Mapping'):

http://www.gamers.org/dEngine/quake/papers/checker_texmap.html

 

6 hours ago, Kroc said:

VRAM is always 1024px wide (at 8bpp)

 

PSX VRAM coordinates are measured in terms of 16-bit pixels, not 8-bit. The dimensions of VRAM are 1024x512 @ 16 bpp which equates to 1 MiB of memory.

[Kroc]

Totally correct, I got muddled there. The 24-bit mode was not used often for this very reason, a single screen buffer would take up most of the VRAM!