Binarystream texture is not drawing in Generals

[xezon]

Prerequisites

• I have searched for similar issues and confirmed this is not a duplicate

Game Version

• Command & Conquer Generals
• Command & Conquer Generals: Zero Hour
• Other (please specify below)

Bug Description

Binarystream texture is not drawing in Generals. Can be tested with Lotus capturing buildings.

Introduced with #1989

It most likely will be resolved by merging more of W3D code.

Reproduction Steps

Lotus

Additional Context

No response

[Mr-Sheerlock]

I found the following:

1- Old Generals behaviour before PR: originally for generals, in the loop of determining dimensions after Validate_Texture_Size hardware compliant dimensions that happened to trigger for thin textures like EXBinaryStream.tga of dimensions 16x256 (ie. doesn't meet the aspect ratio of 1:8) the reduction happened only once always because they passed the wrong variables to Validate_Texture_Size , setting Reduction=1. This ultimately resulted in a D3DTexture: reducedW=8 reducedH=128 mip_level_count=2

if we fix the bug in the old code we get D3DTexture: reducedW=4 reducedH=32 mip_level_count=1 I don't know if this is the desired behaviour in this case.

2- As for the new generals behaviour after the PR: there is a bug of setting Reduction after the hardware caps validation setting it back to 0 even after calculation. This results in D3DTexture: reducedW=4 reducedH=32 mip_level_count=1 and more importantly, accessing the DDS file with reduction =0 resulting in the following mismatch: Load_Compressed_Mipmap Copy: level=0 width=4 height=32 dds_w=16 dds_h=256 which means the render will fail silently.

So why didn't ZH suffer from the same bug? because they used a new EXBinaryStream32.tga of dimensions 32x256 which is aspect-ratio compliant.

Fixing the redundant Reduction assignment resulted in setting width to zero, so adding clamping to 4 in multiple places resulted in dimensions of 4x32 and fixed the problem. I still don't know if this would be considered a valid solution thus I didn't make a PR.

If you intend to maintain the original behaviour, in this case we might consider precompiler flags.

[Mr-Sheerlock]

To better demonstrate the part I mean in the textureloader.cpp

// in begin_compressed_load()
TextureLoader::Validate_Texture_Size(width, height,orig_d);

if (width != orig_w || height != orig_h)
{
	
	for (unsigned int i = 1; i < orig_mip_count; ++i)
	{
		unsigned w=orig_w>>i;
		if (w<4) w=4;
		unsigned h=orig_h>>i;
		if (h<4) h=4;
		unsigned tmp_w=w;
		unsigned tmp_h=h;

		TextureLoader::Validate_Texture_Size(w,h,orig_d);

		if (w == tmp_w && h == tmp_h)
		{
			Reduction	+= i;
			width			=	w;
			height		=	h;
			break;
		}
	}
}

Width		= width;
Height	= height;
Format	= Get_Valid_Texture_Format(orig_format, Texture->Is_Compression_Allowed());
Reduction = reduction;   // <--- superflous assignment, overrides the calculation we had just performed.

edit: I think I better make a PR.