PCSX2 Version: 1.3.0 June 18th 2014

PCSX2 Options: Default, Zero modifications.

Plugin's used: GDSX 0.1.16, SPU2-X 2.0.0, Lilypad, cdvdGigaherz 0.9.0, rest nulls

Plugins were not modified beyond their default settings.

Description: Regardless of Software or Hardware, you get odd graphical glitches when trying to load Shawn Murray Demo from the options screen of Tony Hawk Pro Skater 4. Despite this, it loads for a while before eventually freezing. I'm guessing the graphical issues and actual freeze are separate. It freezes at the same loading point every time.

Last known working revision: Couldn't find a version where it loaded.

PC Specifications: Core i5 3570K @ 3.4 GHz, NVIDIA GTX 760, Radeon HD5850, Windows 7 SP1

I searched the forum and wiki for more information, and found nothing. When searching the forums I found nothing, but I'll admit I'm not too familiar with the PCSX2 forums.

The problem is your settings. Set your rounding mode for the VU to 'Nearest' as this is merely a rounding error, that should resolve the graphical problems.

This was documented on the public compatibility list, you must have missed it: http://forums.pcsx2.net/Thread-Tony-Hawk-s-Pro-Skater-4-SLES-51130-E--29306?pid=347099#pid347099
(obviously the comment about the gamedb only applies to the PAL version, but the fix is the same)

I didn't play around with the settings too much. But, regardless, the issue report says that if it happens on the default settings (I didn't touch anything) that I should report it.

Update: I changed VU to nearest and the graphical issues and crash remains.

It didn't change it? How strange! Okay well thanks for testing, i'll look in to that then :)

Enabling the XGKick hack in gamefixes seems to solve the issue mostly, there's still some weirdness in the game, but It's much much better. Still got some things to look in to.

Strangely the hack is actually more correct behaviour, not sure why it's the way around it is actually.

Well it's not like a game fix being more precise emulation is unprecedented, the tri-Ace VU game fix is perhaps the best example of that. In this case any possible behaviour is potentially troublesome.

Wanna add this to the database then for auto patching?

What is the status of this issue?

I think the general agreement is that demos of other games dont get an automatic gamefix unless the main game requires the same gamefix. If you want to see the demo you need to enable it manually.

It would be nice to mention this in the compatibility list.

I cannot get in-game whatsoever in the latest development builds. While loading the main menu, the game hangs about 60% of the way loading. I tried various CPU rounding modes and was unable to work around this. So, I cannot verify whatever using an automatic gamefix works or not.

Hmm, can you trace back at all to when it stopped working through the buildbot builds?

I don't have time to do a super in-depth bisect tonight, but, I'll try to get to it asap. I'm hoping it's just some kind of setting that got changed up. I tried following the wiki settings, though. Tomorrow, after work, I'll get on it.

The full emulog after you observed the hang could be useful.

Does it hang on the THPS4 main menu or the Shawn Murray demo menu? just for clarification?

I'll do some testing when I get home tonight.

I got the game booting fine, must have had some stupid speedhack left on from another test (probably Driv3r.)

Shawn Murray seems to be exactly the same as before. Is there some kind of game fix I need to turn on for that game?

According to ref:

Enabling the XGKick hack in gamefixes seems to solve the issue mostly

Any status for that demo?

@Nobbs66 Status ?

@JMC47 is this still an issue ? If so can you tell me your game serial ?

Yes, Sean Murray is still broken.

I can setup PCSX2 again sometime and mess with this. It's been a long time since I've had PCSX2 setup and kinda forgot about my issues here. I wonder if there's some setting combination that'd have ti work.

-PCSX2 version:
1.2.1.r5873 - compiled on Feb 3 2014

-PCSX2 options:
Defaults, no settings modifications affect the issue.

-Plugins used:

• gsdx32-sse4-r5875
• lilypad-r5875
• spu2-x-r5875
• cdvdGigaherz

-Plugin settings:
Tested GSdx DX9/11 hardware;
DX11 seems to make things worse by having more of an impact.
SkipDraw 1 used to remove player shadow altogether.

-Description:
Basically, most textures are corrupted. One great example is the right eye of most characters (also an issue in previous installments of the game).

-How to replicate:
Boot the game and enjoy the black-textured landscape and corrupted eyes and miscellaneous objects.

-Last known version to work:
Unknown, probably never worked.

-PC specifications: CPU:

• Intel Core i5 650 @ 4.1GHz 54 °C
• 4.00GB Dual-Channel DDR3 @ 819MHz (9-9-9-24)
• Gigabyte Technology Co., Ltd. P55-UD6 (Socket 1156) 50 °C
• 1023MB NVIDIA GeForce GTX 560 Ti (EVGA) 69 °C
• 465GB Western Digital WDC WD5000AAKX-00ERMA0 ATA Device (SATA) 45 °C

-Other comments:
The graphical corruption, including the missing eye(s), is also present in previous installments, including, but not limited to Jak and Daxter (SCUS97558 & SCUS97124).

DX11 mode making things worse is due to the newer Nvidia drivers not working correctly with PCSX2, downgrading your driver to the 327 series or lower will fix those issues.

as for the missing eyes, i believe this is a known issue, i believe putting GSDX in software mode fixes it.

This is this unfamous mipmapping bug.

The cause of the shadow volumes being displayed is unknown for this engine, previous attempts to debug it have not been productive. The GS does not support actual stencil buffers so game engines have to simulate their functionality in various ways.

Could you test the shadows issue on the openGL renderer?

Latest version 1.3.1 20150813215402 from git, using OpenGL, all default settings except 4x scaling, i7-4702HQ @ 2.2GHz / nVidia 765M / 8GB RAM.

Seems that the latest version has fixed some, but not all of the texture issues (water in previous screenshot fixed), but the shadow issue remains. Shadows are not fixed in Jak 1 either.

Re texture issues - eyes sometimes work perfectly, sometimes they work but look in the wrong direction (up not down), and sometimes they are either noise or black. No obvious pattern as to when the eyes do/don't work. Other mipmapping issues are still visible. Jak 1 textures all look fine apart from the eyes (as they do in 1.2.1).

Increase the level of accuracy blending (likely high). It will normally fix the shadow issue.

Just tried all the different blending levels - none of them have any effect on the shadow issue, in Jak 1 or Jak 3.

Strange. Can someone make me a gs dump of the shadow issue (disable all speedhack in PCSX2)

i just posted a dump in the gsdx 1.0 thread on the forums

You know I follow the 2 threads ;) It would have been better to post it here. Anyway I will try to give it a quick look in coming days.

http://cjb248.com/pcsx2dump/jak-shadow-glitch.zip and http://cjb248.com/pcsx2dump/jak3-shadow-glitch.zip - for Jak 1 and Jak 3.

Do you confirm that shadow is broken on SW renderer too?

Hum, I think I understand the issue for the shadow. I'm not sure that we can emulate it.

The bad draw call have both input texture and render target at the same address (0x3300).
The game renders triangle with basically does Alpha RT = Alpha Fragment * Alpha Texture.
However Texture and RT is the same on the GS but not on the plugin.

So they manage to implement a kind of alpha blending of the alpha channel which is normally impossible on the GS.

The best will be to allow to read the RT from the shader but it isn't easy.

Just another idea that could work.
1/ detect the effect (RT Tex and TFX_MODULATE and only_write_alpha)
2/ Create a float texture
3/ Render with blending on with this kind of equation

• GL_FUNC_ADD
• GL_SRC_ALPHA: Alpha fragment
• GL_ZERO
  4/ Convert back the RT to integer color.

We need an unclamped texture because as always alpha range from 0 to 2. However it means clamping won't be accurate. But it could be enough. Otherwise we can still do a 2 pass like the older colclip algo.

Yes, it's broken in the software renderer as well.

Hmm, didn't know this was such a complex issue.

On gpu textures are read-only or write-only. Recent GPU (gl4) support RW texture but out-of-order with atomic. Hum I need to check if mult is supported as atomic. Or maybe replace with +/- 1, it must be close of it.

Yeah no multiplication in atomic. Anyway it won't work neither the blending method above due to rounding.The game uses 127/128 factor to do a -1 and 130/128 to do a +1. Maybe we can replace the draw call with a pseudo colclip.

@charliebruce
Did you generate the above dump with VU cycle stealing enabled?

No, I don't think so - all speedhacks should have been switched off for
both of the dumps I did

On 15 August 2015 at 19:04, Gregory Hainaut notifications@github.com
wrote:

@charliebrucehttps://github.com/charliebruce
Did you generate the above dump with VU cycle stealing enabled?

—
Reply to this email directly or view it on GitHub
#168 (comment).

I pushed a hack for the shadow. Note, it is likely quite slow => UserHacks_AutoFlush = 1

I can test in an hour or so unless somebody else beats me to it :p

I tested the hack and the shadows are nearly perfect. But from some camera angles they glitch out a bit.
The performance without the hack is about 30fps SW mode, 52fps HW mode.(OGL)
With the hack enabled it's about 25fps SW mode, 13fps HW mode.(OGL)
Intel Core i7-4700MQ
nVidia geforce GT 740M
Windows 8.1
screen when the shadows are glitched
2x native, now shadows are glitched all the time (about 2fps)

Yes glitch are expected on the shadow. Except a CRC hack to replace the draw call (same issue as tri-ace game), it isn't doable with upscaling. It is already a miracle that shadows are kind of working in native resolution (due to the different rounding between integer (GS) and float (GPU) ). Potentially you could try accurate blending but it will be sluggish...

Anyway, I was expected very poor performance on the HW renderer. Perf on SW isn't too bad.

Edit: beside without mipmapping HW renderer is kinds of moot

Blending accuracy seems to have no effect. This is already great progress anyway. Thank you for working on this :)
Do you need GS dump when it's glitched?

Even on ultra (and I mean in native resolution). Ah no it might not work as the game does shits with the alpha channel.

No need for a dump. I know exactly what happen. Actually a crc might not be fast enough. Hum maybe I can test something... When I detect the bad draw call, I will try to sample from the rt instead of texture with a full barriere. I will give it a trial when I got extra motivation :)

Native resolution and ultra. It still breaks from certain angles.
What motivation do you mean? (sorry, didn't get it)

Mine ;) Devs are lazy people.

Anyway I implemented it. I don't know for the speed but it would be faster than previous hack. And it will glitch less.

However I need you game name & CRC.

Edit: did a quick speed test and impacts is rather small.

Oh, now I understand :)
Jak 3 (PAL-M7) [SCES-52460] - Platinum
GSdx Lookup CRC:12804727

Please test latest git (without previous hack). You need to enable accuracy blending to basic at least.

In Jak 3 I can confirm that shadows are fine on OGL HW, but now it doesn't work in SW.

Jak X (PAL-M7) (Platinum)
Shadows seems to benefit from this hack as well
[SCES-53286]
GSdx Lookup CRC:DF659E77
hack off
hack on

The CRC hack only impact the openGL HW renderer. The auto flush hacks impacts both renderer. It is likely a bad idea to enable both.
The CRC hack is a faster implementation of the auto flush hack for Jak series. By the way, could you tell me the speed impact of the CRC hack.

I have about 47-55fps without CRC hack and about 45-52fps with the CRC hack.

It is much better than previous hack, I can't do better. Note, perf impact might be bigger if there are lots of shadows (or complex model).

For the record, I'm sorry for AMD users but perf impact will be bigger for them.

I belive you said you needed the CRC's of all Jak games that suffer from this issue, so here's a bunch of them (all of these were tested using the OGL HW renderer and high blending accuracy):

CRC:9C712FF0

CRC:2479F4A9

CRC:DF659E77

Hope this helps :)

I need the game name (for example jak 2). And the region too (for example Eu)

Ok, I'll say it by the same order:

Jak and Daxter: The Precursor Legacy (Europe)
Jak II - Renegade (Europe, Australia)
Jak X (Europe, Australia)

jak
jak2
jakx

then xD

I pushed a new version with various CRC. Tell me if shadows are fine on the openGL renderer + accurate blending on basic.

Teste the above mentioned games with the specified settings, shadows are working fine now:

Also, I can provide you one USA CRC that I have:

Jak 3 (USA) - 644CFD03

Also, the USA version has that weird globe on the upper left corner in all blending accuracies. Non existing in software mode btw.

You ask too much ;) Either mipmap or something wrong in the texture cache. Not for this month, working shadows are already a huge improvement.

I'm not asking, just reporting :)

Actually I saw it on my gs dump. Potentially I already looked at it. If it isn't fixed it is surely a complex issue.

I added your CRC too.

By the way, who can add a gui option for the auto flush hack

SW renderer has wrong skin color on Jak3. If you have the issue could you test the PR #1843

SW renderer has wrong skin color on Jak3. If you have the issue could you test the PR #1843

It's fixed by PR #1843

@gregory38 Jak 3 still has skin issues in Direct3D11 Hardware mode when using upscaling. Direct3D9 and OpenGL are fine, and Direct3D11 is fine on native resolution. The skin issue is basically the same as it was in Software mode, except that the markings are black. Any idea what could be causing it?

Hum, hum. It could be this one.

Draw call N:

• the input texture is the CLUT content
• upscaled output is the frame buffer.

Following draw calls:

• reuse the upscaled output as CLUT table

It means that texture sampling must be 100% correct otherwise you won't have the good color. A slight rounding and you will get the neighbor texel which contains a wrong color.

I would advice to just dump all the texture/frame buffers.

i don't know if some developer already knows this, but i found that if you put the rendering in software mode, and then return to hardware mode the textures on the sand remain correctly loaded, it works every time, i don't know if its worth mentioning

Yes because the bug are related to texture cache. Toggling force a reload of all textures from GS memory. If you're​ lucky it might help to fix bug. Or it will create new ones

I tested Jax 3 US with current nightly build (crash tag team crc) and a AMD RX 480 on game's native resolution.

Shadows issue still existing for me on opengl hw render and dx11 hw render. When I use dx11 sw render it looks fine, but the sw render is to slow to play.

When I enable UserHacks_AutoFlush = 1 its getting even worse. More shadow bugs, the map under the ship (intro) is just black.

Also dx11 hw render gives me 60fps ~ while opengl hw render gives 20-30 fps ~ (in every game I tested).