Wine Benchmarks and CAPS

2007-03-29 Thread Tom Wickline

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

2007-03-29 Thread Dennis Schridde
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?

2007-03-29 Thread Shachar Shemesh
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

2007-03-29 Thread Dmitry Timoshkov

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)

2007-03-29 Thread Vit Hrachovy
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

2007-03-29 Thread Frank Richter
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

2007-03-29 Thread Tom Wickline

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!

2007-03-29 Thread Dan Kegel

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

2007-03-29 Thread Byeong-Sik Jeon
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)

2007-03-29 Thread Tom Spear

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

2007-03-29 Thread Tom Spear

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.

2007-03-29 Thread Huw Davies
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

2007-03-29 Thread Stefan Dösinger
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!

2007-03-29 Thread John Smith

*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

2007-03-29 Thread Tom Wickline

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

2007-03-29 Thread Frank Richter
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)

2007-03-29 Thread H. Verbeet

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)

2007-03-29 Thread H. Verbeet

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)

2007-03-29 Thread Stefan Dösinger
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

2007-03-29 Thread H. Verbeet

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

2007-03-29 Thread Stefan Dösinger
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

2007-03-29 Thread 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?




Re: [PATCH 2/3] wined3d: Add ARB_texture_rectangle extension

2007-03-29 Thread H. Verbeet

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)

2007-03-29 Thread H. Verbeet

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

2007-03-29 Thread H. Verbeet

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

2007-03-29 Thread Jan Zerebecki
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

2007-03-29 Thread Stefan Dösinger
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

2007-03-29 Thread Jan Zerebecki
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

2007-03-29 Thread Dennis Schridde
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

2007-03-29 Thread Marty Schmidt

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.

2007-03-29 Thread Sasan Iman


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

2007-03-29 Thread Axel Petzold
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

2007-03-29 Thread Stefan Dösinger
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

2007-03-29 Thread Alexandre Julliard
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.

2007-03-29 Thread Felix Nawothnig

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

2007-03-29 Thread Alexandre Julliard
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

2007-03-29 Thread 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:

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

2007-03-29 Thread Paul Vriens

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

2007-03-29 Thread Alexandre Julliard
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

2007-03-29 Thread Stefan Dösinger
 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

2007-03-29 Thread Dennis Schridde
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.

2007-03-29 Thread Brian Vincent

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

2007-03-29 Thread Robert Shearman

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

2007-03-29 Thread Dmitry Timoshkov

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.