Re: [AVIFIL32] question about ACMStream_fn[AddRef|Release] in acmstream.c
Paul Vriens <[EMAIL PROTECTED]> writes:
> Hi,
>
> during my code cleanup I came to acmstream.c and found the following:
>
> static ULONG WINAPI ACMStream_fnAddRef(IAVIStream *iface)
> {
> IAVIStreamImpl *This = (IAVIStreamImpl *)iface;
>
> TRACE("(%p) -> %ld\n", iface, This->ref + 1);
>
> /* also add reference to the nested stream */
> if (This->pStream != NULL)
> IAVIStream_AddRef(This->pStream);
>
> return ++(This->ref);
> }
>
> the AddRef can be cleaned up.
I don't really know what you want to cleanup here, looks very clean to me.
> the Release however looks buggy:
>
> static ULONG WINAPI ACMStream_fnRelease(IAVIStream* iface)
> {
> IAVIStreamImpl *This = (IAVIStreamImpl *)iface;
>
> TRACE("(%p) -> %ld\n", iface, This->ref - 1);
>
> if (This->ref == 0) {
> /* destruct */
>
>
> This means I have to do a Release twice before it actually goes into the
> if statement, because the decrementing takes place at the end of the
> Release function.
>
> Can anybody confirm my finding.
You are right, the release method is buggy. the comparision must check
against one instead of zero or the decrement in the return statement
must be moved before this if-statement.
Michael Günnewig
Re: acmstream mem leak fix
James Hawkins <[EMAIL PROTECTED]> writes: > Unless I'm mistaken, we don't want to free allocated memory only when > the call fails. Sorry, but you are wrong. When you always free the memory you will run into a segmentation fault when the application uses the returned stream. The problem is the same as with the icmstream patch you made. The current implementation will work correctly in all cases although it doesn't look very COM-like as Mike already pointed out for the icmstream patch. The methods you analyzed are only called internally from IClassFactory_fnCreateInstance in the factory.c file. The memory block which is allocated by LocalAlloc in the AVIFILE_CreateICMStream and AVIFILE_CreateACMStream is only returned to the application if the IAVIStream_QueryInterface call doesn't return an error. So when you always free the memory block you will most probably run into a segmentation fault. The proposed patch from Mike for the icmstream.c file should be adapted to this file when you don't like the LocalFree call there, but I'm sure that then people will ask why we don't call LocalFree in this method. So it would be perhaps fine when also some comments would be added to prevent another discussion about what's wrong or correct. When you don't understand the code feel free to write me as I'm the one who has produced it. Regards Michael Günnewig
Re: [dx88] Cull fix
Jason Edmeades <[EMAIL PROTECTED]> writes: > Michael - See if this helps with your map / figure problems... Sorry, but it doesn't helped. Also the other ones doesn't helped. The fixme's fixme:d3d_surface:IDirect3DSurface8Impl_LockRect fixme:d3d:IDirect3DDevice8Impl_SetRenderTarget fixme:d3d:IDirect3DDevice8Impl_ResourceManagerDiscardBytes also still appear as before. Do you want a new "-debugmsg +d3d8,+d3d_surface" log or pherhaps the texture snapshots? But I couldn't create any of them before next week, because I'm going sailing over the weekend. Michael
Re: {Heap,Global,Local,}ReAlloc status (take 2)
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > Hi folks, > > Oleg has been doing a lot of good work, and we are now > down to 73 HeapReAlloc and 73 non-HeapReAlloc entries > to review. I'm still not sure how the comctl32.ReAlloc() > should behave, any help in getting that resolved would > be highly appreciated. > > Here is the update list: These are okay: > ./dlls/avifil32/api.c: pOptions->lpFormat = > GlobalReAllocPtr(pOptions->lpFormat, size, GMEM_MOVEABLE); > ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, > cbBuffer *= 2, GPTR)) != NULL); > ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, > cbBuffer *= 2, GPTR)) != NULL); > ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, > cbBuffer *= 2, GPTR)) != NULL); > ./dlls/avifil32/extrachunk.c:lp = (LPDWORD)GlobalReAllocPtr(extra->lp, extra->cb > + size + 2 * sizeof(DWORD), GHND); > ./dlls/avifil32/extrachunk.c:lp = (LPDWORD)GlobalReAllocPtr(extra->lp, extra->cb > + cb, GHND); > ./dlls/avifil32/getframe.c: This->lpInFormat = GlobalReAllocPtr(This->lpInFormat, > This->cbInBuffer, 0); > ./dlls/avifil32/getframe.c: > (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpOutFormat, size, GMEM_MOVEABLE); > ./dlls/avifil32/icmstream.c: > (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpbiPrev,size,GMEM_MOVEABLE); > ./dlls/avifil32/icmstream.c: > (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpbiPrev,size,GMEM_MOVEABLE); > ./dlls/avifil32/editstream.c: GlobalReAllocPtr(This->pStreams, > (This->nTableSize + 32) * sizeof(EditStreamTable), GMEM_SHARE|GHND); > ./dlls/avifil32/editstream.c:pEdit->pStreams = GlobalReAllocPtr(pEdit->pStreams, > This->nStreams * sizeof(EditStreamTable),GMEM_SHARE|GHND); These must be fixed because GlobalReAlloc under Win98SE doesn't allocates memory when handle is NULL: > ./dlls/avifil32/avifile.c: This->idxFmtChanges = > GlobalReAllocPtr(This->idxFmtChanges, This->nIdxFmtChanges * sizeof(AVIINDEXENTRY), > GHND); > ./dlls/avifil32/avifile.c:This->idxFrames = GlobalReAllocPtr(This->idxFrames, > This->nIdxFrames * sizeof(AVIINDEXENTRY), GHND); > ./dlls/avifil32/avifile.c:(LPDWORD)GlobalReAllocPtr(This->lpBuffer, max(size, > This->sInfo.dwSuggestedBufferSize), GMEM_MOVEABLE); > ./dlls/avifil32/acmstream.c:This->acmStreamHdr.pbSrc = > GlobalReAllocPtr(This->acmStreamHdr.pbSrc, > ./dlls/avifil32/acmstream.c:This->acmStreamHdr.pbDst = > GlobalReAllocPtr(This->acmStreamHdr.pbDst, Will make the above ones, was my mistake. Michael
Re: [dx85] vertex blend fixmes
Jason Edmeades <[EMAIL PROTECTED]> writes: > Michael - This will silence those horrible fixmes about > worldmatrix(0..255) and vertex blend not being supported - We > incorrectly return support since the NVidia drivers dont claim support > for it, but DO return a number for the GL_MAX_VERTEX_UNITS_ARB (which > is only supported as far as I can tell, if arb_vertex_blend is > supported... weird). Does it help with the textures at all? Jeah, it works. Textures are present and it also doesn't crash anymore. Thank you. :-) Michael
Re: Misc bugs found by using valgrind
Alexandre Julliard <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Michael Günnewig) writes: > >> It's a point, so here is the new patch. > > I don't think we need to check string sizes against MAXINT, that's > just a waste of time. Okay you're correct, the check isn't necessary as MAXINT * 2 is MAXUINT - 1 and the size parameter of GlobalAlloc is unsigned. But the * sizeof(WCHAR) in the GlobalAlloc call is necessary to avoid possible memory corruption because of buffer overruns. So here is it. Michael --- dlls/avifil32/api.c.SAV 2003-09-20 16:14:45.0 +0200 +++ dlls/avifil32/api.c 2003-10-03 00:54:11.0 +0200 @@ -1009,2 +1009,2 @@ szFilter[0] = 0; szFilter[1] = 0; - wszFilter = (LPWSTR)GlobalAllocPtr(GHND, cbFilter); + wszFilter = (LPWSTR)GlobalAllocPtr(GHND, cbFilter * sizeof(WCHAR)); if (wszFilter == NULL) return AVIERR_MEMORY;
Re: [dx82] Recode all the lights support
Jason Edmeades <[EMAIL PROTECTED]> writes: > Changelog > > MaxActiveLights means number of concurrent lights, but any number can > be set up. Change support for lights into a linked list and only set > up an equivalent gl light when the light is enabled. > > Jason > > PS If this causes any regressions please let me know. I have tested it > as far as possible and havent seen anything wrong with it. When trying to playing "The Elder Scrolls III: Tribunal" version 1.4.1313 german I get now the following fixme's: fixme:d3d:IDirect3DDevice8Impl_LightEnable Light enabled requested but light not defined, so defining one! Now the cone's of the lights are visible on surfaces near a source. Looks better now, but the known issues (body texture missing, crash after a while) still persists. Michael
Re: Misc bugs found by using valgrind
Shachar Shemesh <[EMAIL PROTECTED]> writes: > Michael Günnewig wrote: > >>Changelog: >> Fixed use of uninitialized memory and wrong buffersize (found by valgrind). ... > What are we doing to prevent integer overflow on these allocations? > Shouldn't we, perhaps, use some wrapper that checks that > "cbFilter*sizeof(WCHAR)" is not greater than "MAXINT"? It's a point, so here is the new patch. Michael --- dlls/avifil32/api.c.SAV 2003-09-20 16:14:45.0 +0200 +++ dlls/avifil32/api.c 2003-09-22 12:13:55.0 +0200 @@ -1005,12 +1005,14 @@ return AVIERR_BADPARAM; if (cbFilter < 2) return AVIERR_BADSIZE; + if (cbFilter >= MAXINT_PTR / sizeof(WCHAR)) +return AVIERR_MEMORY; szFilter[0] = 0; szFilter[1] = 0; - wszFilter = (LPWSTR)GlobalAllocPtr(GHND, cbFilter); + wszFilter = (LPWSTR)GlobalAllocPtr(GHND, cbFilter * sizeof(WCHAR)); if (wszFilter == NULL) return AVIERR_MEMORY; --- dlls/kernel/profile.c.~1.2.~ 2003-09-07 23:33:00.0 +0200 +++ dlls/kernel/profile.c 2003-09-20 15:06:51.0 +0200 @@ -1221,7 +1221,8 @@ LPWSTR bufferW; INT retW, ret = 0; -bufferW = buffer ? HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)) : NULL; +bufferW = (buffer ? HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, + len * sizeof(WCHAR)) : NULL); if (section) RtlCreateUnicodeStringFromAsciiz(§ionW, section); else sectionW.Buffer = NULL; if (filename) RtlCreateUnicodeStringFromAsciiz(&filenameW, filename); --- dlls/user/message.c.~1.45.~ 2003-09-16 13:25:43.0 +0200 +++ dlls/user/message.c 2003-09-20 14:51:57.0 +0200 @@ -2166,6 +2166,7 @@ TRACE( "hwnd %p msg %x (%s) wp %x lp %lx\n", hwnd, msg, SPY_GetMsgName(msg, hwnd), wparam, lparam ); +memset(&info, 0, sizeof(info)); info.type = MSG_POSTED; info.hwnd = hwnd; info.msg= msg; @@ -2211,6 +2212,7 @@ } if (USER_IsExitingThread( thread )) return TRUE; +memset(&info, 0, sizeof(info)); info.type = MSG_POSTED; info.hwnd = 0; info.msg= msg;
Re: Bug in the heap management code?
[EMAIL PROTECTED] (Michael Günnewig) writes:
> Have done some tests with some other programms which seems to work and
> get the following (and some more which I was able to fix myself):
> ,-
> | ==3597== 6 errors in context 4 of 5:
> | ==3597== Conditional jump or move depends on uninitialised value(s)
> | ==3597==at 0x402606D7: HEAP_ValidateInUseArena (heap.c:854)
> | ==3597==by 0x40260A40: HEAP_IsRealArena (heap.c:965)
> | ==3597==by 0x402615F2: RtlValidateHeap (heap.c:1489)
> | ==3597==by 0x4145E5B0: HeapValidate (heap.c:199)
> | ==3597==
> `-
>
> At heap.c:854 (it's ntdll/heap.c Version 1.23):
> ,-
> 851 | }
> 852 |
> 853 | /* Check magic number */
> 854 | if (pArena->magic != ARENA_INUSE_MAGIC)
> 855 | {
> 856 | if (quiet == NOISY) {
> 857 | ERR("Heap %08lx: invalid in-use arena magic for %08lx\n",
> `-
>
> Will try to find out who is the bad guy ... can someone guide me?
Okay, these will occur when releasing a memory block allocated by
GlobalAlloc without the GMEM_ZEROINIT flag. When adding the flag
valgrind is happy. Does that mean that's a bug in valgrind or in wine?
Michael
Re: [TOOLS] winecheck has still old environment syntax
Oops, wrong list and that twice. Stupid resend to -- entered wine-patches but sended it to wine-devel again *grumpf* Michael
Re: Bug in the heap management code?
[EMAIL PROTECTED] (Michael Günnewig) writes:
> Mike Hearn <[EMAIL PROTECTED]> writes:
>
>> This is very much like a problem I am having with InstallShield.
>> Something, somewhere, is trashing the heap data structures, which causes
>> a crash some time later, often yards away from the original bug. As far
>> as I know, there is no good way to spot this problem, it's just C/C++
>> sucking maybe valgrind might help?
Have done some tests with some other programms which seems to work and
get the following (and some more which I was able to fix myself):
,-
| ==3597== 6 errors in context 4 of 5:
| ==3597== Conditional jump or move depends on uninitialised value(s)
| ==3597==at 0x402606D7: HEAP_ValidateInUseArena (heap.c:854)
| ==3597==by 0x40260A40: HEAP_IsRealArena (heap.c:965)
| ==3597==by 0x402615F2: RtlValidateHeap (heap.c:1489)
| ==3597==by 0x4145E5B0: HeapValidate (heap.c:199)
| ==3597==
`-
At heap.c:854 (it's ntdll/heap.c Version 1.23):
,-
851 | }
852 |
853 | /* Check magic number */
854 | if (pArena->magic != ARENA_INUSE_MAGIC)
855 | {
856 | if (quiet == NOISY) {
857 | ERR("Heap %08lx: invalid in-use arena magic for %08lx\n",
`-
And when I quit "The Elder Scrolls III: Tribunal" version 1.4.1313
german before it bombs, I sometimes get the error message from line 857.
Will try to find out who is the bad guy ... can someone guide me?
Michael
Re: Bug in the heap management code?
Lionel Ulmer <[EMAIL PROTECTED]> writes: >> Yes and no. valgrind still doesn't support many instructions... > > Well, using any DRI GL libraries or the NVIDIA GL libraries is not really > supported by Valgrind right now... Yes, but even with Mesa it bombs. Seems to be that quartz.dll is the problem, but I need the native version because the builtin one is missing some things which are needed. Michael
Re: [DXT3] menu in Tribunal now vanishes (regression?)
"Ann and Jason Edmeades" <[EMAIL PROTECTED]> writes: > Thanks! I'll take a look. It'll probably be the weekend before I get a > chance to dig in, so bear with me. From your last post I think I understand > what you mean, and it should be easy to resolve. I'll get back to you Thanks, the patches dx76 up to dx79 have fixed the menu issue and als the most textures in the game are now back. But in the game the textures for the body of the persons are still missing as before, see screenshot at http://ls6-www.cs.uni-dortmund.de/~guennewi/Morrowind-Juib.png Don't know why because it doesn't give any error. Pherhaps these textures are only present with DXT2/4 support which isn't available. Michael
[TOOLS] winecheck has still old environment syntax
Symptom:
>>> Checking drive F settings:
016. Checking Path option... SUSPICIOUS (%HOME% does
not exist !).
- ADVICE: create this directory or point Path to a real directory.
017. Checking Type option... OK.
--> PROBLEM.
Changelog:
Adapted winecheck to use new environment variable syntax (ex. %HOME%).
Michael
Index: tools/winecheck
===
RCS file: /home/wine/wine/tools/winecheck,v
retrieving revision 1.13
diff -d -u -r1.13 winecheck
--- tools/winecheck 4 Apr 2003 22:12:21 - 1.13
+++ tools/winecheck 19 Sep 2003 15:49:09 -
@@ -346,7 +346,7 @@
$level = $serious ? $is_failed : $is_bad;
$reason = "wrong Path format ".$path;
}
- elsif ($path =~ /\$\{(.*)\}$/)
+ elsif ($path =~ /\%(.*)\%$/)
{
# get path assigned to environment variable
my $envpath = $ENV{$1};
Re: Bug in the heap management code?
Mike Hearn <[EMAIL PROTECTED]> writes: > This is very much like a problem I am having with InstallShield. > Something, somewhere, is trashing the heap data structures, which causes > a crash some time later, often yards away from the original bug. As far > as I know, there is no good way to spot this problem, it's just C/C++ > sucking maybe valgrind might help? Yes and no. valgrind still doesn't support many instructions... Have set and exported __GL_FORCE_GENERIC_CPU=1 else it will crash much earlier. Seems to me that the native DLLs which I need to run Morrowind contains some non-486 instructions. Does anyone knows whether it's possible to tell these DLLs that we only have a 486 ? Output of valgrind is attached. Michael valgrind.log.gz Description: Morrowind-valgrind.log.gz
Re: [DXT3] menu in Tribunal now vanishes (regression?)
Stephen Pedrosa Eilert <[EMAIL PROTECTED]> 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
Bug in the heap management code?
Hallo. When I try to play "The Elder Scroll III: Tribunal" version 1.4.1313 german under wine I get a page fault after some time. The time span differs and so the calling point of the heap management but it always occurs in HEAP_CreateFreeBlock in line 415. Generating of a full "-debugmsg +heap" log is nearly impossible because it takes too long to start the game and start playing (after > 200 min. it still wasn't finished with initializing). ,- | err:ntdll:RtlpWaitForCriticalSection section 0x4046001c "?" wait timed out in thread 0010, blocked by 000c, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x7d63d8 "?" wait timed out in thread 0009, blocked by 000c, retrying (60 sec) | Unhandled exception: page fault on write access to 0x53acae7c in 32-bit code (0x400826d1). | In 32-bit mode. | 0x400826d1 (HEAP_CreateFreeBlock+0x11 [heap.c:415] in libntdll.dll.so): movl $0x45455246,0x4(%esi) | 419 pEnd = (char *)ptr + size; | Wine-dbg>bt | Backtrace: | =>0 0x400826d1 (HEAP_CreateFreeBlock+0x11(subheap=0x539a, ptr=0x53acae78, size=0x3f6ebd18) [heap.c:415] in libntdll.dll.so) (ebp=4c031d80) | 1 0x400829be (HEAP_ShrinkBlock+0x4e(subheap=0x539a, pArena=0x53aaae70, size=0x2) [heap.c:521] in libntdll.dll.so) (ebp=4c031d9c) | 2 0x400838c7 (RtlAllocateHeap+0xa7(heap=0x4046, flags=0xa, size=0x2) [heap.c:1159] in libntdll.dll.so) (ebp=4c031dc8) | 3 0x40aac68e (IDirect3DDevice8Impl_CreateImageSurface+0x9e(iface=0x4052fca8, Width=0x100, Height=0x80, Format=0x31545844, ppSurface=0x53a81dd0) [device.c:1987] in d3d8.dll.so) (ebp=4c031dec) | 4 0x40aaba39 (IDirect3DDevice8Impl_CreateTexture+0x119(iface=0x4052fca8, Width=0x100, Height=0x80, Levels=0x5, Usage=0x0, Format=0x31545844, Pool=0x1, ppTexture=0x52c58170) [device.c:539] in d3d8.dll.so) (ebp=4c031e20) | 5 0x006b9766 (Morrowind.exe..text+0x2b8766 in Morrowind.exe) (ebp=535bb5c0) | 6 0x0001 (ebp=00748e84) | 7 0x006cf2a0 (Morrowind.exe..text+0x2ce2a0 in Morrowind.exe) (ebp=006ce690) | 8 0x0478 (ebp=e8f18b56) | *** Invalid address 0xe8f18b56 (MSVCP60.DLL..reloc+0x70dfab56) `- ,- | err:ntdll:RtlpWaitForCriticalSection section 0x4046001c "?" wait timed out in thread 0010, blocked by 000c, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x4046001c "?" wait timed out in thread 0009, blocked by 000c, retrying (60 sec) | Unhandled exception: page fault on write access to 0x537c0064 in 32-bit code (0x400826d1). | In 32-bit mode. | 0x400826d1 (HEAP_CreateFreeBlock+0x11 [heap.c:415] in libntdll.dll.so): movl $0x45455246,0x4(%esi) | 419 pEnd = (char *)ptr + size; | Wine-dbg>bt | Backtrace: | =>0 0x400826d1 (HEAP_CreateFreeBlock+0x11(subheap=0x536b, ptr=0x537c0060, size=0x3f6f4c38) [heap.c:415] in libntdll.dll.so) (ebp=4c032518) | 1 0x400829be (HEAP_ShrinkBlock+0x4e(subheap=0x536b, pArena=0x537bff90, size=0xc8) [heap.c:521] in libntdll.dll.so) (ebp=4c032534) | 2 0x400838c7 (RtlAllocateHeap+0xa7(heap=0x4046, flags=0x2, size=0xc8) [heap.c:1159] in libntdll.dll.so) (ebp=4c032560) | 3 0x412befe7 ([EMAIL PROTECTED]@Z+0x27 in msvcrt.dll.so) (ebp=4c032580) | 4 0x00412b03 (Morrowind.exe..text+0x11b03 in Morrowind.exe) (ebp=4c03261c) | 5 0x00412dcb (Morrowind.exe..text+0x11dcb in Morrowind.exe) (ebp=4af5fce8) | 6 0x5376b8e0 (_end+0x832c1f0) (ebp=4cbe2238) | 7 0x444e414c (_end+0x2ebf630) (ebp=007428b0) | 8 0x004c8620 (Morrowind.exe..text+0xc7620 in Morrowind.exe) (ebp=004c7b90) | 9 0x0018 (ebp=e8f18b56) | *** Invalid address 0xe8f18b56 (MSVCP60.DLL..reloc+0x70dfab56) `- Michael
Re: [DXT3] menu in Tribunal now vanishes (regression?)
"Ann and Jason Edmeades" <[EMAIL PROTECTED]> 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
Re: [DXT3] menu in Tribunal now vanishes (regression?)
Lionel Ulmer <[EMAIL PROTECTED]> writes: >> When IDirect3DImpl_CheckDeviceFormat reports that D3DFMT_DXT3 is >> supported then white blocks appear instead of the menuitems and >> glCompressedTexImage2D returns the error code 0x502 (GL_INVALID_OPERATION). > > Can you paste here the output of 'glxinfo' ? If GLX does not support S3TC > texture compression, it should not return that 'D3DFMT_DXT3' is supported > (at least not before adding software decoding code :-) ). Here is the output of glxinfo and also of xdpyinfo. Michael name of display::0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4020 XFree86 version: 4.2.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x283, revert to PointerRoot number of extensions:28 BIG-REQUESTS DOUBLE-BUFFER DPMS Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD NV-CONTROL NV-GLX NVIDIA-GLX RENDER SECURITY SHAPE SYNC TOG-CUP XC-APPGROUP XC-MISC XFree86-Bigfont XFree86-DGA XFree86-Misc XFree86-VidModeExtension XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1280x1024 pixels (313x232 millimeters) resolution:104x112 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x7c depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xd84031 KeyPressMask EnterWindowMask LeaveWindowMask KeymapStateMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals:16 default visual id: 0x21 visual: visual id:0x21 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x22 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x23 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x24 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x25 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x26 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x27 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x28 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x29 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x2a class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specific
Re: [DXT3] menu in Tribunal now vanishes (regression?)
[EMAIL PROTECTED] (Michael Günnewig) writes: > Hallo, > > with the following 2 patches the menu in "The Elder Scrolls III: > Tribunal Morrowind Expansion Pack" version 1.4.1313 german only shows > white blocks instead of the menuitems as before. Have forgotten to mention the patches, so here they are: 2003-09-02 * dlls/d3d8/d3d8_main.c, dlls/d3d8/directx.c: Jason Edmeades <[EMAIL PROTECTED]> Use a dummy GL context if one is not available when GetDeviceCaps is called. Remove the compiler warnings introduced in the last DXTn patch. 2003-08-15 * dlls/d3d8/d3d8_main.c, dlls/d3d8/d3d8_private.h, dlls/d3d8/device.c, dlls/d3d8/directx.c, dlls/d3d8/utils.c: Jason Edmeades <[EMAIL PROTECTED]> DXT1/3/5 support was broken, but unnoticeable since we also indicated it wasn't supported. 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. Michael
[DXT3] menu in Tribunal now vanishes (regression?)
Hallo, with the following 2 patches the menu in "The Elder Scrolls III: Tribunal Morrowind Expansion Pack" version 1.4.1313 german only shows white blocks instead of the menuitems as before. When IDirect3DImpl_CheckDeviceFormat reports that D3DFMT_DXT3 isn't supported the menuitems will draw correct. When IDirect3DImpl_CheckDeviceFormat reports that D3DFMT_DXT3 is supported then white blocks appear instead of the menuitems and glCompressedTexImage2D returns the error code 0x502 (GL_INVALID_OPERATION). Using NVIDIA drivers 1.0-4349 and updating to 1.0-4496 doesn't solve the problem. Is it the OpenGL implementation which is buggy or the way how wine uses it? I have attached a log of "wine -debugmsg +loaddll,+d3d_surface Morrowind.exe". The binary is a no-cd version, but the original one behaves the same. Some parts from my config: ,- | ... | | [Version] | "Windows" = "win98" | ;"DOS" = "6.22" | | [x11drv] | "AllocSystemColors" = "100" | "PrivateColorMap" = "N" | "UseDGA" = "N" | "UseXShm" = "Y" | "UseXVidMode" = "Y" | "UseTakeFocus" = "Y" | "DXGrab" = "N" | "DesktopDoubleBuffered" = "Y" | "TextCP" = "0" | "Synchronous" = "N" | | [WinMM] | "Drivers" = "wineoss.drv" | ; ... | | ;; Debug, dsound, network are empty | | [DllOverrides] | "*" = "builtin, native" | "msvideo" = "native, builtin" | "msvfw32" = "native, builtin" | "ole32"= "native, builtin" | "oleaut32" = "native, builtin" | "quartz" = "native, builtin" | "rpcrt4" = "native, builtin" | | ... `- Will send more details if someone wish. Michael Morrowind-nv_gl.log.bz2 Description: Morrowind-nv_gl.log.bz2
