[DXT3] menu in Tribunal now vanishes (regression?)

[Michael Günnewig]

"Ann and Jason Edmeades" <us at the-edmeades.demon.co.uk> writes:

>>The patches themself seem to be okay only that the new if-statement in
>>IDirect3D8Impl_CheckDeviceFormat should be #ifdef
>>GL_EXT_texture_compression_s3tc because if it's not defined we don't
>>have the support as you can see in IDirect3DSurface8Impl_LoadTexture
>>(surface.c:468). So it will lead to white boxes on a system, when at
>>compile-time the constant isn't defined and the system says it support
>>it. But this isn't the case for me because the log show that it
>>definitly calls glCompressedTexImage2D.
>
> I dont understand this fully. The whole point is to eventually make all the
> decisions based at run time as to the capabilities of the graphics card, to
> enable distributions of wine (otherwise you are limited to the capabilities
> of the machine it was compiled on). Therefore in fillglcaps, we loog for the
> prescence of the compressed texture string (EXT_texture_compression_s3tc)
> and if present we will call it.

Yes but that what we have now. If GL_EXT_texture_compression_s3tc
isn't defined at compile time we disable support for DXT1/3/5 in
LoadTexture but we don't disable the code to ask the OpenGL system if
it supports it. So when the headers don't define the constant but the
hardware supports it we currently say that we would support it even if
we doesn't. There are these possible ways to solve this:

1. #ifdef the code in CheckDeviceFormat so that it will say
    unsupported if the code in LoadTexture isn't present.
2. remove the #ifdef in LoadTexture (only problem could be that
    glCompressedTexImage2D couldn't be resolved at time of linking)
3. write a software solution, so that we support S3TC even if the
    hardware doesn't.

> In your case, it is present so it will be called. So when querying device
> formats, we can return that dxt1,3,5 are available, and later on we should
> call the glCompressedTexImage2D call. #ifdef'ing it either takes it out (in
> which case we say we dont support dxtn and the pgm probably does its own
> decompression), or you go through the same code.
>
> So its back to why are you getting an error from that call. Can you please
> send me (not wine-devel) a --debugmsg +d3d,+d3d_surface trace up to the
> point the menu is displayed please (ie I should see the error on the load
> texture for a dxtn format).

Okay. I will upload it an a server instead of mailing it to you,
because of it's size even with BZIP2 compression.

> One final question, did the game use to play ok? I get very little feedback
> on dx8 games, so I dont really know how well things are running.

I can start playing the game but there some graphic errors:
 - when DXT3 is enabled instead of the menu only white blocks appear.
   all the textures are missing in the game
 - when DXT3 is disabled the menu is okay, the textures are there.

But after playing a very short time it leaves with an exception in the
heap managment code -- will post a bug report on this soon.


  Michael