Discuss alternate realities here!

[tomaitheous]

I realize that one processor can outperform another regardless of the bit-width. Nonetheless, the consensus between the three systems above was that the PS2 CPU outperformed the other two in polygon generation and game related performance.

This is the first I've heard anyone make that kind of statement. I mean, outside the clueless youtube vagrants (which I don't associate you with). Especially compared to the XBOX. I think polygon wise, they all looked with in range of each other. It was mostly texture and other graphical effects that looked better on the other two consoles. Maybe in rather useless numbers/specs (non real world numbers). I specifically remember GC's polygon numbers being reported well below PS2s, and yet the games (release and otherwise) always looked much better (resolution, textures details, texture colors, GFX, etc). If there was a multiconsole port of a game, I almost always bought the GC over the PS2 one because of this (having a 53" HD set in your face via component back then, really showed off the difference. Plus, there were more progressive output games on the GC VS the PS2 - which also made a noticeable step in video quality difference for motion). Could be my memory, but I seem to remember more PS2 ports of multiconsole game versions, having a little bit more slow down than the other ports. It wasn't across the board difference (number of games), but it was noticeable enough.

We're off topic, right? ;>_>

[sheath]

That is actually what I am trying to say. Everything I have seen so far says that the PS2 focused on its CPU (supported by its GPU) for polygon performance and the Xbox and GC focused on its GPU (supported by their CPUs) for the same. Supposedly, even though Xbox and GC games outperformed PS2 games, with rare exceptions, the PS2's CPU grunt still existed somehow (sound familiar?).

For that entire generation I could_not get away from conjecture that the PS2 was a "polygon monster" or some similar conclusion no matter where I read about it. I never saw it in the games, and Resident Evil 4 having to be toned down in textures *and* polygon counts on the PS2 version proved it wasn't true. But I was speaking to the consensus.

I am fairly confident that the majority of the Dreamcast, PS2, Xbox and Gamecube libraries are below 1.5 million polygons per second. My experience also implies that the texture resolution and color counts and effects favored everything but the PS2.

This sounds like the argument you and I had about the "16-bit" consoles, but this time it is the most popular platform that just doesn't show what it is said to be capable of.

[kool kitty89]

Not quite - the PS2 CPU was based on the 3900, a 32 bit MIPS with much (but not all) of the 64 bit architecture added. It used strictly 32 bit addressing to make it easier to drop into existing designs. The VR4300 in the N64 was true 64 bit.

Huh, haven't even heard of that one (can't find much info online either), was the 3900 a commercial product?

So it's a 64-bit MIPS CPU with a 32-bit address model? (I'd gotten the impression the R4300 had a 32-bit external address bus as well as a 32-bit data bus -but that doesn't have anything to do with the internal architecture -ie 68000, 68EC020, and 386SX with 24-bit external address buses)

The first Intel x86-64 CPUs were fully 32 bit internally, using microcode and the regular x86 architecture to simulate the AMD64 architecture. That's partly why XP64 was held back - it performed like a dog on Intel chips because they didn't have a true 64 bit mode. Intel recommended running in 32 bit mode for better speed at that time.

So it wasn't so much poorer performance in general, but just in 64-bit mode...

So for many applications you could still have very competitive performance on a fully 32-bit system compared to a comparable 64-bit system. (using a 64-bit AMD CPU of generally similar technology -ie NOT a newer/faster CPU)

If it hadn't been for addressing, 32-bit CPU/OSs could still be generally competitive (if not more efficient in some respects -if not performance, cost/performance ratio or other factors). And until very recently, the applications where more than 32-bit physical addressing was necessary were rather limited. (even now, for a big chunk of consumers/mass users it's not really necessary, probably the most common thing is wanting 4+ GB of RAM, and that's only as necessary as it is due to the bloating of newer OSs)

In many cases, older OSs (ie XP-32) are faster, but the support and features get ever limited. (there's fundamental limitations too, but a huge part is declining support in general) It's even true for increasingly older OSs (2k, 98SE, OS/2 Amiga OS, etc but also increasingly limited in general support)

That's even true with 64-bit CPUs, better performance (especially resource usage) than using a 64-bit OS, hell there's even cases of 32-bit programs being generally faster than the 64-bit version. (my dad's been playing around with Firefox 32-bit and 64-bit and 32-bit seems to benchmark consistently faster on his machine)
And if not total speed, at least resource use: ie RAM. (which will eventually limit speed if you start paging let alone thrashing -even with 2 MB and winXP 32, you'd likely be better off in many common cases than with 4 MB and vista/7 64-bit -vista/7 32 isn't nearly as good as XP in terms of memory consumption either, even if customized to cut back, at least from my experience)

This is the first I've heard anyone make that kind of statement. I mean, outside the clueless youtube vagrants (which I don't associate you with). Especially compared to the XBOX. I think polygon wise, they all looked with in range of each other. It was mostly texture and other graphical effects that looked better on the other two consoles. Maybe in rather useless numbers/specs (non real world numbers). I specifically remember GC's polygon numbers being reported well below PS2s, and yet the games (release and otherwise) always looked much better (resolution, textures details, texture colors, GFX, etc). If there was a multiconsole port of a game, I almost always bought the GC over the PS2 one because of this (having a 53" HD set in your face via component back then, really showed off the difference. Plus, there were more progressive output games on the GC VS the PS2 - which also made a noticeable step in video quality difference for motion). Could be my memory, but I seem to remember more PS2 ports of multiconsole game versions, having a little bit more slow down than the other ports. It wasn't across the board difference (number of games), but it was noticeable enough.

We're off topic, right? ;>_>

Not so much off topic but a tangent of the discussion targeting a claimed supporting argument about CPU capabilities, so it does have some bearing on the technical "what if" side of this thread.

The on-chip coprocessors with the CPU (even the FPU is arguable) could really be considered totally separately from the CPU itself (in terms of "the CPU doing the work"), especially in the context of non-standard/custom coprocessors specifically implemented for the game system. (vector unit in the Dreamcast, added hardware in the EE separate from the CPU block, etc -FPUs are standard in the Xbox and GC's CPUs, but that's still arguable as a separate coprocessor in the same sense separate FPUs were on older CPUs or the SPEs in the Cell -or the GTE in the PSX which is also on-chip with the CPU iirc)

And the fact that a "64-bit architecture" is not at all automatically indicative of performance... and that 32-bit CPUs are generally competitive in most respects with contemporary technology.

[Chilly Willy]

Huh, haven't even heard of that one (can't find much info online either), was the 3900 a commercial product?

Yes. It was a popular chip from Toshiba for palmtop PCs of the late 90's like this one: http://www.pencomputing.com/showcase/husky_fex21.html

Toshiba was also involved in the design and manufacture of the EE, so you can see why it was derived from the 3900 - that's what Toshiba was using for all it's embedded applications at the time).

So it's a 64-bit MIPS CPU with a 32-bit address model?

Yes.

(I'd gotten the impression the R4300 had a 32-bit external address bus as well as a 32-bit data bus -but that doesn't have anything to do with the internal architecture -ie 68000, 68EC020, and 386SX with 24-bit external address buses)

The 4300 has a 32 bit data and address bus, but that has nothing to do with the internal architecture, which is fully 64 bit (unless running in 32 bit mode, which disables all 64 bit instructions and switches back to 32 bit addressing).

The entire address space from 0 to 0xFFFFFFFF80000000 (unsigned -> 16 Mega Tera Bytes - 2 Giga Bytes) is available for apps, although the 32 bit bus on the 4300 limits the physical memory and IO. The 4300 was made for embedded applications where you didn't have to deal with huge amounts of memory. The N64 was a prime example... just a few MB of ram and a few MB for IO... nowhere close to even using the full 32 bit range of the bus. With the available MMU inside the 4300, you COULD make a virtual memory system that would allow apps as much virtual memory as you had space on a drive.

[kool kitty89]

Yes. It was a popular chip from Toshiba for palmtop PCs of the late 90's like this one: http://www.pencomputing.com/showcase/husky_fex21.html

Toshiba was also involved in the design and manufacture of the EE, so you can see why it was derived from the 3900 - that's what Toshiba was using for all it's embedded applications at the time).

Ahh, so it was a 3rd party development of the Architecture? (sort of like the R4600 -or various 3rd party x86 implementations among others)

Using the Toshiba reference makes it a lot easier to search for too.

It looks like it came out the same year as the R4300 too and was pushed in a similar sector of the market even.
http://www.toshiba.com/taec/componen...39_Core_um.pdf
So it's fully 32-bit externally, but with added 64-bit instructions and a 64-bit ALU? (and no onboard FPU)

The 4300 has a 32 bit data and address bus, but that has nothing to do with the internal architecture, which is fully 64 bit (unless running in 32 bit mode, which disables all 64 bit instructions and switches back to 32 bit addressing).

I'd gotten the impression that, as used in the N64, the R4300 was almost always in 32-bit mode, so much so that Project64 emulates the 32-bit operations and traps the few 64-bit ones. (and the use of the R4300 was mainly due to a lack of a similarly powerful 32-bit SGI/MIPS CPU with teh R3000 too far behind at least at the speeds available -though I suppose marketing a "64-bit" console might have had something to do with it too)

And if the SGI chipset for the N64 had been in development since 1993 (if not earlier), that would imply the R4300 was not the original choice at all or they were working around a prototype of the R4300 long before it came to market. (it seems rather likely that they may just have been working with an R4200 and switched to the even lower-cost R4300 later in the design)

That is actually what I am trying to say. Everything I have seen so far says that the PS2 focused on its CPU (supported by its GPU) for polygon performance and the Xbox and GC focused on its GPU (supported by their CPUs) for the same. Supposedly, even though Xbox and GC games outperformed PS2 games, with rare exceptions, the PS2's CPU grunt still existed somehow (sound familiar?).

That's not the CPU, it's a coprocessor on-chip with the CPU... (sound famialliar? -cough GTE cough-) And if you're implying the Saturn was like that, there's a LOT more to it than that, including the dedicated DSP coprocessor which was simply poorly documented.
NOW that IS familliar with the PS2, yes, both had poor software development tools, especially for high-level performance and even with good tools, it was still impossible to get really good performance without lots of low-level optimization. Except the PS2 was worse in that respect by a good margin than the Saturn or the Jaguar, and a lot of the games showed it... The difference was that developers were willing to pour tons of their own resources into the PS2 because of Sony's reputation and marketing hype. (to the point of developers taking it upon themselves to develop better tools as well as pushing the extremely demanding hardware in spite of far more attractive competition)

The PS2 proves possibly even more than the IBM PC that good hardware is not key when you have so many other advantages. (and IF you don't have those advantages you may still lose in spite of having the best product at the best price in the world) If you have all that reputation, funding, and good management and on top of that you still have a product that meshes exceptionally well with the market at the time (ie the PSX) it adds just that much more against the competition. (the PSX was sort of a perfect storm for Sony, and had they had much less ideal hardware, but still every other advantage, things wouldn't have likely been much different -assuming all the other companies did the same thing, especially in terms of management and funding)

The Emotion Engine is not just the CPU, it's an ASIC, like the chip containing the CPU+GTE in the PSX or the SH4+Vector coprocessor in the dreamcast, at least how I understand it. Putting stuff on-chip sort of muddies the waters for general comparison, but it's really not a different case than with other ASICs.

For that entire generation I could_not get away from conjecture that the PS2 was a "polygon monster" or some similar conclusion no matter where I read about it. I never saw it in the games, and Resident Evil 4 having to be toned down in textures *and* polygon counts on the PS2 version proved it wasn't true. But I was speaking to the consensus.

That's true, polygon pushing was the PS2's only real advantage overall, but that was complicated by the frustratingly difficult architecture and lack of tools exacerbating that further.

But polygon count doesn't mean much on it's own: other effects like texture filtering (a big range of quality there), texture resolution, bump mapping, antialising, shading and lighting effects, and efficient use of clipping are all very important factors. On top of that you have the difficult architecture making a lot of (especially early) games sub-par and the good games take a lot of effort and resources to actually push decent performance. (that's a big reason early PS2 games looked far worse than early -or all- dreamcast games and even a lot of later games didn't look as good -granted there's a few areas where the DC is fundamentally superior too, but not nearly to the extent of the Xbox or GC)

I am fairly confident that the majority of the Dreamcast, PS2, Xbox and Gamecube libraries are below 1.5 million polygons per second. My experience also implies that the texture resolution and color counts and effects favored everything but the PS2.

Yep, it's not all about polygon count: if that were the case, the N64 would look far worse compared to the PSX than it does. (and as it is, the biggest problem with the N64 is the limited ROM space forcing low-res/more compressed/lower color textures -the poor support for RSP programmability was another factor for wasted potential of course, but the N64 had a few dedicated developers persevering on that front, but the ROM issue was a no-go -closest you got was a few large, late games, be even those were only 32-64 MB)

This sounds like the argument you and I had about the "16-bit" consoles, but this time it is the most popular platform that just doesn't show what it is said to be capable of.

The only useful thing for bitness in the casual sense is to use in leu of formal designation of generations. I still don't like it for that as it's misleading (ie the 4th gen = 16-bit era while the 5th gen is the 32/64-bit era but there's a massive range applied to the 8-bit era from everything from 1976-1987 or a bit more even, and the 64/32-bit era is still raging on )
So the ONLY applicable "era" as such by bitness is really the 4th generation or 16-bit era, and even then it's misleading. (I believe all 3 major consoles have 16-bit video buses, but only 1 has a 16-bit CPU bus and that CPU is arguably 32-bit while one other is 8-bit to the core and the other is arguably 8-bit depending on the context)



Anyway, there's nothing wrong with keeping with 32-bit CPU architectures, the N64 wouldn't have been any worse off with a pure 32-bit CPU or similar utility. (could have technically been better off in some respects even outside of marketing...) The SNES would have likely been better off with a CPU more like the PCE and I think the PCE's bank switching was even less problematic than the 65816's. (though it also would have been better off with a simply faster 65816 derivative; even 5.37 MHz -with full speed RAM to match- should have really evened things out against the competition).
It does make you wonder how much marketing/perception had to do with hardware design. (of course, it's usually the other way around even if marketing sometimes takes a gimmick so far that it almost seems like the hardware was designed around that gimmick rather than it being a coincidence, but it would be interesting to know if public perception actually came into play)

[Chilly Willy]

Ahh, so it was a 3rd party development of the Architecture? (sort of like the R4600 -or various 3rd party x86 implementations among others)

MIPS doesn't make CPUs - they make a reference that they license to other companies to turn into their own CPUs. Very similar to ARM today.

Using the Toshiba reference makes it a lot easier to search for too.

It looks like it came out the same year as the R4300 too and was pushed in a similar sector of the market even.
http://www.toshiba.com/taec/componen...39_Core_um.pdf
So it's fully 32-bit externally, but with added 64-bit instructions and a 64-bit ALU? (and no onboard FPU)

That's what it's derived from. For more info on the EE itself, just google for "Emotion Engine". There's tons of info out.

I'd gotten the impression that, as used in the N64, the R4300 was almost always in 32-bit mode, so much so that Project64 emulates the 32-bit operations and traps the few 64-bit ones. (and the use of the R4300 was mainly due to a lack of a similarly powerful 32-bit SGI/MIPS CPU with teh R3000 too far behind at least at the speeds available -though I suppose marketing a "64-bit" console might have had something to do with it too)

I've heard that as well, but have no real idea of what percentage of N64 games actually run in 32bit mode.

The homebrew SDKs (libn64 and libdragon) both run in 64 bit mode. That might be partly why existing emulators can't run N64 homebrew.

And if the SGI chipset for the N64 had been in development since 1993 (if not earlier), that would imply the R4300 was not the original choice at all or they were working around a prototype of the R4300 long before it came to market. (it seems rather likely that they may just have been working with an R4200 and switched to the even lower-cost R4300 later in the design)

I seem to remember early N64 dev systems were just SGI workstations. There doesn't seem to be anything specific to the VR4300 compared to the 4000 reference, so any 4000-based part could have been used initially.

[kool kitty89]

I seem to remember early N64 dev systems were just SGI workstations. There doesn't seem to be anything specific to the VR4300 compared to the 4000 reference, so any 4000-based part could have been used initially.

I meant that if they intended on designing a reasonably cost-effective chipset for a game console, the R4200 would have been the best option prior to the even more cut-down 4300. (assuming they hadn't already been planning to cut the 4200 down further in 1993)

[Chilly Willy]

I meant that if they intended on designing a reasonably cost-effective chipset for a game console, the R4200 would have been the best option prior to the even more cut-down 4300. (assuming they hadn't already been planning to cut the 4200 down further in 1993)

They probably did start with the 4200. The 4200 is what NEC based the VR4300i on. It's basically a cost-reduced version specifically intended for low-cost embedded systems. The biggest thing cut was the hardware MMU - much like the PPC603, the 4300 uses software exceptions for the MMU handling.

[sheath]

That's not the CPU, it's a coprocessor on-chip with the CPU... (sound famialliar? -cough GTE cough-) And if you're implying the Saturn was like that, there's a LOT more to it than that, including the dedicated DSP coprocessor which was simply poorly documented.
NOW that IS familliar with the PS2, yes, both had poor software development tools, especially for high-level performance and even with good tools, it was still impossible to get really good performance without lots of low-level optimization. Except the PS2 was worse in that respect by a good margin than the Saturn or the Jaguar, and a lot of the games showed it... The difference was that developers were willing to pour tons of their own resources into the PS2 because of Sony's reputation and marketing hype. (to the point of developers taking it upon themselves to develop better tools as well as pushing the extremely demanding hardware in spite of far more attractive competition)

I guess that's as apt a comparison as any. I would say that the Saturn and Playstation 2 represent the same design philosophy. Very different solutions but a similar result of requiring assembly for full performance, which subsequently keeps garage developers out. The PS2's CPU would not function on its own without the FPU, VU0 or VU1. I've never read anything about it being advantageous that they were put on the same die as the CPU. I've also never read any developers complaining or bragging about getting them all working to their full potential. That's not to say that it didn't happen, but I'm keen to finding comments like that and never saw them.

For example, Melbourne house bragging about maxing out the Dreamcast at 5 million polygons per second, and Capcom saying they lowered RE4 on the PS2 to 900k polygons per second, are the kinds of quotes that I look for to see what the systems ended up being capable of.

The PS2 proves possibly even more than the IBM PC that good hardware is not key when you have so many other advantages.

Absolutely, and that is why I keep saying that if Sega hadn't lost arcades, the historical Saturn and 32X would have lasted longer, much the same as the Gamecube limped on because Nintendo still had the handheld market.

The Emotion Engine is not just the CPU, it's an ASIC, like the chip containing the CPU+GTE in the PSX or the SH4+Vector coprocessor in the dreamcast, at least how I understand it. Putting stuff on-chip sort of muddies the waters for general comparison, but it's really not a different case than with other ASICs.

Right, I understand that, but the coprocessors define what the systems are capable of and were added to, or assisted, the CPU, not the GPU. That is all I think I was trying to say.

That's true, polygon pushing was the PS2's only real advantage overall, but that was complicated by the frustratingly difficult architecture and lack of tools exacerbating that further.

Not to mention lack of GPU effects.

But polygon count doesn't mean much on it's own: other effects like texture filtering (a big range of quality there), texture resolution, bump mapping, antialising, shading and lighting effects, and efficient use of clipping are all very important factors. On top of that you have the difficult architecture making a lot of (especially early) games sub-par and the good games take a lot of effort and resources to actually push decent performance. (that's a big reason early PS2 games looked far worse than early -or all- dreamcast games and even a lot of later games didn't look as good -granted there's a few areas where the DC is fundamentally superior too, but not nearly to the extent of the Xbox or GC)

Ken Kuturagi's engineering career just rolled over in its grave.

Yep, it's not all about polygon count: if that were the case, the N64 would look far worse compared to the PSX than it does.

The entire thing started because of Sony's announced PS1 specs, and Gamefan and EA free advertising for the PS1 in 1995. If Sega hurriedly redesigned the Saturn based on what Sony claimed the PS1 could do on paper (1mpps flat shaded, 360k textured gouraud shaded), well, they just didn't. If they did they still failed utterly because even Sega's own Saturn specs lists 500k theoretical and 200k texture mapped non-gouraud shaded. With Gamefan and EA jumping up and down summer of 95 about Daytona "only" being 60k pps Sega had a PR/Marketing problem, not a system problem.

I do find it interesting why a number of multiplatform titles run at a locked 20FPS on Saturn and 30FPS on PS1 though. Developer comments indicate that those games weren't pushing 80k pps, which is well below say NiGHTs' rumored 160k gouraud shaded and lit.

Back on what you were saying though, yeah I agree, polygon counts, unless we're talking double or triple in one game (as was the case RE4), don't matter. What's more, the polygons per second spec is impossible to measure from the consumer side of things, I'd rather know the resolution (texture, internal and output) polygons per frame, and then the framerate personally.

The only useful thing for bitness in the casual sense is to use in leu of formal designation of generations. I still don't like it for that as it's misleading (ie the 4th gen = 16-bit era while the 5th gen is the 32/64-bit era but there's a massive range applied to the 8-bit era from everything from 1976-1987 or a bit more even, and the 64/32-bit era is still raging on )
So the ONLY applicable "era" as such by bitness is really the 4th generation or 16-bit era, and even then it's misleading. (I believe all 3 major consoles have 16-bit video buses, but only 1 has a 16-bit CPU bus and that CPU is arguably 32-bit while one other is 8-bit to the core and the other is arguably 8-bit depending on the context)

Heh, seeing a shiny chrome "61 Colors Onscreen" on top of my Genesis, or what if it was the TurboGrafx-7.16 Mhz! There was a very distinctive look to that generation of gaming too, it was very clear all three were in the same class and 16-bit versus 8-bit (NES/SMS) seemed apt. Nintendo marketed the NES as "a toy, not a videogame" and the SMS was pretty much supposed to be bringing the arcade experience home. Once the 32-bit consoles came along the obvious jump was to 3D, and they've just been cramming more of the same into each subsequent generation. Once things went exclusively 3D, performance was all that mattered to early adopters.

Anyway, there's nothing wrong with keeping with 32-bit CPU architectures, the N64 wouldn't have been any worse off with a pure 32-bit CPU or similar utility. ...
It does make you wonder how much marketing/perception had to do with hardware design.

Once Sega established the SH-4 as "128-bit" Sony had to do the same with the PS2 regardless of whether it mattered for the games. But we were all talking about polygon performance more than anything else on Usenet. MS dodged that bullet handily by having a system that so obviously looked different in the average game. Similarly to the SNES master palette facilitated "brighter," and therefore commonly thought more colorful, games, the Xbox's GPU effects and texture capabilities really stood out.

[kool kitty89]

Absolutely, and that is why I keep saying that if Sega hadn't lost arcades, the historical Saturn and 32X would have lasted longer, much the same as the Gamecube limped on because Nintendo still had the handheld market.

Hmm, yes, but Nintendo wasn't supporting nearly as many platforms as Sega had to deal with: the N64 was more or less dropped soon after the release of the GC (about as soon as the 32x was after the US Saturn launch) and the older consoles were already off the table (outside the used/budget only market -which the N64 was moving into), so ALL they had to deal with was the GBA and GC at that point. (some lingering GBC support perhaps)
But in 1995 Sega had: the Game Gear, lingering SMS support, Genesis/MD, MCD, 32x, Saturn, AND the arcade platforms to support. So it's not the same case at all. (the SMS was going to break off regardless, but that was minimal as development had little added cost over parallel GG releases)

One interesting thing Chilly Willy mentioned recently was that the Sega CD alone should have been reasonably competitive with the polygon pushing capabilities of the SVP, or especially Super FX. (in particular mentioning that VR probably could have been managed on the stock MCD and only be moderately slower than the SVP version -or be as fast but make some other cuts or optimization) And you have advantages over the SuperFX and SVP in terms of texture rendering and scaling/rotating objects. (but the amount of textures/objects used and their resolution would be heavily limited by RAM too)

Right, I understand that, but the coprocessors define what the systems are capable of and were added to, or assisted, the CPU, not the GPU. That is all I think I was trying to say.

Yes, but "GPU" is a very generic term, and you could have a complex ASIC referred to as the GPU with a lot of co-processors built-in... like if the GTE was inside the PSX's GPU rather than the CPU ASIC.
Sometimes general display processors (even simpler VDCs/VDPs) are called GPUs (even though they shouldn't be) or VDCs including blitter functionaility (arguably more GPU like), and then you have modern GPUs (or the "GPU" in the Jaguar) which are in another category entirely...
In the Jaguar's case, "TOM" is the ASIC contaning all the video coprocessors and the display processor and as such might be referred to as a GPU, but in the case of the Jag, the "GPU" actually refers to a rather flexible RISC microprocessor optimized for transform and lighting operations among other things. (and while not really a good CPU, it was flexible enough to be used for game logic as well... and mroe dedicated developers/homebrewers ended up using that as the main CPU and generally not using the 68000)

Hell, the N64's RSP is a customized/modified derivative of the R4000 CPU core used in the N64's CPU, and the PSP uses a CPU core very similar to the main CPU as a graphics coprocessor iirc.

Not to mention lack of GPU effects.

It had GPU effects for sure, but not as many integrated as some others... the GC and DC certianly didn't have all the graphics related co-processors on-chip with the GPU... (the FPUs were likely useful for graphics operations and especially the vector unit in the DC)

So again, it's a matter of context and confusion from the high degree of integration of such chipsets.

Actually doing things in software is another matter entirely and does indeed directly rely on CPU resource.

Ken Kuturagi's engineering career just rolled over in its grave.

I think the mention of height map engines alone over polygons would do that. XD

The entire thing started because of Sony's announced PS1 specs, and Gamefan and EA free advertising for the PS1 in 1995. If Sega hurriedly redesigned the Saturn based on what Sony claimed the PS1 could do on paper (1mpps flat shaded, 360k textured gouraud shaded), well, they just didn't. If they did they still failed utterly because even Sega's own Saturn specs lists 500k theoretical and 200k texture mapped non-gouraud shaded. With Gamefan and EA jumping up and down summer of 95 about Daytona "only" being 60k pps Sega had a PR/Marketing problem, not a system problem.

Regardless, if the redesign was true, the Saturn seriously needed a boost to remotely compete in the 5th gen (if the SH1+VDP2 speculation is correct).

And that initial spec never claimed gouraud shaded, but texture mapped and lit (ie flat shaded textures with light sourcing -which gives the faceted look of Virtua Fighter 2 on the PC with light sourcing on).
I think the 1 million polygons was based on the GTE's performance, which can do 1 million verteces/second peak I think, but that doesn't take GPU rasterization speed or general bandwidth limits into account.
You might be able to meet those specs under very specific circumstances, and that's how most hyped specs are pushed: even the Jaguar did that with the pixels/second figure. (true in a very specific context, but very misleading)
For pure practical purposes, the Saturn (with quads) and PSX (with triangles) are fairly close in peak performance but with a lot of variables. (especially with the Saturn's variable resource for vertex calculation -ie the amount of CPU resource used, if the DSP is used, etc)

Back on what you were saying though, yeah I agree, polygon counts, unless we're talking double or triple in one game (as was the case RE4), don't matter. What's more, the polygons per second spec is impossible to measure from the consumer side of things, I'd rather know the resolution (texture, internal and output) polygons per frame, and then the framerate personally.

Polygons rates are useful for general comparison, but without general context there's not that much to say. Doom (other than PSX/Saturn and modern source ports) has a polygon count of exactly Zero, as does Duke nukem, etc. (and I'm sure the poly count in Outcast is very low for what the game looks like)

Heh, seeing a shiny chrome "61 Colors Onscreen" on top of my Genesis, or what if it was the TurboGrafx-7.16 Mhz! There was a very distinctive look to that generation of gaming too, it was very clear all three were in the same class and 16-bit versus 8-bit (NES/SMS) seemed apt. Nintendo marketed the NES as "a toy, not a videogame" and the SMS was pretty much supposed to be bringing the arcade experience home. Once the 32-bit consoles came along the obvious jump was to 3D, and they've just been cramming more of the same into each subsequent generation. Once things went exclusively 3D, performance was all that mattered to early adopters.

Nintendo tried marketing the NES as a "toy" but in reality, that didn't really happen more so than previous consoles (which had been considered expensive toys in general)... the SMS was no exception, at very least after Tonka took chage with considerably improved marketing. (albeit too late)
Focusing on the arcade in the US in 1986 was bad management and clearly not knowing the US market in general with the still weak and recovering arcade market... (compared to Japan and Europe)

What nintnedo did was market to a broader audience in general, manage things extremely well along with the anti-competitive tactics. (they had the right market model, the right advertising, the right software, the right business sense, learned from previous failings in the industry, had the money to back it all up, etc -Sega and Atari had some of that but were missing in critical areas like management/market understanding or funding)

Once Sega established the SH-4 as "128-bit" Sony had to do the same with the PS2 regardless of whether it mattered for the games. But we were all talking about polygon performance more than anything else on Usenet. MS dodged that bullet handily by having a system that so obviously looked different in the average game. Similarly to the SNES master palette facilitated "brighter," and therefore commonly thought more colorful, games, the Xbox's GPU effects and texture capabilities really stood out.

Yeah, but that got halted after both got called on that BS and so goes the death of the bit wars.

All Sony had to do was point out the SH2 was really 32-bit as much as Intel's pentium. (or such)
Really though, if a company really played it smart, the bit wars could have been weakened if not broken before they were really established. (NEC had the most reason to do so with the "8-bit" stigma and again, it's not really hard to argue and give points like how the Master System and VCS are both 8-bit systems in the respect the PC Engine is, or that the Intellivision was 16-bit in the same sense the SNES was -etc)

[tomaitheous]

This sounds like the argument you and I had about the "16-bit" consoles, but this time it is the most popular platform that just doesn't show what it is said to be capable of.

Hahaha, it does Though, the discussion about the hardware we were talking about was much simpler relative to this generation being discussed here. Soo many more factors that come into play (either giving advantages or taking the ones that look good on paper away).

[kool kitty89]

Absolutely, and that is why I keep saying that if Sega hadn't lost arcades, the historical Saturn and 32X would have lasted longer, much the same as the Gamecube limped on because Nintendo still had the handheld market.

I missed this before: It's more than that, Nintendo also managed the GC a hell of a lot better than Sega did the Saturn regardless of the handheld buffer, and they also had a stronger brand name than Sega did overall (especially in Japan). The GC was the biggest (or pretty much only) direct competition the PS2 faced on the market in Japan from 2001 to 2006 and it actually had a surprising market share all things considered. (one could only guess what the DC might have done had it been pushed longer, though it probably would have come in behind the GC unless things picked up in 2001)

I still maintain that Sega didn't need the 32x and that it did complicate things, but I agree that the real problems came after that and could have been about as bad even without the 32x's release. (albeit the media would have less of a scapegoat)
Those problems were, of course: Sega launching the Saturn too early (August would have been a healthy head start, May was insane) with related problems with 3rd parties and retailers as well as limited software,
-Sega pulling back all consumer product resources to focus on the Saturn alone in 1996 including abrupt cancellation of the CD, 32x, and more gradual phase out of the GG and Genesis (along with dropping the SMS) while the CD and 32x should at very least have been phased out gradually and only if support was not merited by sales and the Genesis and Game Gear shouldn't have started to be phased out until much later (marketed up to 1999 at least) and even the SMS could have brought in some additional revenue. (especially if Sega had continued to sell it in Brazil rather than selling the rights to TecToy -albeit that sale likely helped funds more in the short-term).
-Then there's cutting back the marketing budget in mid 1996 (not sure on the context of that one though)
-Pulling back on the Saturn in the west in 1997 and not in a manner to facilitate a gradual phase out and overlap with the Dreamcast's release. (if they really didn't have the funds, they should have pushed for the niche market, but given the funds being poured into DC: cutting back a bit on that to help push the Saturn long enough to allow a smooth transition would have been a much better investment than putting it all-in with the DC -in fact, that's more or less the same mistake of pushing all-in with the Saturn in 1996)


But in terms of the 32x competing on the mass market, I really don't see it as necessary, especially as the mass market would have been competing with the SNES and the 32x didn't really help that at all.
I think that's part of the problem: Sega was pushing too much into the "next-gen" stuff rather than holding onto the mass 16-bit market which was dominant well into 1996 and still significant a year following that.
Nintendo took the very reasonable route of investing in more software for the SNES (which really paid off) and there's no reason Sega couldn't have done the same for the Genesis, not to mention the Sega CD. (if they were going to come out with a genesis related/compatible system for fall of '94, a low-cost Sega CD Duo would have been great, not to mention the on-cart enhancement possibilities -if they wanted something that meshed with the Saturn then the "Jupiter" would have made way more sense)

But after the fact, it was definitely a bad move to cancel the 32x like they did, but that tied in with reducing diversity in general: putting all their eggs in one basket with the Saturn. (albeit screwing up in a lot of other ways too and making that very same mistake again when pushing for the DC)

One other major factor was Sony's price point: the 32x itself would have been far more attractive as 5th gen competitor and especially in the context of the Saturn had the prices stayed higher longer as they likely would have without Sony's upset in the trend of marketing tactics. (ie the Saturn probably wouldn't have dropped to $300 until mid 1996, the N64 would have stayed $250 in '96, etc -and the 3DO and Jaguar would have had better chances to compete, etc)



So if anything the combination of weaker arcade revenue than expected and Sony's shocking marketing tactics forced Sega to react (or overreact) in panic and make rash actions that ended up hurting them a lot more than had they not reacted strongly at all. (with Nintendo you had the polar opposite tied to their major mistake: the arrogance/stubbornness to make the N64 cart only costing them Square and pretty much handing Sony the market when Nintendo could have put up considerably more competition)

[kool kitty89]

I was thinking on this again, and taking this context:
-Sega doing everything exactly the same as they did through 1992/93 (at least as far as the public was concerned)
-That the Saturn or any such successor to the Genesis was not going to be backwards compatible.

Sega as it was tended to (apparently) have a lot of parallel projects going on with groups of competing designs that would get whittled down to one... and with the arcade stuff that would seem to make sense, but also wastes a lot of money and R&D resources. (again, assuming that held true for console designs as well, which may not have been the case at all)
The big plus would be that they could aim at a number of predicted possible targets for where games were going and what features would be most needed in the future and then selecting the design that was closest to emerging trends.
If that was the case with the Saturn, they certainly missed the ball on that or perhaps all of their designs were not directly suited as such. (at least at low cost)
And you could argue that having the SGI chipset onboard as a competing design could have made sense too... or Sega initiating their own design based on the same performance concept, but that would still be expensive in general.

One major alternative to such an expensive approach would be to instead of starting parallel designs, work on a number of fairly modulate peices of hardware that could efficiently work together with each other and/or a variety of odd the shelf components as well, especially a variety of CPU architectures and bus configurations with relatively efficient bus sharing capabilities. Or even one single modular and very flexible consolidated component or ASIC that could have the rest of the system modified heavily depending on needs.

In contemporary standards the Jaguar chipset (especially TOM) would be a nearly ideal example of that with the exception of a few bugs caused by limited development time and resources for a 1993 release (something with Sega's funding would have addressed). Indeed Atari implemented the chipset in basically the lowest-end configuration possible short of omitting Jerry for a simple I/O and PCM sound chip and using an 8086 in place of the 68k. (or clocking the system speed even lower than 13.3 MHz) The architecture was aimed at allowing a variety of bus widths for the CPU (at least 16 and 32, I think 64 and possibly 8-bit even) as well as providing support for both X86 and 68k architecture CPUs and by extension, the majority of RISC processors on the market as well. (hence the 68EC020 and R3000 available in the arcade version)
In fact, SoJ might have been quite impressed with what Flare had if Atari had proposed selling or licensing the chipset back in 1992 or early '93 and not just in the sense of exceptional 2D performance and low-cost, but general flexibility and performance. (it could have been an absolute monster with dual DRAM banks or use of EDO DRAM or SDRAM at 26.6 MHz, or both, and using an SH2 in place of the 68k... using Jerry vs another custom sound chip would have trade-offs... though if they had time to fix Jerry's DMA to main memory, there's no way they would have dropped it as it would double the capabilities of the GPU -same core as the GPU but in the Jag it's got bugs to its DMA to main memory as well as being stuck on a 16-bit bus due to the 68k, so only an 8.8 MB/s vs 17.7 MB/s with 32-bits or 53.2 MB/s with 32-bit and fixed DMA... or double that with EDO/SDRAM) Had they had more funds from the start or a longer dev time, a GPU cache likely would have been possible too.

[SonicTheHedgehog]

I didn't vote for any of the above reality options as i feel and think there should be another option. My reality would of been no invention of Sega CD and no invention of 32x with all that time and money spent investing and pushing the MD and developing games for it. And then a better designed Saturn with one CPU (would a 40mhz SH2 with 8kb on chip cache have been competitive overall with Sonys mips cpu?) and one GPU or VDP (mabee working with SGI to improve their design that Sega turned down twice) and a more unified ram setup. Also adding hardware audio & video compression to the systems abilities and having excellent SDK'S. And finally having the system backward compatible with MD/GEN via the cartridge slot at the back and having a seperate slot for memory card/s. Perhaps an early 95 Jap launch and a Nov/Dec US & Europe launch and price it the same as Sony's machine. Then once out pester, beg, plead and throw money at Squaresoft to get them to agree on Saturn exclusivity. And i don't think they needed a Sonic game as the PS sold on the basis of its strong 3rd party support. A Sonic game alone wouldn't of sold the Saturn in the way the PS sold no matter how good it was.

Sega's reputation would of been probably the strongest in most of the world come the 32bit gen due to the MD gaining considerable market share and popularity coupled with the fact that they wouldn't of buggered up with 2 hardware failures and due to their Saturn being excellently designed like the PS so that anyone could work on it plus the fact that Nintendo dissappointed people by going with cartridges and for those reasons i think they could of got the exclusivity deals they needed to sell hugely in the 32 bit gen particularly Core Design and TR and many of the other good selling PS games would of appeared on Saturn. Then come the 128 bit gen due to the Saturn selling way more than in the real reality (i predict at least 50m units compared to this reality's 9.5m) and Sega having the best brand name in the gaming world and thus being financially waaaaaaaay better of due to the money they made in the 32 bit gen they could of launched a more powerful but just as easy to work on Dreamcast at the beginning of 2001 in Japan and around November in the US/Europe which was fully backward compatible with Saturn games and with DVD games storage and DVD movie playback (licensing fees easily afforded due to their increased financial position).

Yes the PS2 would of came in March 2000 but remember in this alternate reality it wouldn't of been anywhere near as anticipated due to the PS1 selling way less and the Saturn selling alot more and thus Sega could of just released a statement to all the gamers in the world along the lines of ''don't bother with PS2 as we are working on the Saturns successor that will be even more powerful, will also feature DVD playback and will be backward compatible with Saturn games'' and the control pad would of been better designed with dual analogues horizontal to each other like the dual shock and 2 top L & R buttons

We would of then probably seen a scenario with PS2 that we saw with Dreamcast as in it sells well at launch but as 2001 approaches and the Dreamcast comes out 3rd parties and gamers all switch their attention to Sega's machine and the PS2 sales start to dry up. And remember without the Playstation brands ultra strong reputation in this alternate reality the hard to work on PS2 would of actually counted against them alot more. All the GTA games all the FF games and more than likely EA'S sports games and the MGS games all would of come to Dreamcast and it probably would of sold like the PS2 sold in reality.

Oh and one final thing if i was the head guy at Sega making all these decisions and at the same time i had come from this 2011 reality thus having all the gaming history knowledge i would of overruled the rest and choose to name the Saturn the Dreamcast. I don't care if they argued with me and tried to explain that they wanted to name their system after planets i would of stood firm and convinced them in seeing the beauty of the name Dreamcast and would have to just make up the fact that i came up with the name after having a good Sega dream . The Saturn was not a popular name with the gaming masses and in naming the Saturn Dreamcast it would of then allowed me to tell Sega to name their 128 bit successor the Dreamcast 2 when it was time to launch it. Dreamcast Bomberman anyone!

Other little silly obsessive things of mine i would of done was made the Dreamcast (formerly Saturn) white with blue power/reset/open buttons in all territories and on the disk lid i would of had the SEGA writing on the top part of the lid in colour (blue) and the Dreamcast writing where the Sega Saturn writing was which was on the lower part of the lid and had the swirl blue in all territories. I'm aware it was Orange in Japan for luck reasons but i would of quickly overruled that aswel and said ''sorry we don't need luck we are skillful and blue must represent the Sega brand always and worldwide (just like red is associated with Nintendo and Green is associated with Xbox). It would just be my way of making Sega's machines stylish and aesthetically attractive/pleasing in its own unique way which we all know works.

[KnightWarrior]

Kool Kitty89 Wow, your replys is like a book..When someone replys with 30 words, you come out with 500 words..