..:: PCSX2 Forums ::..

(11-21-2012, 04:39 PM)Krude Wrote: [ -> ]I assume this was directed at VIRGIN KLM? Otherwise, color me confused. MSAA sure isn't fixing any texture issues.

I'm talking about texture filtering methods, so no it has nothing to do with my post.
Also MSAA and EAA is not even near the same thing, they have nearly nothing in common so the visual results and compatibility will not be the same let alone the fact that one is hardware and the other is software exclusive.

Is there anything I could supply or do to help concerning the issues I posted earlier? The game (Trapt) isn't exactly high profile, I understand.
By now I found out that the flickering and invisible objects like the boulder can be fixed in DX11 mode by activating the Alpha HW hack, but the corrupted and missing textures on the geometry is still only absent in Software + EAA.

It can be rather disorienting in-game to not see the ground you walk on, especially around inclines.

As an aside, is there any way to make some game-specific GSDx settings like Interlacing Mode or HW Hacks? Auto Interlacing doesn't always choose the best mode for a game, and the hacks seem similar to the game-specific fixes, which can be applied automatically via the game database.

There's that booting through commandline option, but I'd have to keep a whole config folder for every game when all that really changes is one or two settings in GSDx.

GSDX plugin haven't update and haven't fix old bug for long time and please wait patient for Gabest to fix this issue

I have problems with few games in GSDX Software.

NFS: Most Wanted on screen transparent squares, in HW here no problems.

[attachment=40944]

Silent Hill 3 problems with flashlight, in HW no problems.

[attachment=40945]

Beyond Good & Evil too many artefacts.

[attachment=40946]

And yes, thanks guys for Software renderer, i like it very much! ^_^

Here my performance result, total 77 games:

Dunno if anyone thought of that but what about 3D model Tessellation?
I think both DX9 and DX10 (and DX11) support it internaly.

I think only D3D11 has it as an official feature with relative ease of use. I think you would define what a model is, then cage it for tessellation. How to do that, no idea, but if it was done, in my imagination of the outcome... there's nothing but ugly blobs all-around.

dx9 could do it in software and shove the extra vertices up the pcie bus. not good. dx10 has geometry shaders to do it and dx11 does it in hardware. neither of it does have any use anyway cause you need a surface definition aka normals to smooth it round or you just have a flat tesselated polygon. and the ps2 doesn't send normals to the rasterizer cause the only value it has - the vertex lighting - is already served and done on the vu. there's no point trying to tesselate.

Well, there's more than one method of tessellation. Another one is the one that like all 3D model viewers/editors do/have an option to apply. It detects all the sharp edges and de-sharps/curves them using Hermite/Catmull splines resulting into a less polygonal looking model or better a more rich polygonal model with nearly zero performance impact.
Another one affects the lighting, like it won't accent the sharp edge of a polygon with a shadow behind the source but it will use a smooth type of shading that will make it look like it has atleast 4 times more polygons there. I'm pretty sure all these have a name in the APIs but it's been a long time since I read about them and I cant remember them. Generaly I remember that there are like 2 ways of practical tessellation in DX9 and 5 for DX10 depending on the data provided.
In OGL means this is the result and an intresting thing to read:
http://fireuser.com/blog/tessellation_en..._geometry/

right. but 3d model tools have the surface normals to do it in hardware or if not they do that in software. again the ps2 doesn't offer them to the rasterizer or gsdx. there's NO SURFACE NORMALS. if doing it one could do a routine to calculate the normal from edges. in software and add plenty of load. or hardware but complicated. this is a miss in terms of the design of the dx pipeline. to detect the edges really good and get good normals you need access to all neighbor vertices and have some sort of adjency info of all neighbors. this is not there. the effort to compute and deliver that data to a vertex shader and geometry shader or doing a compute shader is pretty big.

this' technical sh*t. but that's the thing.

In lamens terms he means, you don't just have a shape and a texture stuffed over it, you need to tell it if that is a solid shape or not, to do this for every triangle on the screen would take aaaaages, even longer to do tesselation to make it nice and shapely, it's better to achieve it in the artwork than get directx to generate it.