Fix ship dealer preview window rendering garbage

[BC46]

In the ship dealer preview window, there is a rendering bug that causes some surfaces of the ship to render with a dark-blue tint.

Actual model (no issues):

Model in ship dealer preview window with some surfaces having a dark tint:

This dark tint happens because the ship preview window is rendering garbage data. I was unable to figure out what causes this under the hood because the FL beta renders this window in a similar fashion, but it doesn't suffer from this bug. Eventually I managed to make the discovery that wiping out the call that sets the culling mode to none fixes the bug. After that I talked to Schmackbolzen and we figured out that using the depth test D3DCMP_LESS instead of D3DCMP_LESSEQUAL fixed the problem for the most part too, besides a couple of surfaces that still render incorrectly.

freelancer.exe, 1845A7, 04 -> 02 = use D3DCMP_LESS in ship dealer preview
freelancer.exe, 19E333, 99 -> 96 = wipe out call for setting culling mode to none (volatile approach, use only for testing)

My suggestion is to hook the ship rendering function and set the culling mode to anything other than none while the ship is being rendered. Though this will certainly conflict with #11 because this feature requires the exact same function to be hooked. The problem with this is that I want these to be two separate features that can be disabled independently via the config file in the event that there are issues.

[thaddeus-ex]

The dark parts arrowed are dds _2side textures, they are supposed to view the same from both sides - not dark like this. The Banshee also displays the same problem with _2side textures around the cockpit.

[BC46]

The dark parts arrowed are dds _2side textures, they are supposed to view the same from both sides - not dark like this.

This is correct. Before trying to come up with a code-based solution I talked about it with Jeider and he pointed it out as well, that the bugged textures use the material type DcDtTwo. He suggested changing the material type of elite_256LB_2side to DcDt to fix the dark front texture on the BH ships. This worked, so I did the same thing for liberty1_256_2side to fix the texture around the cockpit glass. However, in addition to fixing the bug, it caused the inner sides of the baydoors to be transparent, which is clearly undesired.

The Banshee also displays the same problem with _2side textures around the cockpit.

After having a careful look, it appears that many other ships suffer from this problem as well in some way (e.g. the metal around cockpit glass of the BW ships, Corsair ships, Pirate ships, and the Drake). The Humpback has two large side panels around the baydoor that are bugged too. It's really unfortunate to notice all of this just now. As I child, the dark front-panel on the BH ships did stand out to me, but I didn't think much of it.

My theory is that the ship preview renderer draws the DcDtTwo textures separately for every face, but the face that has the dark-blue tint is drawn last. During this last draw there is a bug in the code that causes the diffuse color to be garbage essentially because the tint is same for every problem instance, yet the color appears to be completely arbitrary. The bugged texture being draw last would explain why changing the D3DCMP_LESSEQUAL depth test to D3DCMP_LESS fixes the problem for the most part. Before it was the last drawer wins, now it's the other way around, so the first drawer wins.

[BC46]

I took some PIX captures of the Hamburg ship dealer while the dealer menu was open. This allowed me to see how exactly the Humpback was rendered step by step in both the room and the preview window. From there I carefully compared the calls so I could note the differences in both render approaches. Finally I saw why the ships in the preview window were rendering incorrectly. The developers forgot to set the ZFUNC and CULLMODE render states right before rendering the preview ship. Thanks to how FL's rendering pipeline works under the hood, this results in missing calls when each individual ship part is rendered. Whenever FL renders a ship in any other scene, it does set the two render states correctly, which is why in those scenarios the ship renders as it should.

This does mean our original suspicions were indeed the correct ones. Implementing the fix from here should be pretty much trivial.