Which consoles have been called 'PC in a box'?

@ronvalencia:

The Xbox's graphical prowess comes from its NV2A GPU, not the PIII. It's the NV2A's hardware T&L that does all the geometry processing, not the PIII. The PIII doesn't need to do any graphical processing, but it's the NV2A that does all the graphical processing, from the geometry to the rendering. The PIII had very little to do with the Xbox's graphical capabilities. The main reason Microsoft selected the PIII as the Xbox's CPU is because of its compatibility with PC. As we've already discussed previously, the SH-4 performs faster geometry calculations than a PIII 800. But that's unnecessary for the Xbox if its NV2A GPU already has its own more powerful hardware T&L for geometry processing.

SuperH had a more efficient instruction set than x86 at the time. A SuperH instruction never exceeds 2 bytes, whereas an x86 instruction can take up to 15 bytes. There was also a benchmark that found "SH3 architecture generates smaller code than the x86". SuperH's efficient instruction set was licensed by ARM to create the Thumb instruction set, now widely used by mobile devices. The SH-4 also introduced 4D vector instructions, which x86 lacked at the time, allowing the SH-4 to perform faster geometry calculations (as we've already discussed previously).

Like I said previously, the Dreamcast doesn't need as much external memory bandwidth, due to its tiled-rendering architecture and deferred-rendering capabilities. Its fast on-chip cache (with up to 15 GB/s bandwidth) renders a tile-buffer and handles Z-sorting on the chip, meaning there's no need to render a Z-buffer (or even a framebuffer) in RAM. And its deferred-rendering capabilities means it only needs to render a fraction of the polygons and textures in a scene, as it only renders the polygons and textures actually visible on the screen, without any overdraw. So the only polygons and textures it needs to access from RAM are the ones visible on screen. The Dreamcast's tiled-rendering architecture has far more efficient bandwidth usage, equivalent to a non-tiled GPU with up to 6 GB/s memory bandwidth (and that's without even taking texture compression into account).

The GeForce 3 released in 2001, so it's irrelevant. The 4x AGP transmission bus was a limitation in the year we're actually talking about, 1999.

Far Cry's minimum system requirements include a PIII or Athlon running at 1 GHz, along with a GeForce2 or Radeon 8500 (or a 64 MB graphics card). That goes well beyond what a 1999 PC could handle.

As for that 3DMark2000 benchmark, its polygon count for the GF256 (with PIII 800E) is only about 1.7 million polygons/sec. In comparison, DOA2 was pushing over 4 million textured polygons/sec on the DC. The 3DMark2000 benchmark also only reaches up to 3.41 MB texture data per frame. In comparison, Shenmue was pushing 5 MB texture data per frame on the DC (equivalent to 25-30 MB uncompressed textures), and that's only for the textures actually visible on screen (equivalent to about 10-20 MB per frame, or 50-100 MB uncompressed). In other words, that GeForce 256 benchmark has already been outperformed by actual Dreamcast games in terms of polygon counts and texture data.

Again, CPU still has geometry control points processing due game simulation logic processing.

Understand T&L's role https://en.wikipedia.org/wiki/Transform,_clipping,_and_lighting

Transformation is the task of producing a two-dimensional view of a three-dimensional scene. Clipping means only drawing the parts of the scene that will be present in the picture after rendering is completed. Lighting is the task of altering the colour of the various surfaces of the scene on the basis of lighting information.

Both GeForce 256 (Oct 1999) and Matrox G400 (Sep 1999) introduced fix function T&L and bump mapping.

T&L reduces the processing load on Pentium III CPU which enables it to focus on geometry control points processing and game logic.

T&L unit has evolved into vertex shader unit e.g. GeForce 3 into introduced programmable T&L as vertex shaders.

DX7/DX8/DX9 fix function T&L and programmable vertex shader units are already 32bit floating point (FP32) units.

DX7 fix function pixel pipelines are integers

DX8 programmable pixel shaders are integers

DX9 programmable pixel shaders are floating point. Floating point can be FP16, FP24 and FP32.

DX10 programmable pixel shaders are mandatory 32bit floating point (FP32).

It would take DX10 era GPU to enable geometry control processing i.e. GPU-geometry shader hardware and GPU-stream-out.

Limit your expectation on T&L's workload scope. PS3's CELL slots itself for CPU categories with GeForce 7.

Xbox 360's DX9L+ vertex shaders has additional features which includes GPU-stream out and tessellation unit.

DX8 era GPU doesn't handle all geometry processing! You're jumping the gun since it's DX10 era GPU has your requested feature!

My point still stands, Pentium III Coppermine at 733Mhz still beats Dreamcast on geometry processing.

Geometry processing involves more than ADD or MUL functions being applied on the matrix number values since game code has intersection/compare branch test. Branch test processing is 4X faster on Pentium III at 800 Mhz when compared 200 Mhz SuperH-4 CPU

https://www.beyond3d.com/content/articles/50/3

GeForce has a lower peak performance than some high-end general-purpose CPUs running optimized software T&L engine. But does this have any meaning for a game? Not really. In a game, your CPU is doing much more than just T&L. The whole game is running on your CPU. Now what hardware T&L does is remove load from the CPU. So the simple fact is this: a CPU running nothing but T&L is faster than the GeForce, but the essential thing to remember is parallelism. So, in a real game where the CPU has to do "so" much more than just T&L, the GeForce would end up winning. Say that 25% of the time is spent on T&L in a software situation, and during that 25% you can only reach 25% of the peak number we measure here. Our conclusion is this: in a game situation, GeForce will be faster. The CPU software T&L combo is only faster when 100% of the time is devoted to T&L, which is never the case in a real game anyway. So, although in this peak test the GeForce is lacking, it will win in all true games.

...

The main thing to remind you of is that this "software test under discussion" is a peak test; these peak software numbers are only reached when your CPU does nothing but T&L. We know that this is not true in real life; the CPU has to do much more in a true game situation. And this is why GeForce will be faster in games: it takes load away from the CPU. So what if the GPU is a bit slower than what the main CPU could do on its own in some special peak test. The point is, in a game the GeForce will help out and your game will run faster.

@ronvalencia:

The Xbox's NV2A GPU has a powerful hardware T&L unit capable of calculating 5.8 GFLOPS and over 100M vertices/sec. It's the NV2A doing all the matrix transformations, projection transformations and lighting calculations. The NV2A takes away all the load for the actual polygon geometry and lighting calculations, freeing up the PIII to focus on the physics and game logic.

Besides, your line of argument is nonsensical. Your argument essentially boils down to the Xbox (2001) being more powerful than the Dreamcast (1998), therefore that somehow makes a 1999 PC more powerful than the Dreamcast. That's a logical fallacy. How powerful the Xbox is tells us nothing about how powerful a 1999 PC is. I could just as easily use a similar line of argument by bringing up Sega's SH-4 based arcade systems, such as the Sega Hikaru (1999) and Naomi 2 (2000), both of which wiped the floor with 1999-2000 PCs, and therefore that would somehow make the SH-4 more powerful than the PIII and Athlon according to your own logic.

Either way, we've already confirmed on the previous page that the SH-4 calculates polygon geometry and lighting faster than the PIII. The PIII takes anywhere from 17 cycles to 31 cycles just to perform a 4x4 matrix transformation, whereas the SH-4 only takes a measly 4 cycles to perform a matrix transformation. And benchmarks show the SH-4 transforming and lighting more than 10M triangles/sec, whereas the PIII 750 can only transform and light 6.7M triangles/sec (equivalent to 7M triangles/sec for the PIII 800). The point still stands that the SH-4 is a more powerful geometry processor than the PIII 800.

You are losing your time Ronvalencia will use the most out of this world arguments to try to win and quote 300 irrelevant charts in the process.

The dude claim the xbox 360 still selling now,because every xbox one sold = another xbox 360 sold because the xbox one can play some 360 games.

That derange is ronvalencia.

I already show him how expensive it would have been to own a damn pentium 3 800mhz which again were release on the very end of 1999,basically 2000 when the DC launched in 1998,and it was freaking $700 in quantities of 1,000 in other words retailers prices,so that Pentium 3 basically was use in 2000 and was like $800 or more just for a CPU,the Gforce 256 was another $300.

Using a 800mhz CPU vs a 200 mhz SH4 is just another lol worthy moment clock by clock that SH4 was better than the Pentium 3 for what it was intended.

@tormentos: Yeah, Ronvalencia just seems to be going around in circles, repeating the same arguments, and going off on irrelevant tangents (e.g. the Xbox, which has hardly anything to do with the debate). I've already provided more than enough sufficient evidence to prove my original point that the Dreamcast was, graphically speaking, at least as powerful as the most high-end PC hardware available in late '99 (Pentium III 800 with GeForce 256). So there's not really much more to add here.

False.

T&L doesn't handle control points geometry!

Due to multiple NPC opponents, Quake 3 has higher path finding logic workload when compared to "Dead or Alive" game.

Handling branch heavy physics and path finding workloads reduces the computational resource on SH-4 CPU's T&L capability.

Quake 3 on Dreamcast didn't not demonstrate render capability superiority on apples to apple example.

Quake 3 supports OpenGL T&L to reduce workload on the CPU on hardware that supports it which enables the CPU to focus other workload task.

T&L workload is only part of the problem to be solved.

Again, understand T&L's role https://en.wikipedia.org/wiki/Transform,_clipping,_and_lighting

Transformation is the task of producing a two-dimensional view of a three-dimensional scene. Clipping means only drawing the parts of the scene that will be present in the picture after rendering is completed. Lighting is the task of altering the colour of the various surfaces of the scene on the basis of lighting information.

Try again.

Xbox One's Xbox 360's BC is re-enabling Xbox 360 games sales . My argument is consistent for PC master race being applied for Xbox.

You are the real derange fool.

Your argument is consistent with a totally derange fanboy,by your logic the PS1 sold 346 million units because the PS2 and PS3 could play PS1 game,oh wait no 426 millions i forgot the PSP could also play PS1 games.

Man can't you be a man and admit you were wrong? Man have some decency no one will believe that shit.

About Quake III...

...I don't think anymore needs to be said. Ronvalencia can try make whatever excuses he wants to explain away such a huge gap in textured polygon performance.

You're still wrong since my argument is not against PS2's backward compatibility with PS1. MIPS CPU designers during this time are still evolving their CPU competitively, but there are signs prior to PS2's release that MIPS CPU designs are already behind with the clock speed race when compared to other RISC CPU vendors e.g. PowerPC, Alpha.

With CISC-RISC hybrid CPU designs, AMD and Intel are ahead in clock speed race over pure RISC competition during year 2000. IBM didn't give up on the clock speed race.

Fat PS3 has the PS2 hardware which doesn't contribute to PS3's overall performance nor boost PS2 game performance hence it's a waste of silicon which is different to Xbox One's Xbox 360 BC since it didn't waste silicon like fat PS3's PS2 BC.

PS5's BC plans to leverage PS4 platform by PC style evolved super-set hardware improvement methods.

Try again.

---

MIPS CPU IP are still protected by the US government.

https://shiva-engine.com/how-many-polygons/

Dead or Alive series, Character – ~10,000-15,000 on Xbox. Game world scope is very small with tiny little path finding workloads.

Xbox version has more polygons over Dreamcast version.

Deal with it.

Btw, Star Wars Jedi Knight II (OpenGL, Quake 3 based engine) has double the polygon count over Quake 3 . https://www.newgamenetwork.com/article/104/jedi-knight-ii-jedi-outcast-review/

https://www.anandtech.com/show/910/9

GeForce 2 MX 400 is similar to GeForce 256. https://www.anandtech.com/show/570/10

https://www.anandtech.com/show/570/9

Where's Dreamcast's 117 fps Quake 3?

The GeForce2 MX performs just as like we expected at 640x480 - matching the rest of the GeForce line in 16-bit color, and matching the GeForce SDR in 32-bit where memory bandwidth starts to become an issue. Notice the T&L enabled cards (the GeForce line and the Savage 2000 based Viper II), take the top 5 spots in this benchmark.

-------------

Gears of War, Xbox 360, 2006 (for comparison)

Wretch – 10,000 polygons with diffuse, specular and normal maps

Marcus – 15,000 polygons with diffuse, specular and normal maps

This is a larger world game scope when compared to Dead or Alive series. Xbox 360 has 48 unified shader for both vertex and pixel shading (not factoring additional 192 fix function pixel co-processors in EDRAM).

Dreamcast's theoretical capabilities didn't yield superior Quake 3 results which supported T&L. Dead and Alive lacks game world maps for path finding and many NPC AI workload.

Dreamcast is moving two less than Xbox's 10,000-15,000 polygons characters at 60 fps.

https://www.anandtech.com/show/429

GeForce 256 DDR was release on December 25, 1999 which doubled it's memory bandwidth.

So, with a simple switch of memory types, the GeForce's memory bandwidth rockets from 2.7GB/s to an unparalleled 4.8GB/s*

https://forum.beyond3d.com/threads/yes-but-how-many-polygons-an-artist-blog-entry-with-interesting-numbers.39321/

Half-Life, Dreamcast, 2000-2001 (Canned)

Zombie - 1649 polygons <------ Couldn't match PS2's version LOL.

Half-Life, PS2, 2001

Zombie - 2822 (Highest LOD)

Half-Life 2, PC, 2004

Alyx Vance - 8323 polygons

Barney - 5922 polygons

Combine Soldier - 4682 polygons

Classic Headcrab - 1690 polygons

SMG - 2854 polygons (with arms)

Pistol - 2268 polygons (with arms)

Yet again, Ronvalencia bringing up irrelevant things (like 2001 Xbox/PS2 games and 2001-2004 PC games/hardware, when we're talking about 1999 here) and recycling arguments that have already been refuted (poorly-optimized ports like Quake III which barely tap a small fraction of the Dreamcast's power, and arguing memory bandwidth when I already pointed out the Dreamcast's tiled/deferred rendering makes its bandwidth equivalent to around 5-6 GB/s without even taking texture compression into account).

But nice try with the NPC AI and pathfinding excuse... Shenmue was an open-world game with the most advanced NPC AI, pathfinding and weather system of its time, yet it still pushed far more textured polygons than 1999 PC games.

Dreamcast polygon counts:

• Shenmue - 57,150 polygon backgrounds, 14,361 polygon characters
• Dead or Alive 2 - 51,894 polygon backgrounds, 9,246 polygon characters
• Jet Set Radio - 57,378 polygon scenes
• Sonic Adventure - 50,000 polygon scenes
• Sports Jam - 18,357 polygon characters
• Half-Life (Dreamcast) - 2836 polygon characters, 3411 polygon bosses

PC polygon counts:

• Half-Life (PC) (1998) - 1000 polygon characters, 2500 polygon bosses
• Quake III Arena (1999) - 10,000 polygon scenes, 1000 polygon characters
• Unreal Tournament (1999) - 900 polygon backgrounds, 800 polygon characters
• Star Wars: Jedi Knight II (2002) - 20,000 polygon scenes

The fact remains that Dreamcast games were pushing far more textured polygons than 1999 PC games. Deal with it.

I think this might be a good point to end the debate. Agree to disagree?