Cxbx-reloaded: Regression in Indiana Jones (vertex explosions)

[PatrickvL]

Indiana Jones once rendered perfectly in-game

However, this regressed, now showing 'vertex explosions'

For this issue, figure out which commit broke this, and fix it.

@medieval reported :

well I have it narrowed down it is between commits
4412fef9bb5584a5b492eae43f7cf727ff3c1bbb
and
5b45eba1a9b582d0613789aa32f964506b7692df

PR #1375 (initial d3d9 port) , indiana jones crashes (the commit immediately prior it renders normally, I can't say it would NOT in 1375, but because of the crash I can't rule it out)
PR #1377 (fix zapper!), no crash, but it it has the vertex explosion.

[LukeUsher]

So it seems to be a casualty of the DirectX9 port then...

[medievil1]

yea I am gonna go out on a limb and say something. maybe the way dx9 does it, changed enough in vertex shaders that it caused the issue....we know (through GPA's frame cap analyzer) that the actual vertex data for the characters is there.. it(the various body sections) renders in gpa.. it is almost, to my eye's as though the coordinates are gettign jumbled when it goes to be rendered, the save/load book in indiana jones for selecting game for example, instead of being wide, is narrow and goes up offscreen...you can see the page texture, can even see it flip pages...same for characters, you can see the blue shirt texture in buffy, it's just reduced to a narrow column that goes up offscreen... though I have NOT looked much at texturing...I've not played around with it enough to know if it is even possibly just a texturing issue

[medievil1]

MAYBE narrowed it down a bit more... Patch D3DDevice_SetVertexShaderConstantNotInline seems to have a bit to do with it...altering it alters the draw, of which SOME things do draw correctly.. the statues on the sides(after the videos and the loading screen) for example..if they do not get drawn, neither do the exploded sections, so I am doubting it is the actual drawing that's at issue...since this sets constants, has to be the constants that are at issue (or it expects something else to further alter the vertex)

Interestingly GetVertexShaderConstants, has no affect , commenting the patch out changed nothing

```// *********************
// * patch: D3DDevice_SetVertexShaderConstantNotInline
// *********************
VOID __fastcall XTL::EMUPATCH(D3DDevice_SetVertexShaderConstantNotInline)
(
INT Register,
CONST PVOID pConstantData,
DWORD ConstantCount
)
{
LOG_FORWARD("D3DDevice_SetVertexShaderConstant");

// The XDK uses a macro to automatically adjust to 0..191 range
// but D3DDevice_SetVertexShaderConstant expects -96..95 range
// so we adjust before forwarding
EMUPATCH(D3DDevice_SetVertexShaderConstant)(Register - X_D3DVS_CONSTREG_BIAS, pConstantData, ConstantCount /4);

}```

[medievil1]

NZJenkins seems to think it might well be related to this tidbit about the dx9 vs register a0
from this pdf http://www.nvidia.com/docs/IO/8230/D3DTutorial1_Shaders.pdf

 Loading a0 now rounds-to-nearest rather than
truncating

so he THINKS it may just need to be floored as the extra decimal spots in the shader seem to be wreaking havock

[LukeUsher]

NZJenkins seems to think it might well be related to this tidbit about the dx9 vs register a0
from this pdf http://www.nvidia.com/docs/IO/8230/D3DTutorial1_Shaders.pdf

 Loading a0 now rounds-to-nearest rather than
truncating

so he THINKS it may just need to be floored as the extra decimal spots in the shader seem to be wreaking havock

That would make sense actually, we have seen similar issues in the past cause us problems. Would be much easier to solve if we were generating hlsl shaders, but for now, we could probably detect this scenario and inject extra instructions

[medievil1]

confirmed issue is resolved in PR #1774

[LukeUsher]

Great!