Objects not rendered on Treasure Planet: Battle at Procyon

[MegWATTT]

Software information

Game: Treasure Planet: Battle at Procyon
Most objects are invisible when running the game with D8VK, on both Linux and Windows.

On native D3D8 (good):

On D8VK (bad):

WineD3D have the exact same issue. It can be worked around by disabling vertex shaders by setting the registry "MaxShaderModelVS" to 0 for this game.
An other workaround which works on both WineD3D and D8VK is to make invalid the "HemisphericalLighting.vsh" file in the VertesShaders directory of the game, by deleting all it's content for instance.

I've recorded a trace of the game on Windows, but the issue is unfortunately not reproducible by replaying the trace with D8VK.

System information

• GPU: AMD RX 6700
• Driver: RADV Mesa 23.0.2
• Wine version: 7.41 (Lutris Proton GE)
• D8VK version: 1.0

Apitrace file(s)

• d3d8 trace: tp_win32_comp.trace.zip

Log files

• d3d8.log: tp_win32_d3d8.log

[dungeon007]

"I've recorded a trace of the game on Windows, but the issue is unfortunately not reproducible by replaying the trace with D8VK."
I am not seeing shader compile in trace. Seems like windows driver is just able to skipping trying to compile that shader.
So result is the same as if you do var WINE_D3D_CONFIG="MaxShaderModelVS=0" with WINED3D or to make it not compile by editing a shader file.
Or well for d8vk try to put d3d9.shaderModel = 0 in dxvk.conf

[MegWATTT]

I can confirm that "d3d9.shaderModel = 0" is a good workaround. Maybe the game takes the decision to use vertex shaders based on some informations/CAPS.
I've also recorded a trace on Linux with the bug (with d3d8.dll set to native,builtin). It have some rendering issues with d8vk and crashes on Windows with "unhandled exception" when trying to render the 1st frame after loading the game.
Linux trace: tp_win32.4_comp.zip

[AlpyneDreams]

Another game using undefined vertex attributes in the shader like #129. Odd. If it used v5 for this geometry it would be fine. Maybe I need to clamp register indices or something.

debug: Vertex Declaration Tokens:
debug:  STREAM , num=0
debug:  STREAMDATA type=2, register=0
debug:  STREAMDATA type=2, register=3
debug:  STREAMDATA type=4, register=5
debug:  STREAMDATA type=1, register=7
debug:  END

The game is not declaring that register either. I think it either expects to get the value in v5, which it doesn't use, or maybe since v6 is D3DVSDE_SPECULAR it expects the material specular color for some reason.

[AlpyneDreams]

I guess the easiest solution is I can just do the same trick I did for #129 but I feel like there must be a unifying reason behind these two issues. Some way that the vertex shader assigns registers that works on native but doesn't work here.

[AlpyneDreams]

Unfortunately there is no extra information in the VS decl

debug: Vertex Declaration Tokens:
debug:  STREAM 20000000, num=0
debug:  STREAMDATA 40020000 type=2, register=0, regIn=0
debug:  STREAMDATA 40020003 type=2, register=3, regIn=0
debug:  STREAMDATA 40040005 type=4, register=5, regIn=0
debug:  STREAMDATA 40010007 type=1, register=7, regIn=0
debug:  END

There are some bits I haven't looked at but none of them are used here.

[AlpyneDreams]

Seems like actually just doing the obvious fix like in #129 (d3d8.forceVsDecl=0:2,3:2,6:4,7:1) doesn't quite create correct results because there is not shading like in the screenshot above. Perhaps it expects fixed-function lighting to still occur and be stored in v6...? In v5 there is just white except for some painted vertices.

[AlpyneDreams]

Actually, I have a suspicion the screenshot provided is just using fixed-function lighting only. So v5 might actually be correct (see below). After all, the shader is called HemisphericalLighting.vsh.

[MegWATTT]

It it's the case, then I'm wondering why every windows driver only take the fixed function path and not the shader one. The game always looked like the 1st screenshot.

[WinterSnowfall]

Did you ever play it on Win98 or XP? I believe native behavior might have been a bit different back then, which is why we're running into these oddities every now and then. That or it never actually worked and they shipped the game with a broken shader (it's not impossible). But I think it's more likely there were workarounds in place in that day and age which made the issue transparent.

[AlpyneDreams]

Seems to not be related to #66 or #131

Looking at this game's demo's files HemisphericalLighting.vsh, it's a text file so it's likely the game compiles it at runtime. Could be a difference in the shader compiler on Wine. It does indeed try to use v6

vs.1.1             // version number

;------------------------------------------------------------------------------
; Vertex transformation
;------------------------------------------------------------------------------

; Transform to projection space
m4x4 oPos, v0, c4


;------------------------------------------------------------------------------
; Lighting calculation
;------------------------------------------------------------------------------

; tranform normal to world space
m3x3  	r0, v3, c0  
	    
; dot product against sky vector
dp3	r0, r0, -c44   

; the dot product was between -1 to 1. We want to re-range this to 0 to 1
mad	r0, r0, c20, c20

; now lerp between the two sky colors
mov	r1, c42
sub	r1, c41, r1         
mad	r0, r1, r0, c42

; modulates against a darkening term or occlusion term, embedded in the z tex cordinate, we want 1-z though
sub	r1, c40, v7.zzz    
	    
; darken sky term
mul	r0, r0, r1         

; now modulate against object's color
mul	oD0, r0, v6       


;------------------------------------------------------------------------------
; Texture Coords
;------------------------------------------------------------------------------

mov oT0.xy, v7.xy

[AlpyneDreams]

On native, CreateVertexShader just fails. I'm gonna assume that it never worked and just fix the game's registers for it like I did for #129