GSdx 1.0

[masterotaku]

Gregory, I have a question about the Dragon Ball Z Budokai Tenkaichi games. I have always noticed Z-fighting in all stages. Could it be due to this same thing that was fixed in Dolphin?:

https://es.dolphin-emu.org/blog/2016/09/...gust-2016/

5.0-464 and 5.0-466 - Further Depth Fixes by Armada¶
You didn't think it'd be that easy, did you? There's always at least one case that mucks up even the best of plans.
The way Dolphin achieves the depth precision it needs is to use reversed depth. It brings the far plane to near for higher precision where it's needed, while computing the near plane in far where the precision is usually not necessary. For Dolphin to emulate the GameCube's depth in current graphics APIs without zfighting, this is a necessity.
The problem is that certain games, such as Dragon Ball Budokai Tenkaichi 2 and 3, had the same idea. They used reversed depth to achieve greater depth precision on console! This means that Dolphin was reversing reverse depth, losing precision and causing issues.
On OpenGL, Dolphin can handle this situation by simply not reversing depth in these cases, but D3D11/12 do not support that. With a Vulkan backend in development, it's worth it to note that while the API allows it, most available drivers currently do not. Hopefully that will change and allow for Vulkan to match OpenGL in depth accuracy in the future.


The zfighting is minor enough that we had to really zoom in.

How it should always look.


This isn't the end of the world, though. Unlike the previous case of everything being broken there will instead just be some minor zfighting on D3D11, 12 and eventually Vulkan. Thankfully, this should be limited to titles using their own form of reversed depth.

They could fix it on OpenGL but not DX11 and DX12.

[gregory]

It could worth to check it, but unlike dolphin which emulate a more standard GPU, GS is really an alien.

The reverse trick only works for float depth. Whereas the GS is integer. Actually the Z test on GS could only be "always/greater/never", so I don't know how it can reversed (GPU supports "less" too). However the GS supports 32 bits integer so with 32 bit accuracy. Whereas standard float is 23/24 bits of accuracy (depends if you reverse it or not).

Near/Far plan is computed on the VU. If the game really uses 32 bits, potentially VU emulation will lost some bits. So even the SW renderer might suffer of Z fighting.

Edit: some old discussion https://github.com/PCSX2/pcsx2/issues/544

[nintendo85]

So no word on that texture caching issue for the battle transition effects in Square Enix games or do I need to make a new dump with a automatically compiled build and use Shift + F8 for that?

Or should I just give up on having such a complex issue resolved?

[gregory]

Or should I just give up on having such a complex issue resolved?

I'm sorry but it is the fastest and the most realiable solution. Project has a tons of issue https://github.com/PCSX2/pcsx2/issues

I'm trying my best to fix as many bug as can.

[nintendo85]

I'm sorry but it is the fastest and the most realiable solution. Project has a tons of issue https://github.com/PCSX2/pcsx2/issues

I'm trying my best to fix as many bug as can.

Meaning? What's the most reliable solution? Filing reports?

[gregory]

sorry missing word Reliable way to be happy with current situation. The bug is hard to reproduce with a gs dump so it is likely a complex texture cache issue.

[nintendo85]

sorry missing word Reliable way to be happy with current situation.  The bug is hard to reproduce with a gs dump so it is likely a complex texture cache issue.

So what do you suggest I do? Give up on it ever being fixed? I recall reporting this issue about a year ago, should I report it as an issue again or just not bother at all? Yeah because given its complexity , what's the point of me even asking or having hope? There is none. So why should I even ask if it's been a year and the complex issue...never mind... It wasn't worth asking before, sure as heck won't be worth asking it now.

[gregory]

I didn't say it wasn't worth it. Due to the high number of bugs I need to prioritize them. I recently fixed a 3 years old bug (which even impact the sw renderer). I can fix some issues in 1 hour with a proper testcase. Others could take several weeks to debug and then to fix. Unfortunately your transition bug is in the last category. So far it is limited to battle transition whereas some game suffers of half screen issue. I'm sure you could understand that your bug is a lower priority.

[nintendo85]

I didn't say it wasn't worth it. Due to the high number of bugs I need to prioritize them. I recently fixed a 3 years old bug (which even impact the sw renderer). I can fix some issues in 1 hour with a proper testcase. Others could take several weeks to debug and then to fix. Unfortunately your transition bug is in the last category. So far it is limited to battle transition whereas some game suffers of half screen issue. I'm sure you could understand that your bug is a lower priority.

That's all I needed to hear, okay, thanks for clearing it up. Now I should go beat myself up for ticking you off -_-

[gregory]

hum, did you test with CRC hack disabled ?