Questions about PS2

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

 

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).

 

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.

 

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.

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 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.

 

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

 

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.

 

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...

 

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.

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

 

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

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.

 

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...

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...)

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

GS physically connects to the EE, so yes.

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.

 

This answers my question perfectly. Thanks.

 

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.

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.

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.

 

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.

 

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.