Wine Benchmarks and CAPS
Hello, I have the 0.9.33 page done, and you may notice that Wine regressed in a couple of the test. When looking at these scores you will need to take into account the actual visual quality . The scores were somewhat high in past test because everything wasn't being rendered, while that makes for a nice score the visual wasn't on par with that of Windows. As of 0.9.33 the visual quality is very close to that of Windows, so in test like 3DMark2001SE we not only got drastically improved visual quality, we also have a 50% improvement in performance! And 3DMark 03 has a nice showing out of the gate as well. Why no OpenGL test? I plan to wait for a resolution to a couple outstanding OpenGL bugs, and then run the test again. I also plan to dramatically increase the screen resolution in the next update, GL-Excess in the past was run at only 640x480x16 in the future all test will be run at a resolution of 1024x768x32 or greater. If all goes well In a couple months there should be another update with OpenGL test and 3DMark 05/06 results. If 3DMark 2000, 2001SE or 2003 should drastically change ill also update them as well at that time. I also updated the CAPS page with 0.9.33 and 1.0.9755. 0.9.33 results: http://wiki.winehq.org/BenchMark-0.9.33 Past results: http://wiki.winehq.org/BenchMarks CAPS results: http://wiki.winehq.org/DirectX-Caps Some screen shots of past test results You may want to look at them ASAP if your interested in them, I plan to ask Dimi to rm -rf the page in a couple weeks to save the HD space on the wiki server, this way I can start a new In Progress page and not feel guilty about uploading all the shots :D http://wiki.winehq.org/BenchMark-0.9.6 Cheers! -- Tom Wickline Respectable computing - Linux/FOSS
extracting info from a minidump via winedbg
Hello Wine users! I've got a minidump from a (real) Windows user of our game and would like to extract information from it using winedbg. The information winedbg gives me by default, is this: WineDbg starting on minidump on pid 068c warzone2100.exe was running on #1 Intel ???-0.521 CPU on Windows XP (2600) Register dump: CS:001b SS:0023 DS:0023 ES:0023 FS:003b GS: EIP:0051008b ESP:0022f844 EBP:0022f858 EFLAGS:00010a87( - 00 ROISP1C) EAX:c7b054d8 EBX:19ff502e ECX:0040 EDX:000f ESI:02010101 EDI: Stack dump: 0x0022f844: 3f80 0x0022f854: 0022f8c8 0050e796 19ff502e 0x0022f864: 3f80 0x0022f874: ff4a4a4a 0x0022f884: 0005 02010101 0x0022f894: 0022f8c8 Backtrace: =1 0x0051008b (0x0022f858) 2 0x0050e796 (0x0022f8c8) 3 0x00410c3b (0x0022f948) 4 0x0041172d (0x0022f9c8) 5 0x004b2272 (0x0022f9d8) 6 0x004aa97b (0x0022f9f8) 7 0x004b615a (0x0022fab8) 8 0x004b663f (0x0022fad8) 9 0x004b67e1 (0x0022faf8) 10 0x0041e39e (0x0022fb28) 11 0x00459d3e (0x0022fb58) 12 0x0045b2ee (0x0022fca8) 13 0x0055e77b (0x0022fcf8) 14 0x0055e932 (0x0022fef8) 15 0x0055e483 (0x0022fff0) 16 0x (0x) WineDbg starting on pid 068c Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles. My questions are: - Why doesn't winedbg extract the sourcecode locations itself? - Why doesn't winedbg show me the other information included in the minidump, like the loaded modules, commandline options or version information? - How can I get the parameters to the last called function(s)? If winedbg is missing the commands/functions to achive the above, I may be able to provide it. The minidump functions seem to be documented rather good on msdn and it would just require printing it to the console. Thanks in advance, Dennis pgpDKNM2rwMPv.pgp Description: PGP signature
What is the X11 lock?
Hi list, Can anyone please explain to me what the x11 lock is used for? I can see that SOME X11 functions (e.g. - read description on X11DRV_KEYBOARD_DetectLayout) require a lock, while others seem to call X11 functions with no lock. I can see that sometimes the x11 lock is obtained around a single X11 call. Is there any guideline I can follow that will tell me whether I need a lock for code I'm writing? What is the race this lock was designed to fix? Thanks, Shachar
Re: ntdll: add ZwAreMappedFilesTheSame to ntdll.spec
Louis. Lenders [EMAIL PROTECTED] wrote: diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec index e315057..3377db3 100644 --- a/dlls/ntdll/ntdll.spec +++ b/dlls/ntdll/ntdll.spec @@ -948,7 +948,7 @@ # @ stub ZwAllocateUserPhysicalPages @ stdcall ZwAllocateUuids(ptr ptr ptr) NtAllocateUuids @ stdcall ZwAllocateVirtualMemory(long ptr ptr ptr long long) NtAllocateVirtualMemory -# @ stub ZwAreMappedFilesTheSame +@ stub ZwAreMappedFilesTheSame # @ stub ZwAssignProcessToJobObject @ stub ZwCallbackReturn # @ stub ZwCancelDeviceWakeupRequest It seems you haven't read an introducing comment in the first lines of ntdll.spec before changing it. -- Dmitry.
More Direct3D settings in winecfg (was: Enabling GLSL in winecfg)
Hi, according to Stefan, Direct X options regarding * Available Video Memory * Enable GLSL will be useful in winecfg / Graphics section. However there is still missing consensus to how and whether to implement user accessible way to enable/disable GLSL in winecfg. Ray Jones, Stefan and me would like this in winecfg. Please share Your opinion. According to the discussion results, I'm going to add either only Available Video Memory text input box, or both Memory and GLSL toggle checkbox to winecfg. Summary of previous discussion follows: Available Video Memory (text input box) -- User will input here the RAM size of his graphic card. According to Stefan: There are vendor dependent ways to read it, but implementing them is pretty nasty(requires some private to winex11.drv). Altough we had that discussion a number of times already and we only agreed on a registry key so far. Enable GLSL (checkbox) --- GLSL should be made default in 1.0. However, according to Stefan: some drivers(*cough* macos *cough*) have serious problems with glsl. Until there is a specification in 1.0 requirements that these issues have to be resolved prior 1.0, this checkbox would be useful even past 1.0. Stefan Dosinger with H. Verbeet pointed out that this option should be in Vertex Shader dropdown box, but after inspecting code, I've found wouldn't blend well with the rest of Vertex Shader idea. This is due to GLSL registry key differs from Vertex Shader registry key. Should they be merged into one? Ivan Gyurdiev pointed out that GLSL can be both enabled for hardware vertex shader and software vertex shader, so the idea of merging GLSL with Vertex Shader dropdown box would result in two menu options - 'GLSL with HW support' and 'GLSL with SW support'. Another stance is to make GLSL enabled by default in next Wine versions. Offscreen Rendering (dropdown box) --- Default option will be 'fbo', optional is backbuffer. Stefan doesn't consider it worthy adding to winecfg. Regards Vit
Re: Wine Benchmarks and CAPS
On 29.03.2007 09:41, Tom Wickline wrote: CAPS results: http://wiki.winehq.org/DirectX-Caps Some note on the coloring: presumably, a green coloring in the Wine row means better, red means worse. For true/false caps those that Wine has but native doesn't are green, while those that Wine does not have but native not are red. However, presence of a cap is not always better: for example D3DPTEXTURECAPS_CUBEMAP_POW2 - MSDN says that this means Device requires that cube texture maps have dimensions specified as powers of two. So it's actually better if the flag is absent (as that means cubemaps can be non-POW2). It would be nice if the visual hint could reflect that - this way a red background would be a clear signal that this needs work. -f.r. signature.asc Description: OpenPGP digital signature
Re: Wine Benchmarks and CAPS
On 3/29/07, Frank Richter [EMAIL PROTECTED] wrote: However, presence of a cap is not always better: for example D3DPTEXTURECAPS_CUBEMAP_POW2 - MSDN says that this means Device requires that cube texture maps have dimensions specified as powers of two. So it's actually better if the flag is absent (as that means cubemaps can be non-POW2). It would be nice if the visual hint could reflect that - this way a red background would be a clear signal that this needs work. I personally think any value that doesn't match, better or worse should be highlighted in red as it doesn't match that of Windows. -f.r. -- Tom Wickline Respectable computing - Linux/FOSS
Re: Nine good SoC propsals!
On 3/28/07, Bryan DeGrendel [EMAIL PROTECTED] wrote: Do you have any idea how many will be accepted? Six, maybe? It's hard to say, they juggle the slots right up until the last moment.
Re: imm32: Change the default IME window to better reflect applications request
It looks good to me. Thanks to Aric :) Aric Stewart wrote: First part of this change was proposed by Byeong-Sik Jeon [EMAIL PROTECTED] Use a tooltip window instead to avoid stealing focus from the application. Additionally respect parameters give to us by ImmSetCompositionWindow for placement of the composition window.
Re: More Direct3D settings in winecfg (was: Enabling GLSL in winecfg)
On 3/29/07, Christoph Frick [EMAIL PROTECTED] wrote: On Thu, Mar 29, 2007 at 12:25:31PM +0200, Vit Hrachovy wrote: Please share Your opinion. ok you asked for it ;) Available Video Memory (text input box) -- User will input here the RAM size of his graphic card. According to Stefan: There are vendor dependent ways to read it, but implementing them is pretty nasty(requires some private to winex11.drv). Altough we had that discussion a number of times already and we only agreed on a registry key so far. go for it! since there where a registry key for this i had to fix it source every time. there are games out there that wont work without proper setting (e.g. Richard Burns Rally in my case 1600x1200). a text input is simple and easy - everyone, who does not know what to do will leave it alone and the others will see the wrong number and fix it. later when there are better ways to acquire this number one still might be able to change/correct it there if the algorithms fail or for people with graphics-cards, that does not allow reading the value. Enable GLSL (checkbox) --- GLSL should be made default in 1.0. However, according to Stefan: some drivers(*cough* macos *cough*) have serious problems with glsl. Until there is a specification in 1.0 requirements that these issues have to be resolved prior 1.0, this checkbox would be useful even past 1.0. dont go for it! if it is supposed to be the default enable it and keep the key for the developers. for osx: change the default at compile time using autohell? -- cu I agree with him. Put the Video memory in! I'm tired of having wine default to 64MB when I have a 256MB GFX Card. As for the GLSL, however I'm kinda mixed about this one. On the one hand, it would be nice to have the setting to make it easier to link with appdefaults, but on the OTOH we dont want to have to do more support b/c people played with it when they shouldn't have.Definitely make it default if it works for the majority of DX apps/games. I would say go ahead and put it in but put a big fat warning to not touch it if you dont know what you are doing, and that the best setting is to leave it at the default. I would rather tell someone to enable it b/c it makes their game work, than to disable it because every other game isnt working. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: Wine Benchmarks and CAPS
On 3/29/07, Tom Wickline [EMAIL PROTECTED] wrote: Hello, I have the 0.9.33 page done, and you may notice that Wine regressed in a couple of the test. When looking at these scores you will need to take into account the actual visual quality . The scores were somewhat high in past test because everything wasn't being rendered, while that makes for a nice score the visual wasn't on par with that of Windows. As of 0.9.33 the visual quality is very close to that of Windows, so in test like 3DMark2001SE we not only got drastically improved visual quality, we also have a 50% improvement in performance! And 3DMark 03 has a nice showing out of the gate as well. Why no OpenGL test? I plan to wait for a resolution to a couple outstanding OpenGL bugs, and then run the test again. I also plan to dramatically increase the screen resolution in the next update, GL-Excess in the past was run at only 640x480x16 in the future all test will be run at a resolution of 1024x768x32 or greater. If all goes well In a couple months there should be another update with OpenGL test and 3DMark 05/06 results. If 3DMark 2000, 2001SE or 2003 should drastically change ill also update them as well at that time. I also updated the CAPS page with 0.9.33 and 1.0.9755. 0.9.33 results: http://wiki.winehq.org/BenchMark-0.9.33 Past results: http://wiki.winehq.org/BenchMarks CAPS results: http://wiki.winehq.org/DirectX-Caps Some screen shots of past test results You may want to look at them ASAP if your interested in them, I plan to ask Dimi to rm -rf the page in a couple weeks to save the HD space on the wiki server, this way I can start a new In Progress page and not feel guilty about uploading all the shots :D http://wiki.winehq.org/BenchMark-0.9.6 Hi Tom, thanks for the updates! I just wanted to ask about Aquamark. How come there isnt a test with that one? I use it more than I use 3dmark. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: gdi32: Implement the fake_bold for one faced fonts.
On Thu, Mar 29, 2007 at 10:00:12PM +0900, Byeong-Sik Jeon wrote:
diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
index f7b1220..427def4 100644
--- a/dlls/gdi32/freetype.c
+++ b/dlls/gdi32/freetype.c
+memcpy(gmetrix, ft_face-glyph-metrics, sizeof(FT_Glyph_Metrics));
+if ( font-fake_bold )
+{
+/* fitting values to MS-Windows */
+strength = pFT_MulFix( ft_face-units_per_EM,
ft_face-size-metrics.y_scale ) / 42;
+if ( strength 64)
+{
+gmetrix.width+= strength;
+gmetrix.height += strength;
+gmetrix.horiBearingY += strength;
+gmetrix.horiAdvance += strength;
+}
+else if ( strength 77)
+{
+gmetrix.width+= 63;
+gmetrix.height += 63;
+gmetrix.horiBearingY += 63;
+gmetrix.horiAdvance += 63;
+}
+else
+{
+gmetrix.width+= strength;
+gmetrix.height += strength;
+gmetrix.horiBearingY += strength;
+}
This needs more investigation. I can't believe Windows uses this
algorithm...
Huw.
--
Huw Davies
[EMAIL PROTECTED]
Re: [PATCH 2/3] wined3d: Add ARB_texture_rectangle extension
Am Donnerstag 29 März 2007 14:09 schrieb Vitaly Budovski: Add support for ARB_texture_rectangle extension. --- dlls/wined3d/directx.c|3 +++ include/wine/wined3d_gl.h |9 + 2 files changed, 12 insertions(+), 0 deletions(-) There is also GL_NV_texture_rectangle. Is that one related? pgpq81iKJ2m0K.pgp Description: PGP signature
Re: Nine good SoC propsals!
*ulp* I knew I should of unsubscribed during the interim period, thanks for making me more worried =P On 3/29/07, Dan Kegel [EMAIL PROTECTED] wrote: On 3/28/07, Bryan DeGrendel [EMAIL PROTECTED] wrote: Do you have any idea how many will be accepted? Six, maybe? It's hard to say, they juggle the slots right up until the last moment.
Re: Wine Benchmarks and CAPS
On 3/29/07, Tom Spear [EMAIL PROTECTED] wrote: Hi Tom, thanks for the updates! I just wanted to ask about Aquamark. How come there isnt a test with that one? I use it more than I use 3dmark. Hi Tom, I will add Aquamark 3 to the next update, thanks for the suggestion. There is a good review of Aquamark 3 here : http://www.nvnews.net/previews/AquaMark3/index.shtml -- Thanks Tom
Re: [PATCH 2/3] wined3d: Add ARB_texture_rectangle extension
On 29.03.2007 16:02, Stefan Dösinger wrote: Am Donnerstag 29 März 2007 14:09 schrieb Vitaly Budovski: Add support for ARB_texture_rectangle extension. --- dlls/wined3d/directx.c|3 +++ include/wine/wined3d_gl.h |9 + 2 files changed, 12 insertions(+), 0 deletions(-) There is also GL_NV_texture_rectangle. Is that one related? I think they're the same. -f.r.
Re: [PATCH 3/3] wined3d: Correctly set conditional NPOT caps bit (try 2)
On 29/03/07, Vitaly Budovski [EMAIL PROTECTED] wrote: This patch sets the conditional NPOT bit only when required. If an implementation has full support for NPOT textures through the ARB_texture_non_power_of_two extension, then support for the subset of capabilities provided by the ARB_texture_rectangle extension is implied. Add additional check for the equivalent NV extension. --- Do you know what ARB_texture_rectangle is? It's not a subset of ARB_texture_non_power_of_two, and it doesn't correspond to WINED3DPTEXTURECAPS_NONPOW2CONDITIONAL in any way. Please read http://www.opengl.org/registry/specs/ARB/texture_rectangle.txt
Re: [PATCH 2/3] wined3d: Add NV/ARB_texture_rectangle extension (try 2)
On 29/03/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Donnerstag 29 März 2007 17:13 schrieb Vitaly Budovski: Add support for NV_texture_rectangle and ARB_texture_rectangle extensions. --- dlls/wined3d/directx.c|6 ++ include/wine/wined3d_gl.h | 19 +++ 2 files changed, 25 insertions(+), 0 deletions(-) Nothing really wrong with this patch, Except that it adds an extension that isn't actually being used, and probably won't be.
Re: [PATCH 2/3] wined3d: Add NV/ARB_texture_rectangle extension (try 2)
Am Donnerstag 29 März 2007 17:13 schrieb Vitaly Budovski: Add support for NV_texture_rectangle and ARB_texture_rectangle extensions. --- dlls/wined3d/directx.c|6 ++ include/wine/wined3d_gl.h | 19 +++ 2 files changed, 25 insertions(+), 0 deletions(-) Nothing really wrong with this patch, though I am concerned about patch 3. This patch is a dependency of patch 3, but there is nothing really wrong with adding the extensions.
Re: [PATCH 3/3] wined3d: Correctly set conditional NPOT caps bit
On 29/03/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Donnerstag 29 März 2007 14:09 schrieb Vitaly Budovski: This patch sets the conditional NPOT bit only when required. If an implementation has full support for NPOT textures through the ARB_texture_non_power_of_two extension, then support for the subset of capabilities provided by the ARB_texture_rectangle extension is implied. --- dlls/wined3d/directx.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) I am not sure if we shouldn't set NONPOWER2CONDITIONAL unconditionally if POW2 is set. WineD3D emulates np2 textures by using a texture of the next pow2size and adjusting the texture matrix accordingly. This doesn't work for shaders though, but mipmapping and other things are supported. That's not what NONPOWER2CONDITIONAL is for. The cap basically means that a card has broken ATI NPOT support.
Re: [PATCH 3/3] wined3d: Correctly set conditional NPOT caps bit
Am Donnerstag 29 März 2007 14:09 schrieb Vitaly Budovski: This patch sets the conditional NPOT bit only when required. If an implementation has full support for NPOT textures through the ARB_texture_non_power_of_two extension, then support for the subset of capabilities provided by the ARB_texture_rectangle extension is implied. --- dlls/wined3d/directx.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) I am not sure if we shouldn't set NONPOWER2CONDITIONAL unconditionally if POW2 is set. WineD3D emulates np2 textures by using a texture of the next pow2size and adjusting the texture matrix accordingly. This doesn't work for shaders though, but mipmapping and other things are supported. pgppKa3gNEaV8.pgp Description: PGP signature
Question about OpenAL
Is there any interest in adding OpenAL to Wine? I would imagine it's relatively simple to implement the OpenAL dll that would be a simple wrap around the Linux OpenAL library assuming they have the same functionality(from what I know of OpenAL, they should). It's not a very common library, but if we could implement it on top of the local implementation, that would mean that programs that use it would be using local devices without having to go through the DirectSound library. I'm not talking about using OpenAL as an audio driver, but an implementation of the OpenAL library for Wine that would use the local version of OpenAL. I tried looking around, and the only thing I found was talk about the OpenAL driver, and also brief requests for an OpenAL dll, but I didn't see anything official. Any thoughts on if this is something that would be beneficial to add?
Re: [PATCH 2/3] wined3d: Add ARB_texture_rectangle extension
On 29/03/07, Frank Richter [EMAIL PROTECTED] wrote: On 29.03.2007 16:02, Stefan Dösinger wrote: Am Donnerstag 29 März 2007 14:09 schrieb Vitaly Budovski: Add support for ARB_texture_rectangle extension. --- dlls/wined3d/directx.c|3 +++ include/wine/wined3d_gl.h |9 + 2 files changed, 12 insertions(+), 0 deletions(-) There is also GL_NV_texture_rectangle. Is that one related? I think they're the same. Pretty much, but the ARB version has GLSL interactions specified.
Re: [PATCH 2/3] wined3d: Add NV/ARB_texture_rectangle extension (try 2)
On 29/03/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Except that it adds an extension that isn't actually being used, and probably won't be. Well, we have other extensions which are unused and are in our header files(or at least were unused for a long time, like NV_texture_shader). Wasn't there the plan to write our own gl headers with all the extensions out there? I think the plan was to add the definitions for base GL 1.1 or so, so we wouldn't have to deal with different GL headers. That would mostly make it easier for developers not to forget adding definitions when using extension. I don't think the idea was to just add everything out there, just the ones we use. Our wined3d_gl.h could use some cleanup, but at least NV_texture_shader is an extension we might end up using anyway for fixed function env. bump mapping.
Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg + update Czech locales for Winecfg
On 29/03/07, Ivan Gyurdiev [EMAIL PROTECTED] wrote: Do you want to make it easy to configure GLSL, or make it easy to enable GLSL? In other words, can you enumerate the cases where one would disable GLSL? Should those be in a document somewhere on the wiki as blockers to 1.0 (since GLSL default was pointed out as a 1.0 requirement)? Do we expect this option to be around for a long time? I don't see consensus to add these options in the referenced thread - if more testing exposure is needed, why not just enable this by default? IMO the only reasons for having this option would be for specifically testing the ARB backend, or working around broken drivers. I don't think either warrants an option in winecfg. The video memory setting could be useful though, since I don't think we're going to solve that soon.
Re: Wine Benchmarks and CAPS
On Thu, Mar 29, 2007 at 02:26:58PM +0200, Frank Richter wrote: On 29.03.2007 09:41, Tom Wickline wrote: http://wiki.winehq.org/DirectX-Caps It would be nice if the visual hint could reflect that - this way a red background would be a clear signal that this needs work. I just highlighted the changes. Think of the color as being chosen by random :) . You are invited to change the colors so that better and worse are coded, but please either verify that for all highlighted ones or mark those that you checked or those that you didn't. Jan
Re: Question about OpenAL
Am Donnerstag 29 März 2007 17:38 schrieb Mike Schaadt: Is there any interest in adding OpenAL to Wine? I would imagine it's relatively simple to implement the OpenAL dll that would be a simple wrap around the Linux OpenAL library assuming they have the same functionality(from what I know of OpenAL, they should). Such a DLL was written already by nick burns, but not yet accepted into wine because it broke applications using openal and wasn't ready for prime time yet. Seach the wine-patches archives for openal thunk. I think there was consent that a thunk should go in, but a driver comparably to our alsa backend shouldn't. Some stuff google finds: Oldest version: http://www.winehq.org/pipermail/wine-devel/2006-November/052501.html My first mail with a simmilar suggestion: http://www.archivesat.com/Wine_Developers_list/thread2111847.htm Some more updated patch: http://www.winehq.org/pipermail/wine-patches/2006-November/033205.html The latest patch I could find: http://www.winehq.org/pipermail/wine-patches/2007-January/034454.html pgp9sDDXIjeQF.pgp Description: PGP signature
Re: Question about OpenAL
On Thu, Mar 29, 2007 at 10:38:26AM -0500, Mike Schaadt wrote: Is there any interest in adding OpenAL to Wine? I would imagine it's relatively simple to implement the OpenAL dll that would be a simple wrap around the Linux OpenAL library assuming they have the same functionality(from what I know of OpenAL, they should). There is interest and there was an implementation posted to this list (and/or possibly -patches) that worked fine for some people. But it seems for the time being it isn't further pursued by the author. Jan
Re: Question about OpenAL
Am Donnerstag, 29. März 2007 schrieb Mike Schaadt: Is there any interest in adding OpenAL to Wine? I would imagine it's relatively simple to implement the OpenAL dll that would be a simple wrap around the Linux OpenAL library assuming they have the same functionality(from what I know of OpenAL, they should). It's not a very common library, but if we could implement it on top of the local implementation, that would mean that programs that use it would be using local devices without having to go through the DirectSound library. I'm not talking about using OpenAL as an audio driver, but an implementation of the OpenAL library for Wine that would use the local version of OpenAL. I tried looking around, and the only thing I found was talk about the OpenAL driver, and also brief requests for an OpenAL dll, but I didn't see anything official. Any thoughts on if this is something that would be beneficial to add? See this link for to the associated bug: http://bugs.winehq.org/show_bug.cgi?id=7142 There is also a link to the discussion of a patch. I don't know how this progressed, though. --Dennis pgpAyDwX1SlsW.pgp Description: PGP signature
Re: [2/2] wined3d: Fix GLSL cnd instruction for INF and NAN arguments
Can you send me a patch??
- Original Message -
From: Fabian Bieler [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 29, 2007 1:00 PM
Subject: [2/2] wined3d: Fix GLSL cnd instruction for INF and NAN arguments
From 1bca82ab76f27dd0e636305da74ec428caf9a919 Mon Sep 17 00:00:00 2001
From: Fabian Bieler [EMAIL PROTECTED]
Date: Thu, 29 Mar 2007 19:59:11 +0200
Subject: [PATCH] wined3d: Fix GLSL cnd instruction for INF and NAN arguments
---
dlls/wined3d/glsl_shader.c | 37 +++--
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c
index 3d04f45..3ceb935 100644
--- a/dlls/wined3d/glsl_shader.c
+++ b/dlls/wined3d/glsl_shader.c
@@ -1156,26 +1156,35 @@ void shader_glsl_cnd(SHADER_OPCODE_ARG* arg) {
glsl_src_param_t src0_param;
glsl_src_param_t src1_param;
glsl_src_param_t src2_param;
-DWORD write_mask;
-size_t mask_size;
-
-write_mask = shader_glsl_append_dst(arg-buffer, arg);
+DWORD write_mask, cmp_channel = 0;
+unsigned int i, j;
if (shader-baseShader.hex_version WINED3DPS_VERSION(1, 4)) {
-mask_size = 1;
+write_mask = shader_glsl_append_dst(arg-buffer, arg);
shader_glsl_add_src_param(arg, arg-src[0], arg-src_addr[0],
WINED3DSP_WRITEMASK_0, src0_param);
-} else {
-mask_size = shader_glsl_get_write_mask_size(write_mask);
-shader_glsl_add_src_param(arg, arg-src[0], arg-src_addr[0],
write_mask, src0_param);
+shader_glsl_add_src_param(arg, arg-src[1], arg-src_addr[1],
write_mask, src1_param);
+shader_glsl_add_src_param(arg, arg-src[2], arg-src_addr[2],
write_mask, src2_param);
+shader_addline(arg-buffer, %s 0.5 ? %s : %s);\n,
+src0_param.param_str, src1_param.param_str,
src2_param.param_str);
+return;
}
+/* Cycle through all source0 channels */
+for (i=0; i4; i++) {
+write_mask = 0;
+/* Find the destination channels which use the current source0
channel */
+for (j=0; j4; j++) {
+if ( ((arg-src[0] (WINED3DSP_SWIZZLE_SHIFT + 2*j)) 0x3)
== i ) {
+write_mask |= WINED3DSP_WRITEMASK_0 j;
+cmp_channel = WINED3DSP_WRITEMASK_0 j;
+}
+}
+write_mask = shader_glsl_append_dst_ext(arg-buffer, arg, arg-dst
(~WINED3DSP_SWIZZLE_MASK | write_mask));
+if (!write_mask) continue;
-shader_glsl_add_src_param(arg, arg-src[1], arg-src_addr[1],
write_mask, src1_param);
-shader_glsl_add_src_param(arg, arg-src[2], arg-src_addr[2],
write_mask, src2_param);
+shader_glsl_add_src_param(arg, arg-src[0], arg-src_addr[0],
cmp_channel, src0_param);
+shader_glsl_add_src_param(arg, arg-src[1], arg-src_addr[1],
write_mask, src1_param);
+shader_glsl_add_src_param(arg, arg-src[2], arg-src_addr[2],
write_mask, src2_param);
-if (mask_size 1) {
-shader_addline(arg-buffer, mix(%s, %s, vec%d(lessThan(%s,
vec%d(0.5);\n,
-src2_param.param_str, src1_param.param_str, mask_size,
src0_param.param_str, mask_size);
-} else {
shader_addline(arg-buffer, %s 0.5 ? %s : %s);\n,
src0_param.param_str, src1_param.param_str,
src2_param.param_str);
}
--
1.4.4.1
Is Wine a platform for Codeweaver to make money?! Please help me understand.
First of all, let me say that I am not a developer. But I have been interested in Wine since early 2003. The thing that has always made me scratch my head is that the Windows software that motivates me to install Wine on my linux system (i.e. MS OFfice, etc.) has never worked with wine in a reliable manner. Meanwhile, Codeweaver has always had MS Office working on Wine. Now shouldn't getting the most common windows software working on Wine in an idiot-proof (meaning I can get it to work) manner be the highest priority for Wine developers? Instead, this is left to CodeWeavers and others. I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ? I just can't understand why the more common application are left to a commercial company. My conspiratorial side makes me want to think this is a conspiracy but I am sure there is valid technical and logistical reasons for it so I am asking you guys. Thanks. Sasan
re: Improvement of WSAIoctl
Hi Dan, I'm thrilled you're doing this. What's your software called? The software is called FuturERS. If you are interested on further info, you can look at http://www.futura4retail.com. But you can't do this: + * Copyright (C) the Wine project as there's no legal entity called the Wine project. You have to use your company's name, I think. (And be sure they've granted permission.) Or if you have the rights to what you do in your spare time, your own name is fine. I copied the header from another file in the include directory. I've done it in my spare time and I don't insist on any copyrights on this patch. So, I thought to copy this as it is, was a good idea. Cheers, Axel
Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg + update Czech locales for Winecfg
Am Mittwoch 28 März 2007 23:09 schrieb Vit Hrachovy: Hi Stephan, GLSL depends on Czech localization update. Should I split them into two separate patches with different numbers? Should I send them split in two different requests? Regards Send the localization update first, then GLSL. Number the patches, for example [1/2] winecfg: czech localization update [2/2] winecfg: add d3d options You can send them at once, but in different mails
Re: gdi32: Add failing metrics test for negative font widths
Felix Nawothnig [EMAIL PROTECTED] writes: Felix Nawothnig wrote: --- dlls/gdi32/tests/font.c | 37 + 1 files changed, 37 insertions(+), 0 deletions(-) Anything wrong with this patch? It fails here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c touch font.ok font.c:541: Tests skipped: Symbol is not installed so skipping this test font.c:784: Tests skipped: Arial is not installed font.c:1094: Tests skipped: Arial is not installed font.c:1228: Tests skipped: Arial Black is not installed font.c:1228: Tests skipped: Symbol is not installed font.c:1682: Tests skipped: Arial Black or Symbol/Wingdings is not installed font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1513: Test failed: Expected 0031, got 0002 font.c:1515: Test succeeded inside todo block: Expected , got font.c:1517: Test succeeded inside todo block: Expected 003d, got 003d font.c:1513: Test failed: Expected 004d, got 0001 font.c:1513: Test failed: Expected 000d, got 0001 font.c:1513: Test failed: Expected 001c, got 0001 font.c:1513: Test failed: Expected 0047, got 0002 make: *** [font.ok] Error 17 -- Alexandre Julliard [EMAIL PROTECTED]
Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.
Sasan Iman wrote: I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ? My guess: Wine is not a product so it's not targeted to anyone. It's a community project developed by volunteers - and the primary priority of those volunteers is to get Wine to run the applications they want to use. Since there are many nice free libre cross-platform alternatives to the MS office suite there is just not much incentive to get it to run or keep it running. Games OTOH... Felix
Re: Excluding a Windows version from the tests
Paul Vriens [EMAIL PROTECTED] writes: But in this case we're dealing with win98 which new apps will not support anymore! Of course the alternative is to simply stop worrying about test failures on win98... -- Alexandre Julliard [EMAIL PROTECTED]
Re: extracting info from a minidump via winedbg
Dennis Schridde a écrit : Hello Wine users! I've got a minidump from a (real) Windows user of our game and would like to extract information from it using winedbg. The information winedbg gives me by default, is this: WineDbg starting on minidump on pid 068c warzone2100.exe was running on #1 Intel ???-0.521 CPU on Windows XP (2600) Register dump: CS:001b SS:0023 DS:0023 ES:0023 FS:003b GS: EIP:0051008b ESP:0022f844 EBP:0022f858 EFLAGS:00010a87( - 00 ROISP1C) EAX:c7b054d8 EBX:19ff502e ECX:0040 EDX:000f ESI:02010101 EDI: Stack dump: 0x0022f844: 3f80 0x0022f854: 0022f8c8 0050e796 19ff502e 0x0022f864: 3f80 0x0022f874: ff4a4a4a 0x0022f884: 0005 02010101 0x0022f894: 0022f8c8 Backtrace: =1 0x0051008b (0x0022f858) 2 0x0050e796 (0x0022f8c8) 3 0x00410c3b (0x0022f948) 4 0x0041172d (0x0022f9c8) 5 0x004b2272 (0x0022f9d8) 6 0x004aa97b (0x0022f9f8) 7 0x004b615a (0x0022fab8) 8 0x004b663f (0x0022fad8) 9 0x004b67e1 (0x0022faf8) 10 0x0041e39e (0x0022fb28) 11 0x00459d3e (0x0022fb58) 12 0x0045b2ee (0x0022fca8) 13 0x0055e77b (0x0022fcf8) 14 0x0055e932 (0x0022fef8) 15 0x0055e483 (0x0022fff0) 16 0x (0x) WineDbg starting on pid 068c Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles. My questions are: - Why doesn't winedbg extract the sourcecode locations itself? because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable - Why doesn't winedbg show me the other information included in the minidump, like the loaded modules, commandline options or version information? 'info share' should do part of it... winedbg doesn't show the command line info nor options other thing you can do is to use winedump (man winedump) - How can I get the parameters to the last called function(s)? see above for debug info A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Excluding a Windows version from the tests
Alexandre Julliard wrote: Paul Vriens [EMAIL PROTECTED] writes: But in this case we're dealing with win98 which new apps will not support anymore! Of course the alternative is to simply stop worrying about test failures on win98... I agree with that one. So if we only have crashes on win9x we don't care. If we can avoid crashes/failures on win9x (by skip or other means) we don't run them on win9x. And if they crash on something higher then win9x we disable them totally. Does that make sense? Cheers, Paul.
Re: Excluding a Windows version from the tests
Paul Vriens [EMAIL PROTECTED] writes: So if we only have crashes on win9x we don't care. If we can avoid crashes/failures on win9x (by skip or other means) we don't run them on win9x. And if they crash on something higher then win9x we disable them totally. Does that make sense? Sure; the thing we want to avoid is version checks in tests, because then things don't get tested on Wine when the version is changed. But as long as win98 is detected by its missing features then skipping things is fine. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Excluding a Windows version from the tests
Sure; the thing we want to avoid is version checks in tests, because then things don't get tested on Wine when the version is changed. But as long as win98 is detected by its missing features then skipping things is fine. Shouldn't then the wine code do a version check too and behave differently if the winver is set to win98? pgpADCpADxoNk.pgp Description: PGP signature
Re: extracting info from a minidump via winedbg
Am Donnerstag, 29. März 2007 schrieb Eric Pouech: Dennis Schridde a écrit : Hello Wine users! I've got a minidump from a (real) Windows user of our game and would like to extract information from it using winedbg. The information winedbg gives me by default, is this: [...] Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles. My questions are: - Why doesn't winedbg extract the sourcecode locations itself? because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable Maybe I am just doing it wrong, but _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp doesn't change anything... (Even supplying the full path doesn't.) The exe (not all dlls, because I don't have a copy of the user's system) is of course in the working directory. - Why doesn't winedbg show me the other information included in the minidump, like the loaded modules, commandline options or version information? 'info share' should do part of it... winedbg doesn't show the command line info nor options That only shows me the memory ranges of some modules. The minidump includes more info, like the paths to dlls and similar. I am not sure whether it includes version information, but it certainly contains the commandline used to start the app. other thing you can do is to use winedump (man winedump) How do I do this? And what will it provide? I tried winedump -G warzone2100.exe but I have no idea what I shall do with that tremedously long and cryptic list. - How can I get the parameters to the last called function(s)? see above for debug info If the general debug info worked, that would also show me the function parameters? --Dennis pgpwzVtrDvMPT.pgp Description: PGP signature
Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.
On 3/28/07, Sasan Iman [EMAIL PROTECTED] wrote: I know that if you fiddle around with the stock release long enough you can get MS Office working on Wine as I have on a number of occasions, but shouldn't making this work for everyone be the highest priority for getting Wine to be adopted more widely?! Or is Wine more targeted to gamers which is mostly what I read about on WineHQ? CodeWeavers isn't Evil. I think everyone involved in Wine would agree with that. There is absolutely no question that without their involvement several core pieces of Wine probably wouldn't exist. For example, MSI, COM, MSHTML, etc. We'd probably still have a good Direct3D implementation though because Stefan is sick like that. As far as getting Office to work, you and everyone else are more than welcome to work on that. We even have a free graphical regression testing system (cxtest) that CodeWeavers developed that could help you maintain that. Personally, I'd be ecstatic if you'd be willing to work on that. Finally, I wouldn't exactly say Wine is targeted at gamers any more than anything else. -Brian
Re: Excluding a Windows version from the tests
Alexandre Julliard wrote: Paul Vriens [EMAIL PROTECTED] writes: yesterday a patch of mine was committed to test more profile stuff from kernel32. When I have a look now at test.winehq.org I see that some test(s) crash on win98 but not on others. Although I could use a if(0) construction (as is done in several other tests), I'm wondering if we should just not run specific tests on specific Windows versions. It's a shame that one OS version blocks the running of several other tests. In general, if a feature crashes on Windows it's unlikely that an app would depend on it, so it's not a problem to disable or remove the test. Unfortunately, these days apps are coded for NT only and I would expect new applications to only be supported on XP upwards. However, I guess until we see a real application that confirms this, it is all hand-waving theory. -- Rob Shearman
Re: Declare another bunch of raw input structures and constants
Kovács András [EMAIL PROTECTED] wrote:
+typedef struct tagRAWMOUSE {
+ USHORTusFlags;
+ union {
+ ULONGulButtons;
+ struct {
+ USHORT usButtonFlags;
+ USHORT usButtonData;
+ } s;
+ } u;
You have to use DUMMYSTRUCTNAME and DUMMYUNIONNAME instead of s and u.
Also please use 4 spaces indents instead of strange mix of 2 + 7 + 2.
--
Dmitry.
