This is the final part of this little research about hardware and graphics capabilities of old generation consoles, we will cover the 32-bit and 64-bit generation consoles specs comparison, evaluating Sega Saturn, Sony Playstation and Nintendo 64 hardware-wise. As an extra bonus, I'm also adding the Gameboy Advance to the list, having a 32-bit cpu! Maybe it's a bit unfair, but it's the last full 2D console produced, so at least we could compare its 2D graphics capabilities to the others.

I could also have added the Atari Jaguar, 3DO and Amiga CD32 but I'm running out of time lately. Anyway, if someone else want to keep doing this for the next generations of consoles, I will be happy to follow the discussion in the forum ;)

But first, if you missed the other parts, you can check generation comparisons here:
- Part 1: 8-bit Generation
- Part 2: 16-bit Generation

As for the other topics I tried to search for every information I could find on the web, trying to be as accurate as possible but, again, feel free to post corrections and report errors if needed.

Let's start!

Hardware Comparison: Saturn Vs PSX Vs N64 Vs Gameboy Advance

[About SATURN Hardware]
SCU Geometry DSP: Handles vector and matrix calculations, 3D point transformations, lighting, geometry and coordinate transformations. That's a powerful co-processor that unfortunately required assembly-only for coding and it's estimated to have been used by only the 15~20% of games (profiling on emulators). Having both the SH-2 CPU a DSP Math core, often they were preferred for those type of calculations despite being slower in this task.
VDP1: Handles sprite/texture and polygonal drawing, color calculation and shading of geometry. It used it's own framebuffer.
VDP2: Handles backgrounds, 2D special effects, 2D scrolling and 3D rotation planes with texture perspective correction. It accessed the VDP1 framebuffer (at any stage) to read it and then writing to its own framebuffer to compose the final image output.

[About PSX Hardware]
GTE (Geometry Transform Engine): Handles vector and high-speed matrix multiplications, lighting, geometry, polygon and coordinate transformations.
GPU: Handles display of graphics, controls its own framebuffer, drawing of polygons and textures (3D Engine), 2D graphics processing (Sprite Engine).
MDEC: Handles fullscreen, high quality FMV, decompression of images and video into VRAM.

[About N64 Hardware]
RSP: Handles transform, clipping, lighting calculations and triangles setup. It featured programmable microcode, default microcodes were Fast3D (for accuracy) and Turbo3D (for performance). Nintendo encouraged devs to use Fast3D for better quality polygons over its rivals, purposely limiting the maximum number of polygons on screen, while with Turbo3D the GPU could have rendered many more polygons at Saturn/PSX quality levels.
RDP: Handles the 3D fixed-pipeline and pixel drawing engine (including z-buffering), performs rasterization and drawing or texturing of pixels in the framebuffer. It used its own framebuffer and the texture cache.

2D Specs:

* Theoretical peak numbers.

Some examples of 2D graphics output comparison:

Saturn	PSX	N64	Gameboy Advance

[SATURN 2D/Sprite Implementation]
Sprites and 3D-Primitive/Shapes are handled both in the same way, being made of quads, the machine considered 3D-Objects like they were “meshes of transformed/distorted sprites”. VDP1 can render up to 8000 sprites on screen at peak with transformations, can apply additional effects such as true-transparency (alpha blending, limited use) or basic-transparency (dithering), while VDP2 blended it all together with its 3D infinite planes (Mode7-like planes), backgrounds and parallax scrolling.

[PSX 2D/Sprite Implementation]
The machine managed sprites in two ways, using the Sprite Engine by issuing sprite-commands for rendering up to 4000 sprites at peak but without transformations, a sprite is composed of a 2D quad, or by using the 3D Engine for rendering actual 3D flat-textured quads (2x triangles) as sprites.

[N64 2D/Sprite Implementation]
The machine managed sprites in two ways, using the sprite-microcode (Sprite Lib) for rendering up to 6000 sprites at peak with scaling only, a sprite is composed of a 2D quad, or by using the 3D Pipeline for rendering actual 3D flat-textured quads (2x triangles) as sprites.

[GBA 2D/Sprite Implementation]
This system had a standard 2D Tile/Sprite engine, as previous generations consoles, rendering on the fly per scanline.

3D Specs:

* To render the equivalent of a quad the other systems would have used 2x triangles.
** It's not a modern hardware Transform & Lighting, at the time T&L was implemented in software while running on a dedicated co-processor.
*** Theoretical peak numbers, referred to calculated/transformed-only polygons not drawn on screen.

[SATURN]: With its dual CPUs in master/slave configuration, each with a DSP core, a dedicated math co-processor and two different GPUs, one for 2D/3D (polygons and sprites rendering) and the other for 2D only (special effects, backgrounds and parallax scrolling), this machine was flexible, powerful but yet very difficult to develop for. Master SH-2 could pass instructions to Slave SH-2, while the SCU DSP could run in parallel, however, each one needed to sync on access to the same memory and bus. Also, the two VDP were very different from each other, with VDP1 in charge of filling the framebuffer while the other in need of drawing it too. The most important issue, above all, was the very limited SDK libraries Sega distributed to developers at start, absolutely not capable of using at best this highly parallelized machine. Most notably, in the first version of the SDK, there were no reference on how to use and program the SCU DSP, which required assembly in any case. The result was that the first generation of games used only 1x SH-2 and VDP1 while have been estimated that of all games released, only 15~20% used the SCU DSP effectively. Subsequently, the SDK was rewrote and optimized, finally letting developers to fully use the hardware at its best.

[PSX]: A powerful straightforward 2D/3D-capable machine that could easily handle dynamic lighting with multiple colored light-sourcing, true transparency in both 2D and 3D games and a solid fast 3D engine for innovative special effects such as motion blur and fog. Developers side, it was the easiest of the 3 to code for, thanks to very high quality libraries developed by Sony Computer Entertainment simply available from the start. It hadn't a dedicated 2D graphic processing unit like the Saturn nor an advanced sprite-based rendering system, but thanks to its Sprite Engine and the ability to easily elaborate the framebuffer this was more than enough to reach highest levels in 2D based games.  

[N64]: A powerhouse in heavy computational tasks and very advanced in 3D rendering, it featured many novel 3D features for the time, such as Z-Buffering and Mip-Mapping, Anti-Aliasing, and a very effective hardware-based "Level of Details" (LoD) system. It didn't feature a dedicated graphic processing unit for 2D and the microcode and libraries for 2D graphics weren't much advanced for the task, in comparison to its rivals, but this was only a Nintendo's choice, such as the one to limit its polygonal output on screen in favor of a more accurate polygons rendering or for the use of ROM cartridge instead of CD-ROM, which limited space for more detailed textures, images and prevented it from having Full Motion Video in games, an highly spectacular feature at the time.

[GBA]: Historically the last true full-2D system released on the market, it featured a fast ARM-based CPU and a secondary CPU for compatibility with original Gameboy and Gameboy Color games. With its tile/sprite based hardware rendering was able to output many colorful sprites on screen, outclassing any previous 2D machine while inheriting all the 2D features and special effects from the SNES, although at a lower resolution, thanks to its enhanced 16-bit PPU. Moreover, its 32-bit CPU was capable of 3D software rendering at higher performance then previous generation 3D chips (SVP and SFX), reaching an estimated peak of 4'000 poly/sec with shading and texture mapping at an acceptable framerate (in few games, like V-Rally 3 and Monkey Ball).

Some examples of 3D graphics output comparison:

Saturn	PSX	N64	Gameboy Advance

These additional data may help to understand the evolution of graphics quality in games through the years, thanks to improved libraries and better knowledge of the hardware by developers at the time. Data may contain some inaccuracies and have been rounded.

Saturn Games:

* Data obtained from Yabause emulator’s profiler while running games.
* SATURN used quads while PSX and N64 used triangles, to draw a quad they used 2x triangles.
** All polygons / sec data include polygons drawn by frame + polygons calculated (transformed) and submitted to the GPU but not seen (clipped), to approximate polygons / sec effectively drawn, reduce by a 30~35% these raw values. Eg. for Daytona USA, the Yabause emulator reports about ~ 19k poly/sec effectively drawn.

PSX Games:

* Data obtained from official profiling documentation, developers declarations or deducted by scenes/characters poly-count ripped from the games.
** Only 2 cars on screen (instead of 5)
*** All polygons / sec data include polygons drawn by frame + may include polygons calculated (transformed) and submitted to the GPU but not seen (clipped). Eg. for MotorToon GP2 the PSX Profiler Analyzer manual from Polyphony Digital reports about ~55k poly/sec effectively drawn.

N64 Games:

* Data deducted by scenes/characters poly-count ripped from the games.
** All polygons / sec data include polygons drawn by frame + may include polygons calculated (transformed) and submitted to the GPU but not seen (clipped).

---------------------------------------------------------------------------------------------
So, in your opinion which was the best hardware of the 32/64-bit generation?

Which console had the most impressive 2D graphics or 3D visuals?
Which one had the best overall 2D/3D graphics for the time?

Just choose based on your personal preferences for 2D graphics, 3D graphics or overall 2D/3D visuals.

Let the 32/64-bit war begin (again)! 

The N64 had the best 3D graphics of the three, but it was the weakest on 2D. A lot of companies didn't handle its filtering capabilities very well leading to blurry graphics.

PS1 generally got the best results with hybrids of 3D models on 2D backgrounds, as was done with Final Fantasy and Resident Evil. But Rare actually did the same thing in reverse with Killer Instinct Gold, carefully moving the backgrounds around to provide a pseudo 3D appearance to a 2D fighter. That's most noticeable in the stages for TJ Combo, Kim Wu, and Tusk.

A lot of how good games looked came down to the artistry and comfort level developers had with 3D graphics. Nobody could really touch Nintendo's circle of developers, which includes Rare, when it came to N64 games looking good. Konami got rather inconsistent results due to having some difficulty mastering 3D graphics. Castlevania didn't look nearly as good as Ocarina of Time. Mystical Ninja Starring Goemon utilized a simpler art style and actually didn't look bad.

Meanwhile, Tekken 3 utilized what were probably the best human models I saw of the generation as far as animation and detail, but since that game was 3D models on 2D backgrounds on PS1, Namco could concentrate on modeling and animating the fighters. Final Fantasy's battle animations were amazing, but there's also a difference between playing canned animated sequences and the things you could do in realtime in Ocarina of Time.

Saturn's games were much more primitive in 3D, but they still managed to come up with some good-looking games like Virtua Fighter (which had real 3D backgrounds, unlike Tekken), NiGHTS, and Panzer Dragoon Saga. I can't really attest to the 2D graphics, since I didn't own a Saturn and certainly didn't own a memory expansion for it to play the Capcom fighters. I wasn't really interested in those anyway.

And damn, I wish Nintendo had been able to finish Earthbound 64/Mother 3. Besides satisfying a desperate need for RPGs, what they had done looked really good. And it seems like they were pretty close to being able to finish, but it was too little, too late. It's too bad they couldn't at least move development to the Gamecube. 

For graphics, it was N64>PS1>Saturn. For sound, though, the PS1 laid waste the N64. That's what strikes me the most whenever I play my PS1 and N64. The sound quality because of the CD medium. It was ridiculous. Also, for some strange reason, cut-scenes tended to be better on PS1 as well. But I'm not tech savvy enough to tell you why.

SEGA Saturn is a more capable machine than given credit for. It was beastly but in a lot of ways similar to PS3 in why it was so difficult to work on and get the best out of it. So it was rarely done. The machine could do transparencies but again getting there is not easy so most settled on a mesh.(funny enough see a lot in Switch games)

I also feel SEGA Saturn is the 2nd best console that generation in terms of library esp when you go into the Japanese library which is rich with Shmups,fighting games and RPGs esp A number of other genres as well.

Is because storage space. If a nintendo 64 game went over 32mb it would teake a bigger rom chip and would be more expensive per unit to produce. For a ps1 game it was the same 32mb or 320mb, a cd would cost the same so they often put higher quality voice samples and higher quality video cut-scenes and sometimes higher quality textures. That makes an impact so it confuse some people into thinking the Ps1was more powerful. I remember a wrestling game that had more and higher quality voice samples and somebody saying look proof the Ps1 is more powerful. But that was just more storage at the same price.

I feel like the Atari Jaguar and 3DO should have been included here. Yes, they came out pretty early on (1993), they are still both 32-bit machines on a technical level. This is especially true given the fact that you've included the GBA in this comparison where DS would probably have fit better.

FMV is very storage-intensive, so the N64's cartridge format meant that FMV was very limited and what there was, was heavily compressed. See: The N64 version of Resident Evil 4, which came on a 64MB Game Pak.

The N64 didn't have a dedicated sound chip, to save on manufacturing costs. Sound had to be handled by the CPU and the Reality Co-Processor, which meant that N64 sound was competing with graphics and general computing, so it generally got the short end.

German developer Factor-5 did come up with an audio tool called MusyX that helped somewhat. Konami had a pretty good grasp of the N64's sound capabilities. Goemon had two vocal tracks, and Castlevania had some beautiful music.

In terms of pure processing power the N64 is on a completely different level than the other 2. Its CPU and GPU were 2-3 times more powerful, and that kind of difference meant something back then. It had state-of-the-art features like anti-aliasing and mip-mapping the competition didn't have. On paper N64 games should have looked night and day better than PSX games. But Nintendo shot themselves in the foot by deliberately designing it in a way that made it difficult to develop for, and it was up to other companies like Factor 5 to make the tools to get around these issues when Nintendo should have done so in the first place. It's a similar mistake to what Sony did with the PS3 a decade later, and this is when Nintendo started to learn that raw power isn't everything.

Just how much more expensive would the N64 had been if it had shipped without all of its design flaws and was easy to use to its full potential? Would it have really cost so much more if the system had a larger texture cache, for instance?

We also need to keep in mind that.... The Gamecube, Wii, WiiU, Switch, Xbox, Xbox 360, Xbox One, Xbox Series X, Playstation 2, Playstation 3, Playstation 4 and Playstation 5 are also 32bit or 64bit devices as well.

The OG Xbox being -the- most capable 32bit console ever with it's 32bit Intel Pentium 3 based processor and the Nintendo 64 being the weakest 64bit console.

If we are going by the CPU (as we seem to be in this thread), then the PS2 is 128-bit. I'd also argue that the Wii U had the most capable 32-bit processor.