Crash Bandicoot Texture Pack Minecraft 14
Arnau Cyr
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
7fc3f7cf58