July 2004 - Wine-Devel - list.winehq.org

Re: [D3D] Added native and emulated S3TC support

by Christian Costa

Lionel Ulmer wrote: >I have just a few comments on the patch (yeah, it would not have been fun if >I had commented on wine-d3d first :-) ). > :-) > >But anyway, great work ! > > > >>+static BOOL DDRAW_bind_to_s3tc( void ) >>+{ >>+ const char *s3tcname = SONAME_LIBS3TC; >>+ >>+ s3tc_handle = wine_dlopen(s3tcname, RTLD_NOW, NULL, 0); >>+ if (!s3tc_handle) { >>+ printf("Wine cannot find the S3TC software decompression library (%s).\n",s3tcname); >> >> > >Why did you use 'printf' here instead of WARN or ERR ? > >Moreover, with this, we will print an error at DirectX loading when the >users do not have this library installed ... even if the game does never >request any compressed mode textures. > > Ooop... Forgot to clean-up these printf. >Would it not be better to somehow print the error message when the >application wants to create a DXTN texture (ie somehow remember that we do >not support this feature and keep the error message for later). > > Good idea. I will see... > > >>+ return FALSE; >>+ } >>+ >>+#define API_FUNCTION(f) \ >>+ if((f = wine_dlsym(s3tc_handle, #f, NULL, 0)) == NULL) \ >>+ { \ >>+ printf("Can't find symbol %s\n", #f); \ >> >> > >Same printf comment here (but this one can be kept here :-) ). > Same as above. > > > >>+ goto sym_not_found; \ >>+ } >>+ API_FUNCTION(fetch_2d_texel_rgba_dxt1); >>+ API_FUNCTION(fetch_2d_texel_rgba_dxt3); >>+ API_FUNCTION(fetch_2d_texel_rgba_dxt5); >>+#undef API_FUNCTION >>+ >>+ return TRUE; >>+ >>+sym_not_found: >>+ WARN("Wine cannot find functions that are necessary for S3TC decompression\n"); >>+ wine_dlclose(s3tc_handle, NULL, 0); >>+ s3tc_handle = NULL; >>+ return FALSE; >>+} >>+ >> >> > >(...) > > >> >>+ if (src_pf->dwFlags & DDPF_FOURCC) { >>+ GLenum retVal; >>+ int size = surf_ptr->surface_desc.u1.dwLinearSize; >>+ int width = surf_ptr->surface_desc.dwWidth; >>+ int height = surf_ptr->surface_desc.dwHeight; >>+ LPVOID buffer = surf_ptr->surface_desc.lpSurface; >>+ >>+ switch (src_pf->dwFourCC) { >>+ case MAKE_FOURCC('D','X','T','1'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT; break; >>+ case MAKE_FOURCC('D','X','T','3'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT3_EXT; break; >>+ case MAKE_FOURCC('D','X','T','5'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT; break; >>+ default: >>+ FIXME("FourCC Not supported\n"); >>+ return DD_OK; >>+ break; >>+ } >>+ GL_extensions.glCompressedTexImage2D(GL_TEXTURE_2D, current_level, retVal, width, height, 0, size, buffer); >> >> > >How are we sure that this code will never be called with the >'glCompressedTexImage2D' unset ? I.e. when we are in emulation mode, what >happens here ? > Humm... You're right. If the app does not check if the device supports theses texture formats, this may happen. > >Is this because when we are in emulation mode, we do not advertise support >for DTXN textures, this means that the application can create such textures, >but will be automagically converted to RGB ones at Loading ? > If the device does not support these textures formats you can still create such textures. You need to blit from a S3TC texture to a RBG one to do the decompression and use the latter with the device. > >Anyway, I would still prefer a test here to prevent crashes for application >which do not behave well :-) > OK. > >(...) > > >>+ if (current_surface->surface_desc.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) { >>+ GLint retVal; >>+ int size = current_surface->surface_desc.u1.dwLinearSize; >>+ int width_ = current_surface->surface_desc.dwWidth; >>+ int height_ = current_surface->surface_desc.dwHeight; >>+ LPVOID buffer = current_surface->surface_desc.lpSurface; >>+ >>+ switch (current_surface->surface_desc.u4.ddpfPixelFormat.dwFourCC) { >>+ case MAKE_FOURCC('D','X','T','1'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT; break; >>+ case MAKE_FOURCC('D','X','T','3'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT3_EXT; break; >>+ case MAKE_FOURCC('D','X','T','5'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT; break; >>+ default: >>+ FIXME("Not supported\n"); >>+ return DD_OK; >>+ break; >>+ } >>+ /* GL_extensions.glCompressedTexSubImage2D(GL_TEXTURE_2D, current_level, xoffset, yoffset, width, height, retVal, (unsigned char*)temp_buffer); */ >>+ GL_extensions.glCompressedTexImage2D(GL_TEXTURE_2D, current_level, retVal, width_, height_, 0, size, buffer); >> >> > >Same here. > > > >>+ } >>+ >>+ if (strstr(glExtensions, "GL_EXT_texture_compression_s3tc")) { >>+ TRACE(" - S3TC compression supported\n"); >>+ GL_extensions.s3tc_compressed_texture = TRUE; >>+ GL_extensions.glCompressedTexImage2D = pglXGetProcAddressARB("glCompressedTexImage2D"); >>+ GL_extensions.glCompressedTexSubImage2D = pglXGetProcAddressARB("glCompressedTexSubImage2D"); >> } >> >> > >If I were pedantic, you should test for 'GL_ARB_texture_compression' to be >able to get the 'glCompressedTexImage2DARB' and >'glCompressedTexSubImage2DARB' functions (which may be better than using the >non-ARB versions which are, AFAIK, the ones in GL 1.4). > >And then to get 'GL_EXT_texture_compression_s3tc' to set >'GL_extensions.s3tc_compressed_texture' to TRUE. > >But as 'GL_EXT_texture_compression_s3tc' depends on >'GL_ARB_texture_compression', I will let you do this shortcut :-) > :-) > > > >>- /* We do not support for now compressed texture formats... */ >>- if (ddsd.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) >>+ /* We support for now only DXT1, DXT3 & DXT5 compressed texture formats... */ >>+ if ((ddsd.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) && >>+ (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','1')) && >>+ (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','3')) && >>+ (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','5')) ) >> { >> return DDERR_INVALIDPIXELFORMAT; >> } >> >> > >What to do here when neither hardware nor emulated support is present ? >Maybe we should print an error (cf previous comment) and return >INVALIDPIXELFORMAT, no ? > Yes, we must check if there is any S3TC support otherwise we must return an error. > > Lionel (who goes testing NOFL :-) ) > > > Thanks for the comments. Bye, Christian

July 29, 2004

Bug in menu.c

by Dan Timis

Hi, The MS documentation on the structure MENUITEMINFO says that the field fMask indicates what fields to retrieve or set. Here is what it says about the value MIIM_TYPE: > Retrieves or sets the fType and dwTypeData members. Windows 98/Me, > Windows 2000/XP: MIIM_TYPE is replaced by MIIM_BITMAP, MIIM_FTYPE, > and MIIM_STRING. So if one wants to specify a text menu item in XP, one would use MIIM_STRING, not MIIM_TYPE. fType would also need to be MFT_STRING. In menu.c in GetMenuItemInfo_common(): /* copy the text string */ if ((lpmii->fMask & (MIIM_TYPE|MIIM_STRING)) && (MENU_ITEM_TYPE(menu->fType) == MF_STRING) && menu->text) { and so on... This works fine. It retrieves the text if either MIIM_TYPE or MIIM_STRING are set. But, in GetMenuItemInfo_common(): if (lpmii->fMask & MIIM_TYPE) { /* Get rid of old string. */ if (IS_STRING_ITEM(menu->fType) && menu->text) { HeapFree(GetProcessHeap(), 0, menu->text); menu->text = NULL; } /* make only MENU_ITEM_TYPE bits in menu->fType equal lpmii->fType */ menu->fType &= ~MENU_ITEM_TYPE(menu->fType); menu->fType |= MENU_ITEM_TYPE(lpmii->fType); menu->text = lpmii->dwTypeData; and so on... This sets the text only if MIIM_TYPE is set. I changed the first line to: if (lpmii->fMask & (MIIM_TYPE|MIIM_STRING)) { and menus that were drawing before as a long thin vertical line, started to show correctly. I'm not sure if this is the right way to fix this, but it works for me. I am using a wine version from 2004-04-08. BTW, I reported earlier a crash in menu.c. I did not hear anything back. Should I log this into Bugzilla? Thanks, Dan Timis Muse Research, Inc.

July 29, 2004

Re: Test drive error

by sergio ojalvo

On Thu, 2004-07-29 at 18:29, Dimitrie O. Paun wrote: > On Thu, Jul 29, 2004 at 01:50:20PM +0300, sergio ojalvo wrote: > > Hi > > I'm working on Debian Linux. I just install the wine packages and > > download sources for trying the test driver. > > Running Winemaker to winemine test project I note: that configure script > > was not created and Makefile is created instead of Makefile.in. (like > > wrote in the web page) > > I think is a new feature... I'm wrong? > > It is a new feature, it's true. > > > Anyway, I try to run make after that and that is the output: > > > > winebuild -o winemine.exe.dbg.c --debug -C. dialog.c main.c > > winegcc -c -mno-cygwin -I. -o winemine.exe.dbg.o winemine.exe.dbg.c > > winegcc -c -mno-cygwin -I. -o dialog.o dialog.c > > winegcc -c -mno-cygwin -I. -o main.o main.c > > wrc -I. -foEn.res En.rc > > En.rc:23:22: Error: syntax error > > That means there's something around line 23 in the En.rc file that > wrc doesn't understand. Can you send us a copy of the file? I get the tar files with the sources from sourceforge and didn't change this file. Anyway attached find the En.rc file. > > > After that I try with another 2 projects (win32 code) and I receive a > > lot of compilation errors like: > > > > In file included from /usr/include/c++/3.3/iosfwd:46, > > from /usr/include/c++/3.3/ios:44, > > from /usr/include/c++/3.3/ostream:45, > > from /usr/include/c++/3.3/iostream:45, > > from midi2nokia.cpp:4: > > /usr/include/c++/3.3/i486-linux/bits/c++locale.h:53: error: `uselocale' > > was not declared in this scope > > Using the std C++ lib is still a problem if you need to use > msvcrt. Try to use wineg++ (instead of winegcc) *without* > the -mno-cygwin flag. Can you explain exactly what to do? I'm newbie on this project. I just do: $ winemaker --mfc -Imydir . $ make Thanks in advance, -- ____________________________ ________ _______________________________ | Sergio Ojalvo \ \ / | | Senior System Analyst \ \/ To bring IN-OVATION turn to | | mailto:sergio(a)ximpo.com /\ \ your open source of solutions | | Phone: +972-545-558586 / \ \ | | Fax: +972-151-545-558586 -------- http://www.ximpo.com/ | |__________________________ Ximpo Group _____________________________|

July 29, 2004

Re: RPCRT4_NdrClientCall2 stub (fixme)?

by Robert Shearman

Jeroen Janssen wrote: > Hello, > > I have 'hit' upon a RPCRT4_NdrClientCall2 stub/fixme call. > > It seems some discussion on this has been happening in a the past few > months? > Can someone maybe explain the current status on this? > (probably Rob or Mike, since they seem to be the Wine COM "gurus"?) > Below is is a short snip of trace logging I get: Wow. I think that's the first time I've ever been called a guru :) Yes, I have an implementation of NdrClientCall2 in my local tree, but I'm a bit busy with other COM things at the moment. I'll send an updated patch to the list either tonight or sometime over the weekend. Rob

July 29, 2004

RPCRT4_NdrClientCall2 stub (fixme)?

by Jeroen Janssen

Hello, I have 'hit' upon a RPCRT4_NdrClientCall2 stub/fixme call. It seems some discussion on this has been happening in a the past few months? Can someone maybe explain the current status on this? (probably Rob or Mike, since they seem to be the Wine COM "gurus"?) Below is is a short snip of trace logging I get: trace:ole:COMPOBJ_DLLList_Add trace:ole:CStdPSFactory_QueryInterface (0x660cea80)->QueryInterface({d5f569d0-593b-101a-b569-08002b2dbf7a},0x4067faa4) trace:ole:CStdPSFactory_CreateProxy (0x660cea80)->CreateProxy((nil),{11ef83d1-553a-11d3-bb12-0004ac9658d6},0x4067faa0,0x4067fbfc) trace:ole:FindProxyInfo found: ProxyInfo 0x660cbc48 Index 65 trace:ole:StdProxy_Construct ((nil),0x660cd048,0x660cea80,0x4067faa0,0x4067fbfc) ICoKMFactoryManager trace:ole:StdProxy_Construct stubless=0x660c5230 trace:ole:StdProxy_Construct iid={11ef83d1-553a-11d3-bb12-0004ac9658d6} trace:ole:StdProxy_Construct vtbl=0x660cd050 trace:ole:StdProxy_Construct stubless thunks: count=6 trace:ole:StdProxy_Construct method 3: stacksize=12 trace:ole:StdProxy_Construct method 4: stacksize=16 trace:ole:StdProxy_Construct method 5: stacksize=4 trace:ole:CStdPSFactory_AddRef (0x660cea80)->AddRef() trace:ole:CStdPSFactory_Release (0x660cea80)->Release() trace:ole:StdProxy_Connect (0x4034f1f0)->Connect(0x4034f288) trace:ole:StdProxy_Release (0x4034f1f0)->Release() trace:ole:ObjectStubless (0x4034f1f4)->(3)([12 bytes]) ret=4067fc94 fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x660c7c08,pFormat = ^0x660c7d30,...): stub trace:ole:IUnknown_Release_Proxy (0x4034f1f0)->Release() ICoKMFactoryManager wine: Unhandled exception (thread 0014), starting debugger... Best regards, Jeroen Janssen

July 29, 2004

Re: Wine and locales

by Shachar Shemesh

Filip Navara wrote: > Dmitry Timoshkov wrote: > >> We should not complicate things, especially since it's not clear at all >> what APIs are affected by system/user locale differences. >> > System locale affects System locale affects all *A functions. I.e. - it affects all ANSI functions. Aside from this affect: > > - String comparsions > (IntlStrEqWorker[AW], lstrcmp[AW], lstrcmpi[AW]) > Uses system locale after trying thread locale (which is > derived from user locale on thread creation). Uses User locale. Not system locale. It determines the collation (sort order). Obviously, it affects the A functions (lstrcmpA, etc.), but no more nor less than it does CreateWindowA, FormatHardDiskA, or AnyOtherFunctionA. > > - Resource loading > (FindResource & friends) > Uses system locale after trying Default UI Language (see > GetSystemDefaultUILanguage and GetUserDefaultUILanguage > or NtQueryDefaultLanguage) and user locale. Actually, here I don't think system locale affects at all. I'll be able to tell with more certainty later, though. > > - Input locale identifier > The thread default input language for system applications > (that are started before user logins) is derived from the > system locale setting. This probably isn't relevant for > Wine. > > And if you ask, no, I will not write a testcase, because it's > sometimes hard for me to even understand the problems caused > by different locales. > > Regards, > Filip Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

July 29, 2004

Re: Fix crash in dsound test

by Ferenc Wagner

Paul Millar <paulm(a)astro.gla.ac.uk> writes: > The build failed. It looks like there's a bug in CVS. Both > CLSID_DirectSoundPrivate and DSPROPSETID_DirectSoundDevice defined multiple > times (the wine-version of mingw libraries and in the source). Yes, there was a short discussion about this on 23-24 July on wine-devel. It reached no conclusion, though, and I didn't try the various MinGW libraries recommended there. The abundance of MinGW packages always confused me, and at the moment I don't even know where I got mine from. But it can't compile the dsound tests, that's for sure. Comments welcome. -- Feri.

July 29, 2004

Re: Wine and locales

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)shemesh.biz> writes: > Actually, that's a bug in Wine. User locale should not affect that. It > should affect functions such as GetCurencyFormat, GetDateFormat > etc. I'm now working on a fix to that problem. That's not true, user locale definitely affects resource loading. It should also be affected by UI language, which isn't implemented now, so that's probably the difference you see. -- Alexandre Julliard julliard(a)winehq.org

July 29, 2004

Re: Test drive error

by Vincent Béron

Le jeu 29/07/2004 à 11:29, Dimitrie O. Paun a écrit : [snip] > > Anyway, I try to run make after that and that is the output: > > > > winebuild -o winemine.exe.dbg.c --debug -C. dialog.c main.c > > winegcc -c -mno-cygwin -I. -o winemine.exe.dbg.o winemine.exe.dbg.c > > winegcc -c -mno-cygwin -I. -o dialog.o dialog.c > > winegcc -c -mno-cygwin -I. -o main.o main.c > > wrc -I. -foEn.res En.rc > > En.rc:23:22: Error: syntax error > > That means there's something around line 23 in the En.rc file that > wrc doesn't understand. Can you send us a copy of the file? The instructions need to be changed, this error comes out every once in a while. Winemine's En.rc is meant to be included by another .rc file (rsrc.rc), which itself #include <windows.h>. If En.rc is compiled by itself, you get some undefined references (probably LANG_ENGLISH in this specific case). Vincent

July 29, 2004

Re: Wine and locales

by Filip Navara

Dmitry Timoshkov wrote: >We should not complicate things, especially since it's not clear at all >what APIs are affected by system/user locale differences. > System locale affects - String comparsions (IntlStrEqWorker[AW], lstrcmp[AW], lstrcmpi[AW]) Uses system locale after trying thread locale (which is derived from user locale on thread creation). - Resource loading (FindResource & friends) Uses system locale after trying Default UI Language (see GetSystemDefaultUILanguage and GetUserDefaultUILanguage or NtQueryDefaultLanguage) and user locale. - Input locale identifier The thread default input language for system applications (that are started before user logins) is derived from the system locale setting. This probably isn't relevant for Wine. And if you ask, no, I will not write a testcase, because it's sometimes hard for me to even understand the problems caused by different locales. Regards, Filip

July 29, 2004