re: New Wine Gecko
Thanks, Jacek, we're really looking forward to it!
New Wine Gecko
Hi, As there will be a new Gecko release soon, I'd like to give you a good background over what's going on as I feel that there is some misunderstanding on it that I'd like to clarify. I'm sorry for the long mail. First, let me give you a short history of the Gecko package. As we started using Gecko in our MSHTML implementation, we had to provide our own package and an easy way for its installation. I've prepared a package that actually was a temporary solution. It was a SeaMonkey build that had some files manually removed and modified to reduce its size. It was, of course, hacky and ugly but, as there was no urgent need for changing it, we used it for over a year. The next version was built by me. The build process was long and ugly - it needed a Windows installation and MSVC6. Except that I had to try many versions before finding one that worked fine for Wine, as it had both to compile with MSVC6 (back then they were switching to a newer compiler that needed actctx) and work with Wine (there were a few APIs that were not implemented in Wine that they started using). Also, there was the XULRunner project that looked promising but proved to not be good enough for us. I ended up with building the SeaMonkey target and, again, modifying and removing some files afterwards. Now, not only because of CS4 but because we really should follow new Gecko versions as well, the time to release a new package has come. The first decision was to try again by building with MinGW on Windows. I've tried it with limited success and then I found that Mozilla developers have recently worked on building Mozilla with MinGW under Linux (for code analyzers). That was something I hoped to do some day, so I gave it a try and it came out that it works better than compiling on Windows! Also XULRunner project has matured so that we may use it, avoiding other pains from previous packages. But not all is so good. Some changes introduced in the recent Gecko have prevented Wine from working correctly. It was unnoticed for long time because we were using the 1.8 branch, while the newest is 1.9. Because of it, I had to add serious patches (previous build had only minor changes in code) to fix it. I'm working with Mozilla developers to get these patches to official Gecko. We definitely want to avoid maintaining such differences. There are other advantages that will come with the new Gecko. I'm going to make a debug build that seems to work really well on Wine. Although it causes an assert in dbghelp that I didn't look at deeper, for one build I was even able to step through Gecko code with winedbg. Hopefully Valgrind will be happy with it. Also, I'm going to put the code to Git and provide a good building instruction. It's not trivial to build the package, but hopefully with some efforts everyone will be able to succeed with it. In this place I'd like to note: if you're not planning to work on Gecko (I mean not even MSHTML, but Gecko itself), there is no reason to do it. Also I know that some package maintainers would be interested in building it. Please, don't do it! You will realize that it is not possible with a fresh Linux installation without manually setting up environment. Also, due to its complexity, I'm worried about broken builds. I don't really see the reason to do it. If it's a matter of trust policy... well, you've trusted my builds for over three years now, so I'd like to ask you to keep trusting me... Also, I didn't really have a clear idea about version numbering. The first, temporary, package was numbered 0.0.1. The next one was 0.1.0 with plans to release 0.1.x if we'd release a new package on the same code base (there was 0.1.1 candidate that was never released). My plan was to release a package compiled under Linux as 1.0.0, and until then release next 0.x.y builds. Now that we compile the new package on Linux, I still don't like to call it 1.0.0, because of patches needed in our build. I'd prefer to wait with 1.0.0 hoping to fix the difference for next major release. I don't feel strongly about it so if anyone has any suggestion, I'm happy to change the plan. I plan to put Wine Gecko code into a public Git so developing it will be easier. Now releasing a new version should be much easier (as long as we won't find a new blocker, but if we'll find it quicker, it will be easier to fix). I'm happy with releasing the build I've written about a few days ago. I got feedback from Mozilla developer about things we could get to Mozilla tree and I'm going to try to get some patches to Mozilla. That shouldn't delay our release IMO, so I'm going to release tomorrow unless there are any objections. I hope to have another release in a few months that well be closer to main stream Gecko. Please let me know if you have any suggestion or question. Thanks, Jacek
Re: Implementing dxdiag as student project?
Louis wrote: > 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 Thanks for the link. I refreshed your patch, and also added in the parsing for the commandline options used by GameShadow. That game needs a lot of overrides, and I never got it to run far enough to check the output of dxdiag. Does anyone know of other apps that require dxdiag.exe (as opposed to dxdiagn.dll)? - Dan
Re: [PATCH 5/6] dinput: Fix usage of HeapReAlloc.
Alexandre Julliard wrote: > While you are fixing it you should fix it properly by preserving the old > pointer on failure. > Thanks. Sent fixed patch. Vitaliy
Re: wined3d: Do not treat oversized textures as failure
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
RE: xinput: Add stub XInputEnable
yup, the patches look good on a quick glance. > Date: Mon, 29 Dec 2008 02:30:26 +0700 > From: andrewf...@gmail.com > To: hverb...@gmail.com; wine-de...@kievinfo.com; ricardo_barb...@hotmail.com > Subject: Re: xinput: Add stub XInputEnable > CC: wine-devel@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/
Re: xinput: Add stub XInputEnable
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
Re: xinput: Add stub XInputEnable
2008/12/28 Andrew Fenn : > 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? > 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 : > > 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.
Re: wined3d: Do not treat oversized textures as failure
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
Re: wined3d: Do not treat oversized textures as failure
2008/12/28 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. > 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.
Re: xinput: Add stub XInputEnable
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.
Re: Implementing dxdiag as student project?
> 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
RE: xinput: Add stub XInputEnable
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: andrewf...@gmail.com > To: wine-devel@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
RE: wined3d: Do not treat oversized textures as failure
> 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...
RE: Implementing dxdiag as student project?
> 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
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? From 7653e90dfca104c19c074274c723446a6f7cfd1d Mon Sep 17 00:00:00 2001 From: Andrew Fenn Date: Sun, 28 Dec 2008 23:31:24 +0700 Subject: xinput: Added prototypes to header --- include/xinput.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/xinput.h b/include/xinput.h index 46fd0ac..afb1198 100644 --- a/include/xinput.h +++ b/include/xinput.h @@ -22,6 +22,12 @@ #include +DWORD WINAPI XInputGetState(DWORD dwUserIndex, +XINPUT_STATE* pState); +DWORD WINAPI XInputGetCapabilities(DWORD dwUserIndex, +DWORD dwFlags, +XINPUT_CAPABILITIES* pCapabilities) + /* * Bitmasks for the joysticks buttons, determines what has * been pressed on the joystick, these need to be mapped -- 1.5.4.3
Re: Implementing dxdiag as student project?
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.
Re: Implementing dxdiag as student project?
> On Sun, Dec 28, 2008 at 8:43 AM, Roderick Colenbrander < > thunderbir...@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 > ehoo...@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
RE: Implementing dxdiag as student project?
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)
Re: wined3d: Do not treat oversized textures as failure
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
Re: Implementing dxdiag as student project?
On Sun, Dec 28, 2008 at 8:43 AM, Roderick Colenbrander < thunderbir...@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 ehoo...@mines.edu
Re: RE: Implementing dxdiag as student project?
> > > 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 -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
RE: Implementing dxdiag as student project?
> > 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.
RE: wined3d: Do not treat oversized textures as failure
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-boun...@winehq.org [mailto:wine-devel- > boun...@winehq.org] On Behalf Of Vincent Pelletier > Sent: Sunday, December 28, 2008 4:21 PM > To: wine-devel@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
Re: Implementing dxdiag as student project?
> On Sun, Dec 28, 2008 at 7:43 AM, Roderick Colenbrander > 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
Re: Implementing dxdiag as student project?
On Sun, Dec 28, 2008 at 7:43 AM, Roderick Colenbrander 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
Re: Implementing dxdiag as student project?
> On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet 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
Re: wined3d: Do not treat oversized textures as failure
2008/12/28 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. > 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.
Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size
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 diff --git a/dlls/d3d9/tests/visual.c b/dlls/d3d9/tests/visual.c index 9bcb42f..ed883f2 100644 --- a/dlls/d3d9/tests/visual.c +++ b/dlls/d3d9/tests/visual.c @@ -8340,6 +8340,7 @@ static void pointsize_test(IDirect3DDevice9 *device) 448,64, 0.1, 512,64, 0.1, 576,64, 0.1, +640,64, 0.1, }; /* Transforms the coordinate system [-1.0;1.0]x[-1.0;1.0] to [0.0;0.0]x[640.0;480.0]. Z is untouched */ @@ -8456,6 +8457,12 @@ static void pointsize_test(IDirect3DDevice9 *device) hr = IDirect3DDevice9_SetRenderState(device, D3DRS_POINTSIZE_MIN, *((DWORD *) (&ptsizemin_orig))); ok(hr == D3D_OK, "IDirect3DDevice9_SetRenderState failed, hr=%08x\n", hr); +ptsize = 0.0; +hr = IDirect3DDevice9_SetRenderState(device, D3DRS_POINTSIZE, *((DWORD *) (&ptsize))); +ok(hr == D3D_OK, "IDirect3DDevice9_SetRenderState failed, hr=%08x\n", hr); +hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_POINTLIST, 1, &vertices[27], sizeof(float) * 3); +ok(hr == D3D_OK, "IDirect3DDevice9_DrawPrimitiveUP failed, hr=%08x\n", hr); + hr = IDirect3DDevice9_EndScene(device); ok(hr == D3D_OK, "IDirect3DDevice9_EndScene failed hr=%08x\n", hr); } @@ -8554,6 +8561,13 @@ static void pointsize_test(IDirect3DDevice9 *device) color = getPixelColor(device, 576+4, 64+4); ok(color == 0x00ff, "pSize: Pixel (448+4),(64+4) has color 0x%08x, expected 0x00ff\n", color); +color = getPixelColor(device, 640-1, 64-1); +ok(color == 0x00ff, "pSize: Pixel (640-1),(64-1) has color 0x%08x, expected 0x00ff\n", color); +color = getPixelColor(device, 640-0, 64-0); +ok(color == 0x00ff, "pSize: Pixel (640-0),(64-0) has color 0x%08x, expected 0x00ff\n", color); +color = getPixelColor(device, 640+1, 64+1); +ok(color == 0x00ff, "pSize: Pixel (640+1),(64+1) has color 0x%08x, expected 0x00ff\n", color); + hr = IDirect3DDevice9_SetRenderState(device, D3DRS_POINTSIZE, *((DWORD *) (&ptsize_orig))); ok(hr == D3D_OK, "IDirect3DDevice9_SetRenderState failed hr=%08x\n", hr); hr = IDirect3DDevice9_SetTransform(device, D3DTS_PROJECTION, &identity);
Re: wined3d: Do not treat oversized textures as failure
2008/12/28 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 ? > 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.
Re: wined3d: Do not treat oversized textures as failure
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
Re: Implementing dxdiag as student project?
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
Re: Implementing dxdiag as student project?
2008/12/28 Dan Kegel : > On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet 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.
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
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 36fbcba..549badc 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -869,7 +869,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateTexture(IWineD3DDevice *iface, U
{
/* use the callback to create the texture surface */
hr = D3DCB_CreateSurface(This->parent, parent, tmpW, tmpH, Format, Usage, Pool, i, WINED3DCUBEMAP_FACE_POSITIVE_X, &object->surfaces[i],NULL);
-if (hr!= WINED3D_OK || ( (IWineD3DSurfaceImpl *) object->surfaces[i])->Flags & SFLAG_OVERSIZE) {
+if (hr!= WINED3D_OK) {
FIXME("Failed to create surface %p\n", object);
/* clean up */
object->surfaces[i] = NULL;
Re: wined3d: Make WARN about oversized texture output surface and texture sizes
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
From d02d16f5469f699a8b36f1104219c0abbd23bc4e Mon Sep 17 00:00:00 2001
From: Vincent Pelletier
Date: Sun, 28 Dec 2008 14:50:09 +0100
Subject: Make WARN about oversized texture output surface and texture size.
---
dlls/wined3d/surface.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 67097ac..a306f2c 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -3865,7 +3865,7 @@ static HRESULT WINAPI IWineD3DSurfaceImpl_PrivateSetup(IWineD3DSurface *iface) {
3:WARN and return WINED3DERR_NOTAVAILABLE;
4: Create the surface, but allow it to be used only for DirectDraw Blts. Some apps(e.g. Swat 3) create textures with a Height of 16 and a Width > 3000 and blt 16x16 letter areas from them to the render target.
*/
-WARN("(%p) Creating an oversized surface\n", This);
+WARN("(%p) Creating an oversized surface: %ux%u (texture is %ux%u)\n", This, This->pow2Width, This->pow2Height, This->currentDesc.Width, This->currentDesc.Height);
This->Flags |= SFLAG_OVERSIZE;
/* This will be initialized on the first blt */
--
1.5.6.5
Re: Implementing dxdiag as student project?
On Sun, Dec 28, 2008 at 6:24 AM, Henri Verbeet 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
Re: wined3d: Make WARN about oversized texture output surface and texture sizes
2008/12/28 Vincent Pelletier :
> +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.
Re: xinput: Add stub XInputEnable
2008/12/28 Andrew Fenn : > +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.
Re: Implementing dxdiag as student project?
2008/12/28 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 > 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.
Re: Assorted spelling fixes.
2008/12/28 Francois Gouget :
> -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"?
winecfg: Add dll override on return key press in combobox [resend]
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
Re: Implementing dxdiag as student project?
Chris Robinson 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.
Re: Implementing dxdiag as student project?
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.
Re: Implementing dxdiag as student project?
> 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 -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
wine.budgetdedicated.com down?
Hi Scott, I'm trying to install Wine, but I cannot connect to the server. Just thought I would let you know. Regards, Dustin
Re: 260 tests passing on win64!
"Dan Kegel" 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 julli...@winehq.org
