Re: World of Warcraft Progress

[Tomas Carnecky]

darckness wrote:
> First off, the D3D (DX9) runs MUCH better (faster and more smoothly)
> than the OGL mode.  Big kudos to you guys; last time I played, the D3D
> mode was completely unusable because there was no D3D support in wine.
> Very impressive.
> 

The GLX_ARB_vertex_buffer_object is described on the AppDb page for
World of Warcraft and has now been known for quite some time already. If
you apply the hack, you'll see that running in OGL and D3D mode won't
make a difference in the framerate.

I also noticed the modeswitch crash, but I didn't investigate it. I
always edit the Config.wtf file if I need to switch modes (or graphics
settings). But I'll look into if if nobody else will ;)

tom

Re: World of Warcraft Progress

[Stefan Dösinger]

Am 02.01.2007 um 09:51 schrieb darckness:

First off, the D3D (DX9) runs MUCH better (faster and more smoothly)
than the OGL mode.  Big kudos to you guys; last time I played, the D3D
mode was completely unusable because there was no D3D support in wine.
Very impressive.

Nice :-)

The OGL performance isn't bad by any means, but it isn't great either.
I was running some traces as I played, but nothing in particular  
seemed

to be the culprit in terms of choppiness, so it's possible that it
could just be my system.  I'll write back soon when I have more
conclusive evidence.  Additionally, OGL mode crashes any time I  
attempt

to change a video setting, something that does not happen in D3D mode.
The d3d renderer of wow is said to be much better than the ogl  
renderer, even under windows. And I think there is a bug in wow which  
causes performance issues with the GL_ARB_vertex_buffer_object  
extension, you can bypass this by blacklisting it with a registry key.



I guess my only real complaint at this point, since the D3D mode woks
so well, is that the X cursor still shows up in the game window along
with the game cursor.  I vaguely recall having this problem a long  
long
time ago in OGL mode, but I can't remember exactly what caused it  
or how

it was fixed.  Anyone have a better memory than I do?
Yes, that is a known problem. We haven't figured out yet when the  
cursor is shown or hidden exactly, but for wow it seems that we have  
to hide the cursor on the IDirect3DDevice9::SetCursorProperties call  
which sets a d3d cursor. Unfortunately wow only calls that if hw  
cursors are enabled, but wine doesn't do that yet. Henri Verbeet has  
some patches needed for that, but they are pretty huge and affect the  
core cursor handling down to wineserver.

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Tim Kosse]

Mike Hearn wrote:
> Well if you can get the email address of a WoW developer then maybe we
> can track down where the problem in WoW is and work with them to fix
> it.

You might have some luck contacting Sam Lantinga. He is the creator and
current maintainer of the SDL library and works for Blizzard as WoW
developer and, as far as I know, responsible for UI and scripting.
According to his personal homepage, his mail address is slouken at
devolution.com. In the SDL source I've also found slouken at libsdl.org
Due to his interest in free open source software, he might be able to
refer you further.

Regards,
Tim

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Raphael]

On Tuesday 30 May 2006 16:37, Mike Hearn wrote:
> > Interesting.. if MacOSX has a similar memory layout as linux, maybe we
> > could get Blizzard to include a workaround that is only active when it
> > sees that it's running under wine/cedega.
>
> Well if you can get the email address of a WoW developer then maybe we
> can track down where the problem in WoW is and work with them to fix
> it. I don't think Wine-specific workarounds make any sense: the
> address space layout when not requesting a specific address is not
> guaranteed. Vista already includes ASLR which is likely to break such
> software. It will need to be fixed sooner or later, might as well be
> sooner :)

Yes ia agree,
maybe asking them to try it on vista may help :)

Regards,
Raphael



pgpWozQVhV1wq.pgp
Description: PGP signature

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Mike Hearn]

WoW Has a all chain of checks that go up all the way to rootkit reveler
to make sure the user is not aided by an automatic system, Given the
player an advantage  other players do not have. The Memory layout checks
is for making sure the program is not loaded by a Debugger of sorts. Or
that core Dll(s) where not replaced/hooked/emulated.


Yes, it could be the Warden, but I doubt it. If the Warden is
triggered you get banned from the game yet this bug surfaces not as
spurious bannings but some kind of mouse control/targetting problem.
To be honest I'm amazed we haven't seen any reports of Wine triggering
anti-cheat systems like Blizzards before, and I'm sure we'd hear about
it if it did 


It is possible that approaching Blizzard might be helpful. Is WoW
supported by Cedega?


Yes, using a slightly more generic version of the same memory layout hack.

thanks -mike

Re: World of Warcraft (WoW) patch/more address space layout stuff

[n0dalus]

On 5/30/06, Mike Hearn <[EMAIL PROTECTED]> wrote:


This has been discussed previously. It looks likely that to fix this so
WoW works out of the box requires extensive and intricate changes to the
core of either Wine or the kernel to provide a more accurate match to the
NT memory layout model.

I rate the chances of this happening anytime soon as being low. It's not
that people don't care, it's more that there are no developers with the
time/motivation/skill hanging around who want to work on it, it seems.


It would be really great if someone could document the patch and
explain what exactly is stopping WoW from working (as well as which
changes would cause problems for other programs). I think there would
be more chance of getting developers working on the problem if the
problems involved were clearer and easier to see/understand.


Alternatively there could be (should be!) pre-built versions of Wine that
run for all users customized for WoW specifically.


Given the amount of users who use wine to run WoW, would it be
possible to have the patch included with a compile-time option? Would
it even be possible to make the patch a runtime feature?

n0dalus.

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Boaz Harrosh]

Mike Hearn wrote:

It's a bug in WoW itself, it relies upon the exact way NT maps memory
which is different to how Linux does it. I guess they are storing
information in the high bits of a pointer somewhere or some similar
trick.

One can never be sure, but I suspect this is not do to a bug but to a 
fixture.
WoW Has a all chain of checks that go up all the way to rootkit reveler 
to make sure the user is not aided by an automatic system, Given the 
player an advantage  other players do not have. The Memory layout checks 
is for making sure the program is not loaded by a Debugger of sorts. Or 
that core Dll(s) where not replaced/hooked/emulated.


It is possible that approaching Blizzard might be helpful. Is WoW 
supported by Cedega?


Free Life
Boaz

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Mike Hearn]

Interesting.. if MacOSX has a similar memory layout as linux, maybe we
could get Blizzard to include a workaround that is only active when it
sees that it's running under wine/cedega.


Well if you can get the email address of a WoW developer then maybe we
can track down where the problem in WoW is and work with them to fix
it. I don't think Wine-specific workarounds make any sense: the
address space layout when not requesting a specific address is not
guaranteed. Vista already includes ASLR which is likely to break such
software. It will need to be fixed sooner or later, might as well be
sooner :)

thanks -mike

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Mike Hearn]

On Tue, 30 May 2006 16:08:42 +0200, Tomas Carnecky wrote:
> Since WoW also runs on MacOSX, how does the memory layout on MacOSX
> differ from NT and Linux? 

I have no idea, but the MacOS and Windows versions of WoW will be
different; probably the bug is only in the Windows specific parts of the
code.

> Maybe that's the reason why they won't do a
> Linux port: because they rely on a certain memory layout and the code
> can't be changed that easily.

I suspect the real reason is the usual one: concern over profitability.
They'd need to have a full time Linux dev team as well, because the code
constantly evolves. The problems Second Life is having shows what happens
when you don't do that :/

thanks -mike

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Tomas Carnecky]

[EMAIL PROTECTED] wrote:
> No, they have added this regressions after a little patch-set. 
> So they can fix it.
> And as we can't download a playable demo ...
> 

Interesting.. if MacOSX has a similar memory layout as linux, maybe we
could get Blizzard to include a workaround that is only active when it
sees that it's running under wine/cedega.

tom

Re: Re: World of Warcraft (WoW) patch/more address space layout stuff

[fenix]

Message d'origine
>Date: Tue, 30 May 2006 16:08:42 +0200
>De: Tomas Carnecky <[EMAIL PROTECTED]>
>A: Mike Hearn <[EMAIL PROTECTED]>
>Copie à: wine-devel@winehq.com, n0dalus <[EMAIL PROTECTED]>
>Sujet: Re: World of Warcraft (WoW) patch/more address space layout stuff
>
>Mike Hearn wrote:
>> It's a bug in WoW itself, it relies upon the exact way NT maps memory
>> which is different to how Linux does it. I guess they are storing
>> information in the high bits of a pointer somewhere or some similar
>> trick.
>> 
>
>Since WoW also runs on MacOSX, how does the memory layout on MacOSX
>differ from NT and Linux? Maybe that's the reason why they won't do a
>Linux port: because they rely on a certain memory layout and the code
>can't be changed that easily.

No, they have added this regressions after a little patch-set. 
So they can fix it.
And as we can't download a playable demo ...

Regards,
Raphael

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Tomas Carnecky]

Mike Hearn wrote:
> It's a bug in WoW itself, it relies upon the exact way NT maps memory
> which is different to how Linux does it. I guess they are storing
> information in the high bits of a pointer somewhere or some similar
> trick.
> 

Since WoW also runs on MacOSX, how does the memory layout on MacOSX
differ from NT and Linux? Maybe that's the reason why they won't do a
Linux port: because they rely on a certain memory layout and the code
can't be changed that easily.

tom

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Mike Hearn]

On 5/30/06, n0dalus <[EMAIL PROTECTED]> wrote:

It would be really great if someone could document the patch and
explain what exactly is stopping WoW from working (as well as which
changes would cause problems for other programs).


It's a bug in WoW itself, it relies upon the exact way NT maps memory
which is different to how Linux does it. I guess they are storing
information in the high bits of a pointer somewhere or some similar
trick.

The patch is a hack that makes Wine follow the Windows method -
unfortunately it will happily force an allocation to an area that is
already allocated. Right now it relies on pure luck to avoid blasting
a previous allocation. Expect random undebuggable failures with this
technique.


I think there would be more chance of getting developers working on the problem 
if the
problems involved were clearer and easier to see/understand.


The real issue is that it seems not many Wine developers play WoW themselves ;)


Given the amount of users who use wine to run WoW, would it be
possible to have the patch included with a compile-time option? Would
it even be possible to make the patch a runtime feature?


Doubtful. You'd have to ask Alexandre. He may know of a different
solution also. Wine has a policy of not accepting application specific
hacks though there are a few generic hacks in there.

You'd be better off IMHO by preparing your own Wine binary install
that is specific to WoW itself.

thanks -mike

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Mike Hearn]

On Mon, 22 May 2006 19:18:07 +0100, Nick Law wrote:
> Below is an email regarding this partiicular problem, I would be 
> grateful for any comments that I can pass back to Jan Riewe. Thanks

Hi Nick,

This has been discussed previously. It looks likely that to fix this so
WoW works out of the box requires extensive and intricate changes to the
core of either Wine or the kernel to provide a more accurate match to the
NT memory layout model.

I rate the chances of this happening anytime soon as being low. It's not
that people don't care, it's more that there are no developers with the
time/motivation/skill hanging around who want to work on it, it seems.

It'd be better to get the bug in WoW fixed, whatever that is. I do not
know how you might contact Blizzard.

Alternatively there could be (should be!) pre-built versions of Wine that
run for all users customized for WoW specifically.

thanks -mike

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Mike Hearn]

Well ever since me, Mike and Alexandre did the preloader work a few
years ago Wine itself has been execshield resistant, but the apps
themselves may not be (my guess is that this is why Microsoft have not
implemented it themselves ... that and they appear to be scared of
their own dynamic linker code).

We could add the syscall to switch off execshield and get a legacy VMA
layout to Wine itself, but Alexandre doesn't like it as the "ABI
personality" syscall basically has no well defined behaviour at all
and is used for all kinds of things, some of which may be useful. If
there was an execshield/VMA randomization specific way to disable
things on a per-process basis that'd be best. Otherwise I guess adding
the personality syscall to the WoW patch wouldn't hurt, as it's
already custom.

thanks -mike

On 5/2/06, n0dalus <[EMAIL PROTECTED]> wrote:

On 5/1/06, Mike Hearn <[EMAIL PROTECTED]> wrote:
>
> Seems the WoW appdb page (apart from being a great example of what an
> appdb entry should be like!) recommends users patch their Wine to run WoW
> properly.
>

The patch mentioned particularly causes problems on systems like
Fedora with randomized prelinking and exec-shield.

On FC5 it took me some time to get the patched version to run and used:
setarch i386 -L wine WoW.exe -opengl

This apparently enables support for a legacy address layout. Does
anyone know how this would allow it to run?

Just curious,
n0dalus.

Re: World of Warcraft (WoW) patch/more address space layout stuff

[n0dalus]

On 5/1/06, Mike Hearn <[EMAIL PROTECTED]> wrote:


Seems the WoW appdb page (apart from being a great example of what an
appdb entry should be like!) recommends users patch their Wine to run WoW
properly.



The patch mentioned particularly causes problems on systems like
Fedora with randomized prelinking and exec-shield.

On FC5 it took me some time to get the patched version to run and used:
setarch i386 -L wine WoW.exe -opengl

This apparently enables support for a legacy address layout. Does
anyone know how this would allow it to run?

Just curious,
n0dalus.

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Troy Rollo]

On Monday 01 May 2006 20:59, Mike Hearn wrote:

>  * Is this working around a bug in WoW? (my guess - almost certainly yes)

Perhaps, but there are other problems with the Linux kernel not using the 
entire address space.

>  * What exactly is it doing?! No comments! It seems to be forcing the
>kernel to follow an NT allocation pattern.

Sort of. NT's allocation pattern is somewhat erratic. I started looking into 
it last weekend. The allocation pattern varies depending on the calls you 
make (GlobalAlloc and VirtualAlloc use address space in a different order, I 
have not checked file mapping yet).

However NT will start allocating at around 0x0010, whereas Wine starts 
allocating in the 0x6600 range, so this patch makes initial allocations 
appear much closer to the NT range than raw Wine.

The other problem is that the Linux kernel will not map anything below 
0x4000 unless an mmap call explicitly requests such an address, so after 
we lock out 0x8000-0xe000 we are left with 1GB of usable address 
space for everything (Wine, native libraries, data) unless we decide 
ourselves where mappings without a start address should begin. The problem 
with that is that something else may have mapped stuff where we plan to map 
something.

>  * How should we fix this properly? Forcing the rtld to map every DSO in a
>predictable manner seems awfully hard work. Likewise, kernel patches
>would kind of suck ...Is this approach of a new preloader
>region and then doing manual mmap management going to work?

Mapping of DSOs is not the immediate problem, although it would be nice if we 
could force all native shared libraries above 0x8000 (and above 
0xc000 on architectures where address space above there is available) so 
that Windows apps have the largest possible address space available to them.

The solution is that we need to know about all memory allocations, which means 
hooking into mmap and related calls in libc and making the system call 
ourselves so that we have a record of "all" memory mappings other than those 
made by libraries that make their system calls directly (hopefully the 
intersection of this set with the set of libraries we use is empty). If we 
record the mappings, then ntdll could make the decision on where to map 
things based on Windows allocation patterns and knowledge of allocated space. 
If the allocation fails because something is mapped there already we would 
display a FIXME and then use a search algorithm to identify the allocated 
block (or grovel at /proc, but Alexandre has indicated before he prefers not 
to do that).

-- 
Troy Rollo - [EMAIL PROTECTED]

Re: World of Warcraft (WoW) patch/more address space layout stuff

[Tomas Carnecky]

Mike Hearn wrote:
> (yeah i'm bored :/)
> 
> Seems the WoW appdb page (apart from being a great example of what an
> appdb entry should be like!) recommends users patch their Wine to run WoW
> properly.
> 
> The patch is this one, which I am SURE we discussed before but I can't
> find the thread! So my questions are:
> 
>  * Is this working around a bug in WoW? (my guess - almost certainly yes)
> 

Speaking from my own experience with WoW bugs and Blizzard: Unless the
bug affects Windows or MacOS users and you can prove and show the exact
location of the bug (which functions are called, which arguments passed
etc.) Blizzard has no interest in fixing the bug whatsoever.

To prove the 'targeting circle' bug was easy, WoW passed a negative
value to an OpenGL function and the bug affected the game on all
platforms when running in OpenGL mode (and thus all MacOS users). And
yet Blizzard postponed the fix to the next major patch release (with at
least two minor releases in between!), even though the patch probably
was a one-liner.

I think Blizzard should test WoW under wine or cedega because I believe
there are many bugs that are hard to track down and it would be easier
to find them when running under another memory layout. I don't think
they'll ever to that.

Hell, the guy at Blizzard didn't even want to give credit to the
OpenSource community for finding that bug. And frankly, playing without
the targeting circles was a major pain and I think many people were
happy to see that bug fixed.


tom

Re: World of Warcraft 0.10 Public Test Realm (PTR)

[Tomas Carnecky]

Tomas Carnecky wrote:
> so.. I know where the problem is.. WoW loads its own Survey.dll which
> requires ddraw.dll, ddraw initializes itself and during that it creates
> a drawable and a context and calls glXMakeCurrent(). After some tests
> WoW unloads ddraw.dll but someone (ddraw, wine or WoW) fails to activate
> the old drawable and context, eg. call glXMakeCurrent() with the real
> window and rendering context.
> 
> a trace with +x11drv,+x11settings,+ddraw,+loaddll is in the attachment..
> 
> in a full trace with +opengl,+ddraw,+loaddll I can see that there is no
> wglMakeCurrent call after the ddraw dll is unloaded
> 

for those who can't wait to login into the PTR, here is a little patch
that disables opengl support in ddraw, so ddraw won't call
glXMakeCurrent(). It's a really ugly solution, but at least now we can
try to login into the PTR.

The better solution would be to save the old drawable and context and
reactivate it after ddraw initilizes opengl. Or whatever the ddraw
author comes up with :-)

tom
diff --git a/dlls/ddraw/main.c b/dlls/ddraw/main.c
index d9abebe..8212c38 100644
--- a/dlls/ddraw/main.c
+++ b/dlls/ddraw/main.c
@@ -91,6 +91,8 @@ static BOOL DDRAW_bind_to_opengl( void )
 {
 const char *glname = SONAME_LIBGL;
 
+return FALSE;
+
 gl_handle = wine_dlopen(glname, RTLD_NOW, NULL, 0);
 if (!gl_handle) {
 WARN("Wine cannot find the OpenGL graphics library (%s).\n",glname);

Re: World of Warcraft 0.10 Public Test Realm (PTR)

[Tomas Carnecky]

so.. I know where the problem is.. WoW loads its own Survey.dll which
requires ddraw.dll, ddraw initializes itself and during that it creates
a drawable and a context and calls glXMakeCurrent(). After some tests
WoW unloads ddraw.dll but someone (ddraw, wine or WoW) fails to activate
the old drawable and context, eg. call glXMakeCurrent() with the real
window and rendering context.

a trace with +x11drv,+x11settings,+ddraw,+loaddll is in the attachment..

in a full trace with +opengl,+ddraw,+loaddll I can see that there is no
wglMakeCurrent call after the ddraw dll is unloaded

tom
trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin
trace:loaddll:load_native_dll  Loaded module 
L"Z:\\games\\World.of.Warcraft\\WoWTest\\WoW.exe" : native
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\msvcrt.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\advapi32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\gdi32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\user32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\comctl32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\iphlpapi.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\rpcrt4.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\ole32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\shlwapi.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\shell32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\ws2_32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\wsock32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\opengl32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\imm32.dll" : builtin
trace:loaddll:load_native_dll  Loaded module 
L"Z:\\games\\World.of.Warcraft\\WoWTest\\DivxDecoder.dll" : native
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\winmm.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\msacm32.dll" : builtin
trace:loaddll:load_native_dll  Loaded module 
L"Z:\\games\\World.of.Warcraft\\WoWTest\\fmod.dll" : native
trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\mpr.dll" 
: builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\wininet.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\winex11.drv" : builtin
trace:x11settings:X11DRV_Settings_SetHandlers Resolution settings now handled 
by: NoRes
trace:x11settings:X11DRV_Settings_SetHandlers Initialized new display modes 
array
trace:x11settings:X11DRV_Settings_AddOneMode initialized mode 0: 1280x1024x32 
@0 Hz (NoRes)
trace:x11drv:X11DRV_XF86DGA2_Init 
trace:x11drv:X11DRV_SetupXIM X display of IM = 0x7c0630e0
trace:x11drv:X11DRV_SetupXIM Using C locale of Input Method
trace:x11drv:X11DRV_SetupXIM ximStyles->count_styles = 2
trace:x11drv:X11DRV_SetupXIM ximStyles[0] = XIMPreeditNone 
trace:x11drv:X11DRV_SetupXIM ximStyles[1] = XIMPreeditNothing 
trace:x11drv:X11DRV_SetupXIM Setting Style: ximStyleRoot = STYLE_ROOT
trace:x11drv:X11DRV_SetupXIM No callback style avalable
trace:x11drv:X11DRV_CreateBitmap (0x1a4) 32x32 1 bpp
trace:x11drv:X11DRV_CreateBitmap (0x1a8) 32x32 1 bpp
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a8, buffer=0x7fd2b944, count=0x80)
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a4, buffer=0x7fd2b9c4, count=0x80)
trace:x11drv:X11DRV_CreateBitmap (0x1ac) 32x32 1 bpp
trace:x11drv:X11DRV_CreateBitmap (0x1b0) 32x32 1 bpp
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1b0, buffer=0x7fd2bc14, count=0x80)
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1ac, buffer=0x7fd2bc94, count=0x80)
trace:x11drv:X11DRV_CreateBitmap (0x1c0) 16x16 24 bpp
trace:x11drv:X11DRV_CreateBitmap (0x1c4) 16x16 1 bpp
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c4, buffer=0x7fd2c344, count=0x20)
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c0, buffer=0x7fd2c364, count=0x300)
trace:x11drv:X11DRV_CreateBitmap (0x1c8) 16x16 24 bpp
trace:x11drv:X11DRV_CreateBitmap (0x1cc) 16x16 1 bpp
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1cc, buffer=0x7fd2c68c, count=0x20)
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c8, buffer=0x7fd2c6ac, count=0x300)
trace:x11drv:X11DRV_CreateBitmap (0x1d0) 16x16 24 bpp
trace:x11drv:X11DRV_CreateBitmap (0x1d4) 16x16 1 bpp
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d4, buffer=0x7fd2c9d4, count=0x20)
trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d0, buffer=0x7fd2c9f4, count=0x300)
trace:loaddll:load_builtin_dll Loaded module 
L"c:\\windows\\system32\\uxtheme.dll" : builtin
trace:x11drv:X11DRV_CreateBitmap (0x210) 512x16 1 bpp
trace:x11drv:X11DRV_CreateBitmap (0x248) 1024x32 1 bpp
trace:x1

Re: World of Warcraft 0.10 Public Test Realm (PTR)

[Tomas Carnecky]

Tomas Carnecky wrote:
> At a certain point the screen just turns black, it's always at the same
> point, and when looking through the +x11drv trace I can see these
> messages at that point:
> 
> trace:x11drv:X11DRV_DCICommand (20,(12,2079885668,543712117),(nil))
> trace:x11drv:X11DRV_DCICommand (20,(13,1792,543712117),0x7bf88d40)
> trace:x11drv:X11DRV_DCICommand (20,(11,1792,543712117),0x7bf88d60)
> trace:x11drv:X11DRV_DCICommand (20,(10,1792,543712117),0x7bf88ea8)
> 
> also, these messages don't appear in version 1.9.4 (which is the 'live'
> version). So I suspect that Blizzard added something related to this
> function to the 0.10 version which breaks something.
> 
> When the screen turns black, its just the screen, everything else works,
> keyboard for sure, I can press 'Esc' to get out of the game, not sure
> about the mouse though..
> 

It seems that Blizzard added DDraw HAL.. right after these CDICommand
calls I see:

trace:x11settings:X11DRV_Settings_CreateDriver Setting up display
settings for DDRAW (NoRes)
trace:x11drv:X11DRV_DDHAL_SwitchMode (0,(nil),(nil))

which changes the display setting, but I disabled xvidmode and xrandr so
this really shouldn't do anything.

also, it seems like WoW draws to a completely different buffer after
that because I see two different pictures changing, like the application
would call SwapBuffers() on two buffer that are not updated.. like WoW
would set up a new drawable but not switch to it..

tom

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Eddahbi Karim]

Mike Hearn  codeweavers.com> writes:

> 
> On Wed, 12 Oct 2005 21:16:05 +, Eddahbi Karim wrote:
> > Now the mouse problem comes back but the workarounds don't work this
> > time. It's not a regression, it's a bug enhancement.
> > 
> > The old workaround for WineX still work according to gentoo-forums [2].
> 
> It seems Warcraft relies upon NULL-addressed VirtualAlloc starting
> allocation from above a certain range - possibly they're pulling some
> silly bit-twiddling hack or optimisation. The Cedega patch linked to on
> the forums basically hints to mmap that it should allocate at a fixed
> address in this case:
> 
>   http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html
> 
> Which for WoW they seem to set this hint to 256mb - is there some aspect
> of the NT kernel we're not correctly implementing here? Does Windows
> always allocate from 256mb upwards? 

The weird thing here, IMHO, is that the old workaround like switching to 2.6.12
kernels (which did the trick for me), using some "hacked" preloaders (which
didn't do the trick for me) and all [1] don't work this time.

Only the Cedega fix *seems* to work (According to *one* post on the gentoo forum
[2])

If you want some debugging informations, just give me the way to look for them
and I'll give them.

> thanks -mike
> 

--
Notes :

[1] http://forums.gentoo.org/viewtopic-t-390127.html
[2] http://forums.gentoo.org/viewtopic-p-2794128.html#2794128

-- 
Eddahbi Karim <[EMAIL PROTECTED]>
Freelance

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Christoph Rudorff]

Mike Hearn schrieb:
> On Wed, 12 Oct 2005 21:16:05 +, Eddahbi Karim wrote:
> 
>>Now the mouse problem comes back but the workarounds don't work this
>>time. It's not a regression, it's a bug enhancement.

ACK

>>
>>The old workaround for WineX still work according to gentoo-forums [2].
> 
> 
> It seems Warcraft relies upon NULL-addressed VirtualAlloc starting
> allocation from above a certain range - possibly they're pulling some
> silly bit-twiddling hack or optimisation. The Cedega patch linked to on
> the forums basically hints to mmap that it should allocate at a fixed
> address in this case:
> 
>   http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html

I tried that logic with the mmap wrapper but that did not help ... with
and without printf. I'm just wondering of this code because start
address must be a multiple of pagesize. WoW allocs sometimes less ...
like 2 or 178 bytes.

> 
> Which for WoW they seem to set this hint to 256mb - is there some aspect
> of the NT kernel we're not correctly implementing here? Does Windows
> always allocate from 256mb upwards? 
> 
> Alexandre, Mike - does hinting to mmap in the port library as TransGaming
> do it seem like a good solution here or would it be better to adapt the
> preloader to block off the lowest $X megs?

I'm away for a week so I dont have time to hack and test this into wine
... and I have no time for gaming either :-/

chris

> 
> thanks -mike
> 
> 
> 

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Jesse Allen]

On 10/15/05, Christoph <[EMAIL PROTECTED]> wrote:
> Mike Hearn schrieb:
>
> Here is maybe a clue. Can anyone outline the role of imm32.dll and if it
> can be involved in our problem?
>


imm32.dll seems to be a dll for internationalizing certain text.

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Christoph]

Mike Hearn schrieb:
> On Fri, 14 Oct 2005 19:02:02 +0200, Christoph wrote:
> 
>> WoW really seems to relay on this magic address.
> 
> 
> And yet it works in Windows which presumably does not have any WoW 
> specific appgoo in it. So I imagine it's actually some weird quick of
> the NT kernel we're not emulating correctly here, but Alexandre is
> the true man to ask.

I tested my patch yesterday for about 4 hours and I only had one crash.
Game freezed. Got lock in ntdll, no run out of memory!

Here is maybe a clue. Can anyone outline the role of imm32.dll and if it
can be involved in our problem?

I looked at the output, and this catched my eye.
Here I started WoW without any wine hacks, just with my dropped MESSAGE
lines, so with mouse click problem :

trace:loaddll:load_builtin_dll Loaded module
L"C:\\windows\\system\\opengl32.dll" : builtin
EXE not mmap 0xbfe2, 16384,  7,  50, -1 = 0xbfe2
trace:loaddll:load_native_dll  Loaded module
L"C:\\windows\\system\\IMM32.dll" : native
EXE not mmap 0x1000, 430080, 7,  50, -1 = 0x1000
trace:loaddll:load_native_dll  Loaded module L"E:\\World of
Warcraft\\DivxDecoder.dll" : native
not mmap 0x7ff9, 4096,   3,  50, -1 = 0x7ff9
trace:loaddll:load_builtin_dll Loaded module
L"C:\\windows\\system\\winmm.dll" : builtin
EXE set mmap (nil),  655360, 7,  34, -1 = 0x7fedd000

imm32 is the only one loaded in 0x1xxx. I tried buildin and native
version, no difference.
later, WoW uses adresses like this:

not mmap 0x7d601000, 32768,  0,  50, -1 = 0x7d601000
not mmap 0x79b2, 4096,   0,  50, -1 = 0x79b2
not mmap 0x79921000, 1048576,0,  50, -1 = 0x79921000
not mmap 0x6249d000, 4096,   0,  50, -1 = 0x6249d000
not mmap 0x7d641000, 212992, 0,  50, -1 = 0x7d641000
...

mouse clicks do not work.

Here with my patch, mouse working

trace:loaddll:load_builtin_dll Loaded module
L"C:\\windows\\system\\opengl32.dll" : builtin
not mmap 0xbfe2, 16384,  7,  50, -1 = 0xbfe2
trace:loaddll:load_native_dll  Loaded module
L"C:\\windows\\system\\IMM32.dll" : native
set mmap 0x10246000, 495616, 7,  50, -1 = 0x10246000
trace:loaddll:load_native_dll  Loaded module L"E:\\World of
Warcraft\\DivxDecoder.dll" : native
not mmap 0x7ff9, 4096,   3,  50, -1 = 0x7ff9
trace:loaddll:load_builtin_dll Loaded module
L"C:\\windows\\system\\winmm.dll" : builtin
set mmap 0x102bf000, 655360, 7,  50, -1 = 0x102bf000
not mmap 0x7ff6, 4096,   3,  50, -1 = 0x7ff6

and later game running:

not mmap 0x107c5000, 0,  0,  50, -1 = 0x107c5000
not mmap 0x1074d000, 4096,   0,  50, -1 = 0x1074d000
not mmap 0x1074e000, 4096,   0,  50, -1 = 0x1074e000
not mmap 0x1074c000, 4096,   0,  50, -1 = 0x1074c000
not mmap 0x10749000, 0,  0,  50, -1 = 0x10749000
not mmap 0x122ed000, 4096,   0,  50, -1 = 0x122ed000
not mmap 0x122ee000, 4096,   0,  50, -1 = 0x122ee000
not mmap 0x122ec000, 4096,   0,  50, -1 = 0x122ec000
not mmap 0x122e9000, 0,  0,  50, -1 = 0x122e9000
not mmap 0x107bf000, 4096,   0,  50, -1 = 0x107bf000
not mmap 0x107be000, 4096,   0,  50, -1 = 0x107be000
...

just for fun I tested with 0x2000. imm32.dll still at 0x1000,
wow uses 0x2xxx, mouse working.

0x3000 works either, all other segfault or game starts but crash
while entering the world.


chris

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Mike Hearn]

On Fri, 14 Oct 2005 19:02:02 +0200, Christoph wrote:
> WoW really seems to relay on this magic address.

And yet it works in Windows which presumably does not have any WoW
specific appgoo in it. So I imagine it's actually some weird quick of the
NT kernel we're not emulating correctly here, but Alexandre is the true
man to ask.

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Eddahbi Karim]

Christoph  u-club.de> writes:

> Hi
> 
> http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html
> 
> With the attached patch WoW is working for me, clicks on the playfield
> are now ok!
> 

I used a derived work [1] of your patches and it worked for me but not 
for others.

The patch I tested seems to make wineserver eats a lot of memory in some
implementations.


> chris
> 

Thanks for the work you've done and for digging in the transgaming 
mailing lists.

[1] http://forums.gentoo.org/viewtopic-p-2800297.html

-- 
Eddahbi Karim
Freelance

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Christoph]

Hi

http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html

Good news. This is working in wine too, with some modifications. I must
set FIXED flag so I really get the desired addresses.

With the attached patch WoW is working for me, clicks on the playfield
are now ok!

This patch is not for production, only for playing, delete the MESSAGE
lines. This time a printf is no more necessary to hack around ;)

TODO make an AppDefault option ... I'm away now.

chris




WoW really seems to relay on this magic address.

Here are some lines of the output:

wine WoW.exe -opengl
nil mmap 0x8100, 1056833536, 0, 16418, -1 = 0x3cf2
nil mmap 0x8100, 528416768, 0, 16418, -1 = 0x8100
nil mmap 0xa07f, 528416768, 0, 16418, -1 = 0x5c71
nil mmap 0xa07f, 264175616, 0, 16418, -1 = 0xa07f
nil mmap 0xb03e, 264241152, 0, 16418, -1 = 0x6c30
nil mmap 0xb03e, 132120576, 0, 16418, -1 = 0x7410
...
nil mmap 0xb81e, 132120576, 0, 16418, -1 = 0xb81e
set mmap 0x1000, 16384, 3, 50, -1 = 0x1000
set mmap 0x10004000, 1179648, 0, 50, -1 = 0x10004000
nil mmap 0x7bea, 4096, 3, 50, -1 = 0x7bea
nil mmap 0x7bc8, 4096, 3, 50, -1 = 0x7bc8
trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin
set mmap 0x10124000, 73728, 3, 50, -1 = 0x10124000
trace:process:init_current_directory starting in L"E:\\World of
Warcraft\\" 0x18
trace:process:find_exe_file looking for L"WoW.exe"
trace:process:find_exe_file Trying built-in exe L"E:\\World of
Warcraft\\WoW.exe"
trace:process:find_exe_file Trying native exe L"E:\\World of
Warcraft\\WoW.exe"
trace:process:__wine_kernel_init starting process name=L"E:\\World of
Warcraft\\WoW.exe" file=0x1c argv[0]="WoW.exe"
trace:process:__wine_kernel_init starting Win32 binary L"E:\\World of
Warcraft\\WoW.exe"
nil mmap 0x40, 882, 7, 50, -1 = 0x40
set mmap 0x10136000, 1114112, 3, 50, -1 = 0x10136000


and while the game is running:

nil mmap 0x1a577000, 4096, 0, 50, -1 = 0x1a577000
nil mmap 0x1a576000, 4096, 0, 50, -1 = 0x1a576000
nil mmap 0x1a575000, 0, 0, 50, -1 = 0x1a575000
nil mmap 0x123d5000, 4096, 0, 50, -1 = 0x123d5000
nil mmap 0x123d5000, 0, 0, 50, -1 = 0x123d5000
nil mmap 0x122fb000, 4096, 0, 50, -1 = 0x122fb000
nil mmap 0x122fb000, 0, 0, 50, -1 = 0x122fb000
nil mmap 0x1a5ab000, 4096, 0, 50, -1 = 0x1a5ab000
nil mmap 0x1a5ab000, 0, 0, 50, -1 = 0x1a5ab000
nil mmap 0x1a5d5000, 4096, 0, 50, -1 = 0x1a5d5000
nil mmap 0x1a5d6000, 4096, 0, 50, -1 = 0x1a5d6000
nil mmap 0x1a5d5000, 0, 0, 50, -1 = 0x1a5d5000
nil mmap 0x19fff000, 4096, 0, 50, -1 = 0x19fff000
nil mmap 0x19ffe000, 4096, 0, 50, -1 = 0x19ffe000
nil mmap 0x19ffc000, 4096, 0, 50, -1 = 0x19ffc000
nil mmap 0x19ff9000, 0, 0, 50, -1 = 0x19ff9000
nil mmap 0x1233b000, 4096, 0, 50, -1 = 0x1233b000
nil mmap 0x1233b000, 0, 0, 50, -1 = 0x1233b000
nil mmap 0x12339000, 4096, 0, 50, -1 = 0x12339000
nil mmap 0x1233a000, 4096, 0, 50, -1 = 0x1233a000
nil mmap 0x1233c000, 4096, 0, 50, -1 = 0x1233c000

no more calls with start=NULL



Index: mmap.c
===
RCS file: /home/wine/wine/libs/wine/mmap.c,v
retrieving revision 1.10
diff -u -3 -p -r1.10 mmap.c
--- mmap.c	20 Jun 2005 11:43:47 -	1.10
+++ mmap.c	14 Oct 2005 16:40:53 -
@@ -58,6 +58,31 @@ static const int granularity_mask = 0xff
 static inline int munmap( void *ptr, size_t size ) { return 0; }
 #endif
 
+/* This function returns the address that mmap should use for any
+ * allocation where start is passed as NULL. */
+void *__memory_layout_override = NULL;
+static void *get_anon_mmap_null_address(size_t size)
+{
+static int got_override = 0;
+static void *low_alloc_ptr = NULL;
+void * current_low_alloc_ptr;
+
+if (!got_override)
+{
+//if (__memory_layout_override)
+	{
+low_alloc_ptr = (void *)0x1000;
+got_override = 1;
+}
+}
+
+current_low_alloc_ptr = low_alloc_ptr;
+
+if (low_alloc_ptr)
+low_alloc_ptr += size;
+
+return current_low_alloc_ptr;
+}
 
 #if (defined(__svr4__) || defined(__NetBSD__)) && !defined(MAP_TRYFIXED)
 /***
@@ -209,13 +234,27 @@ void *wine_anon_mmap( void *start, size_
 return start;
 #endif
 }
-return mmap( start, size, prot, flags, fdzero, 0 );
+#include 
+WINE_DEFAULT_DEBUG_CHANNEL(module);
+if ((start == NULL) && !(flags & MAP_FIXED)) {
+   MESSAGE("set ");
+   flags |= MAP_FIXED;
+   start = get_anon_mmap_null_address(size);
+} else {
+   MESSAGE("nil ");
+}
+void *result = mmap( start, size, prot, flags, fdzero, 0 );
+
+MESSAGE("mmap %p, %i, %i, %i, %i = %p \n", \
+start, size, prot , \
+flags, fdzero, result);
+
+return result;
 #else
 return (void *)-1;
 #endif
 }
 
-
 #ifdef HAVE_MMAP
 
 /***

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Christoph]

Mike Hearn schrieb:
> On Wed, 12 Oct 2005 21:16:05 +, Eddahbi Karim wrote:
> 
>>Now the mouse problem comes back but the workarounds don't work this
>>time. It's not a regression, it's a bug enhancement.

ACK

>>
>>The old workaround for WineX still work according to gentoo-forums [2].
> 
> 
> It seems Warcraft relies upon NULL-addressed VirtualAlloc starting
> allocation from above a certain range - possibly they're pulling some
> silly bit-twiddling hack or optimisation. The Cedega patch linked to on
> the forums basically hints to mmap that it should allocate at a fixed
> address in this case:
> 
>   http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html

I tried that logic with the mmap wrapper but that did not help ... with
and without printf. I'm just wondering of this code because start
address must be a multiple of pagesize. WoW allocs sometimes less ...
like 2 or 178 bytes.

> 
> Which for WoW they seem to set this hint to 256mb - is there some aspect
> of the NT kernel we're not correctly implementing here? Does Windows
> always allocate from 256mb upwards? 
> 
> Alexandre, Mike - does hinting to mmap in the port library as TransGaming
> do it seem like a good solution here or would it be better to adapt the
> preloader to block off the lowest $X megs?

I'm away for a week so I dont have time to hack and test this into wine
... and I have no time for gaming either :-/

chris

> 
> thanks -mike
> 
> 
> 

Re: [ World of Warcraft ] The 1.8 Patch brings the target ( or targeting ) problem back

[Mike Hearn]

On Wed, 12 Oct 2005 21:16:05 +, Eddahbi Karim wrote:
> Now the mouse problem comes back but the workarounds don't work this
> time. It's not a regression, it's a bug enhancement.
> 
> The old workaround for WineX still work according to gentoo-forums [2].

It seems Warcraft relies upon NULL-addressed VirtualAlloc starting
allocation from above a certain range - possibly they're pulling some
silly bit-twiddling hack or optimisation. The Cedega patch linked to on
the forums basically hints to mmap that it should allocate at a fixed
address in this case:

  http://lists.transgaming.org/pipermail/winex-devel/2004-May/000259.html

Which for WoW they seem to set this hint to 256mb - is there some aspect
of the NT kernel we're not correctly implementing here? Does Windows
always allocate from 256mb upwards? 

Alexandre, Mike - does hinting to mmap in the port library as TransGaming
do it seem like a good solution here or would it be better to adapt the
preloader to block off the lowest $X megs?

thanks -mike

Re: World of Warcraft

[Jacob Emcken]

Hi,

[EMAIL PROTECTED] wrote:

It's me again.  The latest WoW patch (1.5.1) broke stuff again, and now I'm 
unable to click on anything outside of menu items in game.  The issue seems to 
be related to camera angle, as I am able to click on items/people when I have 
my camera positioned just right.  It's basically unplayable at the moment 
though.

Anyway, I'd appreciate it if one of the OpenGL/D3D guys (it's most likely 
something that would be easily fixed by one of you) could take a look at it if 
they have some free time.


For me the bug has disappeared after upgrading to Ubuntu Breezy with a 
2.6.12 kernel and the lastest release of WINE.


I stumbled upon a post on a Gentoo forum where a few people said that 
they didn't need the ugly cadega workaround to play WoW after using 
kernel 2.6.12.


So after I got Ubuntu upgraded from Hoary to Breezy (which uses a 2.6.12 
kernel instead of a 2.6.10) I tested WoW with a clean WINE 20050725 
(Debian packages from wine.df.net/apt).


The bug hasn't shown itself since. I belive it is the kernel upgrade.
I dunno, I might have just been lucky.


Just wanted to let you know, dunno if I have just been lucky.


Regards
--Jacob

Re: World of Warcraft

[Christoph]

Some more impressions from the test server and coming patches.

First the server was heavy crowded. Funny but net latency about 1200ms. 
Hard to play. Blizz added a lot new game content and that is to be 
tested. They happily rebootet the servers several times while I was on 
and also applied a tiny patch to the clients.


The "1.6-test" patch is not a bugfix at all. Not yet ...
All the ingame bugs that I know are also in the test version. E.g. stuck 
loot bug, still the same typos in the localized text. I found a new game 
bug (graphics) but the GM ticket system is not working.


I used wine-20050524 because latest 20050628 broke these thinks:

- arts sound (I use this with artsd TeamSpeak)
- loose focus minimize/maximize bug

Can anyone confirm this?

One good thing: The game used to crash on exit and wine is stuck until 
ctrl-c (Threadlock?). But this time, I noticed it while patching, the 
game now exits without crashing. I can't say if it was due the patch. I 
haven't hunted this bug. I do believe, this bug patched himself :)


chris




Christoph schrieb:




Joseph Garvin schrieb:

The test realms are up, which lets players test the next patch. 
Anyone tried it to see if the problem is fixed?



No, it is not fixed.

Re: World of Warcraft

[Christoph]

Christoph schrieb:



Joseph Garvin schrieb:

The test realms are up, which lets players test the next patch. Anyone 
tried it to see if the problem is fixed?


No, it is not fixed.





Yes, I'm going to test.

first gotcha the bizzard char copy page. The page did not work in 
Firefox. Clicking in a circle, not accepting a new char name. Looked at 
page source. What a joy. The europe/german Version of the page contains 
a bag full of typos ... such as not closed tags ! Thanks to the 
Webdeveloper plugin in Firefox I got finally a test char :-P


second download tool. 100% cpu and 'nothing' happens until winedbg came 
up with seg fault. Simply retried 5 times, now it's downloading and 
uploading with 3040MB/s . Great speedup :=)


third, ... hey I have to cvs the latest wine ;-)


K. First test run with wine-20050628 with WoW-1.5.1
The "I cannnot click on any NPC" is still there.
Audio is not working (artsdrv) also not with sndrec32.exe ("no sound 
device"). artsd is running and no conn from wine.
Mh, something rotten with wineconfig/registry?! I can see wine is 
loading wineoss.drv instead. Regedit shows me correctly 
WineMM/Drivers=winearts.drv


Tried alsa, that is working.

New bug in wine-20050628: if WoW looses focus, it minimizes and 
maximizes automatically and steals focus again (I'm using WMaker) more 
worse graphics becomes shifted about +1px+1px every time. Makes game 
unplayable after this. Is the option "UseTakeFocus" = "n" no more working?!


So, now I'm going to patch the game.

K. patched fine. creates a new folder WoWTest with empty wtf/ 
config-Folder so have to adjust settings after a quick run.


Game is up. Still has the "cannot click on NPC"

The cheap wrapper trick is still making it working.


further testing needs now lots more time ;)






chris

Re: World of Warcraft

[Christoph]

Joseph Garvin schrieb:
The test realms are up, which lets players test the next patch. Anyone 
tried it to see if the problem is fixed?




Yes, I'm going to test.

first gotcha the bizzard char copy page. The page did not work in 
Firefox. Clicking in a circle, not accepting a new char name. Looked at 
page source. What a joy. The europe/german Version of the page contains 
a bag full of typos ... such as not closed tags ! Thanks to the 
Webdeveloper plugin in Firefox I got finally a test char :-P


second download tool. 100% cpu and 'nothing' happens until winedbg came 
up with seg fault. Simply retried 5 times, now it's downloading and 
uploading with 3040MB/s . Great speedup :=)


third, ... hey I have to cvs the latest wine ;-)


chris

Re: World of Warcraft

[Joseph Garvin]

The test realms are up, which lets players test the next patch. Anyone 
tried it to see if the problem is fixed?

Re: World of Warcraft

[Mike Hearn]

On Tue, 21 Jun 2005 23:07:00 +0200, Christoph wrote:
> Finaly it is the printf who does the magic and not the wrapped mmap! The
> above example also worked for me. Can we still solve this problem with
> logic?

Hehe, I highly doubt it's the printf. More likely, the LD_PRELOADed shared
library is modifying the address space in such a way that the WoW bug is
no longer triggered. I expect you could put anything there (that won't be
optimised out) and it'll still work.

Re: World of Warcraft

[Christoph]

Raphael schrieb:

Hi,



To me it looks like an overoptimized geometry problem. As long there is
only sky and no terrain or building behind the objects, you can klick
them. This is mostly the case, when you look up. Just like users reported.

I just wrote a lousy mmap wrapper which sets start to 0x1000 . This
works for me with wine 20050601 and the latest from cvs.



Interesting

More interesting:
http://forums.gentoo.org/viewtopic-t-246098-postdays-0-postorder-asc-start-200.html?sid=3afd22e0a94b246c583b2d2bd043712f

Gamers are playing with lib. wrapper ... just like me!
But I came to the same conclusion:

static void initialize() __attribute__ ((constructor));

static void initialize() {
printf("Hurra !!!\n");
// _mmap = dlsym(RTLD_NEXT, "mmap");
}

Finaly it is the printf who does the magic and not the wrapped mmap! The 
above example also worked for me. Can we still solve this problem with 
logic?


But I still do believe, that blizzard will release a new patch soon :=)





Latest cvs raises another bug. When the wow window looses focus, it
minimize and maximizes again and stays on top. More worse, the graphics
is shifted to approx. +2+2 pixels every time. Here's the output from
console:

fixme:opengl:wglQueryPbufferARB unsupported WGL_PBUFFER_LOST_ARB (need
glXSelectEvent/GLX_DAMAGED work)




... and this "bug" reminds me to a config option which I set to n many 
years ago:


[x11drv]
"UseTakeFocus" = "n"

Does this no more work in cvs version? I dont have another picky 
application here to test. sol.exe does not have that min/max effect.




Arg,
i didn't expect this fixme :(

And it's so boring to handle (needs some x11drv work too)
I'll let Lionel (or Alexandre) trying to fix this case, i have already find 
the way to handle (see the fixme text) :)




 and the TODO becomes a bit longer again.



yes really longer ...



chris



Raphael


chris

Re: World of Warcraft

[Stefan Dösinger]

On Monday 20 June 2005 22:22, Raphael wrote:
> Stupid kmail
I updated to KDE 3.4 and kmail seems to do a fine job now.
*Reply replies to the list
*Reply to all replies to list + Sender
*Reply to Author replies to the author only
*Reply to Mailing list replies to the mailing list only.

I think that's how it should work

Stefan

Re: World of Warcraft

[Aric Cyr]

> > fixme:opengl:wglQueryPbufferARB unsupported WGL_PBUFFER_LOST_ARB
> > (need
> > glXSelectEvent/GLX_DAMAGED work)
> 
> Arg,
> i didn't expect this fixme :(

I don't think we have to worry about this fixme.  We can always return
GL_FALSE, since that is the way the OpenGL surfaces were created.

>From http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt:

 If the GLX_PRESERVED_CONTENTS_SGIX attribute is set to False in
, then an "unpreserved" pbuffer is created and the
contents of the pbuffer may be lost at any time. If this attribute
is not specified, or if it is specified as True in ,
then when a resource conflict occurs the contents of the pbuffer
will be preserved (most likely by swapping out portions of the
buffer to main memory).  In either case, the client can register
to receive a "buffer clobber" event which is generated when the
pbuffer contents have been preserved or have been damaged. (See
the event description.)

So the fixme should be fixed to always return GL_FALSE I think.


Also, there is an interesting workaround for the clicking problem as well on
the Gentoo forums.  Seems to be working for the majority of people
(including myself).  It seems to reaffirm that the problem is indeed
the memory layout.
http://forums.gentoo.org/viewtopic-p-2509340.html#2509340

-- 
Aric Cyr (http://acyr.net)
gpg fingerprint: 943A 1549 47AC D766 B7F8  D551 6703 7142 C282 D542

Re: World of Warcraft

[Raphael]

Stupid kmail

Sorry
Raphael


pgpcJIYGhghQ6.pgp
Description: PGP signature

Re: World of Warcraft

[Raphael]

On Monday 20 June 2005 09:40, Raphael wrote:
> Hi,
>
> > To me it looks like an overoptimized geometry problem. As long there is
> > only sky and no terrain or building behind the objects, you can klick
> > them. This is mostly the case, when you look up. Just like users
> > reported.
> >
> > I just wrote a lousy mmap wrapper which sets start to 0x1000 . This
> > works for me with wine 20050601 and the latest from cvs.
>
> Interesting


After some investigation (using interesting users dumps at 
http://home.gci.net/~slipster5/WowError/ and in many others places)

looks like more an ugly WoW bug

For example seeing this typilical error:

This application has encountered a critical error:

ERROR #132 (0x85100084)
Program:C:\Program Files\World of Warcraft\WoW.exe
Exception:  0xC005 (ACCESS_VIOLATION) at 001B:00650E16

The instruction at "0x00650E16" referenced memory at "0x33991588".
The memory could not be "read".


While registers was:

EAX=0001  EBX=13991500  ECX=00A49658  EDX=0003  ESI=1399155C
EDI=  EBP=0012FC58  ESP=0012FC38  EIP=00650E16  FLG=00210202
CS =001B  DS =0023  ES =0023  SS =0023  FS =003B  GS =


The must interesting is that error address was always (EBX + 0x2000) + 
something little (usually between 0x10-0x88). 

for info 0x2000 => 512Mb :)

So who go to blizzard to fix the bug ? :)


Raphael


pgpAZhseGaLeO.pgp
Description: PGP signature

Re: World of Warcraft

[Andreas Mohr]

Hi,

On Mon, Jun 20, 2005 at 09:34:52AM +0200, Raphael wrote:
> Hi,
> 
> > Hopefully somebody will figure this one out. If not maybe a trip to the
> > local games shop is in order :)
> 
> lol
> what about asking blizzard support :)
I'd really recommend doing exactly that.
Those game publishers'd better get used to us having issues with their
 awkward patches all the time ;)
That way they might go as far as testing it on Wine themselves before release
or mailing it to interested Wine people beforehand.

We need to get on the radar of those companies...

Andreas Mohr

Re: World of Warcraft

[Raphael]

Hi,

> To me it looks like an overoptimized geometry problem. As long there is
> only sky and no terrain or building behind the objects, you can klick
> them. This is mostly the case, when you look up. Just like users reported.
>
> I just wrote a lousy mmap wrapper which sets start to 0x1000 . This
> works for me with wine 20050601 and the latest from cvs.

Interesting

> Latest cvs raises another bug. When the wow window looses focus, it
> minimize and maximizes again and stays on top. More worse, the graphics
> is shifted to approx. +2+2 pixels every time. Here's the output from
> console:
>
> fixme:opengl:wglQueryPbufferARB unsupported WGL_PBUFFER_LOST_ARB (need
> glXSelectEvent/GLX_DAMAGED work)

Arg,
i didn't expect this fixme :(

And it's so boring to handle (needs some x11drv work too)
I'll let Lionel (or Alexandre) trying to fix this case, i have already find 
the way to handle (see the fixme text) :)

>  and the TODO becomes a bit longer again.

yes really longer ...

> chris

Raphael


pgpeNj4AdJMhT.pgp
Description: PGP signature

Re: World of Warcraft

[Raphael]

Hi,

> Hopefully somebody will figure this one out. If not maybe a trip to the
> local games shop is in order :)

lol
what about asking blizzard support :)

> thanks -mike

Regards,
Raphael


pgpPMvZ8VJLuB.pgp
Description: PGP signature

Re: World of Warcraft

[Raphael]

Hi,

On Friday 17 June 2005 16:12, Mike Hearn wrote:
> On Thu, 16 Jun 2005 09:44:34 +0200, Raphael wrote:
> > Well cedega seems to have the same problem (google) and they fixed it
> > using specific memory layout for WoW (mmap begins at 0x1000) Seems
> > more a WoW bug than wine/cedega bug :)
>
> Yes, it's a WoW bug, some Windows users are affected too. Unfortunately it
> seems very few Windows users hit the problem but all Linux/Wine users see
> it.

Yes seems a strange WoW optimization :)

> > I don't want to do ugly hack to ovveride memory layout so if any wine
> > memory layout expert can look why it happened (Alexandre ?)
>
> There's something else going on here, the Cedega fix doesn't seem to work
> for everybody.
>
> Well, I don't think Alexandre has a WoW account or copy and there isn't
> enough information here to see what's going on. It's odd that seems VM
> layout related though. 

as me, i haven't a WoW account 
but seems that WoW do some checks using presumption on VM layout (and wine VM 
layout is really different)

> The issue looks like it's in OpenGL though, their 
> "1.5 patch hotfix" is a replacement of the opengl32 DLL.

1.5.O WoW patch used to work (with my openGL patces to get 1.4.1 working)
we are speaking about 1.5.1 problem

> thanks -mike

Regards,
Raphael


pgp6C187YQDdD.pgp
Description: PGP signature

Re: World of Warcraft

[Christoph Rudorff]

Ove Kaaven schrieb:

søn, 19,.06.2005 kl. 16.07 +0100, skrev Mike Hearn:


On Sat, 2005-06-18 at 05:12 -0400, Ove Kaaven wrote:


That OpenGL hotfix is for 1.5.0 (improved ARB_pixel_format, something
Wine already have). The VM issue this thread is about is in 1.5.1. This
is not the fix you're looking for.


Ah OK, thanks.

I guess you don't wish to tell us what the bug is? If not then I'd
understand completely.



It looks like a game bug related to virtual memory to me, and it's
possible to do a couple of configuration changes in Cedega to provoke
different virtual memory layouts, which apparently makes a difference.
Exactly why, I don't know. Since workarounds exist for now, and it's not
a simple bug to track down, and it's possible Blizzard may simply fix
the bug themselves in a future update, this is not important enough that
I've been told to drop my current tasks and do an in-depth investigation
of this instead.


:(







Hello!

To me it looks like an overoptimized geometry problem. As long there is 
only sky and no terrain or building behind the objects, you can klick 
them. This is mostly the case, when you look up. Just like users reported.


I just wrote a lousy mmap wrapper which sets start to 0x1000 . This 
works for me with wine 20050601 and the latest from cvs.


Latest cvs raises another bug. When the wow window looses focus, it 
minimize and maximizes again and stays on top. More worse, the graphics 
is shifted to approx. +2+2 pixels every time. Here's the output from 
console:


fixme:opengl:wglQueryPbufferARB unsupported WGL_PBUFFER_LOST_ARB (need 
glXSelectEvent/GLX_DAMAGED work)


... and the TODO becomes a bit longer again.

chris

Re: World of Warcraft

[Ove Kaaven]

søn, 19,.06.2005 kl. 16.07 +0100, skrev Mike Hearn:
> On Sat, 2005-06-18 at 05:12 -0400, Ove Kaaven wrote:
> > That OpenGL hotfix is for 1.5.0 (improved ARB_pixel_format, something
> > Wine already have). The VM issue this thread is about is in 1.5.1. This
> > is not the fix you're looking for.
> 
> Ah OK, thanks.
> 
> I guess you don't wish to tell us what the bug is? If not then I'd
> understand completely.

It looks like a game bug related to virtual memory to me, and it's
possible to do a couple of configuration changes in Cedega to provoke
different virtual memory layouts, which apparently makes a difference.
Exactly why, I don't know. Since workarounds exist for now, and it's not
a simple bug to track down, and it's possible Blizzard may simply fix
the bug themselves in a future update, this is not important enough that
I've been told to drop my current tasks and do an in-depth investigation
of this instead.

Re: World of Warcraft

[Mike Hearn]

On Sat, 2005-06-18 at 05:12 -0400, Ove Kaaven wrote:
> That OpenGL hotfix is for 1.5.0 (improved ARB_pixel_format, something
> Wine already have). The VM issue this thread is about is in 1.5.1. This
> is not the fix you're looking for.

Ah OK, thanks.

I guess you don't wish to tell us what the bug is? If not then I'd
understand completely.

Hopefully somebody will figure this one out. If not maybe a trip to the
local games shop is in order :)

thanks -mike

Re: World of Warcraft

[Ove Kaaven]

fre, 17,.06.2005 kl. 15.12 +0100, skrev Mike Hearn:
> Well, I don't think Alexandre has a WoW account or copy and there isn't
> enough information here to see what's going on. It's odd that seems VM
> layout related though. The issue looks like it's in OpenGL though, their
> "1.5 patch hotfix" is a replacement of the opengl32 DLL.

That OpenGL hotfix is for 1.5.0 (improved ARB_pixel_format, something
Wine already have). The VM issue this thread is about is in 1.5.1. This
is not the fix you're looking for.

Re: World of Warcraft

[Joseph Garvin]

Mike Hearn wrote:


Well, I don't think Alexandre has a WoW account or copy and there isn't
enough information here to see what's going on. It's odd that seems VM
layout related though. The issue looks like it's in OpenGL though, their
"1.5 patch hotfix" is a replacement of the opengl32 DLL.

thanks -mike


 

Anyone tried overwriting the new opengl32 with the old one and seeing if 
it works? The game may still think it's patched depending on how it 
tracks versions.

Re: World of Warcraft

[Mike Hearn]

On Thu, 16 Jun 2005 09:44:34 +0200, Raphael wrote:
> Well cedega seems to have the same problem (google) and they fixed it
> using specific memory layout for WoW (mmap begins at 0x1000) Seems
> more a WoW bug than wine/cedega bug :)

Yes, it's a WoW bug, some Windows users are affected too. Unfortunately it
seems very few Windows users hit the problem but all Linux/Wine users see
it.

> I don't want to do ugly hack to ovveride memory layout so if any wine
> memory layout expert can look why it happened (Alexandre ?)

There's something else going on here, the Cedega fix doesn't seem to work
for everybody.

Well, I don't think Alexandre has a WoW account or copy and there isn't
enough information here to see what's going on. It's odd that seems VM
layout related though. The issue looks like it's in OpenGL though, their
"1.5 patch hotfix" is a replacement of the opengl32 DLL.

thanks -mike

Re: World of Warcraft

[Raphael]

Hi,

On Wednesday 15 June 2005 05:18, [EMAIL PROTECTED] wrote:
> It's me again.  The latest WoW patch (1.5.1) broke stuff again, and now I'm
> unable to click on anything outside of menu items in game.  The issue seems
> to be related to camera angle, as I am able to click on items/people when I
> have my camera positioned just right.  It's basically unplayable at the
> moment though.

Well cedega seems to have the same problem (google) and they fixed it using 
specific memory layout for WoW (mmap begins at 0x1000)
Seems more a WoW bug than wine/cedega bug :)

> Anyway, I'd appreciate it if one of the OpenGL/D3D guys (it's most likely
> something that would be easily fixed by one of you) could take a look at it
> if they have some free time.

I don't want to do ugly hack to ovveride memory layout so if any wine memory 
layout expert can look why it happened (Alexandre ?)

> Thanks again,
> Darckness

Regards,
Raphael


pgp6jbbn59nX1.pgp
Description: PGP signature

Re: Debugging with GDB [was: Re: World of Warcraft - crash in game]

[Alex Woods]

On Sun, Apr 24, 2005 at 09:23:22AM +1000, Troy Rollo wrote:
> On Saturday 23 April 2005 22:12, Alex Woods wrote:
> > I'm attaching to the process with gdb, but it's not catching things at
> > the point where they go wrong.  Typically I am just seeing a stack like
> > this though:
> > #0  0x56752a01 in ?? ()
> 
> If it's only giving one frame in the stack trace the cause is normally a 
> corrupted stack, so you may need to examine the stack to try to figure out 
> where the stack frame should be (starting with "x/256xw" may be helpful if 
> the stack pointer is still valid).

Yeah, the stack always looks in pretty bad shape.  The address of the #0
frame has been within nvidia's libGLCore.so.1 everytime I've had a
SIGSEGV.  Other times when an exception is caught by WoW, it often comes
back with an Out of memory message from one of it's files - off the top
of my head MapMem.cpp, SFile.cpp and Texture.cpp.  I don't think it's a
problem with the nvidia driver since it handles doom3 just fine.  I do
think it's a problem around the OpenGL space though, because turning
down the graphical options makes the game stable.  I might try playing
with the options to see if any particular one is the cause.

> Otherwise, when debugging with GDB without going through winedbg you may need 
> to use the "pass" command to skip over first chance exceptions in some cases 
> before you get to the real exception.

I'm not sure I'm seeing the first chance exceptions at all until - I
presume these are exceptions that are raised but are expected to some
extent and so are handled without stopping execution?  I just seem to be
seeing signals telling the thread it's been suspended I think.  I'm not
clear on how wine handles exceptions though.

Cheers.

-- 
Alex

Re: Debugging with GDB [was: Re: World of Warcraft - crash in game]

[Troy Rollo]

On Saturday 23 April 2005 22:12, Alex Woods wrote:
> I'm attaching to the process with gdb, but it's not catching things at
> the point where they go wrong.  Typically I am just seeing a stack like
> this though:
> #0  0x56752a01 in ?? ()

If it's only giving one frame in the stack trace the cause is normally a 
corrupted stack, so you may need to examine the stack to try to figure out 
where the stack frame should be (starting with "x/256xw" may be helpful if 
the stack pointer is still valid).

Otherwise, when debugging with GDB without going through winedbg you may need 
to use the "pass" command to skip over first chance exceptions in some cases 
before you get to the real exception.

Debugging with GDB [was: Re: World of Warcraft - crash in game]

[Alex Woods]

On Thu, Mar 03, 2005 at 08:13:41AM +1100, Troy Rollo wrote:
> On Thu, 3 Mar 2005 03:43, Alex Woods wrote:
> > Unfortunately, I never got to try out this method properly.  WoW has
> > it's own dbghelp.dll that it checks on login and that contains different
> > functions to wine's dbghelp.  So I got stuck there, but it's not all bad
> > news.
> 
> In that case you may be able to use GDB directly on the executable (without 
> winedbg) and attach after the app has started with 
> "gdb /usr/local/bin/wine-pthread process-id". The major drawback of this is 
> that it cannot tell the difference between a first chance exception and a 
> last chance exception, so if the app uses exception handling you may end up 
> using GDB's "pass" command a lot.

Well, after a long break, I'm back at trying to debug wine + WoW again.
Somewhere alsa stopped working for me totally in wine (multilib problem
I think).  Now that it's working again, running the winmm and dsound
tests I don't get any crashes, which I did before.

I still get crashes in WoW though, with both OSS and ALSA, so I figure
I'll try to get to the bottom of the common problems first before going
back to see if ALSA is still a problem.

I'm attaching to the process with gdb, but it's not catching things at
the point where they go wrong.  Typically I am just seeing a stack like
this though:
#0  0x56752a01 in ?? ()
I might be doing something wrong.  It's been a long time since I used
gdb for anything threaded, and never with NTLM.  I've tried attaching to
wine-pthread process and the wine-preloader process, with pretty much
the same results.

It's a real shame that +relay slows things down too much for be to be
able to get to the point where a crash occurs.  Does anyone have any
suggestions as to how I might get a handle on where things are going
wrong?  How are exceptions caught by wine?  A lot of the time WoW
handles the error so can I work back from there?

A lot of the time I get a report like this:

This application has encountered a critical error:

Not enough memory

Program:C:\Program Files\World of Warcraft\WoW.exe
File:   C:\build\buildWoW\WoW\Source\WorldClient\MapMem.cpp
Line:   589

WoWBuild: 4341
--


Stack Trace (Manual)


Address  FrameLogical addr  Module

0064F43E 55C0F970 0001:0024E43E C:\Program Files\World of Warcraft\WoW.exe
006500A5 55C0F988 0001:0024F0A5 C:\Program Files\World of Warcraft\WoW.exe
00651464 55C0F9A8 0001:00250464 C:\Program Files\World of Warcraft\WoW.exe
006B9F82 55C0F9D0 0001:002B8F82 C:\Program Files\World of Warcraft\WoW.exe
006D8FC6 55C0FAF4 0001:002D7FC6 C:\Program Files\World of Warcraft\WoW.exe
006B16AE 55C0FB20 0001:002B06AE C:\Program Files\World of Warcraft\WoW.exe
006B13B7 55C0FB3C 0001:002B03B7 C:\Program Files\World of Warcraft\WoW.exe
00689769 55C0FB4C 0001:00288769 C:\Program Files\World of Warcraft\WoW.exe
0048E70F 55C0FC00 0001:0008D70F C:\Program Files\World of Warcraft\WoW.exe
0048E293 55C0FC8C 0001:0008D293 C:\Program Files\World of Warcraft\WoW.exe
0076DDE1 55C0FCB0 0001:0036CDE1 C:\Program Files\World of Warcraft\WoW.exe
00762520 55C0FCD8 0001:00361520 C:\Program Files\World of Warcraft\WoW.exe
00760C72 55C0FCE4 0001:0035FC72 C:\Program Files\World of Warcraft\WoW.exe
0044224E 55C0FDAC 0001:0004124E C:\Program Files\World of Warcraft\WoW.exe
0041B8E6 55C0FDE4 0001:0001A8E6 C:\Program Files\World of Warcraft\WoW.exe
004175EA 55C0FE5C 0001:000165EA C:\Program Files\World of Warcraft\WoW.exe
00416D71 55C0FE74 0001:00015D71 C:\Program Files\World of Warcraft\WoW.exe
004044B0 55C0FF14 0001:34B0 C:\Program Files\World of Warcraft\WoW.exe
55A58B9B 55C0FFF4 0001:00057B9B c:\windows\system\kernel32.dll

Am I right in thinking that the logical address is the address I should
use to look up the point it's failing in kernel32.dll?  Using that and
an asm dump of kernel32.dll.so places it in the error section of
FindFirstFileExW I think:

   57b82:   00
   57b83:   89 04 24mov%eax,(%esp)
   57b86:   e8 91 80 00 00  call   5fc1c 
   57b8b:   83 ec 0csub$0xc,%esp
   57b8e:   8d 45 e8lea0xffe8(%ebp),%eax
   57b91:   89 04 24mov%eax,(%esp)
   57b94:   e8 37 21 fe ff  call   39cd0 
   57b99:   83 ec 04sub$0x4,%esp
   57b9c:   c7 45 b0 ff ff ff ffmovl   $0x,0xffb0(%ebp)
   57ba3:   8b 45 b0mov0xffb0(%ebp),%eax
   57ba6:   8b 5d fcmov0xfffc(%ebp),%ebx
   57ba9:   c9  leave
   57baa:   c2 18 00ret$0x18

If I attach to wine-pthread and stick a breakpoint in that function, it
does indeed get called right before WoW crashes out with the Out of
memory error.  I guess I'll work that bac

Re: World of Warcraft: fixed?

[cyrix12]

On Sat, 26 Mar 2005 11:35:58 +
Alex Woods <[EMAIL PROTECTED]> wrote:

> On Thu, Mar 24, 2005 at 10:40:18PM -0500, [EMAIL PROTECTED] wrote:
> > I applied the two patches from bugzilla 
> > (http://bugs.winehq.org/show_bug.cgi?id=2814#c8) which includes Raphael's 
> > opengl32 fbconf patch and another one from Tim Savannah  which looks like 
> > this:
> > 
> > --- wine2/dlls/x11drv/opengl.c  2005-03-24 20:51:16.0 -0500
> > +++ wine/dlls/x11drv/opengl.c   2005-03-24 20:50:14.0 -0500
> > @@ -268,9 +268,8 @@
> >if ((iPixelFormat > MAX_PIXELFORMATS) ||
> >(iPixelFormat > physDev->used_visuals + 1) ||
> >(iPixelFormat <= 0)) {
> > -ERR("Wrong pixel format !\n");
> > -/* Should set error */
> > -return 0;
> > +ERR("Wrong pixel format, trying default. !\n");
> > +   iPixelFormat = physDev->used_visuals + 1;
> >}
> >  
> >if (iPixelFormat == physDev->used_visuals + 1) {
> 
> The WoW patch has hit the European servers now, so I've had a chance to
> try things out.  These patches work great for me - everything is running
> as it should.
> 
> > I note two things when using these patches:
> > 1) WoW works.  Game loads and runs again.
> > 2) The login/character select screen will occasionally be extremely
> > choppy/slow.  Sometimes it happens, sometimes it doesn't, and there
> > seems to be no direct cause from what I can tell since the traces are
> > identical.  Once in the game it performs nicely from what I've seen,
> > so it's really just a minor irritation.
> 
> I've not noticed any choppiness in the character selection screen.  I've
> noticed some choppiness turning in some places, but it doesn't feel like
> a wine problem.
> 
> > Thanks for the swift fixes!
> 
> I'll second that :)
> 
> -- 
> Alex

I've discovered that the choppiness I was experiencing can be fixed simply by 
giving focus to another window and then switching back to the game.  It's an 
even smaller issue than I thought!

Darckness

Re: World of Warcraft: fixed?

[Alex Woods]

On Thu, Mar 24, 2005 at 10:40:18PM -0500, [EMAIL PROTECTED] wrote:
> I applied the two patches from bugzilla 
> (http://bugs.winehq.org/show_bug.cgi?id=2814#c8) which includes Raphael's 
> opengl32 fbconf patch and another one from Tim Savannah  which looks like 
> this:
> 
> --- wine2/dlls/x11drv/opengl.c2005-03-24 20:51:16.0 -0500
> +++ wine/dlls/x11drv/opengl.c 2005-03-24 20:50:14.0 -0500
> @@ -268,9 +268,8 @@
>if ((iPixelFormat > MAX_PIXELFORMATS) ||
>(iPixelFormat > physDev->used_visuals + 1) ||
>(iPixelFormat <= 0)) {
> -ERR("Wrong pixel format !\n");
> -/* Should set error */
> -return 0;
> +ERR("Wrong pixel format, trying default. !\n");
> +   iPixelFormat = physDev->used_visuals + 1;
>}
>  
>if (iPixelFormat == physDev->used_visuals + 1) {

The WoW patch has hit the European servers now, so I've had a chance to
try things out.  These patches work great for me - everything is running
as it should.

> I note two things when using these patches:
> 1) WoW works.  Game loads and runs again.
> 2) The login/character select screen will occasionally be extremely
> choppy/slow.  Sometimes it happens, sometimes it doesn't, and there
> seems to be no direct cause from what I can tell since the traces are
> identical.  Once in the game it performs nicely from what I've seen,
> so it's really just a minor irritation.

I've not noticed any choppiness in the character selection screen.  I've
noticed some choppiness turning in some places, but it doesn't feel like
a wine problem.

> Thanks for the swift fixes!

I'll second that :)

-- 
Alex

Re: World of Warcraft

[cyrix12]

On Thu, 24 Mar 2005 00:52:24 +0100
Raphael <[EMAIL PROTECTED]> wrote:

> Hi again,
> 
> > > Hi,
> > >
> > > can you try with this patch ?
> > >
> > > Regards,
> > > Raphael
> >
> > Still doesn't work.  I attached another opengl trace in case you can pick
> > out something that's changed though.
> >
> > Darckness
> 
> Thx, intersesting :)
> 
> And this one ?
> 
> Regards,
> Raphael

I sent another message earlier, but it had a bz2 opengl log which seems to have 
gotten held up somewhere.  So I'll send this one (without a log) in the hopes 
that it will get through and you'll be able to do something.

First email:
>I've got good news and bad news.  The good news is that the World of Warcraft 
>loads now, which is excellent.  The bad news twofold: the performance is 
>AWFUL, and it crashes out in the same place as before (when wine was missing 
>pbuffer support).  But it loads!

Darckness

Re: World of Warcraft

[Raphael]

Hi again,

> > Hi,
> >
> > can you try with this patch ?
> >
> > Regards,
> > Raphael
>
> Still doesn't work.  I attached another opengl trace in case you can pick
> out something that's changed though.
>
> Darckness

Thx, intersesting :)

And this one ?

Regards,
Raphael
Index: wgl_ext.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
retrieving revision 1.4
diff -u -r1.4 wgl_ext.c
--- wgl_ext.c	10 Mar 2005 11:13:33 -	1.4
+++ wgl_ext.c	23 Mar 2005 23:51:05 -
@@ -31,6 +31,7 @@
 #include "winuser.h"
 #include "winerror.h"
 
+#include "gdi.h"
 #include "wgl.h"
 #include "wgl_ext.h"
 #include "opengl_ext.h"
@@ -133,6 +134,18 @@
   return bTest;
 }
 
+int (*p_glXSwapIntervalSGI)(int);
+BOOL query_function_swap_control(glXGetProcAddressARB_t proc, const char *gl_version, const char *gl_extensions, 
+ const char* glx_version, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+  BOOL bTest = (0 <= strcmp("1.3", glx_version) || NULL != strstr(glx_extensions, "GLX_SGIX_swap_group"));
+  if (bTest) {
+p_glXSwapIntervalSGI = proc("glXSwapIntervalSGI");
+bTest = (NULL != p_glXSwapIntervalSGI);
+  }
+  return bTest;
+}
 /***
  *  wglGetExtensionsStringEXT(OPENGL32.@)
  */
@@ -157,18 +170,21 @@
  *  wglSwapIntervalEXT(OPENGL32.@)
  */
 BOOL WINAPI wglSwapIntervalEXT(int interval) {
-FIXME("(%d),stub!\n", interval);
-
-swap_interval = interval;
-return TRUE;
+  TRACE("(%d)\n", interval);
+  swap_interval = interval;
+  if (NULL != p_glXSwapIntervalSGI) {
+return 0 == p_glXSwapIntervalSGI(interval);
+  }
+  WARN("(): GLX_SGI_swap_control extension seems not supported \n");
+  return TRUE;
 }
 
 /***
  *  wglGetSwapIntervalEXT(OPENGL32.@)
  */
 int WINAPI wglGetSwapIntervalEXT(VOID) {
-FIXME("(),stub!\n");
-return swap_interval;
+  TRACE("() returns %d\n", swap_interval);
+  return swap_interval;
 }
 
 typedef struct wine_glpbuffer {
@@ -226,9 +242,12 @@
 #define WGL_STENCIL_BITS_ARB			0x2023
 #define WGL_AUX_BUFFERS_ARB			0x2024
 
-#define WGL_PBUFFER_WIDTH_ARB0x2034
-#define WGL_PBUFFER_HEIGHT_ARB   0x2035
-#define WGL_PBUFFER_LOST_ARB 0x2036
+#define WGL_PBUFFER_WIDTH_ARB   0x2034
+#define WGL_PBUFFER_HEIGHT_ARB  0x2035
+#define WGL_PBUFFER_LOST_ARB0x2036
+
+#define WGL_TYPE_RGBA_ARB			0x202B
+#define WGL_TYPE_COLORINDEX_ARB			0x202C
 
 #if 0 /* not used yet */
 static unsigned ConvertAttribGLXtoWGL(const int* iWGLAttr, int* oGLXAttr) {
@@ -249,6 +268,18 @@
   pop = iWGLAttr[++cur];
   PUSH2(oGLXAttr, GLX_BUFFER_SIZE, pop);
   break;
+case WGL_BLUE_BITS_ARB:
+  pop = iWGLAttr[++cur];
+  PUSH2(oGLXAttr, GLX_BLUE_SIZE, pop);
+  break;
+case WGL_RED_BITS_ARB:
+  pop = iWGLAttr[++cur];
+  PUSH2(oGLXAttr, GLX_RED_SIZE, pop);
+  break;
+case WGL_GREEN_BITS_ARB:
+  pop = iWGLAttr[++cur];
+  PUSH2(oGLXAttr, GLX_GREEN_SIZE, pop);
+  break;
 case WGL_ALPHA_BITS_ARB:
   pop = iWGLAttr[++cur];
   PUSH2(oGLXAttr, GLX_ALPHA_SIZE, pop);
@@ -265,14 +296,34 @@
   pop = iWGLAttr[++cur];
   PUSH2(oGLXAttr, GLX_DOUBLEBUFFER, pop);
   break;
+
+case WGL_PIXEL_TYPE_ARB:
+  pop = iWGLAttr[++cur];
+  switch (pop) {
+  case WGL_TYPE_RGBA_ARB:  pop = GLX_RGBA_BIT; break ; 
+  case WGL_TYPE_COLORINDEX_ARB: pop = GLX_COLOR_INDEX_BIT; break ;
+  default:
+	ERR("unexpected PixelType(%x)\n", pop);	
+	pop = 0;
+  }
+  PUSH2(oGLXAttr,GLX_RENDER_TYPE, pop);
+  break;
+
 case WGL_DRAW_TO_WINDOW_ARB:
-case WGL_SUPPORT_OPENGL_ARB:
+case WGL_DRAW_TO_BITMAP_ARB:
+case WGL_SUPPORT_GDI_ARB:
+  pop = iWGLAttr[++cur];
+  PUSH2(oGLXAttr, GLX_X_RENDERABLE, pop);
+  break;
+
 case WGL_ACCELERATION_ARB:
-/*
-case WGL_SAMPLE_BUFFERS_ARB:
-case WGL_SAMPLES_ARB:
-*/
+case WGL_SUPPORT_OPENGL_ARB:
+  pop = iWGLAttr[++cur];
+  /** nothing to do, if we are here, supposing support Accelerated OpenGL */
+  break;
+
 default:
+  FIXME("unsupported %x WGL Attribute\n", iWGLAttr[cur]);
   break;
 }
 ++cur;
@@ -282,14 +333,118 @@
 
 GLboolean WINAPI wglGetPixelFormatAttribivARB(HDC hdc, int iPixelFormat, int iLayerPlane, UINT nAttributes, const int *piAttributes, int *piValues)
 {
-TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane, nAttributes, piAttributes, piValues);
-return GL_TRUE;
+  Display* display = get_display( hdc );
+  UINT i;
+  GLXFBConfig* cfgs = NULL;
+  GLXFBConfig  curCfg = NULL;
+  int nCfgs = 0;
+  int hTest;
+  int tmp;
+  int curGLXAttr = 0;
+
+  TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, 

Re: World of Warcraft

[cyrix12]

On Wed, 23 Mar 2005 23:37:49 +0100
Raphael <[EMAIL PROTECTED]> wrote:

> On Wednesday 23 March 2005 22:15, [EMAIL PROTECTED] wrote:
> > Sorry to keep bugging you guys about this, but a recent patch broke the
> > opengl mode of World of Warcraft again.  It simply fails to start, similar
> > to the d3d mode (except for the fact that I know why d3d mode doesn't work
> > as of now).  I was scanning through the traces and saw no errors though. 
> > Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure
> > what to look for anyway.  If anyone wants me to send a any sort of debug
> > log (if, for instance, you don't have copy of WoW to test on), let me know
> > (include what you'd want to see as well, if you don't mind).
> >
> > Thanks in advance,
> > Darckness
> 
> Hi,
> 
> can you try with this patch ?
> 
> Regards,
> Raphael
> 

Still doesn't work.  I attached another opengl trace in case you can pick out 
something that's changed though.

Darcknesstrace:opengl:X11DRV_OpenGL_Init GLX is up and running error_base = 64
trace:opengl:X11DRV_OpenGL_Init GLX is up and running error_base = 64
trace:opengl:wgl_ext_initialize_extensions GL version  : "1.5.3 NVIDIA 
71.67".
trace:opengl:wgl_ext_initialize_extensions GL version  : "1.5.3 NVIDIA 
71.67".
trace:opengl:wgl_ext_initialize_extensions GL exts : 
"GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow 
GL_ARB_fragment_shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture 
GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite 
GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 
GL_ARB_texture_bo"
trace:opengl:wgl_ext_initialize_extensions GLX exts: 
"GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer 
GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer 
GLX_ARB_get_proc_address ".
trace:opengl:wgl_ext_initialize_extensions Server GLX exts : 
"GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer 
GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer 
".
trace:opengl:wgl_ext_initialize_extensions Client GLX exts : 
"GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_visual_info 
GLX_EXT_visual_rating GLX_EXT_import_context GLX_SGI_video_sync 
GLX_NV_swap_group GLX_NV_video_out GLX_SGIX_fbconfig GLX_SGIX_pbuffer 
GLX_SGI_swap_control GLX_NV_float_buffer ".
fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67"
fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info 
GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync 
GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer 
GLX_ARB_get_proc_address "
trace:opengl:wgl_ext_initialize_extensions GL exts : 
"GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow 
GL_ARB_fragment_shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture 
GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite 
GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 
GL_ARB_texture_bo"
trace:opengl:wgl_ext_initialize_extensions GLX exts: 
"GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer 
GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer 
GLX_ARB_get_proc_address ".
trace:opengl:wgl_ext_initialize_extensions Server GLX exts : 
"GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer 
GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer 
".
trace:opengl:wgl_ext_initialize_extensions Client GLX exts : 
"GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_visual_info 
GLX_EXT_visual_rating GLX_EXT_import_context GLX_SGI_video_sync 
GLX_NV_swap_group GLX_NV_video_out GLX_SGIX_fbconfig GLX_SGIX_pbuffer 
GLX_SGI_swap_control GLX_NV_float_buffer ".
fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67"
fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info 
GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync 
GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer 
GLX_ARB_get_proc_address "
fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67"
fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67"
fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info 
GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync 
GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer 
GLX_ARB_get_proc_address "
fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info 
GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync 
GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer 
GLX_ARB_get_proc_address "
trace:opengl:wgl_ext_initialize_extensions Supporting following WGL extensions 
: "WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_ARB_pbuffer 
WGL_ARB_pix

Re: World of Warcraft

[Raphael]

On Wednesday 23 March 2005 22:15, [EMAIL PROTECTED] wrote:
> Sorry to keep bugging you guys about this, but a recent patch broke the
> opengl mode of World of Warcraft again.  It simply fails to start, similar
> to the d3d mode (except for the fact that I know why d3d mode doesn't work
> as of now).  I was scanning through the traces and saw no errors though. 
> Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure
> what to look for anyway.  If anyone wants me to send a any sort of debug
> log (if, for instance, you don't have copy of WoW to test on), let me know
> (include what you'd want to see as well, if you don't mind).
>
> Thanks in advance,
> Darckness

Hi,

can you try with this patch ?

Regards,
Raphael

Index: wgl_ext.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
retrieving revision 1.4
diff -u -r1.4 wgl_ext.c
--- wgl_ext.c	10 Mar 2005 11:13:33 -	1.4
+++ wgl_ext.c	23 Mar 2005 22:35:50 -
@@ -31,6 +31,7 @@
 #include "winuser.h"
 #include "winerror.h"
 
+#include "gdi.h"
 #include "wgl.h"
 #include "wgl_ext.h"
 #include "opengl_ext.h"
@@ -133,6 +134,18 @@
   return bTest;
 }
 
+int (*p_glXSwapIntervalSGI)(int);
+BOOL query_function_swap_control(glXGetProcAddressARB_t proc, const char *gl_version, const char *gl_extensions, 
+ const char* glx_version, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+  BOOL bTest = (0 <= strcmp("1.3", glx_version) || NULL != strstr(glx_extensions, "GLX_SGIX_swap_group"));
+  if (bTest) {
+p_glXSwapIntervalSGI = proc("glXSwapIntervalSGI");
+bTest = (NULL != p_glXSwapIntervalSGI);
+  }
+  return bTest;
+}
 /***
  *  wglGetExtensionsStringEXT(OPENGL32.@)
  */
@@ -157,18 +170,21 @@
  *  wglSwapIntervalEXT(OPENGL32.@)
  */
 BOOL WINAPI wglSwapIntervalEXT(int interval) {
-FIXME("(%d),stub!\n", interval);
-
-swap_interval = interval;
-return TRUE;
+  TRACE("(%d)\n", interval);
+  swap_interval = interval;
+  if (NULL != p_glXSwapIntervalSGI) {
+return 0 == p_glXSwapIntervalSGI(interval);
+  }
+  WARN("(): GLX_SGI_swap_control extension seems not supported \n");
+  return TRUE;
 }
 
 /***
  *  wglGetSwapIntervalEXT(OPENGL32.@)
  */
 int WINAPI wglGetSwapIntervalEXT(VOID) {
-FIXME("(),stub!\n");
-return swap_interval;
+  TRACE("() returns %d\n", swap_interval);
+  return swap_interval;
 }
 
 typedef struct wine_glpbuffer {
@@ -226,9 +242,9 @@
 #define WGL_STENCIL_BITS_ARB			0x2023
 #define WGL_AUX_BUFFERS_ARB			0x2024
 
-#define WGL_PBUFFER_WIDTH_ARB0x2034
-#define WGL_PBUFFER_HEIGHT_ARB   0x2035
-#define WGL_PBUFFER_LOST_ARB 0x2036
+#define WGL_PBUFFER_WIDTH_ARB   0x2034
+#define WGL_PBUFFER_HEIGHT_ARB  0x2035
+#define WGL_PBUFFER_LOST_ARB0x2036
 
 #if 0 /* not used yet */
 static unsigned ConvertAttribGLXtoWGL(const int* iWGLAttr, int* oGLXAttr) {
@@ -273,6 +289,7 @@
 case WGL_SAMPLES_ARB:
 */
 default:
+  FIXME("unsupported %x WGL Attribute\n", iWGLAttr[cur]);
   break;
 }
 ++cur;
@@ -282,14 +299,108 @@
 
 GLboolean WINAPI wglGetPixelFormatAttribivARB(HDC hdc, int iPixelFormat, int iLayerPlane, UINT nAttributes, const int *piAttributes, int *piValues)
 {
-TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane, nAttributes, piAttributes, piValues);
-return GL_TRUE;
+  Display* display = get_display( hdc );
+  UINT i;
+  GLXFBConfig* cfgs = NULL;
+  GLXFBConfig  curCfg = NULL;
+  int nCfgs = 0;
+  int hTest;
+  int tmp;
+  int curGLXAttr = 0;
+
+  TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane, nAttributes, piAttributes, piValues);
+  
+  if (0 < iLayerPlane) {
+FIXME("unsupported iLayerPlane(%d) > 0, returns FALSE\n", iLayerPlane);
+return GL_FALSE;
+  }
+
+  cfgs = glXGetFBConfigs(display, DefaultScreen(display), &nCfgs);
+  if (NULL == cfgs) {
+ERR("no FB Configs found for display(%p)\n", display);
+return GL_FALSE;
+  }
+
+  for (i = 0; i < nAttributes; ++i) {
+const int curWGLAttr = piAttributes[i];
+
+switch (curWGLAttr) {
+case WGL_NUMBER_PIXEL_FORMATS_ARB:
+  piValues[i] = nCfgs; 
+  continue ;
+
+case WGL_SUPPORT_OPENGL_ARB:
+  piValues[i] = GL_TRUE; 
+  continue ;
+
+case WGL_TRANSPARENT_ARB:
+  curGLXAttr = GLX_TRANSPARENT_TYPE;
+  if (nCfgs < iPixelFormat) goto pix_error;
+  curCfg = cfgs[iPixelFormat];
+  hTest = glXGetFBConfigAttrib(display, curCfg, curGLXAttr, &tmp);
+  if (hTest) goto get_error;
+  piValues[i] = GL_FALSE;
+  if (GLX_NONE != tmp) piValues[i] = GL_TRUE;
+  continue ;
+  
+case WGL_COLOR_BITS_ARB:
+  curGLXAttr = GLX_BUFFER_

Re: World of Warcraft

[cyrix12]

On Wed, 23 Mar 2005 15:22:46 -0600
James Hawkins <[EMAIL PROTECTED]> wrote:

> On Wed, 23 Mar 2005 16:15:18 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 
> wrote:
> > Sorry to keep bugging you guys about this, but a recent patch broke the 
> > opengl mode of World of Warcraft again.  It simply fails to start, similar 
> > to the d3d mode (except for the fact that I know why d3d mode doesn't work 
> > as of now).  I was scanning through the traces and saw no errors though.  
> > Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure 
> > what to look for anyway.  If anyone wants me to send a any sort of debug 
> > log (if, for instance, you don't have copy of WoW to test on), let me know 
> > (include what you'd want to see as well, if you don't mind).
> 
> Which patch specifically broke WoW?  If you don't know, can you do a
> regression test?
> http://www.winehq.org/site/docs/wine-devel/x1318
> 
> -- 
> James Hawkins

My mistake.  I meant that a World of Warcraft patch from Blizzard broke it, not 
that a wine patch broke it.

Re: World of Warcraft

[James Hawkins]

On Wed, 23 Mar 2005 16:15:18 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Sorry to keep bugging you guys about this, but a recent patch broke the 
> opengl mode of World of Warcraft again.  It simply fails to start, similar to 
> the d3d mode (except for the fact that I know why d3d mode doesn't work as of 
> now).  I was scanning through the traces and saw no errors though.  Seemed 
> odd to me, but I'm not a wine programmer so I'm not exactly sure what to look 
> for anyway.  If anyone wants me to send a any sort of debug log (if, for 
> instance, you don't have copy of WoW to test on), let me know (include what 
> you'd want to see as well, if you don't mind).

Which patch specifically broke WoW?  If you don't know, can you do a
regression test?
http://www.winehq.org/site/docs/wine-devel/x1318

-- 
James Hawkins

Re: World Of Warcraft

[Raphael]

On Tuesday 15 March 2005 10:47, Holly Bostick wrote:
> Noticed this thread on the Rage3D Linux (ATI) Drivers forums:
>
> Fix for WoW in OpenGL mode in wine/cedega (
> http://www.rage3d.com/board/showthread.php?t=33807135 ).
>
> Basically, it seems to involve hex-editing WoW.exe (!!!) to filter out a
> couple of extensions (mainly GL_ARB_vertex_buffer_object), which sounds
> rather horrifying, but does apparently result in vastly improved
> performance in OpenGL mode for ATI users under Wine and Cedega.
>
> Now, I don't play WoW, I'm no programmer, and this may well be an
> ATI-specific issue, but maybe the hack listed here will shed further
> light on the DX9/WoW work currently needed/being done.
>
> Just in case it's useful info that no one happened to see :) . If not,
> please ignore and apologies for the interruption.
>
> Holly

Hi,

well this is an ugly to deactivate GL_ARB_vertex_buffer_object (OpenGL only) 
extension support by game.

If you have correct graphics after that, you have find (another) ATI linux 
driver bug :)

You can send it to ATI guys (they will be happy) :)

Regards,
Raphael

PS: Nvidia drivers seems to have bug on vbo support too (but only on my 
proto) :(


pgpTXBZK6LEa6.pgp
Description: PGP signature

Re: World Of Warcraft

[Holly Bostick]

Noticed this thread on the Rage3D Linux (ATI) Drivers forums:
Fix for WoW in OpenGL mode in wine/cedega ( 
http://www.rage3d.com/board/showthread.php?t=33807135 ).

Basically, it seems to involve hex-editing WoW.exe (!!!) to filter out a 
couple of extensions (mainly GL_ARB_vertex_buffer_object), which sounds 
rather horrifying, but does apparently result in vastly improved 
performance in OpenGL mode for ATI users under Wine and Cedega.

Now, I don't play WoW, I'm no programmer, and this may well be an 
ATI-specific issue, but maybe the hack listed here will shed further 
light on the DX9/WoW work currently needed/being done.

Just in case it's useful info that no one happened to see :) . If not, 
please ignore and apologies for the interruption.

Holly

Re: World of Warcraft - crash in game

[Francois Gouget]

On Wed, 2 Mar 2005, Alex Woods wrote:
[...]
Sound works about the same under both alsa and oss (again alsa oss
emulation).  It's strange that you get no sound from oss.
Sound depends a lot on the sound card. Some sound cards support only 
specific sampling rates while others are more accomodating. And that's 
just one issue, at least on the wineoss side there are a lot of other 
issues such as mmap support, full duplex support and DSP_GETOSPACE 
support that vary from one sound card to the next (and to some extent 
from one Alsa configuration / OSS emulation version to the next) and 
which all cause trouble.


And Wine is way too sensible to these issues, even more so if the 
application uses DirectSound. Part of this is because the Windows API is 
painful to emulate, but part of it is lack of debugging of basic sound. 
Unfortunately, debugging supposes one has a sound configuration that 
does not work which makes it even trickier.

What this means is that each Wine developer who has sound problems can 
essentially only count on himself to debug them. To do so I would 
recommend first checking that winmm works fine:

cd dlls/winmm/tests
make test
and if the above works, do:
WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M winmm.dll -T 
../../.. -p winmm_test.exe.so wave.c

And if the winmm tests worked fine, then do the DirectSound tests:
cd dlls/dsound/tests
make test
already you may have to manually edit the Wine configuration file to set 
HardwareAcceleration = Emulation. That's an heresy, it should be 
automatic. Anyway once you get the above test going, do:

WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M dsound.dll -T 
../../.. -p dsound_test.exe.so dsound.c

I know for a fact that many Wine users are having problems with basic 
not-low-latency stereo sound and unfortunately I have not seen any 
progress on this in the past couple of years (i.e. there are still about 
has many users having problems now as two years ago).


--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
  A black hole is just God dividing by zero.

Re: World of Warcraft - crash in game

[Troy Rollo]

On Thu, 3 Mar 2005 03:43, Alex Woods wrote:
> Unfortunately, I never got to try out this method properly.  WoW has
> it's own dbghelp.dll that it checks on login and that contains different
> functions to wine's dbghelp.  So I got stuck there, but it's not all bad
> news.

In that case you may be able to use GDB directly on the executable (without 
winedbg) and attach after the app has started with 
"gdb /usr/local/bin/wine-pthread process-id". The major drawback of this is 
that it cannot tell the difference between a first chance exception and a 
last chance exception, so if the app uses exception handling you may end up 
using GDB's "pass" command a lot.

Re: World of Warcraft - crash in game

[Alex Woods]

On Wed, Mar 02, 2005 at 06:52:36PM +0100, Paul van Schayck wrote:
> Hey,
> 
> On Wed, 2 Mar 2005 16:43:11 +, Alex Woods <[EMAIL PROTECTED]> wrote:
> > Whilst playing around trying to get some kind of lead, the sound cut out
> > on me whilst playing the game.  I decided to keep going, and the game
> > played for a surprisingly long time.  The next day I booted the game
> > with wine's sound drivers disabled and played for about 10 hours total
> > without a crash (for purely stress-test reasons you understand ;)).
> > I've had a chance to give it a go with the wineoss.drv.so now and that
> > also seems stable, so I guess the problem is in winealsa.drv.so which I
> > had been using.
> 
> I can confirm that. I only managed to get sound working to an
> acceptable rate (ticking, and stutters) with winealsa, no dmix/asym (I
> use that for my no harware mixing soundcard) and dsound hardware
> emulation.
> I will get a lot of these:
> fixme:dsound:DSOUND_MixOne problem with underrun detection
> (mixlen=32768 < primary_done=40572)
> err:dsound:DSOUND_MixOne underrun on sound buffer 0x404071d8

I get a lot of these too, with both winealsa and wineoss, but the rate
seems very acceptable to me with not many ticks and stutters.  I think
also it got better in the last few days, and I notice that a few dsound
changes were made, but I might be imagining things.  I assume the dsound
stuff is cpu bound.

> Without dsound hardware emulation (so plain ALSA) I will get
> stuttering sound. And with wineoss (so, alsa oss emulation) I will not
> get any sound at all.

I just use whatever wine defaults to in that respect.  I have a minimal
config file:

WINE REGISTRY Version 2
[version]
"windows"="winxp"
[WinMM]
"Drivers"="wineoss.drv"
[x11drv]
"DXGrab"="Y"

Sound works about the same under both alsa and oss (again alsa oss
emulation).  It's strange that you get no sound from oss.  The only
visible difference between the drivers from a user level for me is that
alsa makes the game unstable whereas oss does not.

> This is with a 2.6.9 kernel and alsa-driver 1.0.8.

Similar here, alsa driver is whatever version 2.6.9 comes with, but the
libraries are 1.0.7.

-- 
Alex

Re: World of Warcraft - crash in game

[Paul van Schayck]

Hey,

On Wed, 2 Mar 2005 16:43:11 +, Alex Woods <[EMAIL PROTECTED]> wrote:
> Whilst playing around trying to get some kind of lead, the sound cut out
> on me whilst playing the game.  I decided to keep going, and the game
> played for a surprisingly long time.  The next day I booted the game
> with wine's sound drivers disabled and played for about 10 hours total
> without a crash (for purely stress-test reasons you understand ;)).
> I've had a chance to give it a go with the wineoss.drv.so now and that
> also seems stable, so I guess the problem is in winealsa.drv.so which I
> had been using.

I can confirm that. I only managed to get sound working to an
acceptable rate (ticking, and stutters) with winealsa, no dmix/asym (I
use that for my no harware mixing soundcard) and dsound hardware
emulation.
I will get a lot of these:
fixme:dsound:DSOUND_MixOne problem with underrun detection
(mixlen=32768 < primary_done=40572)
err:dsound:DSOUND_MixOne underrun on sound buffer 0x404071d8

And:
ALSA lib pcm_hw.c:590:(snd_pcm_hw_pause) SNDRV_PCM_IOCTL_PAUSE failed:
Function not implemented
err:wave:wodPlayer_ProcessMessages pcm_pause failed: Function not implemented

This last error is probably because of my usb ALSA driver for my usb headset.

Without dsound hardware emulation (so plain ALSA) I will get
stuttering sound. And with wineoss (so, alsa oss emulation) I will not
get any sound at all.

This is with a 2.6.9 kernel and alsa-driver 1.0.8.

Thanks,
Paul

Re: World of Warcraft - crash in game

[Alex Woods]

On Fri, Feb 25, 2005 at 11:07:03AM +1100, Troy Rollo wrote:
> On Fri, 25 Feb 2005 09:22, Alex Woods wrote:
> > Over the course of 13 (unlucky for me ;)) crashes, these are the only 3
> > addresses it has given.  My question is what can I do to debug [target 
> > application SEGVs]. 
> 
> I can't find any good explanation of this either. Googling for "gdb objdump 
> site:winehq.org" gets nothing relevant, and "winedbg objdump" is no better, 
> so it may be that nobody has written an explanation for it before.

Unfortunately, I never got to try out this method properly.  WoW has
it's own dbghelp.dll that it checks on login and that contains different
functions to wine's dbghelp.  So I got stuck there, but it's not all bad
news.

Whilst playing around trying to get some kind of lead, the sound cut out
on me whilst playing the game.  I decided to keep going, and the game
played for a surprisingly long time.  The next day I booted the game
with wine's sound drivers disabled and played for about 10 hours total
without a crash (for purely stress-test reasons you understand ;)).
I've had a chance to give it a go with the wineoss.drv.so now and that
also seems stable, so I guess the problem is in winealsa.drv.so which I
had been using.

I haven't had a chance to try to get some debug logs just for the sound
yet, but when I get the time I will.

Cheers.

-- 
Alex

Re: World of Warcraft - crash in game

[Troy Rollo]

On Fri, 25 Feb 2005 09:22, Alex Woods wrote:
> Over the course of 13 (unlucky for me ;)) crashes, these are the only 3
> addresses it has given.  My question is what can I do to debug [target 
> application SEGVs]. 

I can't find any good explanation of this either. Googling for "gdb objdump 
site:winehq.org" gets nothing relevant, and "winedbg objdump" is no better, 
so it may be that nobody has written an explanation for it before.

This is something that requires a huge amount of patience. Expect to spend 
days (or longer) looking for individual errors. If you don't have that kind 
of patience, you may be better off not trying, but if you do, then this kind 
of thing can be very rewarding when you do succeed.

When debugging a SEGV that occurs in the target application, you need 
familiarity with a number of things.

1. The WINE Developer's Guide 
2. GDB (or in this case, winedbg --gdb)
3. objdump.
4. Intel assembly language (in the AT&T style, not the Intel style, since the
  GNU disassembly code for Intel style output is broken for some addressing
  modes and has been for years).

Once you are familiar with these, the procedures for debugging an application 
SEGV are:

1. Get an assembly listing of the target program. You will need to refer to
this while debugging.

 $ objdump --disassemble program.exe > program.asm

2. Make sure you have BreakOnFirstChance turned OFF. Windows
   applications often generate first chance exceptions routinely, and it's
   rarely helpful to stop the debugger for them. See section 1.5.2 of the
   WINE Developer's Guide to find out how to turn this off.

3. Start the application in GDB:

   a. The simple way:

  $ winedbg --gdb program.exe

   b. The better way when debugging a game is to run the debugger
   from another keyboard or monitor (such as from an ssh connection
   from another machine), the reason being games tend to do funny
   things to the display that may make it impractical to debug. In this
   case, you need to set the DISPLAY variable to make the game run
   on the X display. I generally use a laptop and ssh to the desktop:

 [EMAIL PROTECTED] $ ssh desktop
 Password:
 [EMAIL PROTECTED] $ cd .wine/c/gamedir
 [EMAIL PROTECTED] $ DISPLAY=:0 winedbg --gdb program.exe

4. Run the program until you generate the SEGV

 gdb> run

5. When you get the SEGV, you need to trace the source of the value that
caused the problem. This will involve a number of things:

 a. Tracing values through register assignments and local variables.
 This is fairly straight-forward.

 b. Tracing values back through earlier function calls (usually requires
  setting a breakpoint, possibly a conditional one, in the caller).

 c. Tracing values set into global variables. Usually involves searching
 the assembly listing generated in step 1 and then putting break points
 on all the locations that set the variable.

 d. In some situations you will need to use GDB's watch points, but this
 can be very slow and should be used as a last resort.

   The aim here is to find some value returned from WINE that caused the
   value that caused the SEGV.

Re: World Of Warcraft

[Raphael]

On Wednesday 23 February 2005 10:26, Alex Woods wrote:
> I owe you a beer!

I'm waiting you :)

> It works great.  No crash, and the minimap is there looking how I think
> it should (don't have windows or cedega so it's the first time I've seen
> inside the game properly).  Unfortunately, wine crashes out if I move
> the mouse to another display.  so I can't take a screenshot for you :(
> I'll take a look at that later when I've got more time.  The minimap
> even works indoors (I think start rooms count as indoors), which is
> apparently something that doesn't work in cedega in opengl mode ;)

good news :)
Happy gaming

> There were a couple of compile warnings, but nothing to worry about:
> wgl_ext.c: In function `wglCreatePbufferARB':
> wgl_ext.c:335: warning: format argument is not a pointer (arg 5)
> wgl_ext.c:312: warning: unused variable `bmp'
> wgl_ext.c: At top level:
> wgl_ext.c:218: warning: 'ConvertAttribGLXtoWGL' defined but not used.

don't worry i'll clean it on the real patch

Regards,
Raphael


pgp8cbKclHgfy.pgp
Description: PGP signature

Re: World Of Warcraft

[Raphael]

On Wednesday 23 February 2005 22:32, Troy Rollo wrote:
> On Wed, 23 Feb 2005 19:59, Raphael wrote:
> > On Tuesday 22 February 2005 03:10, Troy Rollo wrote:
> > > Nope. That typo was mine.
> >
> > lol sorry for mismatch :)
> >
> > i'll give you copyright :)
>
> Well I wouldn't want to let somebody else take the blame for my mistakes.
> I'll leave that sort of thing to a certain person who isn't really from my
> local area but votes there anyway.

:)

Regards,
Raphael


pgpzJPJbqyGQf.pgp
Description: PGP signature

Re: World Of Warcraft

[Troy Rollo]

On Wed, 23 Feb 2005 19:59, Raphael wrote:
> On Tuesday 22 February 2005 03:10, Troy Rollo wrote:
> >
> > Nope. That typo was mine.
>
> lol sorry for mismatch :)
>
> i'll give you copyright :)

Well I wouldn't want to let somebody else take the blame for my mistakes. I'll 
leave that sort of thing to a certain person who isn't really from my local 
area but votes there anyway.

Re: World Of Warcraft

[Alex Woods]

On Wed, Feb 23, 2005 at 09:26:25AM +, Alex Woods wrote:
> inside the game properly).  Unfortunately, wine crashes out if I move
> the mouse to another display.  so I can't take a screenshot for you :(

It really doesn't like losing focus from the game, I'll try and get some
logs together later, but in the meantime I managed to get some
screenshots.  You can see them here:

http://www.linux-gamers.net/modules/news/article.php?storyid=707

Thanks very much to everyone who helped get it working.  Great patch,
Raphael :)

-- 
Alex

Re: World Of Warcraft

[Alex Woods]

On Wed, Feb 23, 2005 at 10:03:56AM +0100, Raphael wrote:
> > It looks as though it's the Pbuffer stuff it is after.  Right after all
> > those wglGetProcAddress it does this:
> >
> > trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c)
> > trace:opengl:wglGetPbufferDCARB ((nil))
> >
> > So I guess it could be setting up stuff for the minimap long before it
> > gets into the actual game.
> 
> And it don't crash (we returns a NULL ptr!!) ?
> 
> > Have you actually started on the Pbuffer code now Raphael?  If you have,
> > is there anything I can do to help?  At the very least I have a testbed
> > I suppose ;)
> 
> only a better patch (attached)
> i don't think if it a valid way to do it (maybe an x11drv expert may look it)

I owe you a beer!

It works great.  No crash, and the minimap is there looking how I think
it should (don't have windows or cedega so it's the first time I've seen
inside the game properly).  Unfortunately, wine crashes out if I move
the mouse to another display.  so I can't take a screenshot for you :(
I'll take a look at that later when I've got more time.  The minimap
even works indoors (I think start rooms count as indoors), which is
apparently something that doesn't work in cedega in opengl mode ;)

There were a couple of compile warnings, but nothing to worry about:
wgl_ext.c: In function `wglCreatePbufferARB':
wgl_ext.c:335: warning: format argument is not a pointer (arg 5)
wgl_ext.c:312: warning: unused variable `bmp'
wgl_ext.c: At top level:
wgl_ext.c:218: warning: 'ConvertAttribGLXtoWGL' defined but not used.



-- 
Alex

Re: World Of Warcraft

[Raphael]

On Monday 21 February 2005 22:46, Lionel Ulmer wrote:
> On Mon, Feb 21, 2005 at 09:25:05PM +, Alex Woods wrote:
> > It looks as though it's the Pbuffer stuff it is after.  Right after all
> > those wglGetProcAddress it does this:
> >
> > trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c)
> > trace:opengl:wglGetPbufferDCARB ((nil))
>
> Ah ah !! Now we have some motivation to actually work on PBuffers... Now
> who, from Raphael, Olivier or me will send the patch first :-) ?

I'm waitiing you :)
i have some d3d/dmusic work while you are surfing

>Lionel

Regards,
Raphael


pgpVTSTDIG24h.pgp
Description: PGP signature

Re: World Of Warcraft

[Raphael]

Hi

> It looks as though it's the Pbuffer stuff it is after.  Right after all
> those wglGetProcAddress it does this:
>
> trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c)
> trace:opengl:wglGetPbufferDCARB ((nil))
>
> So I guess it could be setting up stuff for the minimap long before it
> gets into the actual game.

And it don't crash (we returns a NULL ptr!!) ?

> Have you actually started on the Pbuffer code now Raphael?  If you have,
> is there anything I can do to help?  At the very least I have a testbed
> I suppose ;)

only a better patch (attached)
i don't think if it a valid way to do it (maybe an x11drv expert may look it)

Regards,
Raphael
Index: wgl_ext.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
retrieving revision 1.2
diff -u -r1.2 wgl_ext.c
--- wgl_ext.c	31 Jan 2005 11:32:13 -	1.2
+++ wgl_ext.c	23 Feb 2005 08:55:47 -
@@ -29,6 +29,7 @@
 #include "winuser.h"
 #include "winerror.h"
 
+#include "gdi.h"
 #include "wgl.h"
 #include "wgl_ext.h"
 #include "opengl_ext.h"
@@ -37,15 +38,82 @@
 
 WINE_DEFAULT_DEBUG_CHANNEL(opengl);
 
+
+/* x11drv GDI escapes */
+#define X11DRV_ESCAPE 6789
+enum x11drv_escape_codes
+{
+X11DRV_GET_DISPLAY,   /* get X11 display for a DC */
+X11DRV_GET_DRAWABLE,  /* get current drawable for a DC */
+X11DRV_GET_FONT,  /* get current X font for a DC */
+X11DRV_SET_DRAWABLE, /* set current drawable for a DC */
+};
+struct x11drv_escape_set_drawable
+{
+enum x11drv_escape_codes code; /* escape code (X11DRV_SET_DRAWABLE) */
+Drawable drawable; /* X drawable */
+int  mode; /* ClipByChildren or IncludeInferiors */
+POINTorg;  /* origin of DC relative to drawable */
+POINTdrawable_org; /* origin of drawable relative to screen */
+};
+
+/* retrieve the X display to use on a given DC */
+inline static Display *get_display( HDC hdc )
+{
+Display *display;
+enum x11drv_escape_codes escape = X11DRV_GET_DISPLAY;
+
+if (!ExtEscape( hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape,
+sizeof(display), (LPSTR)&display )) display = NULL;
+return display;
+}
+inline static void set_drawable( HDC hdc, Drawable drawable )
+{
+struct x11drv_escape_set_drawable escape;
+
+escape.code = X11DRV_SET_DRAWABLE;
+escape.drawable = drawable;
+escape.mode = IncludeInferiors;
+escape.org.x = escape.org.y = 0;
+escape.drawable_org.x = escape.drawable_org.y = 0;
+
+ExtEscape( hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL );
+}
+
 /* Some WGL extensions... */
 static const char *WGL_extensions_base = "WGL_ARB_extensions_string WGL_EXT_extensions_string";
 static char *WGL_extensions = NULL;
 
 /* Extensions-query functions */
-BOOL query_function_pbuffers(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
-			 const char *server_glx_extensions, const char *client_glx_extensions)
+BOOL query_function_multisample(const char *gl_version, const char *gl_extensions, 
+const char* glx_version, const char *glx_extensions,
+const char *server_glx_extensions, const char *client_glx_extensions)
 {
-return FALSE;
+  return NULL != strstr("GLX_ARB_multisample", glx_extensions);
+}
+
+BOOL query_function_pbuffer(const char *gl_version, const char *gl_extensions, 
+			const char* glx_version, const char *glx_extensions,
+			const char *server_glx_extensions, const char *client_glx_extensions)
+{
+  FIXME("gl_version is: \"%s\"\n", gl_version);
+  FIXME("glx_exts is: \"%s\"\n", glx_extensions);
+
+  return 0 <= strcmp("1.3", glx_version) || NULL != strstr(glx_extensions, "GLX_SGIX_pbuffer");
+}
+
+BOOL query_function_pixel_format(const char *gl_version, const char *gl_extensions, 
+ const char* glx_version, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+  return TRUE;
+}
+
+BOOL query_function_render_texture(const char *gl_version, const char *gl_extensions, 
+   const char* glx_version, const char *glx_extensions,
+   const char *server_glx_extensions, const char *client_glx_extensions)
+{
+  return 0 <= strcmp("1.3", glx_version) || NULL != strstr(glx_extensions, "GLX_SGIX_pbuffer");
 }
 
 /***
@@ -86,12 +154,285 @@
 return swap_interval;
 }
 
+typedef struct wine_glpbuffer {
+  Drawable   drawable;
+  Display*   display;
+  intpixelFormat;
+  intwidth;
+  intheight;
+  int*   attribList;
+  HDChdc;
+  HBITMAPhbmp;
+  void*  save_pixmap;
+} Wine_GLPBuffer;
+
+#define PUSH1(attribs,att)attribs[nAttribs++] = (att); 
+#define PUSH2(attribs,att,value)  attribs[nAttribs++] = (att); attribs[nAttribs++] = (value);
+
+#define WGL_NUMBER_PIXEL_FORMATS_ARB		0x2

Re: World Of Warcraft

[Raphael]

On Monday 21 February 2005 22:50, Lionel Ulmer wrote:
> > >I have absolutely no understanding of this but in the list at the
> > >end of your patch mailed to the list there is...
> > >
> > > { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL,
> > > NULL},
> > >
> > >and 5 lines later
> > >
> > > { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}
> > >
> > >Since it's the only entry where the string and
> > >pointer/function/object/structure/whatever don't match I wondered it
> > >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather
> > >than.
> >
> > You are right
> > Seems that lionel made a typo :)
>
> Oh, I will let you fix it when you send the PBuffer patch in with REAL
> working code this time :-)

well i'll send a patch, but i don't know if it works well

Regards,
Raphael

> Lionel


pgp9LdBfNroI1.pgp
Description: PGP signature

Re: World Of Warcraft

[Raphael]

On Monday 21 February 2005 21:53, Alex Woods wrote:
> On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote:
> > Ouppsss
> >
> > better patch
>
> Thanks, and good timing - I was just about to go and debug it ;)

:)

> The new patch gives the following wglGetProcAddress stuff, which looks
> more like it (chopping the top bits off):

Good news

Regards,
Raphael


pgpjuwJU8JHk9.pgp
Description: PGP signature

Re: World Of Warcraft

[Raphael]

On Tuesday 22 February 2005 03:10, Troy Rollo wrote:
> On Tue, 22 Feb 2005 09:22, [EMAIL PROTECTED] wrote:
> > >Since it's the only entry where the string and
> > >pointer/function/object/structure/whatever don't match I wondered it
> > >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather
> > >than.
> >
> > You are right
> > Seems that lionel made a typo :)
>
> Nope. That typo was mine.

lol sorry for mismatch :)

i'll give you copyright :)

Regards,
Raphael


pgpxylkKT02Kb.pgp
Description: PGP signature

Re: World Of Warcraft

[Troy Rollo]

On Tue, 22 Feb 2005 09:22, [EMAIL PROTECTED] wrote:

> >Since it's the only entry where the string and
> >pointer/function/object/structure/whatever don't match I wondered it
> >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather
> >than.
>
> You are right
> Seems that lionel made a typo :)

Nope. That typo was mine.

Re: Re: World Of Warcraft

[Lionel Ulmer]

> >I have absolutely no understanding of this but in the list at the
> >end of your patch mailed to the list there is...
> >
> > { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL},
> >
> >and 5 lines later
> >
> > { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}
> >
> >Since it's the only entry where the string and
> >pointer/function/object/structure/whatever don't match I wondered it
> >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather
> >than.
> >
> 
> You are right
> Seems that lionel made a typo :)

Oh, I will let you fix it when you send the PBuffer patch in with REAL
working code this time :-)

Lionel

-- 
 Lionel Ulmer - http://www.bbrox.org/

Re: Re: World Of Warcraft

[Lionel Ulmer]

On Mon, Feb 21, 2005 at 10:19:42PM +, [EMAIL PROTECTED] wrote:
> GL_VERSION isn't pertinent as it contains (only) provider and 
> driver version while GLX_VERSION is really the version string of GLX impl. 

Well, on my machine:

OpenGL version string: 1.4.0 NVIDIA 43.63

So it gives you, at least, the OpenGL version which may be different from
the GLX version.

Lionel

-- 
 Lionel Ulmer - http://www.bbrox.org/

Re: World Of Warcraft

[Lionel Ulmer]

On Mon, Feb 21, 2005 at 09:25:05PM +, Alex Woods wrote:
> It looks as though it's the Pbuffer stuff it is after.  Right after all
> those wglGetProcAddress it does this:
> 
> trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c)
> trace:opengl:wglGetPbufferDCARB ((nil))

Ah ah !! Now we have some motivation to actually work on PBuffers... Now
who, from Raphael, Olivier or me will send the patch first :-) ?

   Lionel

-- 
 Lionel Ulmer - http://www.bbrox.org/

Re: Re: World Of Warcraft

[fenix]

Message d'origine
>De: Colin Wright <[EMAIL PROTECTED]>
>A: Raphael <[EMAIL PROTECTED]>
>Sujet: Re: World Of Warcraft
>Date: Mon, 21 Feb 2005 21:07:14 +
>
>Raphael wrote:
>
>> Ouppsss
>> 
>> better patch
>> 
>> sorry
>> 
>> Regards,
>> Raphael
>> 
>> On Monday 21 February 2005 09:58, Alex Woods wrote:
>>> On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
>>> > can you try this patch ?
>>>
>>> Yes, doesn't look any different though.  I did notice that with either
>>> patch I get this though:
>>>
>>> 0009:warn:opengl:wglGetProcAddress Did not find extension
>>> wglGetExtensionsStringARB in either Wine or your OpenGL library.
>>>
>>> Whereas without the patches I get this:
>>>
>>> 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB)
>>> 0009:trace:opengl:wglGetProcAddress  returning WGL function (0x561cbf90)
>>> 0009:trace:opengl:wglGetCurrentDC ()
>>> 0009:trace:opengl:wglGetCurrentDC  returning 0x7b8 (GL context 0x780d7fd8
>>> - Wine context 0x5593f478) 0009:trace:opengl:wglGetExtensionsStringARB ()
>>> returning "WGL_ARB_extensions_string WGL_EXT_extensions_string"
>>>
>>> So something must be broken ;)
>
>I have absolutely no understanding of this but in the list at the
>end of your patch mailed to the list there is...
>
> { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL},
>
>and 5 lines later
>
> { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}
>
>Since it's the only entry where the string and
>pointer/function/object/structure/whatever don't match I wondered it
>"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather
>than.
>

You are right
Seems that lionel made a typo :)

Thx

Regards,
Raphael

Re: World Of Warcraft

[Alex Woods]

On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote:
> Ouppsss
> 
> better patch

It looks as though it's the Pbuffer stuff it is after.  Right after all
those wglGetProcAddress it does this:

trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c)
trace:opengl:wglGetPbufferDCARB ((nil))

So I guess it could be setting up stuff for the minimap long before it
gets into the actual game.

Have you actually started on the Pbuffer code now Raphael?  If you have,
is there anything I can do to help?  At the very least I have a testbed
I suppose ;)

-- 
Alex

Re: Re: World Of Warcraft

[fenix]

Hi lionel,

GL_VERSION isn't pertinent as it contains (only) provider and 
driver version while GLX_VERSION is really the version string of GLX impl. 

Regards,
Raphael

Message d'origine
>De: Lionel Ulmer <[EMAIL PROTECTED]>
>A: Raphael <[EMAIL PROTECTED]>
>Copie à: Alex Woods <[EMAIL PROTECTED]>, wine-devel@winehq.org
>Sujet: Re: World Of Warcraft
>Date: Mon, 21 Feb 2005 21:44:31 +0100
>
>On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote:
>> Ouppsss
>> 
>> better patch
>
>Why did you do this change:
>
>-const char *gl_version = (const char *) glGetString(GL_VERSION);
>+const char *gl_version = glXGetClientString(display, GLX_VERSION);
>
>I.e. replacing the GL version with the one of GLX ? Maybe the GLX version is
>needed, but we could then log both of them and not replace GL by GLX.
>
> Lionel
>
>-- 
>Lionel Ulmer - http://www.bbrox.org/
>
>

Re: World Of Warcraft

[Alex Woods]

On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote:
> Ouppsss
> 
> better patch

Thanks, and good timing - I was just about to go and debug it ;)

The new patch gives the following wglGetProcAddress stuff, which looks
more like it (chopping the top bits off):

trace:opengl:wglGetProcAddress (glIsProgramNV)
trace:opengl:wglGetProcAddress  returning function  (0x561a0810)
trace:opengl:wglGetProcAddress (GetProgramivNV)
warn:opengl:wglGetProcAddress Did not find extension GetProgramivNV in either 
Wine or your OpenGL library.
trace:opengl:wglGetProcAddress (glVertexAttribPointerNV)
trace:opengl:wglGetProcAddress  returning function  (0x561b6590)
trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc150)
trace:opengl:wglGetCurrentDC ()
trace:opengl:wglGetCurrentDC  returning 0x7b8 (GL context 0x780d7fb8 - Wine 
context 0x5593f4c8)
trace:opengl:wglGetExtensionsStringARB () returning "WGL_ARB_extensions_string 
WGL_EXT_extensions_string WGL_ARB_pbuffer WGL_ARB_pixel_format 
WGL_ARB_render_texture"
trace:opengl:wglGetProcAddress (wglGetPixelFormatAttribivARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc2a0)
trace:opengl:wglGetProcAddress (wglGetPixelFormatAttribfvARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc330)
trace:opengl:wglGetProcAddress (wglChoosePixelFormatARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc3c0)
trace:opengl:wglGetProcAddress (wglCreatePbufferARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc450)
trace:opengl:wglGetProcAddress (wglGetPbufferDCARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc4d0)
trace:opengl:wglGetProcAddress (wglReleasePbufferDCARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc530)
trace:opengl:wglGetProcAddress (wglDestroyPbufferARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc5a0)
trace:opengl:wglGetProcAddress (wglQueryPbufferARB)
trace:opengl:wglGetProcAddress  returning WGL function  (0x561cc610)
trace:opengl:wine_glGetIntegerv (34047, 0x5a4582e0)
trace:opengl:wine_glGetFloatv (34045, 0x5a4582ec)

-- 
Alex

Re: World Of Warcraft

[Lionel Ulmer]

On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote:
> Ouppsss
> 
> better patch

Why did you do this change:

-const char *gl_version = (const char *) glGetString(GL_VERSION);
+const char *gl_version = glXGetClientString(display, GLX_VERSION);

I.e. replacing the GL version with the one of GLX ? Maybe the GLX version is
needed, but we could then log both of them and not replace GL by GLX.

 Lionel

-- 
 Lionel Ulmer - http://www.bbrox.org/

Re: World Of Warcraft

[Raphael]

Ouppsss

better patch

sorry

Regards,
Raphael

On Monday 21 February 2005 09:58, Alex Woods wrote:
> On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
> > can you try this patch ?
>
> Yes, doesn't look any different though.  I did notice that with either
> patch I get this though:
>
> 0009:warn:opengl:wglGetProcAddress Did not find extension
> wglGetExtensionsStringARB in either Wine or your OpenGL library.
>
> Whereas without the patches I get this:
>
> 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB)
> 0009:trace:opengl:wglGetProcAddress  returning WGL function (0x561cbf90)
> 0009:trace:opengl:wglGetCurrentDC ()
> 0009:trace:opengl:wglGetCurrentDC  returning 0x7b8 (GL context 0x780d7fd8 -
> Wine context 0x5593f478) 0009:trace:opengl:wglGetExtensionsStringARB ()
> returning "WGL_ARB_extensions_string WGL_EXT_extensions_string"
>
> So something must be broken ;)
Index: wgl_ext.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
retrieving revision 1.2
diff -u -r1.2 wgl_ext.c
--- wgl_ext.c	31 Jan 2005 11:32:13 -	1.2
+++ wgl_ext.c	21 Feb 2005 20:38:15 -
@@ -42,10 +42,31 @@
 static char *WGL_extensions = NULL;
 
 /* Extensions-query functions */
-BOOL query_function_pbuffers(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
-			 const char *server_glx_extensions, const char *client_glx_extensions)
+BOOL query_function_multisample(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
+const char *server_glx_extensions, const char *client_glx_extensions)
 {
-return FALSE;
+  return NULL != strstr("GLX_ARB_multisample", glx_extensions);
+}
+
+BOOL query_function_pbuffer(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
+			const char *server_glx_extensions, const char *client_glx_extensions)
+{
+  FIXME("gl_version is: \"%s\"\n", gl_version);
+  FIXME("glx_exts is: \"%s\"\n", glx_extensions);
+
+  return 0 <= strcmp("1.3", gl_version) || NULL != strstr(glx_extensions, "GLX_SGIX_pbuffer");
+}
+
+BOOL query_function_pixel_format(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+  return TRUE;
+}
+
+BOOL query_function_render_texture(const char *gl_version, const char *gl_extensions, const char *glx_extensions,
+   const char *server_glx_extensions, const char *client_glx_extensions)
+{
+  return 0 <= strcmp("1.3", gl_version) || NULL != strstr(glx_extensions, "GLX_SGIX_pbuffer");
 }
 
 /***
@@ -86,12 +107,176 @@
 return swap_interval;
 }
 
+typedef struct wine_glpbuffer {
+  Drawable   drawable;
+  intpixelFormat;
+  intwidth;
+  intheight;
+  int*   attribList;
+} Wine_GLPBuffer;
+
+#define PUSH1(attribs,att)attribs[nAttribs++] = (att); 
+#define PUSH2(attribs,att,value)  attribs[nAttribs++] = (att); attribs[nAttribs++] = (value);
+
+#define WGL_NUMBER_PIXEL_FORMATS_ARB		0x2000
+#define WGL_DRAW_TO_WINDOW_ARB			0x2001
+#define WGL_DRAW_TO_BITMAP_ARB			0x2002
+#define WGL_ACCELERATION_ARB			0x2003
+#define WGL_NEED_PALETTE_ARB			0x2004
+#define WGL_NEED_SYSTEM_PALETTE_ARB		0x2005
+#define WGL_SWAP_LAYER_BUFFERS_ARB		0x2006
+#define WGL_SWAP_METHOD_ARB			0x2007
+#define WGL_NUMBER_OVERLAYS_ARB			0x2008
+#define WGL_NUMBER_UNDERLAYS_ARB		0x2009
+#define WGL_TRANSPARENT_ARB			0x200A
+#define WGL_TRANSPARENT_RED_VALUE_ARB		0x2037
+#define WGL_TRANSPARENT_GREEN_VALUE_ARB		0x2038
+#define WGL_TRANSPARENT_BLUE_VALUE_ARB		0x2039
+#define WGL_TRANSPARENT_ALPHA_VALUE_ARB		0x203A
+#define WGL_TRANSPARENT_INDEX_VALUE_ARB		0x203B
+#define WGL_SHARE_DEPTH_ARB			0x200C
+#define WGL_SHARE_STENCIL_ARB			0x200D
+#define WGL_SHARE_ACCUM_ARB			0x200E
+#define WGL_SUPPORT_GDI_ARB			0x200F
+#define WGL_SUPPORT_OPENGL_ARB			0x2010
+#define WGL_DOUBLE_BUFFER_ARB			0x2011
+#define WGL_STEREO_ARB0x2012
+#define WGL_PIXEL_TYPE_ARB			0x2013
+#define WGL_COLOR_BITS_ARB			0x2014
+#define WGL_RED_BITS_ARB			0x2015
+#define WGL_RED_SHIFT_ARB			0x2016
+#define WGL_GREEN_BITS_ARB			0x2017
+#define WGL_GREEN_SHIFT_ARB			0x2018
+#define WGL_BLUE_BITS_ARB			0x2019
+#define WGL_BLUE_SHIFT_ARB			0x201A
+#define WGL_ALPHA_BITS_ARB			0x201B
+#define WGL_ALPHA_SHIFT_ARB			0x201C
+#define WGL_ACCUM_BITS_ARB			0x201D
+#define WGL_ACCUM_RED_BITS_ARB			0x201E
+#define WGL_ACCUM_GREEN_BITS_ARB		0x201F
+#define WGL_ACCUM_BLUE_BITS_ARB			0x2020
+#define WGL_ACCUM_ALPHA_BITS_ARB		0x2021
+#define WGL_DEPTH_BITS_ARB			0x2022
+#define WGL_STENCIL_BITS_ARB			0x2023
+#define WGL_AUX_BUFFERS_ARB			0x2024
+
+static void ConvertAttrib(const int* iWGLAttr, int* oGLXAttr) {
+  unsigned nAttribs = 0;
+
+  int pop;
+  while (0 != iWGLAttr[nAttribs]) {
+switch (iWGLAttr[nAttribs]) {
+case WGL_COLOR_BITS_ARB:
+  pop = iWGLAttr[++nAttribs];
+  P

Re: World Of Warcraft

[Alex Woods]

On Mon, Feb 21, 2005 at 10:58:31AM +0100, Lionel Ulmer wrote:
> Can you send me the same snippet of log but with the patch you sent the
> other day ? It's just to be sure that it correctly advertises the three new
> extensions you added in your patch :)
> 
> If all the wglGetProcAddress lines were in the log too, it would even be
> better (i.e. even if the application does not use the new functions, we can
> check if it even tries to get new ones compared to a log without your
> patch).

grep -C 2 "wglGetProcAddress" dump-1.txt:

0009:trace:opengl:wine_glGetString (7938)
0009:trace:opengl:wine_glGetString (7939)
0009:trace:opengl:wglGetProcAddress (glLockArraysEXT)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561a14b0)
0009:trace:opengl:wglGetProcAddress (glUnlockArraysEXT)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561b12d0)
0009:trace:opengl:wine_glGetIntegerv (34018, 0xa2b680)
0009:trace:opengl:wglGetProcAddress (glActiveTextureARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56190a50)
0009:trace:opengl:wglGetProcAddress (glClientActiveTextureARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56192e40)
0009:trace:opengl:wglGetProcAddress (glCompressedTexImage2DARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56194990)
0009:trace:opengl:wglGetProcAddress (glCompressedTexSubImage2DARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56194f00)
0009:trace:opengl:wglGetProcAddress (glBindBufferARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56191770)
0009:trace:opengl:wglGetProcAddress (glDeleteBuffersARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56196620)
0009:trace:opengl:wglGetProcAddress (glGenBuffersARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56199cb0)
0009:trace:opengl:wglGetProcAddress (glBufferDataARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56192a70)
0009:trace:opengl:wglGetProcAddress (glBufferSubDataARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56192c60)
0009:trace:opengl:wglGetProcAddress (glMapBufferARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561a16f0)
0009:trace:opengl:wglGetProcAddress (glUnmapBufferARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561b13e0)
0009:trace:opengl:wglGetProcAddress (glDrawRangeElementsEXT)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56197a30)
0009:trace:opengl:wine_glGetIntegerv (33000, 0x55bdfc50)
0009:trace:opengl:wine_glGetIntegerv (33001, 0x55bdfc44)
0009:trace:opengl:wglGetProcAddress (glCombinerInputNV)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561940f0)
0009:trace:opengl:wglGetProcAddress (glCombinerOutputNV)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561941b0)
0009:trace:opengl:wglGetProcAddress (glFinalCombinerInputNV)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561983f0)
0009:trace:opengl:wglGetProcAddress (glCombinerParameterfvNV)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56194360)
0009:trace:opengl:wglGetProcAddress (glCombinerParameteriNV)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561943f0)
0009:trace:opengl:wglGetProcAddress (glCombinerStageParameterfvNV)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56194510)
0009:trace:opengl:wglGetProcAddress (glProgramStringARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561a9010)
0009:trace:opengl:wglGetProcAddress (glBindProgramARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56191a40)
0009:trace:opengl:wglGetProcAddress (glProgramLocalParameter4fvARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561a8830)
0009:trace:opengl:wglGetProcAddress (glDeleteProgramsARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56196ae0)
0009:trace:opengl:wglGetProcAddress (glGenProgramsARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56199f70)
0009:trace:opengl:wglGetProcAddress (glIsProgramARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561a0880)
0009:trace:opengl:wglGetProcAddress (glGetProgramivARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x5619dc00)
0009:trace:opengl:wine_glGetIntegerv (34929, 0xa2b67c)
0009:trace:opengl:wine_glGetIntegerv (34930, 0xa2b678)
0009:trace:opengl:wglGetProcAddress (glVertexAttribPointerARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561b65a0)
0009:trace:opengl:wglGetProcAddress (glEnableVertexAttribArrayARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56197e90)
0009:trace:opengl:wglGetProcAddress (glDisableVertexAttribArrayARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x56197310)
0009:trace:opengl:wglGetProcAddress (glProgramStringARB)
0009:trace:opengl:wglGetProcAddress  returning function  (0x561a9010)
0009:trace:opengl:wglGetProcAddress (glBindProgramARB)
0009:trace:opengl:wglGetProcAddress  returning f

Re: World Of Warcraft

[Lionel Ulmer]

On Mon, Feb 21, 2005 at 08:58:26AM +, Alex Woods wrote:
> Yes, doesn't look any different though.  I did notice that with either
> patch I get this though:
> 
> 0009:warn:opengl:wglGetProcAddress Did not find extension 
> wglGetExtensionsStringARB in either Wine or your OpenGL library.
> 
> Whereas without the patches I get this:
> 
> 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB)
> 0009:trace:opengl:wglGetProcAddress  returning WGL function (0x561cbf90)
> 0009:trace:opengl:wglGetCurrentDC ()
> 0009:trace:opengl:wglGetCurrentDC  returning 0x7b8 (GL context 0x780d7fd8 - 
> Wine context 0x5593f478)
> 0009:trace:opengl:wglGetExtensionsStringARB () returning 
> "WGL_ARB_extensions_string WGL_EXT_extensions_string"
> 
> So something must be broken ;)

Can you send me the same snippet of log but with the patch you sent the
other day ? It's just to be sure that it correctly advertises the three new
extensions you added in your patch :)

If all the wglGetProcAddress lines were in the log too, it would even be
better (i.e. even if the application does not use the new functions, we can
check if it even tries to get new ones compared to a log without your
patch).

Lionel

-- 
 Lionel Ulmer - http://www.bbrox.org/

Re: World Of Warcraft

[Lionel Ulmer]

On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
> Hi Alex,
> 
> can you try this patch ?

Well, as even with adding the new extensions in the string reported to the
application via wglQueryExtensionStrings it does not try to get these
extensions, I wonder if the problem is really related to our GL support or
if it does not come from somewhere else (it does a lot of strange stuff like
SuspendThread and co around the time it returns the error - no idea if it's
part of their 'assert' procedure or if it is 'normal').

Or maybe it's not waiting for either PBuffers or render-to-texture but
another extension (and then it should fail at the start, not after logging
to the game). So we could add all known WGL extensions to the list and see
what happens :-)

Lionel

-- 
 Lionel Ulmer - http://www.bbrox.org/

Re: World Of Warcraft

[Alex Woods]

On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
> can you try this patch ?

Yes, doesn't look any different though.  I did notice that with either
patch I get this though:

0009:warn:opengl:wglGetProcAddress Did not find extension 
wglGetExtensionsStringARB in either Wine or your OpenGL library.

Whereas without the patches I get this:

0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB)
0009:trace:opengl:wglGetProcAddress  returning WGL function (0x561cbf90)
0009:trace:opengl:wglGetCurrentDC ()
0009:trace:opengl:wglGetCurrentDC  returning 0x7b8 (GL context 0x780d7fd8 - 
Wine context 0x5593f478)
0009:trace:opengl:wglGetExtensionsStringARB () returning 
"WGL_ARB_extensions_string WGL_EXT_extensions_string"

So something must be broken ;)

-- 
Alex

Re: World Of Warcraft

[Paul van Schayck]

Hey Alex,

On Mon, 21 Feb 2005 09:33:29 +0100, Raphael <[EMAIL PROTECTED]> wrote:
> Hi Alex,
> 
> can you try this patch ?

Just applied and tried. It doesn't seem to get the game any further. I
can provide you with a log if you like.

Paul

Re: World Of Warcraft

[Raphael]

Hi Alex,

can you try this patch ?

Regards,
Raphael


> On Sun, Feb 20, 2005 at 01:43:44PM +0100, Lionel Ulmer wrote:
> > Well, if you want just to test if the application works better, just add
> > (stubbed) support for the following extensions:
> >
> > http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pixel_format.txt
> > http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pbuffer.txt
> > http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_render_texture.tx
> >t
> >
> > This entails:
> >
> >  = adding the string for the extension in the WGL extension string (no
> > idea if it needs to be duplicated also in the 'standard' extension
> > string). = adding all functions that are described in the three preceding
> > extensions (having them returning correct values) and printing debug
> > output = run the game again and see if it actually uses now these
> > functions and if it works better (ie better in 'not crashing', not better
> > as in 'working'
> >
> >:-) ).
>
> Well, I've given it a try, but they're either not getting called, or I
> haven't implemented them correctly (first time hacking wine).  I've
> included a patch below showing what I've done.  A few of them don't
> return nice values, but I figured it should get to the traces if they
> are getting called.
>
> > > I guess it's not just a case of passing through like the bulk of the
> > > opengl functions or they'd be done already.
> >
> > For PBuffers, the WGL and SGIX interface is a bit different so an
> > adaptation is required. For 'render to texture', one needs to use
> > 'GL_EXT_framebuffer_object' (or PBuffers) to emulate the extension.
> >
> > So this is not the 'simple' thunking that most of the rest of the OpenGL
> > implementation is...
>
> Well, if I can confirm that some of the functions are getting called, I
> may as well have a go at it ;)
>
> Thanks for your help.
>
> Index: opengl32.spec
> ===
> RCS file: /home/wine/wine/dlls/opengl32/opengl32.spec,v
> retrieving revision 1.23
> diff -u -r1.23 opengl32.spec
> --- opengl32.spec 7 Feb 2004 01:29:33 -   1.23
> +++ opengl32.spec 20 Feb 2005 16:09:21 -
> @@ -24,6 +24,17 @@
>  @  stdcall wglGetPixelFormat(long) gdi32.GetPixelFormat
>  @  stdcall wglSetPixelFormat(long long ptr) gdi32.SetPixelFormat
>  @  stdcall wglSwapBuffers(long) gdi32.SwapBuffers
> +@  stdcall wglGetPixelFormatAttribivARB(ptr long long long ptr ptr)
> +@  stdcall wglGetPixelFormatAttribfvARB(ptr long long long ptr ptr)
> +@  stdcall wglChoosePixelFormatARB(ptr ptr ptr long ptr ptr)
> +@  stdcall wglCreatePbufferARB(ptr long long long ptr)
> +@  stdcall wglGetPbufferDCARB(ptr)
> +@  stdcall wglReleasePbufferDCARB(ptr ptr)
> +@  stdcall wglDestroyPbufferARB(ptr)
> +@  stdcall wglQueryPbufferARB(ptr long long)
> +@  stdcall wglBindTexImageARB(ptr long)
> +@  stdcall wglReleaseTexImageARB(ptr long)
> +@  stdcall wglSetPbufferAttribARB(ptr ptr)
>  @  stdcall glAccum( long long ) wine_glAccum
>  @  stdcall glAlphaFunc( long long ) wine_glAlphaFunc
>  @  stdcall glAreTexturesResident( long ptr ptr )
> wine_glAreTexturesResident Index: wgl_ext.c
> ===
> RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
> retrieving revision 1.2
> diff -u -r1.2 wgl_ext.c
> --- wgl_ext.c 31 Jan 2005 11:32:13 -  1.2
> +++ wgl_ext.c 20 Feb 2005 16:09:43 -
> @@ -39,7 +39,7 @@
>
>  /* Some WGL extensions... */
>  static const char *WGL_extensions_base = "WGL_ARB_extensions_string
> WGL_EXT_extensions_string"; -static char *WGL_extensions = NULL;
> +static char *WGL_extensions = "WGL_ARB_pixel_format WGL_ARB_pbuffer
> WGL_ARB_render_texture";
>
>  /* Extensions-query functions */
>  BOOL query_function_pbuffers(const char *gl_version, const char
> *gl_extensions, const char *glx_extensions, @@ -143,11 +143,89 @@
>  }
>  }
>
> +GLboolean WINAPI wglGetPixelFormatAttribivARB(HDC hdc, int iPixelFormat,
> int iLayerPlane, UINT nAttributes, const int *piAttributes, int *piValues)
> +{
> +TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane,
> nAttributes, piAttributes, piValues); +return GL_TRUE;
> +}
> +
> +GLboolean WINAPI wglGetPixelFormatAttribfvARB(HDC hdc, int iPixelFormat,
> int iLayerPlane, UINT nAttributes, const int *piAttributes, FLOAT
> *pfValues) +{
> +TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane,
> nAttributes, piAttributes, pfValues); +return GL_TRUE;
> +}
> +
> +GLboolean WINAPI wglChoosePixelFormatARB(HDC hdc, const int
> *piAttribIList, const FLOAT *pfAttribFList, UINT nMaxFormats, int
> *piFormats, UINT *nNumFormats) +{
> +TRACE("(%p, %p, %p, %d, %p, %p)\n", hdc, piAttribIList, pfAttribFList,
> nMaxFormats, piFormats, nNumFormats); +return GL_TRUE;
> +}
> +
> +#define HPBUFFERARB void *
> +HPBUFFERARB WINAPI wglCreatePbufferARB(HDC hdc, int iPixelFormat, int
> iWidth, int iHeight, const int *piAttr

Re: World Of Warcraft

[Lionel Ulmer]

On Sun, Feb 20, 2005 at 04:20:57PM +, Alex Woods wrote:
> Well, I've given it a try, but they're either not getting called, or I
> haven't implemented them correctly (first time hacking wine).  I've
> included a patch below showing what I've done.  A few of them don't
> return nice values, but I figured it should get to the traces if they
> are getting called.

Well, your patch looks OK (except that the WGL extensions should not be in
the .spec file as the only way to get them is via the QueryExtension
function, you cannot direct link to them).

Can you send me (or attach to the bug report) a full +opengl trace (with and
without your patch) of the game till the point it fails so that I can 'throw
an eye at it' (French people will understand the expression :-) ).

  Lionel

-- 
 Lionel Ulmer - http://www.bbrox.org/

Re: World Of Warcraft

[Alex Woods]

On Sun, Feb 20, 2005 at 01:43:44PM +0100, Lionel Ulmer wrote:
> Well, if you want just to test if the application works better, just add
> (stubbed) support for the following extensions:
> 
> http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pixel_format.txt
> http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pbuffer.txt
> http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_render_texture.txt
> 
> This entails:
> 
>  = adding the string for the extension in the WGL extension string (no idea
>if it needs to be duplicated also in the 'standard' extension string).
>  = adding all functions that are described in the three preceding extensions
>(having them returning correct values) and printing debug output
>  = run the game again and see if it actually uses now these functions and if
>it works better (ie better in 'not crashing', not better as in 'working'
>:-) ).

Well, I've given it a try, but they're either not getting called, or I
haven't implemented them correctly (first time hacking wine).  I've
included a patch below showing what I've done.  A few of them don't
return nice values, but I figured it should get to the traces if they
are getting called.

> > I guess it's not just a case of passing through like the bulk of the
> > opengl functions or they'd be done already.
> 
> For PBuffers, the WGL and SGIX interface is a bit different so an adaptation
> is required. For 'render to texture', one needs to use
> 'GL_EXT_framebuffer_object' (or PBuffers) to emulate the extension.
> 
> So this is not the 'simple' thunking that most of the rest of the OpenGL
> implementation is...

Well, if I can confirm that some of the functions are getting called, I
may as well have a go at it ;)

Thanks for your help.

Index: opengl32.spec
===
RCS file: /home/wine/wine/dlls/opengl32/opengl32.spec,v
retrieving revision 1.23
diff -u -r1.23 opengl32.spec
--- opengl32.spec   7 Feb 2004 01:29:33 -   1.23
+++ opengl32.spec   20 Feb 2005 16:09:21 -
@@ -24,6 +24,17 @@
 @  stdcall wglGetPixelFormat(long) gdi32.GetPixelFormat
 @  stdcall wglSetPixelFormat(long long ptr) gdi32.SetPixelFormat
 @  stdcall wglSwapBuffers(long) gdi32.SwapBuffers
+@  stdcall wglGetPixelFormatAttribivARB(ptr long long long ptr ptr)
+@  stdcall wglGetPixelFormatAttribfvARB(ptr long long long ptr ptr)
+@  stdcall wglChoosePixelFormatARB(ptr ptr ptr long ptr ptr)
+@  stdcall wglCreatePbufferARB(ptr long long long ptr)
+@  stdcall wglGetPbufferDCARB(ptr)
+@  stdcall wglReleasePbufferDCARB(ptr ptr)
+@  stdcall wglDestroyPbufferARB(ptr)
+@  stdcall wglQueryPbufferARB(ptr long long)
+@  stdcall wglBindTexImageARB(ptr long)
+@  stdcall wglReleaseTexImageARB(ptr long)
+@  stdcall wglSetPbufferAttribARB(ptr ptr)
 @  stdcall glAccum( long long ) wine_glAccum
 @  stdcall glAlphaFunc( long long ) wine_glAlphaFunc
 @  stdcall glAreTexturesResident( long ptr ptr ) wine_glAreTexturesResident
Index: wgl_ext.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
retrieving revision 1.2
diff -u -r1.2 wgl_ext.c
--- wgl_ext.c   31 Jan 2005 11:32:13 -  1.2
+++ wgl_ext.c   20 Feb 2005 16:09:43 -
@@ -39,7 +39,7 @@
 
 /* Some WGL extensions... */
 static const char *WGL_extensions_base = "WGL_ARB_extensions_string 
WGL_EXT_extensions_string";
-static char *WGL_extensions = NULL;
+static char *WGL_extensions = "WGL_ARB_pixel_format WGL_ARB_pbuffer 
WGL_ARB_render_texture";
 
 /* Extensions-query functions */
 BOOL query_function_pbuffers(const char *gl_version, const char 
*gl_extensions, const char *glx_extensions,
@@ -143,11 +143,89 @@
 }
 }
 
+GLboolean WINAPI wglGetPixelFormatAttribivARB(HDC hdc, int iPixelFormat, int 
iLayerPlane, UINT nAttributes, const int *piAttributes, int *piValues)
+{
+TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane, 
nAttributes, piAttributes, piValues);
+return GL_TRUE;
+}
+
+GLboolean WINAPI wglGetPixelFormatAttribfvARB(HDC hdc, int iPixelFormat, int 
iLayerPlane, UINT nAttributes, const int *piAttributes, FLOAT *pfValues)
+{
+TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane, 
nAttributes, piAttributes, pfValues);
+return GL_TRUE;
+}
+
+GLboolean WINAPI wglChoosePixelFormatARB(HDC hdc, const int *piAttribIList, 
const FLOAT *pfAttribFList, UINT nMaxFormats, int *piFormats, UINT *nNumFormats)
+{
+TRACE("(%p, %p, %p, %d, %p, %p)\n", hdc, piAttribIList, pfAttribFList, 
nMaxFormats, piFormats, nNumFormats);
+return GL_TRUE;
+}
+
+#define HPBUFFERARB void *
+HPBUFFERARB WINAPI wglCreatePbufferARB(HDC hdc, int iPixelFormat, int iWidth, 
int iHeight, const int *piAttribList)
+{
+TRACE("(%p, %d, %d, %d, %p)\n", hdc, iPixelFormat, iWidth, iHeight, 
piAttribList);
+return 0;
+}
+
+HDC WINAPI wglGetPbufferDCARB(HPBUFFERARB hPbuffer)
+{
+TRACE("(%p)\n", hPbuffer);
+return 0;
+}
+
+int WINAPI 

Re: World Of Warcraft

[Lionel Ulmer]

> After some going through the first log I realised that the required
> stuff must be missing from it, so I tried to get a trace with more
> logging.  Unfortunately, running with +relay slows things down so much
> that the server disconnects before I can get into the game, so it
> doesn't get to the crash.  Is there some log level that will print out
> the GL extension bits without all the other relay logging?

Then do a full +opengl trace (i.e. one from the start of the program) and it
should be enough to start to look at what happens.

> I'd be happy to have a go at this.  I could do with pointing to some
> docs on the functions though (is this the entirity of PBuffers?:
> http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt).
> What sort of work is involved in actually implementing these functions?

Well, if you want just to test if the application works better, just add
(stubbed) support for the following extensions:

http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pixel_format.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pbuffer.txt
http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_render_texture.txt

This entails:

 = adding the string for the extension in the WGL extension string (no idea
   if it needs to be duplicated also in the 'standard' extension string).
 = adding all functions that are described in the three preceding extensions
   (having them returning correct values) and printing debug output
 = run the game again and see if it actually uses now these functions and if
   it works better (ie better in 'not crashing', not better as in 'working'
   :-) ).

> I guess it's not just a case of passing through like the bulk of the
> opengl functions or they'd be done already.

For PBuffers, the WGL and SGIX interface is a bit different so an adaptation
is required. For 'render to texture', one needs to use
'GL_EXT_framebuffer_object' (or PBuffers) to emulate the extension.

So this is not the 'simple' thunking that most of the rest of the OpenGL
implementation is...

  Lionel

-- 
 Lionel Ulmer - http://www.bbrox.org/