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.
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).
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.
FYI I am still working on it (with a lot less free time at the moment) but getting stuck on a couple of areas we need to address at some point so making slow progress. I want to get back to optimizing again asap.
Jason
"Ann and Jason Edmeades" us@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
Weird... how come Morrowind have started "working" all of a sudden? It crashed for me. I wasn't aware of any patches affecting the problem I was having with it (the original version, but now I have the two expansions available). Time to retest and post my results.
[]'s
Stephen Pedrosa Eilert
--- /"\ \ / CAMPANHA DA FITA ASCII - CONTRA MAIL HTML X ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL / \
Stephen Pedrosa Eilert spedrosa@mailandnews.com writes:
Weird... how come Morrowind have started "working" all of a sudden? It crashed for me. I wasn't aware of any patches affecting the problem I was having with it (the original version, but now I have the two expansions available). Time to retest and post my results.
Using the following native DLLs: msvideo, msvfw32, ole32, oleaut32, quartz, rpcrt4, iviaudio.ax, msvcp60.dll
The rest are builtin ones.
Have registered all self-registering DLLs after installing the winedefault.reg by calling regsrv32.exe by hand (was order dependent, but don't know it anymore, sorry).
Michael
-
Ann and Jason Edmeades -
MichaelGuennewig＠gmx.de -
Stephen Pedrosa Eilert