Perspective Correction --- What's up with that?

[Goku7]

Or, at least the lack of it in the GPU plugins. Yes, yes, I know that the PSX doesn't do perspective correct, but by the same token, it doesn't perform Bilinear Filtering on textures either-- yet practically all GPU plugins let you use Bilinear Filtering.

So, my question is, why haven't we had an option for it in GPU plugins? Is there some technical reason it can't be done?

Lewpy, Pete, Nikk, care to explain?

[Raziel]

Well, since the PSX has no Z-buffer, perspective correction can't be done(the same goes for anisotropic filtering).

[Goku7]

And let me guess-- mask bits (the closest thing the PSX has to a z-buffer) can't be forced to be used in a way that would let the perspective correction work?

And, I didn't realize that you needed a z-buffer for perspective correction. But, it does make sense, now that you mention it.

[Raziel]

Learned that from the mighty Pete himself .

[Nezzar]

How would the games graphics be influenced by this change neway?

[Kane]

It would mean that textures wouldn't be warped, like they are at the moment, and polys wouldn't shake as much.

[Quasius]

Would it be possible to emulate a z-buffer on a high-end video card? Note that I don't really know what I am talking about; I am just guessing.

[Raziel]

err,I don't thinks so .

[Kane]

Basicaly all 3d graphics cards already have it, and PC games taht use 3d acceleration use it. The N64 Emus use it.
The problem is that if you wanted to use that feature to emulate PSX games, you would have to resort to high level emulation, and on the PSX, that would mean emulators which would run one game, maybe two at most. Not really worth it in all honesty

[Lewpy]

Okay, I will post a quick explanation on this, as I've posted several long essays on this in the past and can't remember exactly what I've said ... last thing I want is someone saying "You said this now, but you said this on {insert some really old date in here}!!"

Here goes: the PSX GPU does lack a z-buffer (the N64 does have one, afaik). Because the PSX GPU lacks a z-buffer, no depth information is passed to the GPU with the primitives that are sent for rendering. Because there is no depth information sent with the primitives (ie. on x & y values are sent), there is no way to do perspective correct texturing (which requires *correct* depth values for each vertex in the primitive, so the 1/z interpolation can be performed).

Bilinear filtering does not require any more information than the PSX GPU already gets passed, so it can be enabled. *BUT*, bilinear filtering does require carefull layout of textures in VRAM, which most PSX games do *not* do. This means there are glitches when enabling bilinear filtering, such as black halos (due to chroma-keying issues).

Perspective correct texturing would stop texture "swimming" or "warping", but would be dependant on the PSX game doing perspective correct clipping on the side of the view-port. If the game just does simple clipping, and does no take 1/z interpolation in to account when clipping primitives, you will still get texture swimming on the edge of the view-port, particularly when cameras are slowly panning, etc.

Perspective correct textuing would not really help "wobbling" polys: that needs sub-pixel accuracy in the vertex data (PSX has no sub-pixel accuracy, so everything is rounded to integer values). This is also why small objects do not scale very well even when running an emulator at 1600x1200: one step on the PSX screen of 320x240 results in a jump of 5 pixels on the emulator screen! If the PSX had sixteen levels of sub-pixel correct vertex data, the emulated screen would still be sub-pixel correct.

Theoretically, it would be possible to use some HLE techniques to pass the z information for each vertex to the GPU, as the GTE does actually calculate the z value (used for depth-sorting the primitives, so they are sent to the GPU in reverse depth). But there are many catches to this:-
- The game may modify the z data after calculating it in the GTE
- The game may not use the GTE commands

Basically, each game would probably use the PSX components in different ways: certainly, in my experience, the GPU is used [& abused!!] in so many different ways, sometimes by the same company.
The practicality of doing this kind of HLE for PSX emulation seems very very low. You would probably be better off just simply porting the 3D engine of each and every game to native x86 code

Okay, I wrote more than I anticipated

[Kane]

Ah, I was nearly right. Thanks for clearing up the bit about sub-pixel accuracy.

[Raziel]

Originally posted by Lewpy
Okay, I will post a quick explanation on this, as I've posted several long essays on this in the past and can't remember exactly what I've said ... last thing I want is someone saying "You said this now, but you said this on {insert some really old date in here}!!"

Here goes: the PSX GPU does lack a z-buffer (the N64 does have one, afaik). Because the PSX GPU lacks a z-buffer, no depth information is passed to the GPU with the primitives that are sent for rendering. Because there is no depth information sent with the primitives (ie. on x & y values are sent), there is no way to do perspective correct texturing (which requires *correct* depth values for each vertex in the primitive, so the 1/z interpolation can be performed).

Bilinear filtering does not require any more information than the PSX GPU already gets passed, so it can be enabled. *BUT*, bilinear filtering does require carefull layout of textures in VRAM, which most PSX games do *not* do. This means there are glitches when enabling bilinear filtering, such as black halos (due to chroma-keying issues).

Perspective correct texturing would stop texture "swimming" or "warping", but would be dependant on the PSX game doing perspective correct clipping on the side of the view-port. If the game just does simple clipping, and does no take 1/z interpolation in to account when clipping primitives, you will still get texture swimming on the edge of the view-port, particularly when cameras are slowly panning, etc.

Perspective correct textuing would not really help "wobbling" polys: that needs sub-pixel accuracy in the vertex data (PSX has no sub-pixel accuracy, so everything is rounded to integer values). This is also why small objects do not scale very well even when running an emulator at 1600x1200: one step on the PSX screen of 320x240 results in a jump of 5 pixels on the emulator screen! If the PSX had sixteen levels of sub-pixel correct vertex data, the emulated screen would still be sub-pixel correct.

Theoretically, it would be possible to use some HLE techniques to pass the z information for each vertex to the GPU, as the GTE does actually calculate the z value (used for depth-sorting the primitives, so they are sent to the GPU in reverse depth). But there are many catches to this:-
- The game may modify the z data after calculating it in the GTE
- The game may not use the GTE commands

Basically, each game would probably use the PSX components in different ways: certainly, in my experience, the GPU is used [& abused!!] in so many different ways, sometimes by the same company.
The practicality of doing this kind of HLE for PSX emulation seems very very low. You would probably be better off just simply porting the 3D engine of each and every game to native x86 code

Okay, I wrote more than I anticipated

"Quick" huh ?

[fivefeet8]

Anistrophic filtering also doesn't work in psx emulation.. Is it also because of a lack of a z buffer?

[Kane]

From Matrox's Website

Even though trilinear filtering goes a long way towards improving the image quality of a texture mapped 3D surface, there are cases when trilinear filtering fails to provide good results. Both bilinear and trilinear filtering are used to solve problems that arise due to the difference in size of the source texture and the size of the surface that the texture needs to be mapped on. However, they do not take into account the difference in shape and perspective between the source texture and the target surface. Bilinear and trilinear filtering work best for surfaces that face the viewer squarely (depth across the surface does not change in this case). However, when the surface is oblique to the viewer, filtering causes loss of detail. This degradation in image quality is most obvious when the texture being mapped contains text. Text typically has areas which are as low as one pixel wide. Applying bilinear or trilinear filtering on text that has been mapped obliquely will result in the characters becoming blurry and blending with adjacent characters and therefore almost unreadable depending on the perspective. Anisotropic filtering is used to get around this problem by taking extra samples from the texture map.

These extra pixels are chosen according to the direction of the perspective that the texture is being mapped on. For example, a brick texture being mapped on a wall of a hallway going into the screen will require the texels to be chosen in the direction of the surface of the wall (from front end to back end)

Triliniear filtering utilises the Z-buffer, and Anistropic filtering requires Triliniear filtering to work.

[Goku7]

Fascinating. What is GTE, anyway? And why the heck are we having so much trouble with GTE emulation anyway?

My, uninformed guess is that the GTE is a coprocessor chip or something on the PSX console, from what I've heard in passing conversation (in this case, various readme files and the occasional forum thread), before I figured this out, I thought it was something that had to do with racing games, since GTE is a car company trademark, as far as I know.

[Lewpy]

Originally posted by Lord Kane
Triliniear filtering utilises the Z-buffer

Trilinear filtering uses depth information to determine the blending level required between two successive mip-maps. Strictly, it doesn't need a z-buffer as such, but your geist is correct

Anistropic filtering requires Triliniear filtering to work.

I don't think this is necessarily true. In essence, anistropic filtering is a modification to bilinear filtering. Bilinear filtering is used for trilinear filtering, as trilinear is an extension on bilinear (bi = two directions [x & y], tri = three directions [x, y, & z]).
I have yet to see an implementation of anistropic filtering that performs multiple sampling in the z direction, thus being a true modification to trilinear filtering. To be honest, I can't think of a situation where multi-sampling the z direction would help, so it's probably only a theoretical sampling technique. Except, I suppose, if we start talking about 3D textures ....
Bilinear filtering performs a weighted average filter against the four nearest texels, whereas anistropic filtering performs it over more than just the nearest texels.
If you take anistropic filtering to the extreme, where you can perform any number of samples in either the x or y direction "for free", then there is no need to pre-generate mip-maps for a texture. If you don't need mip-maps, then you don't need trilinear filtering Current hardware performs "anistropic filtering with trilinear" simply because they can't do any number of texture samples "for free".

Just to add: anistropic filtering *does* require depth information to be able to work out the angle a texture is being viewed at, so that it can determine the number of samples it needs to make in the x or y axis of the texture.

[E}I{]

Like Lewpy already said, z-data is not passed to GPU and there is no way to reliably catch it at previous rendering stages(except for writing some sort of emu core plugins for each game). MIP mapping techniques (simple, trilinear, maybe even anisotropic)can actually be used by PSX emu, but it will certainly require slow texture caching(because they don't accept palettized textures ) and will create additional glitches. Basically MIP mapping was created to simulate anti-aliasing for textures by pre-caching many low-res versions of each texture. tri-linear and anisotropic are just enchancements of MIP mapping. If you're using more or less working FSAA like many people today, you don't need MIP mapping at all, so why bother?
P.S. Sorry for bad English

[Lewpy]

Originally written by doomed@c64.org
The Geometry Transformation Engine (GTE) is the heart of all 3d calculations on the psx. The GTE has specialised functions for perspective transformations, light sourcing and the like, and is much faster than the CPU on these operations. It is mounted as the second coprocessor and as such has no physical address in the memory of the psx. All control is done through special instructions.

[Kane]

Oh, I get it wrong again I have a lot to learn on this. I was obviously given the impression that it was required by taking into account todays hardware in a review or something.....
Once again, thanks for clearing that up.

[Goku7]

Ah, that explains it. You can't do the standard memory-dump techniques to get the entire instruction set for the GTE.

Unless, you used some sorta ROM-downloader type device to make an image of the instructions burned onto the chip, and that sorta thing is illegal, right?