Worst system design flaws in consoles?

[Crazyace]

could have been a contender

If the Saturn had dithering in it's gourard shading the difference in look between it and the PSX would have been far smaller.. ( There was the annoying highres only in 8bit VDP1 limitation as well, but that wasn't relevant to as many games )

The trouble with some of the comments, such as raising EE-GS BW , or doubling textured filluse from 8 to 16 is that those limits aren't arbitary, but often come from the balance of the whole system.

 

[archie4oz]

That was sort of the point I was making in the first half of my post (the rest was just wish list)...

 

[nAo]

On the new generation console the most flawed undoubtely is the PS2.
Sometimes I think GS is not even a completed project.
The rasterizer can't even figure out that for a given triangle it should rasterize all the pixel that lies in a page first and the move on the next page. Instead it fills primitive from up to down, left to right..
In many cases that cut the fill rate in half I believe even the voodoo1 was smarter than that.
But that's not all the story...GS has no clipping for primitives that lies trough near or far plane (but at least you can clip on screen bounderies with scissoring).
But the 'best' broken feature is mip map LOD calculation...it's pretty fun how it does it, a completely non sense.
Sometimes I wonder who projected that chip...it shows they weren't much experienced in the GFX HW field if even a rookie like me can point out what is broken and think how could have been done better..

ciao,
Marco

 

[Rodéric]

Marco, where did you find that kind of informations about the PS2 and the rasteriser capabilities ?

Just asking cause I never found that kind of stuff online, and would be interested in reading a bit more about the GS design.

 

[Fafalada]

If I was fixing PS2 I'd double the main memory before anything.
It's the only feature that would actually make a sizeable difference, and one of the very few among already suggested improvements that wouldn't break the balance of the system. (obviously I-32 would be even more efficient, but ... let's try to be realistic )

Most other stuff is just small improvements... But if I had to pick and choose I'd like to see a r5900 with proper caching scheme yeah, maybe even an L2.
But since we're on wishlists, one thing that would be really neat is a 300mhz IPU, especially if it could also quantize into 8bit (and not just 4bit) data, particularly if it did that in single pass rather then through a feedback loop.

GS has no clipping for primitives that lies trough near or far plane

That would be a common "flaw" for vast majority of rasterizers out there. Just looking at consoles... PVRDC doesn't do near/far clipping either, and on Flipper, frustrum clipping is performed by the Transform Processor(and is also rather slow from what I heard), not the rasterizer. Not sure about NV2a.
Although granted, if GS could take H-Space vertices and did the clipping work itself it'd be a nice relief for VU coders.

 

[Crazyace]

rasterising

Marco,

It's a lot more difficult to generate a rasteriser that encodes blocks ( but not impossible ) and given the silicon area restrictions it may not have been worth it... The largest slowdown shown by the GS is about a factor of 2, which is pretty good compared to the competition...

Rookies often come up with brilliant ideas that in practise have to be disregarded - experience is often merely the ability to filter out such ideas first....

Faf,

More main memory would be nice - but L2 cache on CPU ( or just bigger L1 cache ) would improve gamecode performance more..
and tiny improvements to alpha blend ( 8 bit signed option, colour * colour, alpha * alpha etc ) would improve multipass a lot. Indirect textures would be nice, but difficult to implement easily, although VQ could be a minor modification of the CLUT mechanism.


As far as I can tell NV relies on amazingly large floating point guard band, along with some form of midpoint subdivision ( Easier to iterate along subdivisions than calculate intersection directly )

in general the nice thing about a console is that as the hardware is fixed you just get on with it and find solutions - ( On PS2 only clip geometry that intersects view frustum coarsely - very few polys ever go down the slow path, - or in certain games don't even clip properly - just cull at guard band and rely on 2d scissoring )

 

[nAo]

Most other stuff is just small improvements... But if I had to pick and choose I'd like to see a r5900 with proper caching scheme yeah, maybe even an L2.

Yeah...that would be a big win for the r5900.

But since we're on wishlists, one thing that would be really neat is a 300mhz IPU, especially if it could also quantize into 8bit (and not just 4bit) data, particularly if it did that in single pass rather then through a feedback loop.

PVRDC doesn't do near/far clipping either, and on Flipper, frustrum clipping is performed by the Transform Processor(and is also rather slow from what I heard), not the rasterizer. Not sure about NV2a.

Dunno about PVRDC of Flipper, but NV2A performs rasterizing in H-space and it clips away pixels adding edge equations to the standard edge equations for the primitive, and correctly handle primitives that wrap at infinity (in fact you can use that to draw all the pixel that doesn't lie in a given triangle with some tricks on the W component )

Although granted, if GS could take H-Space vertices and did the clipping work itself it'd be a nice relief for VU coders.

Yeah..darn clip code!

ciao,
Marco

 

[archie4oz]

If I was fixing PS2 I'd double the main memory before anything.
It's the only feature that would actually make a sizeable difference, and one of the very few among already suggested improvements that wouldn't break the balance of the system. (obviously I-32 would be even more efficient, but ... let's try to be realistic)

Yeah, more main mem was on the list, but I figured that was an easy one that everybody asks for on every system. As for the I-32, well the GSCube just simply spoiled me...

Most other stuff is just small improvements... But if I had to pick and choose I'd like to see a r5900 with proper caching scheme yeah, maybe even an L2.

I'd personally go for the bigger L1. L2 is basically the compiler's "oops" bucket. It also adds (and requires) more complexity to the cache hiearchy (not to mention more headaches if you're rolling your own compiler and). More sophisticated cache load/store, prefetch, mark and locking instructions would be nice (one particular facet I love about PowerPC)...

I also wondered about how cache line size would affect things (i.e. 128-byte lines to force larger, more greedy prefetches, but then you're looking at artificially shrinking your caches; not good)...

did the clipping work itself it'd be a nice relief for VU coders.

Oh c'mon, clipping code is fun!

At least you don't have to do scan-line conversion...

 

[Fafalada]

Ace,
yeah performance wise that'd be better to have no doubt (it'd be nice not having to be afraid of almost every pointer indirection you write). And I'd like very much to have the convenience of added blending stuff, aside for improved multipass it would make all the framebuffer math all the more powerfull.

Nao,
well I'd say NV2a is the exception that confirms the rule then, At least when it comes to consoles or older PC graphic chips.

Archie,

As for the I-32, well the GSCube just simply spoiled me...

Yeah, unlike some of us mortals that toil in the salt mines

And I did my share of scanline conversion and other pretty things that went along with it in the past thank you very much, I have no particular desire to go back to that. It was fun when I was 10 years younger (although I have to admit, I found some nostalgic fun in making a few effects using nothing but a few GS CRTC registers )
Anyway, clipping code may be fun, but having to think about keeping memory for clip buffers around isn't so much. Especially with shaders that generate their own vertex data...

 

[randycat99]

How about the Win2k kernel in the Xbox that will cockblock you everytime from coding to the metal (to either the CPU or the GPU), should the developer wish?

 

[Glonk]

How about the Win2k kernel in the Xbox that will cockblock you everytime from coding to the metal (to either the CPU or the GPU), should the developer wish?

huh?
That's not what I've heard.

 

[DeathKnight]

Yeah. Devs can certainly code to-the-metal in the Xbox if they so desire. Game code also runs at Ring-0 which is pretty much at the metal.

 

[ERP]

Personally I've often wondered why MS refer to the XBox OS as win2K at all. You can write to the hardware directly, there is no available documentation for some of it, but you can trace the OS calls and roll your own if you really want to.

And FWIW since it started this discussion, the Jaguar shipped very broken. It would take a lot more that 1 simple fix to make it perform the way it should have.

 

[archie4oz]

I'd probably toss in the afterthought second CPU of the Saturn in as well...

 

[evil]

Don't know if it counts as a console here, but the biggest design flaw in a console ever, in my opinion, is the lack of a backlight on the Gameboy Advance.

Second is the 'Microsoft' logo on the X-Box

 

[Tagrineth]

Archie4oz: Saturn's second CPU would be good if the system had the bandwidth to run both at decent speed...

evil: The only handheld with a backlight I've ever used was the Sega Game Gear and oh my GOD does that thing have the worst screen ever. I had to keep one finger on the brightness dial at all times... :\

-----------
MY VOTE: Super Famicom's stupendously underpowered CPU. Just imagine how complex games could've become if its CPU was 3-4x faster...

 

[fbg1]

Personally I've often wondered why MS refer to the XBox OS as win2K at all. You can write to the hardware directly, there is no available documentation for some of it, but you can trace the OS calls and roll your own if you really want to.

I would guess the answer to that is the Dashboard. While you can circumvent the XOS in coding games, the Dashboard is the defacto OS for the box. Settings, Music, Live, and Memory all controlled by the stripped w2k kernel.

 

[ERP]

I would guess the answer to that is the Dashboard. While you can circumvent the XOS in coding games, the Dashboard is the defacto OS for the box. Settings, Music, Live, and Memory all controlled by the stripped w2k kernel.

It was a retorical qiuestion actually.
The reason is because they started with the 2000 kernel, the thread model remains intact as do a number of core technologies. Most of the interfaces remain syntactically similar although most of it has been rewritten.

I just think "Win2K kernel" is misleading to your average joe, who assumes that an OS is a windowing interface. From a marketing standpoint it would probably have been smarter to avoid the term.

 

[fbg1]

I just think "Win2K kernel" is misleading to your average joe, who assumes that an OS is a windowing interface. From a marketing standpoint it would probably have been smarter to avoid the term.

I see. Good point. I think they tried to do that with the term "Dashboard", although the more tech-savy audience caught on to "w2k kernel". I wonder if the non-tech-savy caught onto it too, and got confused.

 

[Mr. Angry Pants]

I don't think the average joe cares what OS a video game console is running.

The 3DO's 32kb of internal memory for saved games was woefully inadequate and short sighted on the part of the console's designers. Yes, it may have been difficult to predict the kind of space requirements complex games of the generation would demand. However, if 3DO wanted its console to become 'The next VCR' then they should have made increasing the console's save space easier and cheaper.

Instead I had to load up Game Genie and compress all the saved games I wanted to keep, play my game of choice, save, load Game Genie again, then compress that save file and decompress the save file for the game I wanted to play next. Argh.