Questions about PS2

[I.S.T.]

Okay, Mario Kart... Was so long ago I forget about these games. Anyway, billboards are a relatively insignificant amount of scenery in the majority of N64 games. Killer Instinct had two rather large and prominent fighters on-screen all the time, so it was pretty unique from that standpoint.

You're forgetting the other games milk listed. Those are sprite-ey as fuck

 

[MJP]

I've heard that before, and AFAIK no, it is not correct. Saturn used quadrilaterals instead of triangles, which meant some inherent disadvantages in 3D rendering; these quads were also used as sprites, which may have led to this confusion.

I'm no Saturn expert, but after skimming some old Saturn development documents it doesn't seem like an unfair assessment. The only way it supported texturing was when rendering quads,and the texture (or portion of the a texture) had to be implicitly mapped to the 4 vertices of the quad (no UV coordinates). In fact the docs actually used the exact term "distorted sprite" for the draw command that supported transformed textured quads (it also supported other "2D" modes that only supported flipping, or scaling).

 

[Exophase]

IIRC, the PSX used triangles as sprites. Not sure if this is correct, mind you, but it'd make sense. I've never heard of any 2D hardware in the system.

PS1 does have sprite primitives, which draw axis aligned rectangles 1:1 from texture to screen space. AFAIK the fillrate is double vs drawing textured triangles because of the simplified texture addressing. I'm guessing that the sprite rendering doesn't break into triangles, although it's impossible to say for sure.

 

[Liandry]

I believe you don't have to calculate polys twice, to do multi-texturing you re-submit the same geometry, but with different textures each time.

But what is the problem then? Suggesting by your previous post it's not the best use of hardware.

No, scratchpad is like regular RAM (only faster, because it runs at CPU clock and is SRAM so probably no or practically no waitstate cycles penalty for accessing it); it stores whatever you manually put in it and only that. Caches have logic to automatically mirror the most-used memory locations without user intervention.

Ok. But then my question, is here some reason for scratchpad memory in PS2, is it useful?

There is no special blocks for those things; like in the original Playstation, the GS uses flat polygon quads for that, oriented parallel to the viewport. Since they're flat and parallel, I believe simpler calculations can be used to process these types of objects, making them fast to generate.

Yes, but IIRC GS can't calculate polygons, so all those quads are calculated by EE? Or not?

To everyone else, grea discussion! Please keep going.

 

[Grall]

But what is the problem then? Suggesting by your previous post it's not the best use of hardware.

No, my post quite specificially states that the PS2 hardware design is not suitable for a portable unit, because its basic architecture is primitive and overgunned, for making up for its primitive nature. An efficient design would draw multitextured pixels in one pass, not in multiple, reading back and blending pixels over and over.

Ok. But then my question, is here some reason for scratchpad memory in PS2, is it useful?

Of course it is useful, but 64k of scratchpad is always going to be LESS useful than the 256k of associative cache in the Gamecube.

Yes, but IIRC GS can't calculate polygons, so all those quads are calculated by EE? Or not?

Yes of course. Or if you were an on-rails type game, you could stream geometry straight off disc, like Crash Bandicoot did back on the old PS. But that style of gameplay is pretty limited.

 

[Shifty Geezer]

No, my post quite specificially states that the PS2 hardware design is not suitable for a portable unit, because its basic architecture is primitive and overgunned, for making up for its primitive nature. An efficient design would draw multitextured pixels in one pass, not in multiple, reading back and blending pixels over and over.

There's a reason why modern mobile SOCs use tile based deferred rendering - probably the exact opposite of PS2's approach!

 

[Liandry]

No, my post quite specificially states that the PS2 hardware design is not suitable for a portable unit, because its basic architecture is primitive and overgunned, for making up for its primitive nature. An efficient design would draw multitextured pixels in one pass, not in multiple, reading back and blending pixels over and over.

Oh, how I undersand. So you think PS2 architecture was good enough?

Of course it is useful, but 64k of scratchpad is always going to be LESS useful than the 256k of associative cache in the Gamecube.

Wasn't it 16kb?

Yes of course. Or if you were an on-rails type game, you could stream geometry straight off disc, like Crash Bandicoot did back on the old PS. But that style of gameplay is pretty limited.

So all geometry goes from EE (polygons + sprites(quads) + particles)? And it is this - "3D CG Geometric transformation with raw 3D perspective operations (VU0+VU1): 66-80+ million vertices per second"? Or particles have no connection with geometry?

 

[Shifty Geezer]

Oh, how I undersand. So you think PS2 architecture was good enough?

It enabled Sony to sell the best seling console ever, with 155+ million units sold and billions in software. It enabled Sony to keep dropping the price to hit mainstream buyers. It produced visuals mostly on par with its rivals and with some amazing specialist games that targeted it well. So yes, it was good enough! Could it have been better? Sure. Could certainly have been easier for devs! But then look at the other platforms who also were far from perfect. "Good enough" is about as good as a console gets, probably. There'll always be compromises - the 'perfect' console would cost way too much money.

 

[milk]

Back to the Saturn sprite vs. quad discussion, because I'm curious about it...
A sprite in the classical sense, is a picture drawn on screen during scann-out. Its used in beam-chasing type graphics hardware, without an actual screen buffer. (some of those have one ore a couple line-buffers though, I guess...)
Within that deffinition, psone supports pseudo-sprites. As they are 2D untransformed pictures rendered onscreen, much like sprites. But they are drawn into the screen buffer using the same rasterization hardware that polygons do.
What I wonder, is if the saturn work in the same fashion, or does it rely in oldschool beam-chasing? In other words, do saturn games have a screen buffer?
The NDS, for exemple was a weird example of a hybrid type thing. It rasterized polygons on a scanline basis, and its gpu was more of a black box than other 3d rendering hardware, much like older 2D consoles. That approach, despite bizarre, has the benefit of giving a hard incentive for devs to run at 60fps...

 

[Liandry]

It enabled Sony to sell the best seling console ever, with 155+ million units sold and billions in software. It enabled Sony to keep dropping the price to hit mainstream buyers. It produced visuals mostly on par with its rivals and with some amazing specialist games that targeted it well. So yes, it was good enough! Could it have been better? Sure. Could certainly have been easier for devs! But then look at the other platforms who also were far from perfect. "Good enough" is about as good as a console gets, probably. There'll always be compromises - the 'perfect' console would cost way too much money.

Thank you for this great explanation!

Can anyone explain one more think. I'll take as an example first Xbox. As I understand it, graphics on it works like this: Vertex blocks calculate polygons (don't know about sprites and particles like PS2), then Pixel blocks make all pixel effects (like bump mapping, specular mapping, glow, post processing effects), then Texture units make texturing, and then ROP blocks make rasterisation. I may be wrong. But I absolutely can't understand how all this processes (chain of processes) goes on PS2.

 

[Shifty Geezer]

A sprite in the classical sense, is a picture drawn on screen during scann-out. Its used in beam-chasing type graphics hardware, without an actual screen buffer. (some of those have one ore a couple line-buffers though, I guess...)
Within that deffinition, psone supports pseudo-sprites. As they are 2D untransformed pictures rendered onscreen, much like sprites. But they are drawn into the screen buffer using the same rasterization hardware that polygons do.

What you describe in PS is what we'd used to term 'bobs'or blitter objects. They are images in RAM copied directly into the framebuffer. This can be front or backbuffer, the former resulting in flickering etc.

However, sprites have come to mean rectilinear images since forever, regardless how they are drawn. So we have sprites as you describe, sprites as bobs, and sprites as quads in 3D hardware.

What I wonder, is if the saturn work in the same fashion, or does it rely in oldschool beam-chasing?

The specs suggest to me 'beam chasing' as it's listed as 'unlimited sprites per line'.

 

[Shifty Geezer]

Vertex blocks calculate polygons (don't know about sprites and particles like PS2), then Pixel blocks make all pixel effects (like bump mapping, specular mapping, glow, post processing effects), then Texture units make texturing, and then ROP blocks make rasterisation. I may be wrong.

Yep. Although the texturing is part of the pixel effects.

But I absolutely can't understand how all this processes (chain of processes) goes on PS2.

Think of it like Xbox, with the GS having the pixel blocks, texture blocks and ROPs inside a black box. So the GS draws pixels - polygons go in and pixels come out. However, it can only draw a single point of colour with no shader code unlike Xbox. So you create your geometry with EE (VUs), then draw it, sampling a texture if wanted. If you want more than a simple texture and lit sample per pixel, you draw over that pixel again with another colour and blend it.

 

[Liandry]

Think of it like Xbox, with the GS having the pixel blocks, texture blocks and ROPs inside a black box.

Then GS Pixel Pipelines is Pixel block + Texture unit + ROP combined?

So you create your geometry with EE (VUs), then draw it, sampling a texture if wanted. If you want more than a simple texture and lit sample per pixel, you draw over that pixel again with another colour and blend it.

Draw again is send results to EDRAM and when from it to GS again? And it is two passes then?

 

[Grall]

I'm no Saturn expert, but after skimming some old Saturn development documents it doesn't seem like an unfair assessment.

Sprites have traditionally been independent of the backgrounds in console and arcade hardware (typically sharing palette registers though), while Saturn "sprites" (and polys) are drawn straight into the background (framebuffer).

I can only assume this distinction is mainly because older-style consoles and arcade machines did not have framebuffers, they used character-mapped displays instead, so there was nothing really to draw into. Also, redrawing even the small amounts of data encompassing a bit/byte-mapped framebuffer at TV rez 50 or 60 times a second would have been very burdensome for the processors available at the time. So hence, character mapping and sprites were used...

Oh, how I undersand. So you think PS2 architecture was good enough?

Good enough to become the best-selling console ever, yeah. It wasn't the easiest console to learn and master though (putting it mildly, I suspect...)

Wasn't it 16kb?

Quite possibly! I really don't remember after all this time. Which would be even worse, by the way.

So all geometry goes from EE

GS physically connects to the EE, so yes.

And it is this - "3D CG Geometric transformation with raw 3D perspective operations (VU0+VU1): 66-80+ million vertices per second"?

Those are marketing numbers, I don't think any game software ever hit close to those levels. VU0 IIRC was also poorly designed and difficult, if not outright impossible to use efficiently in a real-world situation.

 

[Liandry]

GS physically connects to the EE, so yes.

Isn't it the same on Xbox and GameCube?

Those are marketing numbers, I don't think any game software ever hit close to those levels. VU0 IIRC was also poorly designed and difficult, if not outright impossible to use efficiently in a real-world situation.

I know it's marketing, just asked is polygon numbers also contain all this quads for sprites and particles? Speaking about VU0, it calculated all physics, AI, animation and a lot of other stuff. And did it quite good, if we look at best PS2 games.
How about VU1, is it also poorly designed?

 

[milk]

Sprites have traditionally been independent of the backgrounds in console and arcade hardware (typically sharing palette registers though), while Saturn "sprites" (and polys) are drawn straight into the background (framebuffer).

This answers my question perfectly. Thanks.

 

[Grall]

Isn't it the same on Xbox and GameCube?

Curiously, no... In these machines, the CPU hung off of the GPU instead. PS2 was such a custom jobbie it included the system memory controller on the same chip as the CPU itself. Older computer systems traditionally placed memory controller in the northbridge or similar external I/O chip - which in original XBox's case was integrated with its geforce GPU. Gamecube used an IBM powerPC, which also lacked integrated memory controller.

PS2 leveraged its eDRAM very heavily (it was bigger than Gamecube's eDRAM if you recall) and relied on streaming textures from RAM and drawing polygons in texture order rather than front-to-back order to make maximum use of its limited EE-GS connection bandwidth.

This is yet another reason btw you do not really want PS2 as the basis of a handheld console, because to avoid streaming the same texture multiple times you drew all polys using said texture all at once, regardless of if these textures would get covered up by something else or not. Ordinarily, you would want to make use of your Z-buffer and also do front-to-back rendering to avoid wasting fillrate, but PS2 had so much of that it didn't really matter. As long as you paid attention to the hardware's quirks and particulars you could fill each frame at least a dozen times over at 60Hz VBL. Maybe more, I don't recall the exact numbers mentioned here by PS2 devs.

Speaking about VU0, it calculated all physics, AI, animation and a lot of other stuff. And did it quite good, if we look at best PS2 games.

Are you sure about that? Because according to Fafalada (PS2 dev and - now ex - poster here), VU0 really did not see much use in games since it had to be babysat so much by the main CPU, and this was a drag on performance, not a boost. The particulars escape me, but that is the gist of what I seem to recall.

How about VU1, is it also poorly designed?

VU1 was basically a full independent processor IIRC, so no. VU1 is what made PS2 a functional system. It ran all geometry calculations for GS, and maybe more stuff too for all I know.

 

[Exophase]

Back to the Saturn sprite vs. quad discussion, because I'm curious about it...
A sprite in the classical sense, is a picture drawn on screen during scann-out. Its used in beam-chasing type graphics hardware, without an actual screen buffer. (some of those have one ore a couple line-buffers though, I guess...)
Within that deffinition, psone supports pseudo-sprites. As they are 2D untransformed pictures rendered onscreen, much like sprites. But they are drawn into the screen buffer using the same rasterization hardware that polygons do.
What I wonder, is if the saturn work in the same fashion, or does it rely in oldschool beam-chasing? In other words, do saturn games have a screen buffer?
The NDS, for exemple was a weird example of a hybrid type thing. It rasterized polygons on a scanline basis, and its gpu was more of a black box than other 3d rendering hardware, much like older 2D consoles. That approach, despite bizarre, has the benefit of giving a hard incentive for devs to run at 60fps...

Saturn's sprite processor, the VDP1, renders to a backbuffer in VRAM, so it isn't like the traditional 2D sprite hardware you describe. The VDP2, on the other hand, does draw tiled layers in the traditional fashion, and combines in the sprite plane that way.

While Nintendo DS does have a line-based renderer, it's decoupled from the 2D engine by a 48 line buffer. So at least you can go over rendering time for a few lines without having to drop polygons. But if that buffer fills up it starts dropping entire scanlines worth of 3D pixels.

Sadly, a fair number of Nintendo DS games are 30 FPS despite having hard 60 FPS rendering. I guess they weren't that tight with the CPU or geometry usage. Some of these games feed a ton of non-viewable polygons to the geometry processor and rely on its culling without having very good high level CPU culling.

 

[Exophase]

There's a reason why modern mobile SOCs use tile based deferred rendering - probably the exact opposite of PS2's approach!

Funny thing is that PSP's GPU was kind of sort of like a scaled down Graphics Synthesizer. Definitely nowhere remotely as high throughput, but still eDRAM based and in a discrete chip.

 

[Liandry]

Curiously, no... In these machines, the CPU hung off of the GPU instead. PS2 was such a custom jobbie it included the system memory controller on the same chip as the CPU itself. Older computer systems traditionally placed memory controller in the northbridge or similar external I/O chip - which in original XBox's case was integrated with its geforce GPU. Gamecube used an IBM powerPC, which also lacked integrated memory controller.

Oh, now I understan that you talking about. Interesting, never though about it.

PS2 leveraged its eDRAM very heavily (it was bigger than Gamecube's eDRAM if you recall) and relied on streaming textures from RAM and drawing polygons in texture order rather than front-to-back order to make maximum use of its limited EE-GS connection bandwidth.

So, polygons go from EE to EDRAM, then from EDRAM to GS and thei they are textured, and then for some effects they go to EDRAM again and from it to GS and they textured again. Right?

Are you sure about that? Because according to Fafalada (PS2 dev and - now ex - poster here), VU0 really did not see much use in games since it had to be babysat so much by the main CPU, and this was a drag on performance, not a boost. The particulars escape me, but that is the gist of what I seem to recall.

Maybe it depends on developer, i don't know, but I've red a lot about VU0 usage in that way in some PDF's.

VU1 was basically a full independent processor IIRC, so no. VU1 is what made PS2 a functional system. It ran all geometry calculations for GS, and maybe more stuff too for all I know.

As I know it can only calculate geometry and lighting.