dxwrapper: Can't wrap custom d3d8.dll with d3d8to9

I wanted to do some more research and @elishacloud’s info regarding Direct3D8 being redirected to the Direct3D9 drivers after Windows update 19H1 gave me some clues as to where I could look.

First I should mention how Freelancer makes use of DirectX 8’s lights. Basically the game uses so-called Thorn scripts to specify what kind of lights should be used in a scene. Inherently these are just compressed Lua scripts. Here’s an example of how a light is set in one of the scripts that has been decompressed:

{
	entity_name  =  "ambi_LtG03_Basement_Ohd_Ylw",
	type  =  LIGHT,
	template_name  =  "",
	lt_grp  =  3, srt_grp  =  0, usr_flg  =  0,
	spatialprops  = 
	{
		pos  =  { -5.010058, 0, 1.758013 },
		orient  =  { { -0.105263, -0.008535, -0.994408 },
				   { 0.977260, 0.184208, -0.105029 },
				   { 0.184075, -0.982850, -0.011049 } }
	},
	lightprops  = 
	{
		on  =  Y,
		color  =  { 234, 192, 115 },
		diffuse  =  { 0.623529, 0.576471, 0.376471 },
		specular  =  { 0, 0, 0 },
		ambient  =  { 0.086275, 0.086275, 0.07451 },
		direction  =  { 0, 0, 1 },
		range  =  100,
		cutoff  =  179,
		type  =  L_SPOT,
		theta  =  179,
		atten  =  { 1, 0, 0 }
	}
}

If you look closely at the parameters in the lightprops entry, you can see that they look very similar to the values in the D3D8LIGHT8 struct.

A while ago I talked to another Freelancer modder about the lighting bug. After a small investigation they concluded the light type L_SPOT became broken after the Windows update. So they “fixed” it by going into every Thorn script to change each light with the type L_SPOT to L_POINT. Internally this changes the DirectX 8 light type from D3DLIGHT_SPOT to D3DLIGHT_POINT. However, in my opinion this isn’t really a good solution because point lights behave very differently from spot lights.

I really wanted to look for a better solution, and based on the clue regarding the redirection of Direct3D8 to the Direct3D9 drivers, I checked out the documentation for the lights from both DirectX 8 and DirectX 9. One thing that stood out to me right away was that the description for the members Falloff, Theta, and Phi simply said “Not supported.” in the DirectX 8 documentation, whereas in the DirectX 9 documentation it seems these definitely are supported. In the light specifications from the Thorn scripts I noticed that the value theta was set despite it apparently not even being supported in DirectX 8.

I wanted to find out whether or not the sudden support of the three values in DirectX 9 is the cause of the lighting bug. Though I did not know what the given light values for Falloff or Phi are since they are not specified in the light properties. Hence I decided to use @elishacloud’s DirectX-Wrappers project to intercept the IDirect3DDevice8::SetLight method so I could see what the values for each light are and what happens when they are modified.

After some trial and error, I came up with this:

HRESULT m_IDirect3DDevice8::SetLight(DWORD Index, CONST D3DLIGHT8 *pLight)
{
	D3DLIGHT8* pLightEdit = const_cast<D3DLIGHT8*>(pLight);

	// Only the light type D3DLIGHT_SPOT suffers from the lighting bug
	if (pLightEdit->Type == D3DLIGHTTYPE::D3DLIGHT_SPOT)
	{
		// Fix lighting bug
		pLightEdit->Falloff *= 0.5f;
		pLightEdit->Theta *= 0.5f;

		// Impose minimum Falloff to ensure shadows won't look too sharp
		if (pLightEdit->Falloff < 0.6f)
			pLightEdit->Falloff = 0.6f;
	}

	return ProxyInterface->SetLight(Index, pLightEdit);
}

Using the d3d8 wrapper with this code in Freelancer completely rectifies the lighting bug. Basically I reduced the Falloff and Theta values for spot lights to make them appear less harsh. Furthermore, I set a minimum Falloff value to ensure the light edges/shadows look smoother.

I should mention that I can’t confirm whether my suspicion about Falloff, Theta, and Phi not working on DirectX 8 is true because I actually haven’t done any tests on an older Windows version. Also, with these updated values the lighting doesn’t look exactly the same as how it originally did on older Windows versions; in most scenes the light looks slightly dimmer. Maybe a better DirectX programmer can have a look at it one day. Here’s the source code for the implemented lighting bug fix as a proof of concept: https://github.com/BC46/freelancer-lighting-bug-fix.

Before and after screenshots:

Great! Thanks for all your help here!

Ok, great. I’m going to keep the if statement because we don’t want to do anything if Theta is larger than Phi. I’m also not going to change the Falloff since that is best left at it current value.

Here is the final code I will use. I will make a pull request later in d3d8to9.

HRESULT STDMETHODCALLTYPE Direct3DDevice8::SetLight(DWORD Index, const D3DLIGHT8 *pLight)
{
	if (!pLight)
	{
		return D3DERR_INVALIDCALL;
	}

	D3DLIGHT8 LightEdit;
	memcpy_s(&LightEdit, sizeof(LightEdit), pLight, sizeof(LightEdit));

	// Make spot light work more like Direct3D8 worked
	if (LightEdit.Type == D3DLIGHTTYPE::D3DLIGHT_SPOT)
	{
		if (LightEdit.Theta <= LightEdit.Phi)	// Theta must be in the range from 0 through the value specified by Phi.
		{
			LightEdit.Theta /= 1.75f;
		}
	}

	return ProxyInterface->SetLight(Index, &LightEdit);
}

Here is an updated dxwrapper build with this fix in it: dxwrapper.zip

I also enabled the following:

[Compatibility]
D3d8to9                    = 1

[d3d9]
AnisotropicFiltering       = 16
AntiAliasing               = 1

Putting aside that this should all be easily readable in the offline docs shipped with the sdk, you are right that the windows CE version was different. https://web.archive.org/web/20040103201823/http://msdn.microsoft.com/archive/en-us/dx81_c/directx_cpp/GRAPHICS/Reference/CPP/D3D/Structures/d3dlight8.asp https://web.archive.org/web/20040806062027/http://msdn.microsoft.com/archive/en-us/directx9_c/directx/graphics/reference/d3d/structures/d3dlight9.asp https://web.archive.org/web/20040907224729/http://msdn.microsoft.com/archive/en-us/directx9_c/directx/graphics/reference/d3d/enums/d3dlighttype.asp

You should also open another issue about that lighting bug, since it’s kinda within the aims of dxwrapper to fix too.

I wasn’t sure if I was supposed to do this since it’s a very specific issue. But I’ll do it, thanks for letting me know.