Why the bad PS2 filtering?

[Fafalada]

Is that related to mip-mapping?

Actually that IS mipmapping.
Thing is, there's nothing wrong with filtering as such (there's only so many ways you can do linear interpolation ), it's the selection of mipmap levels for each rendered texel that is simplified as nAo said.

What this means for developer is that you have to calculate certain koeficients manually even for basic mipmapping to work, and calculate yet some others if you want it to work in the same vein (or at least close to) as other more 'accurate' implementations.
This also doesn't change the fact that great many games still chose to not use mipmapping at all - although the issues with the way GS handles mipmaps may have dissuaded some people from using them.

.i guess the devs choose to have a sharper although more aliased look in order to fit more stuff into memory. they could use mip-maps but that would cut something else (e.g different varieties of textures).

This was one of the worst misconceptions you could make about PS2 though, as you are effectivelly making a tradeoff to make your game look a lot worse and very likely also run slower.

Next you'll be telling me it can't do back-face culling

Well bf cull would hardly have any effect on GS at all (except wasting some more transistors ).

 

[notAFanB]

it's just a matter of good scheduling of the rendering process.

but the problem is.........

 

[Simon F]

.i guess the devs choose to have a sharper although more aliased look in order to fit more stuff into memory. they could use mip-maps but that would cut something else (e.g different varieties of textures).

This was one of the worst misconceptions you could make about PS2 though, as you are effectivelly making a tradeoff to make your game look a lot worse and very likely also run slower.

Is the internal GS (texture) memory page-based then?

Next you'll be telling me it can't do back-face culling

Well bf cull would hardly have any effect on GS at all (except wasting some more transistors ).

Your saying that the time it takes to fill a polygon is completely negligible? I find that hard to believe. :? Besides, if you've ever had the 'pleasure' of working out the set-up maths for texturing, you'll see that the back-face test is virtually free.

 

[Fafalada]

Is the internal GS (texture) memory page-based then?

Internal organization is page based yes, accessed by the rasterizer through two page buffers/caches (one for FB/ZB, one for texture).
The page breaks are still cheap compared to normal ram (page refill happens at 150GB/s), but even so if they happen too often...
I was also referring to the fact that mipmapping allows you to save a lot of bandwith on the external bus to GS.

Your saying that the time it takes to fill a polygon is completely negligible? I find that hard to believe. Besides, if you've ever had the 'pleasure' of working out the set-up maths for texturing, you'll see that the back-face test is virtually free.

Believe it - the fastest VU can cull is 2 cycles overhead per poly (1 GS clock) and the rendering will already be slower then not culling at all.
Anyway, I believe you it's a tiny silicon cost, but would I be very wrong if I guessed that having one more iterator for perspective correct RGBA would also be a small cost? And yet neither GS nor Flipper implement this... :? And I think I'd pick this over bf cull, personally.

 

[Grall]

BGA is not half-field rendered, and I don't think GT3 is either.

oh yes they are. very much so.

I'm SURE BGA isn't, because it's supposed to have "4x" SSAA; ie 2x vertical via flicker filter and 2x horizontal via double-width screen buffer. So it can't be field rendering if that's the case.

*G*

 

[Panajev2001a]

Fafalada,

wouldn't avoiding the backface-culling test increase the vertex data traffic on the GIF-to-GS bus as you would be sending polygons that you really "know" won't be rendered ?

 

[ERP]

wouldn't avoiding the backface-culling test increase the vertex data traffic on the GIF-to-GS bus as you would be sending polygons that you really "know" won't be rendered ?

In most implementations you'd actually submit exactly the same amount of data if backface culling was on or off.

Your mostly dealing with strips, so unless the entire strip is culled, you generally just tell the GS not to render the primitive and submit the vertex anyway (since it's vertex will be used by subsequent primitives).

The reason that the raterisation speed is basically not relevant is that with decent parallelism all that matters is what the slowest part of the system is. That's almost never the GS. If your submitting a lot of objects, or have complex game logic it'll be the Mips portion of the EE, and if your runtime tessalating it'll be VU 1.

 

[London Geezer]

BGA is not half-field rendered, and I don't think GT3 is either.

oh yes they are. very much so.

I'm SURE BGA isn't, because it's supposed to have "4x" SSAA; ie 2x vertical via flicker filter and 2x horizontal via double-width screen buffer. So it can't be field rendering if that's the case.

*G*

u want a way to see which games are field rendered and which ones aint? get a Blaze VGA adapter and see the effects.

thats it.

GT3 IS field rendered.

BGA is field rendered, whatever tricks they use to make it look anti-aliased. someone said it was rendering at an insane resolution then scale down, but maybe we can get someone to explain how it really works, cuz this game IS field rendered. the output resolution is 640X240 or something like that. which means that u canNOT get pro-scan. all games that are NOT field rendered allow pro-scan display, and GT3 and BG do not.
easy as pie.

 

[Phil]

trust you or the blaze VGA adapter? Just because you see the same results on that particular game with known field-rendered games doesn't necessarely mean it is in fact field rendered. Or do you know how the Blaze Adapter works and for a fact that it works with every game 100%?

Small pieces of evidence rarely tell the whole story...

 

[_phil_]

BGA renders a 1280 x448 backbuffer .

 

[Bowie]

I think people have different definitions for field-rendering. BGDA has a 1280x448 back-buffer and a 640x224 front-buffer. GT3 has a 640x448 back-buffer and a 640x224 front-buffer. The back-buffer is the buffer that is actually rendered to, so if the back-buffer is 640x448 or higher, some people might call that full-frame rendering. But the front-buffer is only 640x224 so some people might call that field-rendering.

 

[marconelly!]

This was one of the worst misconceptions you could make about PS2 though, as you are effectivelly making a tradeoff to make your game look a lot worse and very likely also run slower.

I was always under the impression that this might be the case with some developers. 30% of extra texture memory is not something that seems one would 'throw away' if he believes mip-mapping is not that much important.

Otherwise, would you say that it's just that developers can't bother developing their own mip-mapping calculations, is that too difficult for most people, or is it too cpu intensive?

 

[Squeak]

wouldn't avoiding the backface-culling test increase the vertex data traffic on the GIF-to-GS bus as you would be sending polygons that you really "know" won't be rendered ?

In most implementations you'd actually submit exactly the same amount of data if backface culling was on or off.

Your mostly dealing with strips, so unless the entire strip is culled, you generally just tell the GS not to render the primitive and submit the vertex anyway (since it's vertex will be used by subsequent primitives).

Then how come SCEE, in one of their numerous powerpoint presentations told developers to "Back face cull to reduce GS stalls"?
Link: http://www.technology.scee.net/sceesite/files/presentations/agdc2002/PS2Optimisations.ppt

The reason that the raterisation speed is basically not relevant is that with decent parallelism all that matters is what the slowest part of the system is. That's almost never the GS. If your submitting a lot of objects, or have complex game logic it'll be the Mips portion of the EE, and if your runtime tessalating it'll be VU 1.

If fillrate is such a non issue, then how come we don’t see any games tiling a small detail texture over large surfaces? In that kind of rendering operation memory size or bandwidth wouldn’t be an issue, but fillrate would.

 

[Squeak]

Is the internal GS (texture) memory page-based then?

Internal organization is page based yes, accessed by the rasterizer through two page buffers/caches (one for FB/ZB, one for texture).
The page breaks are still cheap compared to normal ram (page refill happens at 150GB/s), but even so if they happen too often...
I was also referring to the fact that mipmapping allows you to save a lot of bandwith on the external bus to GS.

Of course that wouldn’t be the case with a texture continuously tiled from camera position to far away (like grass)?
As I understand it, it's best to have mip levels of the same texture on the same 8Kb page. But wouldn’t that force ridiculously low resolutions (its bad enough that 8Kb is just enough for 128x128x4 texture)
I know I've stated this as a fact in some other posts before ( ), but isn’t it possible to seamlessly put two or more textures together side by side, for better resolutions?

Your saying that the time it takes to fill a polygon is completely negligible? I find that hard to believe. Besides, if you've ever had the 'pleasure' of working out the set-up maths for texturing, you'll see that the back-face test is virtually free.

Believe it - the fastest VU can cull is 2 cycles overhead per poly (1 GS clock) and the rendering will already be slower then not culling at all.
Anyway, I believe you it's a tiny silicon cost, but would I be very wrong if I guessed that having one more iterator for perspective correct RGBA would also be a small cost? And yet neither GS nor Flipper implement this... :? And I think I'd pick this over bf cull, personally.

Wouldn’t some kind of occlusion culling be advantageous? Large amounts of texture and geometry transfer could be saved, surely that would make a difference?

 

[cthellis42]

If fillrate is such a non issue, then how come we don?t see any games tiling a small detail texture over large surfaces?

I think that particular one would come from it looking like crap all the time. (At least if used excessively, which is what one would be doing to really make a big impact with that.)

 

[London Geezer]

I think people have different definitions for field-rendering. BGDA has a 1280x448 back-buffer and a 640x224 front-buffer. GT3 has a 640x448 back-buffer and a 640x224 front-buffer. The back-buffer is the buffer that is actually rendered to, so if the back-buffer is 640x448 or higher, some people might call that full-frame rendering. But the front-buffer is only 640x224 so some people might call that field-rendering.

thank you, just what i was trying to explain...