TGEA 1.7.1 and DirectX Nov. 2008 - broken

#1 Sounds like you might have inadvertently turned on the interior debug rendering mode... is everything nice neat little different colored poly's? if so you are almost definitely in this mode. If it's all just pastel garbage, I don't know what to tell you.

#2 David, can you post a screenshot?

#3 Yeah, I got the same thing, the buildings and bridge objects are a bluey, pinky wierd color. quite disturbing visual. also the exe file seems 4 times larger than the original ( 4353kb, original was 1868kb )

#4 DirectX November 2008 TGEA Broken d3d 11/08
DirectX SDK 11/2008

I can also verify this problem!
I just had a full-screen of psychedelic shader-patterns, nothing rendered correctly. Alternatively i also saw all-black, all-grey, and all-white depending on various graphics options. Screenshot: TGEA - InaGaddaDaVida



Updated my drivers, to no avail.

- Sun Microsystems Ultra-40 M2 Workstation
- nVidia Quadro-FX1700
- WindowsXP-Pro (SP3)

#5 Definitely broken.

I can verify this also. And if it matters I'm Using Vista with nVidia graphics, 3GB RAM & 2.4 GH processor. Just tried it last night/today. Rendering of interiors were screwed up, some missions would start with the screen being black until switching to the editor, and changing resolutions had...odd results. Didn't take a screenshot though.

Switched back to an older SDK and all problems went away.

#6 Forgot to post back:

I had *better* luck with TGEA-1.8 but still ran into problems IIRC. Ended up rolling back to DirectX-SDK March-2008, and the issue seems to be resolved.

#7 I'm also getting the same results with the DirectX SDK from November 2008.

The issue is only with .DIFs rendering in the technicolor pastel rainbow.

Here's a screenshot.

I'm using Windows XP with Visual Studio 2008. I reverted to the August 2008 DirectX SDK and
the issue is resolved. Is this a TGEA issue or a DirectX issue?

#8 I just looked into this and it looks like it is a DirectX shader compiler optimization bug. When one of the bound samplers doesn't end up actually contributing to the final output color it is getting dropped out. Unfortunately, for some reason the next sampler is getting renumbered with the dropped sampler stage and all of the texture reads are occurring against the wrong texture.

Blarh....bad Microsoft!

On the Interiors this is occurring because the lightNormMap sampler is not actually getting used for anything (since we aren't using a bumpmap or per-pixel specular for most of the Interiors) and the fogMap is getting bound to the 2nd sampler instead.

There are a couple of work-arounds:

1) You can modify the LightNormMapFeatHLSL::processPix() to add something like this at the end:

Var *color = (Var*) LangElement::find( "col" );
   if( color )
   {
      meta->addStatement( new GenOp( "   @.a *= @.a;\r\n", color, lightmapNorm ) );
      meta->addStatement( new GenOp( "   @.a /= @.a;\r\n", color, lightmapNorm ) );
   }

This "uses" the sampler enough to cause it to not be optimized away. However, this only fixes the Interiors. You'll also notice that the underwater shader suffers a similar issue. You can add a similar:

// This is useless but works around a Novemeber 2008 DXSDK shader optimization bug
   float4 refMapColor = tex2Dproj( reflectMap, IN.texCoord3 );
   OUT.col.a *= refMapColor.a;
   OUT.col.a /= refMapColor.a;

2) The fix I am currently testing is to force the shader compiler back to the old shader compiler which we are already using for 1.1 and 1.4 shaders. I'm not 100% sure of the negative impact of this but it could possibly cause a little bit of a slow down (not as optimized) or might have issues with some of the fancier shader model 3.0 shaders but so far everything looks like it is working correctly.

To "enable" this work around go into GFXD3D9Shader::_compileShader() and add this code block on line 598 (just after the #endif):

if (D3DX_SDK_VERSION == 40)
      flags |= D3DXSHADER_USE_LEGACY_D3DX9_31_DLL;

Hopefully this bug is limited to only this release (version 40) and we will get a new one soon. In the meantime it probably wouldn't hurt to avoid the November 2008 DXSDK if you can.

#9 I asked Pat Wilson about the second option (the D3DXSHADER_USE_LEGACY_D3DX9_31_DLL one) and he said that he thought there would only be a minimal impact in performance.

Since he is the expert in such things and this will be reliable across all of the possible combination of features and shaders (unlike the first one which only handles the specific cases already identified) I am going to go with this option.

Btw...if you want to use the November 2008 DXSDK with TGEA 1.7.1 you will have to apply the same patch.

#10 Is the TGEA tied to DirectX? Can we flip over to open GL? Or is that option only for TGE? The reason I went for TGEA is the freakin awesome frame rate.

400+ FPS in the TGEA 1.7.1 stronghold demo
vs
50-70 FPS in TGE 1.5 stronghold demo

#11 Um, anyone have a link to the March 2008 SDK? Microsoft is only showing the 2008 in the default directX download. msdn.microsoft.com/en-us/directx/default.aspx

Looks Like August is here www.microsoft.com/downloads/details.aspx?FamilyID=ea4894b5-e98d-44f6-842d-e32147...

#12 @ Britton TGEA < 1.8 is non OpenGl out of the box.

And heres the march one.

#13 Just as an FYI, this is a problem with TGEA 1.7.0... I was wondering why all my crappy little shacks turned electric blue after rebuilding my PC, lol. Now I just have to find the equivalent to that _compileShader() function and I'll be all set :)

#14 Okay, so for TGEA 1.7.0, for those wondering, I hacked the second workaround from Matt in around line 180 after an #endif in the GFXD3D9Shader::initShader function and it worked like a charm.

#15 Pat Wilson kindly tracked down a member of the Microsoft DirectX team who offered to take a look at this bug.

I sent on the bug report and within 2 hours Andy Campbell and Dieter Van Wassenhove got back to me to say that the bug is already fixed in the March 2009 DirectX SDK (which we should be able to lay our hands on in March or so) and that they will keep add our "failing" shader to their regression tests to make sure it doesn't happen again.

Go Microsoft!

#16 Whoa! Microsoft was actually good for something - amazing!

#17 Go garage games! You guys constantly help restore my faith in humanity.

#18 August 2008 dx sdk works fine