Next Generation Emulation banner

1 - 4 of 4 Posts

·
Registered
Joined
·
7 Posts
Discussion Starter #1
Is there any way to eliminate the "texture bending" that PlayStation normally renders? Is this processed before any graohics accelleration takes place?



Thanks
 

·
Registered
Joined
·
538 Posts
I presume you are refering to "texture swimming", which is caused by non-perspective correct texture mapping.
The simple answer is no, this can't be fixed. It's an inherent "feature" of the PSX graphics hardware.
The more complex answer is "possibly", but it depends how feasible any kind of HLE is for the PSX. Whenever I've thought about HLE for the PSX, I've given myself a headache :eek:
HLE stands for High-Level Emulation: abstracting away from the actual hardware you are trying to emulate.
 

·
Registered
Joined
·
7 Posts
Discussion Starter #3
I don't even know why perspective-correction is necessary to prevemt "swimming." I've made programs in QuickBasic that render "textures" onto quads and all with the use of a couple trigonometric functions (SIN, COS) and a couple reciprocal "z" variables. Yes, it looks real crappy, but stereoscopically, it proves to be perspective correct Non-perspective-correct texture apperance seems like it be much more complicated to produce. What kind of crazy 3d logic does the PSX graphics hardware use? Can someone explain this to me?
 

·
Registered
Joined
·
538 Posts
There are several things to note on the PSX GPU:-

1) Co-ordinates are all integer values
This means there is no sub-pixel precision in the rendering of primitives to the screen. This in turn causes vertices to jump whole pixels during movement, which creates a more "blocky" animation of moving objects, etc. Texture co-ordinates are also not sub-texel precise.

2) The GPU does not receive any Z information
This is the killer to perspective-correct texturing. The Z value for the vertices is not passed to the GPU, only the X & Y (U & V as well, of course). Without the Z, the GPU can't perform the 1/Z iteration per pixel, which is necessary to do perspective-correct iteration of the texture co-ordinates. This is vital in situations where a quad spans a wide range of 1/Z values (i.e a quad which is close to the viewer, especially when being clipped to the viewport). This causes the texture "swimming" on those quads.
And of course, without Z information, there is no chance of Z buffering, meaning all rendered primitives have to be Z-sorted before being sent to the GPU.

You can read more here. The GTE does the 3D calculations prior to rendering, the GPU does the "2D" rendering. Reading about them gives you a better idea of their strengths and inherent weaknesses.

Remember, the quality of the rendered scene is also dependant on the quality of the game developer's 3D engine. If they code it sloppy, it will look sloppy, even on a emulator.
 
1 - 4 of 4 Posts
Top