(11-16-2019, 08:07 PM)commodorejohn Wrote: IIRC the PS1 beats it out in terms of raw 3D performance, since it has a coprocessor designed for vector/matrix operations and a GPU with a 3D-oriented feature set - the Saturn, as I understand it, was more of a really kickass 2D system that could be finagled into doing 3D provided you did all the requisite math. But there really was no better system for 2D games at the time.
Moreorless there's a lot of nuance to this, some of which I can go into now:
The Saturn has 2 SuperH-2 CPUs that, in terms of raw throughput, are better than the single R3000 used in the PS1. They have better code density when used combined.
The PS1's graphics operations are mostly banged out by the CPU with help from the GPU.
Each system speaks differently. The PS1 uses triangles for its base polygons, and the Saturn uses quads or distorted sprites. The Saturn does have 3D capability, but it has a number of design flaws that make it difficult to program for:
1. No hardware transparency if you're not using pure quads. A lot of games set the 4th vertex to 0, allowing them to use "triangles" and this corrupts transparencies, making it impossible to use transparencies.
2. Both CPUs cannot access the memory registers at the same time and have very tiny amounts of L1 cache, so keeping both of them running at the same time is a challenge, and this is complicated by a tendency of the sega dev kits to have poor runtime optimizations, increasing the risks of a costly register spill.
3. Memory is spliced up across the entire system into 256 and 128k chunks - with the only way to access idle memory being to use slow memcpy() functions to copy it to a different block, and this blocks read functions while it's being done, causing stalls.
4. Too many processors to program for. You have two GPUs, one handling the upper sprite layer, and one handling the back sprite layer, rotating playing fields, and texturing functions. You have two CPUs, a 68k, an SH-1 and probably a few more I'm forgetting. That's even worse than the Jag, which I'll cover just because.
5. Poor dev tools. The Sega dev tools basically require some level of assembly to get good performance, and with these not being orthogonal ISAs, this can get messy fast. Unlike the 68k, you have just the basic RISC instructions.
The PS1 is absolutely inferior though, especially when you consider:
1. No hardware Z-buffering, and poor FP performance, leading to jitteryness in the polys and texture warping. This is not really present on the saturn.
2. Poor 2D support. Castlevania and Klonoa are basically 3D but planed to a 2D side-to-side motion.
3. System noise. The video output of the earlier PS1s is just HORRIBLE because the boards have so much system noise.
The Jaguar has many of the same faults of both systems, despite being "64-bit" (it isn't actually, I'll explain in a sec):
1. The Jaguar's central CPU is a 68000 - this CPU dates to the late 70s, and was used in the Mega Drive and many earlier consoles and computers. It was far too long in the tooth.
2. Tom and Jerry are both 32-bit co-processors, and these 3 are connected by a 64-bits wide databus, hence the 64-bit marketing. These are the real workers on most system pushing games.
3. Tom is a 32-bit RISC CPU with 4k of cache, a blitter, z-buffer, and the video output chip.
4. Jerry is a 32-bit DSP RISC co-processor, with 8k of cache, 2 16-bit DACs, FM and wavetable capabilities, and the main FPU of the system.
5. 2M of RAM, split across the system in chunks
There's a few flaws with these that I didn't explain and I will now. The majority of programmers only really used the 68k for heavy lifting, when the original design was as the arbitrator and responsible for memory copying and other supportive functions. Tom is a decent chip, with actually better specs on paper than the PS1's graphics hardware. The issue is that it has not enough cycles to make use of these functions effectively, and it has too little cache. Jerry has a flaw - it cannot perform math and sound operations at the same time. It can buffer sound so it plays while it is doing math, but this is very hard to manage. This is the reason their Doom port is silent, and the SFX are low quality, compressed, and downpitched.
Basically, the Jaguar's got the same complexity issues, only with Atari's balls to the wall arrogance, poor marketing, and no management or support for developers.
Lemme go ahead and briefly cover the 3DO while I'm at it:
1. it's ARM based, but the ARM design is slow, and there's no 3D support for it.
2. the CEO of 3DO was technologically illiterate, irresponsible, and the licensing model meant that console manufacturers had to recoup the system at a profit, hence $700 for a new system.
3. They licensed the tech out to inexperienced companies who did ports like with Doom, where the programmers were given no time at all to handle it
4. Poor devkit support, and the Osborne effect with announcing the M2, which never came out, and killed the system prematurely.
Rant over. Thanks for coming to my TED TALK, and let me know if I got anything wrong. It's been years since I discussed this shit.
