December 2008 - Wine-Devel - list.winehq.org

Re: wined3d: Do not treat oversized textures as failure

by Vincent Pelletier

Le Sunday 28 December 2008 20:20:43 Vincent Pelletier, vous avez écrit : > I discussed with Thunderbird on IRC right after sending last reply. I > noticed that I was not using latest intel driver, so I'm building them atm > to give it a try. (Debian sid is quite outdated these days, because of work > on next stable, I even have to rebuild the kernel) With 2.5.1 version: GL_MAX_TEXTURE_SIZE = 2048 I reverted the patch on my local tree, and the game works fine. Maybe wine should warn for broken drivers when GL_MAX_TEXTURE_SIZE is below 1024 or something... So after all, it seems to be a non-bug. My bad. -- Vincent Pelletier

Dec. 28, 2008

RE: xinput: Add stub XInputEnable

by ricardo filipe

yup, the patches look good on a quick glance. ---------------------------------------- > Date: Mon, 29 Dec 2008 02:30:26 +0700 > From: andrewfenn(a)gmail.com > To: hverbeet(a)gmail.com; wine-devel(a)kievinfo.com; ricardo_barbano(a)hotmail.com > Subject: Re: xinput: Add stub XInputEnable > CC: wine-devel(a)winehq.org > > Sorry guys, that was a really bad patch I submitted much better ones > to wine-patches already. > > [1/2] xinput: Added prototypes to header file > [2/2] xinput: Added stub for XInputEnable >> 2008/12/28 ricardo filipe : >> it's almost that. but it needs some changes. >> first you put the prototypes after the defines and typedefs, they may be needed for the prototypes. >> second you don't put variable names in the protypes, it should be something like: >> DWORD WINAPI XInputGetState(DWORD, XINPUT_STATE*); > No, variable names are optional, but not forbidden. Usually it makesthings more readable to include them. > It's a bit awkward to write "XINPUT_STATE* pState" though, since the *is part of the declarator in C, not part of the base type. i just meant you usually don't put the variable names, as we can see in most other headers in wine. but sure you are right ofc :) _________________________________________________________________ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/

Dec. 28, 2008

Re: xinput: Add stub XInputEnable

by Andrew Fenn

Sorry guys, that was a really bad patch I submitted much better ones to wine-patches already. [1/2] xinput: Added prototypes to header file [2/2] xinput: Added stub for XInputEnable

Dec. 28, 2008

Re: xinput: Add stub XInputEnable

by Henri Verbeet

2008/12/28 Andrew Fenn <andrewfenn(a)gmail.com>: > On Sun, Dec 28, 2008 at 9:39 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> Also, don't forget to add the prototype to the header, I noticed they're missing for all the other xinput functions as well. > > I think I have added the prototypes correctly to the header file. > Could you have a quick look at my patch and tell me if I am doing that > right? > Other than the missing semicolon Vitaliy already mentioned, and the types being defined after their first use, I think it's useful to specify C linkage for C++ applications that might include the header. 2008/12/28 ricardo filipe <ricardo_barbano(a)hotmail.com>: > > it's almost that. but it needs some changes. > first you put the prototypes after the defines and typedefs, they may be needed for the prototypes. > second you don't put variable names in the protypes, it should be something like: > > DWORD WINAPI XInputGetState(DWORD, XINPUT_STATE*); > No, variable names are optional, but not forbidden. Usually it makes things more readable to include them. It's a bit awkward to write "XINPUT_STATE* pState" though, since the * is part of the declarator in C, not part of the base type.

Dec. 28, 2008

Re: wined3d: Do not treat oversized textures as failure

by Vincent Pelletier

Le Sunday 28 December 2008 18:11:15, vous avez écrit : > Wow, that is small. Even my pretty old radeon 9000 supports 2048x2048 > textures... > > I recommend to check the max texture size on Windows(does the game work on > this card on Windows?). I'd say there's some driver problem here, 512x512 > sounds way too small for any semi-recent card. I discussed with Thunderbird on IRC right after sending last reply. I noticed that I was not using latest intel driver, so I'm building them atm to give it a try. (Debian sid is quite outdated these days, because of work on next stable, I even have to rebuild the kernel) As for windows, I don't know. I'll certainly try if the rebuild does nothing. -- Vincent Pelletier

Dec. 28, 2008

Re: wined3d: Do not treat oversized textures as failure

by Henri Verbeet

2008/12/28 Stefan Dösinger <stefan(a)codeweavers.com>: >> It tries to create a 1024x1024 texture, and my card (Intel 945GM) is >> limited >> to 512x512: >> >> glxinfo -l | grep GL_MAX_TEXTURE_SIZE >> GL_MAX_TEXTURE_SIZE = 512 > Wow, that is small. Even my pretty old radeon 9000 supports 2048x2048 > textures... > > I recommend to check the max texture size on Windows(does the game work on > this card on Windows?). I'd say there's some driver problem here, 512x512 > sounds way too small for any semi-recent card. > My i915 can certainly do more than 512x512. > That said, we should still fix the memory leak if CreateTexture fails... > Yes, but it's a bit more structural than just CreateTexture(). Most of the create methods in device are flawed in this way.

Dec. 28, 2008

Re: xinput: Add stub XInputEnable

by Vitaliy Margolen

Andrew Fenn wrote: > I think I have added the prototypes correctly to the header file. > Could you have a quick look at my patch and tell me if I am doing that > right? > > + XINPUT_CAPABILITIES* pCapabilities) Missing semicolon. Vitaliy.

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Roderick Colenbrander

> On Sunday 28 December 2008 07:43:57 am Roderick Colenbrander wrote: > > Native dxdiag is checking the name of the display driver which in our > case > > winex11.drv and I guess this is just the identifier of Winex11.drv. > Inside > > winex11.drv we don't really have the knowledge about the 3d hardware we > are > > emulating. In the end we might need to duplicate some card detection > code > > inside winex11.drv and show a real driver name like the Nvidia or ATI > ones. > > It would be a lot of work and only be worth if apps really need it. > > Are there any X functions that winex11.drv can use to get the strings used > for > a particular screen? Eg. in xorg.conf, I have: > > Section "Device" > ... > Identifier "Card0" > Driver "nvidia" > VendorName "nVidia Corporation" > BoardName "NV80 [GeForce 8600 GT]" > EndSection > > Section "Screen" > Identifier "Screen0" > Device "Card0" > ... > EndSection > > I can't imagine that being inaccessible by X apps.. and I believe I've > seen > some apps report this info. It's something gdi32/user32 can then get for a > particular screen/adapter by calling into winex11.drv (if not also > something > wined3d can use), instead of reporting "X Windows" for the card name. > Those strings were just generated by the tool which created your xorg.conf. These fields are only internal to X. Some of the info can be obtained from X. For instance I requested support for pci id reading in the nvidia drivers and that was added recently. I plan to work on that early next year. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 28, 2008

RE: xinput: Add stub XInputEnable

by ricardo filipe

it's almost that. but it needs some changes. first you put the prototypes after the defines and typedefs, they may be needed for the prototypes. second you don't put variable names in the protypes, it should be something like: DWORD WINAPI XInputGetState(DWORD, XINPUT_STATE*); see the xinput.h file from the windows SDK for more details. :) btw you could make a patch to include all the prototypes and defines of the header too. regards. ---------------------------------------- > Date: Sun, 28 Dec 2008 23:41:57 +0700 > From: andrewfenn(a)gmail.com > To: wine-devel(a)winehq.org > Subject: Re: xinput: Add stub XInputEnable > > On Sun, Dec 28, 2008 at 9:39 PM, Henri Verbeet wrote: >> Also, don't forget to add the prototype to the header, I noticed they're missing for all the other xinput functions as well. > > I think I have added the prototypes correctly to the header file. > Could you have a quick look at my patch and tell me if I am doing that > right? _________________________________________________________________ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/photos.aspx

Dec. 28, 2008

RE: Implementing dxdiag as student project?

by Stefan Dösinger

> I can't imagine that being inaccessible by X apps.. and I believe I've > seen > some apps report this info. It's something gdi32/user32 can then get > for a > particular screen/adapter by calling into winex11.drv (if not also > something > wined3d can use), instead of reporting "X Windows" for the card name. I'm not sure, but I wouldn't expect these settings to be readable via some X11 API. There are X servers without an X config like that, e.g. the MacOS X server, or Windows X servers

Dec. 28, 2008

RE: wined3d: Do not treat oversized textures as failure

by Stefan Dösinger

> It tries to create a 1024x1024 texture, and my card (Intel 945GM) is > limited > to 512x512: > > glxinfo -l | grep GL_MAX_TEXTURE_SIZE > GL_MAX_TEXTURE_SIZE = 512 Wow, that is small. Even my pretty old radeon 9000 supports 2048x2048 textures... I recommend to check the max texture size on Windows(does the game work on this card on Windows?). I'd say there's some driver problem here, 512x512 sounds way too small for any semi-recent card. That said, we should still fix the memory leak if CreateTexture fails...

Dec. 28, 2008

Re: xinput: Add stub XInputEnable

by Andrew Fenn

On Sun, Dec 28, 2008 at 9:39 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > Also, don't forget to add the prototype to the header, I noticed they're missing for all the other xinput functions as well. I think I have added the prototypes correctly to the header file. Could you have a quick look at my patch and tell me if I am doing that right?

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Chris Robinson

On Sunday 28 December 2008 07:43:57 am Roderick Colenbrander wrote: > Native dxdiag is checking the name of the display driver which in our case > winex11.drv and I guess this is just the identifier of Winex11.drv. Inside > winex11.drv we don't really have the knowledge about the 3d hardware we are > emulating. In the end we might need to duplicate some card detection code > inside winex11.drv and show a real driver name like the Nvidia or ATI ones. > It would be a lot of work and only be worth if apps really need it. Are there any X functions that winex11.drv can use to get the strings used for a particular screen? Eg. in xorg.conf, I have: Section "Device" ... Identifier "Card0" Driver "nvidia" VendorName "nVidia Corporation" BoardName "NV80 [GeForce 8600 GT]" EndSection Section "Screen" Identifier "Screen0" Device "Card0" ... EndSection I can't imagine that being inaccessible by X apps.. and I believe I've seen some apps report this info. It's something gdi32/user32 can then get for a particular screen/adapter by calling into winex11.drv (if not also something wined3d can use), instead of reporting "X Windows" for the card name.

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Roderick Colenbrander

> On Sun, Dec 28, 2008 at 8:43 AM, Roderick Colenbrander < > thunderbird2k(a)gmx.net> wrote: > > > Native dxdiag is checking the name of the display driver which in our > case > > winex11.drv and I guess this is just the identifier of Winex11.drv. > Inside > > winex11.drv we don't really have the knowledge about the 3d hardware we > are > > emulating. In the end we might need to duplicate some card detection > code > > inside winex11.drv and show a real driver name like the Nvidia or ATI > ones. > > It would be a lot of work and only be worth if apps really need it. > > > > I'm not sure if this is exactly the same string you're looking at, but > Fallout 3 currently requires a hack for the display driver information or > it > will just crash when you try to start a game ( > http://bugs.winehq.org/show_bug.cgi?id=15839) > > Erich Hoover > ehoover(a)mines.edu This is part of the info which we aren't reporting properly right now. Actually the best thing is to report a fake card and drivers as some games use this info to work around driver bus. Other class of programs are too stupid and need 100% correct info. Fallout3 is one of those cases. The registry changes are more or less fine. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 28, 2008

RE: Implementing dxdiag as student project?

by Stefan Dösinger

I think we should stay as close to the way the windows tools work and avoid inventing too much wine-specific things. This is how I understand the windows tools: * dxdiag.exe: Prints DLL information, has very simple tests for ddraw, d3d, dsound, dmusic, dplay. The tests just show that a device can be created and a cube can be rendered. This could detect if the opengl libs are missing, but it won't be able to tell direct rendering from indirect rendering. (really dxdiag can't say so via the win32 API). *) dxcapsviewer.exe: This app lists all the capability flags advertised for ddraw, d3d8, dsound, etc. It is part of the dx sdk, but I don't see a problem with implementing it. Sooner or later we'll clone other tools from the dx sdk too, like vsa.exe, psa.exe and fxc.exe(shader assemblers and compiler) Another feature idea is to enable ddraw, d3d8 and d3d9 to import a capability flag dump from dxcapsviewer to advertise exactly the same flags as on Windows. This can help to debug capability flag problems. *) pixwin.exe is interesting too. It allows to record something similar to a +d3d9 trace on Windows, and save it for playback. The native version currently doesn't work on wine, but I think it is fixable. A similar tool could be useful to (1) see if a log recorded on windows produces the same output on Wine, and (2) to see if a windows app performs the same calls on Wine as it does on Windows(to detect caps problems for example)

Dec. 28, 2008

Re: wined3d: Do not treat oversized textures as failure

by Vincent Pelletier

Le Sunday 28 December 2008 16:53:44, vous avez écrit : > This patch is wrong; You can't use oversized surfaces for 3D texturing > because the driver doesn't support the given size. So it seems fixing the crash I get requires to make CreateSurface fail when texture is marked as oversized (currently it passes through D3DCB_CreateSurface return value, which is WINED3D_OK), and fixing the leaks. When CreateSurface returns an error, game menu stays on noticeably longer (but notover 3 seconds or so). As it still crashed, I suspected a leak so I artificially made oversized texture be accepted (to have it freed correctly). > What is the texture size limit on your card, and what texture size does the > game try to use? It tries to create a 1024x1024 texture, and my card (Intel 945GM) is limited to 512x512: glxinfo -l | grep GL_MAX_TEXTURE_SIZE GL_MAX_TEXTURE_SIZE = 512 -- Vincent Pelletier

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Erich Hoover

On Sun, Dec 28, 2008 at 8:43 AM, Roderick Colenbrander < thunderbird2k(a)gmx.net> wrote: > Native dxdiag is checking the name of the display driver which in our case > winex11.drv and I guess this is just the identifier of Winex11.drv. Inside > winex11.drv we don't really have the knowledge about the 3d hardware we are > emulating. In the end we might need to duplicate some card detection code > inside winex11.drv and show a real driver name like the Nvidia or ATI ones. > It would be a lot of work and only be worth if apps really need it. > I'm not sure if this is exactly the same string you're looking at, but Fallout 3 currently requires a hack for the display driver information or it will just crash when you try to start a game ( http://bugs.winehq.org/show_bug.cgi?id=15839) Erich Hoover ehoover(a)mines.edu

Dec. 28, 2008

Re: RE: Implementing dxdiag as student project?

by Roderick Colenbrander

> > > Also, isn't it annoying that native dxdiag always says > > > the graphics card is X Windows? Why is that, and > > > should we change Wine so that the true card's info > > > is reported by native dxdiag? > > > > > I don't know, but if I were to guess I'd say it probably doesn't get > > that information from d3d, but from gdi32 or winex11.drv. > I think it is a resource string in winex11.drv. > > Concerning this topic, there are some apps that try to load the nvidia/ati > specific driver files, and have vendor specific strings. City of Heroes > tried to find nvogl.dll(or similar, don't remember exactly). I don't know > what it tried to do with it, but this could potentially be a bigger > problem > than just a string in dxdiag. > Most likely it attempted to load the OpenGL ICD driver directly and that way avoid using opengl32.dll / gdi32.dll. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Dec. 28, 2008

RE: Implementing dxdiag as student project?

by Stefan Dösinger

> > Also, isn't it annoying that native dxdiag always says > > the graphics card is X Windows? Why is that, and > > should we change Wine so that the true card's info > > is reported by native dxdiag? > > > I don't know, but if I were to guess I'd say it probably doesn't get > that information from d3d, but from gdi32 or winex11.drv. I think it is a resource string in winex11.drv. Concerning this topic, there are some apps that try to load the nvidia/ati specific driver files, and have vendor specific strings. City of Heroes tried to find nvogl.dll(or similar, don't remember exactly). I don't know what it tried to do with it, but this could potentially be a bigger problem than just a string in dxdiag.

Dec. 28, 2008

RE: wined3d: Do not treat oversized textures as failure

by Stefan Dösinger

This patch is wrong; You can't use oversized surfaces for 3D texturing because the driver doesn't support the given size. What is the texture size limit on your card, and what texture size does the game try to use? However, the oversize surface stuff is kinda hacky and poorly integrated. I think we should remove it and implement proper sysmem->framebuffer blitting. I used this oversized surface stuff to work around problems with swat 3's (approx) 3500x32 surface which contains the letters it blits onto the main menu. It was the wrong solution though, we should not create a GL texture for sysmem surfaces and use glDrawPixels instead(or temp textures in opengl 3) > -----Original Message----- > From: wine-devel-bounces(a)winehq.org [mailto:wine-devel- > bounces(a)winehq.org] On Behalf Of Vincent Pelletier > Sent: Sunday, December 28, 2008 4:21 PM > To: wine-devel(a)winehq.org > Subject: wined3d: Do not treat oversized textures as failure > > Hi. > > Attached patch is enough to cure the failure in "Operation Flashpoint" > when its menu is displayed on my little i945GM card. > > As the oversised case is (was) explicitely treated as a failure, I > think there is some reasone for it. Does someone remember what it is > for ? > > Regards, > -- > Vincent Pelletier

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Roderick Colenbrander

> On Sun, Dec 28, 2008 at 7:43 AM, Roderick Colenbrander > <thunderbird2k(a)gmx.net> wrote: > >> Also, isn't it annoying that native dxdiag always says > >> the graphics card is X Windows? Why is that, and > >> should we change Wine so that the true card's info > >> is reported by native dxdiag? > > > > Native dxdiag is checking the name of the display driver which in our > case winex11.drv and I guess this is just the identifier of Winex11.drv. > Inside winex11.drv we don't really have the knowledge about the 3d hardware we > are emulating. In the end we might need to duplicate some card detection > code inside winex11.drv and show a real driver name like the Nvidia or ATI > ones. It would be a lot of work and only be worth if apps really need it. > > OK, alternately, where should Wine's dxdiag.exe get that info? > - Dan The best thing would be to get it from the same place as Windows is doing but as mentioned that might not be good right now. Direct3D has info on the card we are emulating (it has emulated pci ids) but right now we only report a generic renderer string. At the moment the best way is to get this info from opengl. (glGetString(GL_RENDERER) Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Dan Kegel

On Sun, Dec 28, 2008 at 7:43 AM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: >> Also, isn't it annoying that native dxdiag always says >> the graphics card is X Windows? Why is that, and >> should we change Wine so that the true card's info >> is reported by native dxdiag? > > Native dxdiag is checking the name of the display driver which in our case winex11.drv and I guess this is just the identifier of Winex11.drv. Inside winex11.drv we don't really have the knowledge about the 3d hardware we are emulating. In the end we might need to duplicate some card detection code inside winex11.drv and show a real driver name like the Nvidia or ATI ones. It would be a lot of work and only be worth if apps really need it. OK, alternately, where should Wine's dxdiag.exe get that info? - Dan

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Roderick Colenbrander

> On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > > ... I think the main use of such an application would be > > dumping information like supported caps, texture formats, etc in case > > of D3D and supported extensions, pixelformats, various limits, drivers > > strings, etc. for OpenGL. > > OK. Can you list the main Win32 API calls you'd like such > an app to use to retrieve information? > > Also, isn't it annoying that native dxdiag always says > the graphics card is X Windows? Why is that, and > should we change Wine so that the true card's info > is reported by native dxdiag? Native dxdiag is checking the name of the display driver which in our case winex11.drv and I guess this is just the identifier of Winex11.drv. Inside winex11.drv we don't really have the knowledge about the 3d hardware we are emulating. In the end we might need to duplicate some card detection code inside winex11.drv and show a real driver name like the Nvidia or ATI ones. It would be a lot of work and only be worth if apps really need it. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 28, 2008

Re: wined3d: Do not treat oversized textures as failure

by Henri Verbeet

2008/12/28 Vincent Pelletier <plr.vincent(a)gmail.com>: > Le Sunday 28 December 2008 16:21:25 Vincent Pelletier, vous avez écrit : >> Attached patch is enough to cure the failure in "Operation Flashpoint" when >> its menu is displayed on my little i945GM card. > > It also fixes mipmap test in d3d9/tests/visual.c, removing the need for a > patch I sent earlier which purpose was to skip mipmap test when texture > allocation fails. > The test should probably check the device caps before trying to create the texture. > Some other notes on IWineD3DDeviceImpl_CreateTexture: > If oversize is treated as an error and return value is changed to some error > code, there seems to be a memory leak: it crashes happens after a rouhly > constant number of frames are rendered, but this time hr has a non-null value > in IWineD3DDeviceImpl_CreateTexture. > CreateTexture() and similar calls leak on error, yeah. This is something that needs to be fixed.

Dec. 28, 2008

Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size

by Vincent Pelletier

Le Friday 26 December 2008 22:35:18 Vincent Pelletier, vous avez écrit : > I'm not sure where to add it. I've added some line in > d3d9/tests/visual.c:pointsize_test (attached too). As I wrote that > test to succeed on wine and did not run it on any windows version, I > would be happy if someone could try it. > Note that this patch also contains a change from fix explained below > (I'm not used to git enough yet to split patches...). Patch regenerated without mipmap test change. -- Vincent Pelletier

Dec. 28, 2008

Re: wined3d: Do not treat oversized textures as failure

by Henri Verbeet

2008/12/28 Vincent Pelletier <plr.vincent(a)gmail.com>: > Hi. > > Attached patch is enough to cure the failure in "Operation Flashpoint" when > its menu is displayed on my little i945GM card. > > As the oversised case is (was) explicitely treated as a failure, I think there > is some reasone for it. Does someone remember what it is for ? > In general you're not supposed to create textures larger than what the hardware allows. I think SFLAG_OVERSIZE is used to allow ddraw to do this anyway in certain cases, but I'm pretty sure this change isn't correct for d3d8 and d3d9. I wonder if the pool has any effect on this though.

Dec. 28, 2008

Re: wined3d: Do not treat oversized textures as failure

by Vincent Pelletier

Le Sunday 28 December 2008 16:21:25 Vincent Pelletier, vous avez écrit : > Attached patch is enough to cure the failure in "Operation Flashpoint" when > its menu is displayed on my little i945GM card. It also fixes mipmap test in d3d9/tests/visual.c, removing the need for a patch I sent earlier which purpose was to skip mipmap test when texture allocation fails. Some other notes on IWineD3DDeviceImpl_CreateTexture: If oversize is treated as an error and return value is changed to some error code, there seems to be a memory leak: it crashes happens after a rouhly constant number of frames are rendered, but this time hr has a non-null value in IWineD3DDeviceImpl_CreateTexture. -- Vincent Pelletier

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Detlef Riekenberg

On Sa, 2008-12-27 at 23:20 -0800, Dan Kegel wrote: > Hi folks, > it seems odd to me that Wine doesn't have a tool like > dxdiag yet. We often have people complain that > graphics aren't working, and we have to ask them > to do things like run glxgears as diagnostics. > Would it make sense to implement our own > dxdiag.exe program? I think, that's a good Idea. When you ask a question in a Game related forum, you get most times a request for the logs of msinfo.exe and dxdiag.exe And in addition to the DX7, DX8 and DX9 rendering tests, we could add - OpenGL rendering test - GDI32 rendering test - DX10 rendering test - the framerate for all rendering tests -- By by ... Detlef

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Henri Verbeet

2008/12/28 Dan Kegel <dank(a)kegel.com>: > On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> ... I think the main use of such an application would be >> dumping information like supported caps, texture formats, etc in case >> of D3D and supported extensions, pixelformats, various limits, drivers >> strings, etc. for OpenGL. > > OK. Can you list the main Win32 API calls you'd like such > an app to use to retrieve information? > For d3d9 that would probably be IDirect3D9::CheckDeviceFormat(), IDirect3D9::CheckDeviceMultiSampleType(), IDirect3D9::EnumAdapterModes(), IDirect3D9::GetAdapterIdentifier() and IDirect3D9::GetDeviceCaps(). Ddraw and d3d8 should have similar methods, I'm not completely sure about dxgi/d3d10. For OpenGL there's DescribePixelFormat(), and glGetString() with various constants like GLRENDERER, GL_VENDOR, GL_VERSION and GL_EXTENSIONS. Limits are usually retrieved with glGetIntegerv() or glGetFloatv() and an appropriate constant. > Also, isn't it annoying that native dxdiag always says > the graphics card is X Windows? Why is that, and > should we change Wine so that the true card's info > is reported by native dxdiag? > I don't know, but if I were to guess I'd say it probably doesn't get that information from d3d, but from gdi32 or winex11.drv.

Dec. 28, 2008

wined3d: Do not treat oversized textures as failure

by Vincent Pelletier

Hi. Attached patch is enough to cure the failure in "Operation Flashpoint" when its menu is displayed on my little i945GM card. As the oversised case is (was) explicitely treated as a failure, I think there is some reasone for it. Does someone remember what it is for ? Regards, -- Vincent Pelletier

Dec. 28, 2008

Re: wined3d: Make WARN about oversized texture output surface and texture sizes

by Vincent Pelletier

Le Sunday 28 December 2008 15:46:46 Henri Verbeet, vous avez écrit : > pow2Height and pow2Width are unsigned, so you'd want to use %u there. Done, thanks. Also, git didn't commit half of the change (I'm too used to subversion commiting files in the state they are when changelog is saved...). They are in attached patch. -- Vincent Pelletier

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Dan Kegel

On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > ... I think the main use of such an application would be > dumping information like supported caps, texture formats, etc in case > of D3D and supported extensions, pixelformats, various limits, drivers > strings, etc. for OpenGL. OK. Can you list the main Win32 API calls you'd like such an app to use to retrieve information? Also, isn't it annoying that native dxdiag always says the graphics card is X Windows? Why is that, and should we change Wine so that the true card's info is reported by native dxdiag? > We could add some tests to see if basic > D3D is working, but on its own I don't think that adds > much over glxinfo & glxgears. Ah, but it's easy and fun :-) Maybe they could throw in a shader test or something... - Dan

Dec. 28, 2008

Re: wined3d: Make WARN about oversized texture output surface and texture sizes

by Henri Verbeet

2008/12/28 Vincent Pelletier <plr.vincent(a)gmail.com>: > + WARN("(%p) Creating an oversized surface: %ix%i\n", This, This->pow2Height, This->pow2Width); pow2Height and pow2Width are unsigned, so you'd want to use %u there.

Dec. 28, 2008

Re: xinput: Add stub XInputEnable

by Henri Verbeet

2008/12/28 Andrew Fenn <andrewfenn(a)gmail.com>: > +void WINAPI XInputEnable(bool enable) Does this compile? "bool" is a C++ type. Also, don't forget to add the prototype to the header, I noticed they're missing for all the other xinput functions as well.

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Henri Verbeet

2008/12/28 Dan Kegel <dank(a)kegel.com>: > Hi folks, > it seems odd to me that Wine doesn't have a tool like > dxdiag yet. We often have people complain that > graphics aren't working, and we have to ask them > to do things like run glxgears as diagnostics. > Would it make sense to implement our own > dxdiag.exe program? > This seems like it might be a fun student project. > - Dan > If the student in question is capable, sure. Like Chris already mentioned, I think the main use of such an application would be dumping information like supported caps, texture formats, etc in case of D3D and supported extensions, pixelformats, various limits, drivers strings, etc. for OpenGL. It would probably also be useful to dump some registry settings, like anything under HKCU\Software\Wine\Direct3D. We could add some tests to see if basic D3D is working, but on its own I don't think that adds much over glxinfo & glxgears.

Dec. 28, 2008

Re: Assorted spelling fixes.

by Henri Verbeet

2008/12/28 Francois Gouget <fgouget(a)free.fr>: > - FIXME("No free constant found to load environemnt bump mapping matrix into the shader. texbem instruction will not apply bump mapping\n"); > + FIXME("No free constant found to load environement bump mapping matrix into the shader. texbem instruction will not apply bump mapping\n"); Shouldn't that be "environment"?

Dec. 28, 2008

winecfg: Add dll override on return key press in combobox [resend]

by Andre Wisplinghoff

Thanks a lot for your hints, Reece and Dmitry. I didn't realize the difference between WndProcs and DlgProcs. I send a new try and hope everything is okay now :) http://www.winehq.org/pipermail/wine-patches/2008-December/066762.html -- Andre

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Louis Lenders

Chris Robinson <chris.kcat <at> gmail.com> writes: > I think such a thing could still be useful. It'll help figure out what kind of > info apps are getting from a given system, and help determine if problems are > app-specific or more general system/wine-related. It can also serve as a > basic interactive test bed for various DX functionality that even users can > run and look at, instead of being delegated to the wine test suite only. Plus > it can check DirectPlay and DirectSound (a couple other components prone to > errors), instead of just Direct3D/DirectDraw. > > Wine needs a dxdiag.exe as some apps expect it to be present, like for example GameShadow. I once gave it a shot already, see http://bugs.winehq.org/show_bug.cgi?id=14118. A builtin dxdiag.exe would aslo be nice addition to wine imo.

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Chris Robinson

On Sunday 28 December 2008 03:02:34 am Roderick Colenbrander wrote: > On Windows the main task of dxdiag is to show some diagnostic info and to > run some very basic network, sound and 3d tests. In case of Wine 3D testing > would be the most important feature but I'm not sure if it is that useful. > There are various causes of slowness e.g. no 3d drivers installed, indirect > rendering, driver bugs (e.g. fglrx falling back to indirect rendering due > to virtual memory issues in Wine), the use of a composition manager and > more. Most of this information can't be retrieved using Win32 APIs or we > would need internal APIs. I think such a thing could still be useful. It'll help figure out what kind of info apps are getting from a given system, and help determine if problems are app-specific or more general system/wine-related. It can also serve as a basic interactive test bed for various DX functionality that even users can run and look at, instead of being delegated to the wine test suite only. Plus it can check DirectPlay and DirectSound (a couple other components prone to errors), instead of just Direct3D/DirectDraw.

Dec. 28, 2008

Re: Implementing dxdiag as student project?

by Roderick Colenbrander

> Hi folks, > it seems odd to me that Wine doesn't have a tool like > dxdiag yet. We often have people complain that > graphics aren't working, and we have to ask them > to do things like run glxgears as diagnostics. > Would it make sense to implement our own > dxdiag.exe program? > This seems like it might be a fun student project. > - Dan > On Windows the main task of dxdiag is to show some diagnostic info and to run some very basic network, sound and 3d tests. In case of Wine 3D testing would be the most important feature but I'm not sure if it is that useful. There are various causes of slowness e.g. no 3d drivers installed, indirect rendering, driver bugs (e.g. fglrx falling back to indirect rendering due to virtual memory issues in Wine), the use of a composition manager and more. Most of this information can't be retrieved using Win32 APIs or we would need internal APIs. I think it would be better to write a 'wine3ddiag' script which uses glxinfo, glxgears and which can also check if lets say compiz is running. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Dec. 28, 2008

Re: 260 tests passing on win64!

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > Ladies and gentlemen, I believe it's time > for a 64 bit winetest.exe to be added to the daily build, > and for 64 bit test data to start showing up at http://test.winehq.org. I'm working on that. I haven't uploaded the results but the current status is that there are about 60 more failing tests on Vista 64-bit compared to 32-bit. -- Alexandre Julliard julliard(a)winehq.org

Dec. 28, 2008

Implementing dxdiag as student project?

by Dan Kegel

Hi folks, it seems odd to me that Wine doesn't have a tool like dxdiag yet. We often have people complain that graphics aren't working, and we have to ask them to do things like run glxgears as diagnostics. Would it make sense to implement our own dxdiag.exe program? This seems like it might be a fun student project. - Dan

Dec. 28, 2008

Re: Combining Fuse and Wine - What's the best way?

by Richard Stitz

So would the best way to do this be to have a separate process for the Wine program that loads the DLL, and then have the Fuse process communicate over pipes or some other IPC method?

Dec. 28, 2008

Status of dxdiagn?

by Dan Kegel

Hi Markus, what's the status of dxdiagn these days? I see a number of games that say they need a native copy: http://www.google.com/search?q=dxdiagn+site%3Aappdb.winehq.org Do you know what needs doing before we can get native dxdiag working, http://bugs.winehq.org/show_bug.cgi?id=1429 ? Also, how about your dxdiagn conformance test? http://www.winehq.org/pipermail/wine-patches/2008-May/055355.html I know it didn't do much, maybe you could have it check a few required properties? I ask because I'm looking around for a student project, and implementing dxdiag.exe came to mind; looking around a bit, I saw dxdiagn, and figured it might be nice to tie up some loose ends there, too. - Dan

Dec. 27, 2008

wine.budgetdedicated.com down?

by Dustin M. Jackson

Hi Scott, I'm trying to install Wine, but I cannot connect to the server. Just thought I would let you know. Regards, Dustin

Dec. 27, 2008

260 tests passing on win64!

by Dan Kegel

I updated http://wiki.winehq.org/Wine64 with easy instructions (thanks, Maarten!) for how to build wine's 64 bit support and try 64 bit pacman (which works!). And then I ran "make -k test". Surprisingly, I got 260 passing tests according to find . -name '*.ok' | wc and only 128 failed tests according to grep ok.*Error test.log | wc -l Ladies and gentlemen, I believe it's time for a 64 bit winetest.exe to be added to the daily build, and for 64 bit test data to start showing up at http://test.winehq.org. That would let us tamp down errors in the test suite on 64 bits. (Yeah, I know, gcc with win64 ABI isn't released yet, and there are problems with exception handling still, but it still seems worth it...) - Dan

Dec. 27, 2008

Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size

by Vincent Pelletier

Le Friday 26 December 2008 22:35:18 Vincent Pelletier, vous avez écrit : > As I guess IWineD3DDeviceImpl_CreateTexture should then return a > failure code, I patched it and made the test give up if texture > allocation failed. (patch attached) Updated to test previous return code, instead of accessing a list behin potentially NULL pointer. -- Vincent Pelletier

Dec. 27, 2008

Minimal patches to try win64?

by Dan Kegel

Out of curiosity, I finally bit the bullet, installed 64 bit Ubuntu 8.10, updated http://wiki.winehq.org/Wine64 to show how to build gcc, and built wine with win64 support enabled. It built successfully on the first try, but starting any conformance test or win64 app fails with wineserver: request.c:744: open_master_socket: Assertion `sizeof(union generic_request) == sizeof(struct request_max_size)' failed. I tried grabbing the patch that seems to fix that, http://repo.or.cz/w/wine/wine64.git?a=commitdiff_plain;h=6e77a4879d5e62a977… but then I got other errors. What's the minimal set of patches needed to start trying win64? I'd rather not pull Maarten's whole repo, I have no idea how closely that tracks winehq... - Dan

Dec. 27, 2008

RE: Simplify dlls/comctl32/nativefont.c

by Gerald Pfeifer

On Sat, 27 Dec 2008, ricardo filipe wrote: > are you sure windows doesn't call those functions with those parameters? you have to check that before sending patches like these ... Yes, I am. Looking at the patch... >> static LRESULT >> -NATIVEFONT_Create (HWND hwnd, WPARAM wParam, LPARAM lParam) >> +NATIVEFONT_Create (HWND hwnd) ...you'll notice that this function is static and thus cannot be invoked by any external caller. I have explicitly excluded functions with external linkage or callback functions from such simplifications. Gerald -- Gerald (Jerry) Pfeifer gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

Dec. 27, 2008

Re: Simplify dlls/comctl32/nativefont.c

by Nikolay Sivov

ricardo filipe wrote: > are you sure windows doesn't call those functions with those parameters? you have to check that before sending patches like these ... > > ---------------------------------------- > >> Date: Sat, 27 Dec 2008 08:57:44 +0100 >> From: gerald(a)pfeifer.com >> To: wine-patches(a)winehq.org >> Subject: Simplify dlls/comctl32/nativefont.c >> >> ChangeLog: >> Simplify NATIVEFONT_Create. >> >> Index: dlls/comctl32/nativefont.c >> =================================================================== >> RCS file: /home/wine/wine/dlls/comctl32/nativefont.c,v >> retrieving revision 1.29 >> diff -u -3 -p -r1.29 nativefont.c >> --- dlls/comctl32/nativefont.c 24 Oct 2008 13:13:47 -0000 1.29 >> +++ dlls/comctl32/nativefont.c 27 Dec 2008 07:57:10 -0000 >> @@ -47,7 +47,7 @@ typedef struct >> #define NATIVEFONT_GetInfoPtr(hwnd) ((NATIVEFONT_INFO *)GetWindowLongPtrW (hwnd, 0)) >> >> static LRESULT >> -NATIVEFONT_Create (HWND hwnd, WPARAM wParam, LPARAM lParam) >> +NATIVEFONT_Create (HWND hwnd) >> { >> NATIVEFONT_INFO *infoPtr; >> >> @@ -85,7 +85,7 @@ NATIVEFONT_WindowProc (HWND hwnd, UINT u >> switch (uMsg) >> { >> case WM_CREATE: >> - return NATIVEFONT_Create (hwnd, wParam, lParam); >> + return NATIVEFONT_Create (hwnd); >> >> case WM_DESTROY: >> return NATIVEFONT_Destroy (infoPtr); >> >> >> > _________________________________________________________________ > Show them the way! Add maps and directions to your party invites. > http://www.microsoft.com/windows/windowslive/events.aspx > > > It isn't exported.

Dec. 27, 2008