This is not a PCSX2 issue, which is why I filed this thread under the general discussion subforum. This is about a very bizarre and obscure graphical glitch that only happens on Tony Hawk's Underground 2 running on real hardware. It seems to work with all models of PS2. I'm hoping I can get some help determining the root cause of the glitch using GS dumps and the PCSX2 debugger, which I don't have a very good understanding of.
Tony Hawk's Underground 2 has a skater editor which lets you create a custom skater. One of the features of the editor allows you to customize the color of any piece of clothing or accessory the skater is wearing. Specifically hue, saturation, and value can be adjusted to shade the object almost any color. There are limits on the minimum and maximum adjustments you can make. Under normal circumstances, this works as expected. However, there is a Gameshark code that locks the "current value" variable used to compare against the limits set in the game's colormenu.qb script. This allows infinite adjustments and makes the broken graphics glitch possible.
To achieve the glitch, the hue/sat/val adjustments must be a specific combination. Hue cycles around when it hits the end, but saturation and value need to be adjusted past their max limits. Screenshots are taken using the GS dump utility in PCSX2 1.4.0 for Linux running at 3x native internal resolution with OpenGL.
Pants showing normal:
Pants showing broken after being colorized:
Video:
The glitch has 2 effects, it breaks the mesh of the piece and causes rainbow colors to appear. The meshes of some items break severely, others only slightly. Everything shows this rainbow effect, which changes with every rendered frame. The skater editor relies on a vertex shader for colorizing with the object's texture still visible. When this breaks, each vertex has a random RGB value which constantly changes. The effect's animation varies with the camera angle and follows a pattern with other things on the screen. This appears to be a pointer error that causes the shader to go from the correct memory address to an invalid one, which changes with every vertex.
I dumped 2 GS frames of the screenshots, one is the control (normal) and the other is broken. I tried to isolate as many things in the scene as possible. Link to dumps in a zip file:
https://www.mediafire.com/file/f6uil4v30...g.zip/file
If someone with knowledge of the architecture and PCSX2 debugger wants to dig into this for giggles, that would be cool. There's really nothing practical to gain from figuring this out, it's academic. The effect is not caused by the cheat being loaded, you can save your skater and load it again later without the cheat. The effect can be quite interesting when used in certain ways. A lot of people used to do this when playing online back in the mid 2000s when Gameshark discs were common. I did test this on the PC (Windows) version and could not reproduce it. I even adjusted the game's script file to remove the adjustment limits and converted/imported the skater's save file from the PS2 version. PCSX2 on Windows also reproduces it, even with Direct3D9. My guess is there is an overflow that corrupts the display lists coming from the EE to the GS, or the GS itself is rendering one of the effects in the display lists incorrectly. I'm thinking the former, as the GS seems to operate on pretty basic principles.
Tony Hawk's Underground 2 has a skater editor which lets you create a custom skater. One of the features of the editor allows you to customize the color of any piece of clothing or accessory the skater is wearing. Specifically hue, saturation, and value can be adjusted to shade the object almost any color. There are limits on the minimum and maximum adjustments you can make. Under normal circumstances, this works as expected. However, there is a Gameshark code that locks the "current value" variable used to compare against the limits set in the game's colormenu.qb script. This allows infinite adjustments and makes the broken graphics glitch possible.
To achieve the glitch, the hue/sat/val adjustments must be a specific combination. Hue cycles around when it hits the end, but saturation and value need to be adjusted past their max limits. Screenshots are taken using the GS dump utility in PCSX2 1.4.0 for Linux running at 3x native internal resolution with OpenGL.
Pants showing normal:
Pants showing broken after being colorized:
Video:
The glitch has 2 effects, it breaks the mesh of the piece and causes rainbow colors to appear. The meshes of some items break severely, others only slightly. Everything shows this rainbow effect, which changes with every rendered frame. The skater editor relies on a vertex shader for colorizing with the object's texture still visible. When this breaks, each vertex has a random RGB value which constantly changes. The effect's animation varies with the camera angle and follows a pattern with other things on the screen. This appears to be a pointer error that causes the shader to go from the correct memory address to an invalid one, which changes with every vertex.
I dumped 2 GS frames of the screenshots, one is the control (normal) and the other is broken. I tried to isolate as many things in the scene as possible. Link to dumps in a zip file:
https://www.mediafire.com/file/f6uil4v30...g.zip/file
If someone with knowledge of the architecture and PCSX2 debugger wants to dig into this for giggles, that would be cool. There's really nothing practical to gain from figuring this out, it's academic. The effect is not caused by the cheat being loaded, you can save your skater and load it again later without the cheat. The effect can be quite interesting when used in certain ways. A lot of people used to do this when playing online back in the mid 2000s when Gameshark discs were common. I did test this on the PC (Windows) version and could not reproduce it. I even adjusted the game's script file to remove the adjustment limits and converted/imported the skater's save file from the PS2 version. PCSX2 on Windows also reproduces it, even with Direct3D9. My guess is there is an overflow that corrupts the display lists coming from the EE to the GS, or the GS itself is rendering one of the effects in the display lists incorrectly. I'm thinking the former, as the GS seems to operate on pretty basic principles.