Hi, I'm the maintainer for World of Warcraft, and I've noticed a few things which have been pointed out before (on irc, bugzilla, mailing list) but have not really gotten any attention. As this is one of the most popular, if not THE most popular pc game at the moment, it seems as though it would be worthwhile to look into getting this to work if it does not require a complete rewrite of wine to do so. There are currently two things preventing operation of the game. Firstly, I'll start off by saying that there are two separate modes to run the game in. d3d9, and opengl. The d3d9 mode doesn't currently work since the support for this dll is not complete. I have been following it closely though, and I constantly find myself impressed with the amount of work being poured into it lately. It's really coming along, and I've even gotten it to run a few demos. Unfortunately, even with the latest patches it still comes up with a blank screen. I don't want to rush anything in this department since I know there's a massive transition from the d3d* architecture to wine3d, and I think it's a really great idea to funnel everything through opengl and only need one rendering library. It's hard for me to say as a WoW addict myself, but I would rather have a complete implementation of d3d9 than one that is only able to play WoW. So I guess what I'd like to say on this front is this: awesome work guys! As for the opengl mode, it crashes strangely just after the character loading screen, but before actually getting into the game. I'm not really sure exactly what is causing the crash. I've run several traces, and all that comes up is a large group of fixmes which look like this: fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet The error I am able to get (when I change my winver to win2k) is an actual game error (not given by wine). This one looks like this: ERROR #0 (0x85100000) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !("CGMinimapFrame::Initialize(): can't get render target for minimap") I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it. I'd appreciate it if someone could give me one of two pieces of information (both would be spectacular!): 1) What exactly is causing the problem with the opengl version, and is it easy to fix? 2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those "It will be done when it's done" sort of things? Thanks in advance, Darckness -- Stop searching forever. Happiness is unattainable.
Speaking of games, I am tracking how far CVS gets in installing Half Life 2, and here's the list of error messages if anyone's interested. The error at the end has to do with switching to the second CD. fixme:msi:MsiInstallProductW L"Z:\\media\\cdrecorder\\hl2.msi" (null) fixme:msi:ACTION_PerformUIAction UNHANDLED MSI ACTION L"Setup_Dialog" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"FindRelatedProducts" fixme:msi:ACTION_AppSearchReg AppSearch unimplemented for RegLocator (key path L"SOFTWARE\\Valve\\Steam") fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"ValidateProductID" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"IsolateComponents" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MigrateFeatureStates" fixme:msi:MsiGetMode STUB (iRunMode=16) fixme:msi:ACTION_PerformUIAction UNHANDLED MSI ACTION L"Welcome_Dialog" fixme:msi:ACTION_PerformUIAction UNHANDLED MSI ACTION L"Progress_Dialog" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"ExecuteAction" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"AllocateRegistrySpace" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnpublishComponents" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MsiUnpublishAssemblies" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnpublishFeatures" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnregisterComPlus" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"SelfUnregModules" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnregisterTypeLibraries" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveODBC" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnregisterFonts" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveRegistryValues" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnregisterClassInfo" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnregisterExtensionInfo" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnregisterProgIdInfo" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"UnregisterMIMEInfo" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveIniValues" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveShortcuts" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveEnvironmentStrings" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveDuplicateFiles" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveFiles" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveFolders" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MoveFiles" err:msi:extract_a_cabinet_file FDICopy failed err:msi:ACTION_InstallFiles Unable to ready media err:msi:ACTION_ProcessExecSequence Execution halted due to error (1627) -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University
On Wed, 2005-02-16 at 01:37 -0500, Ivan Gyurdiev wrote:
Speaking of games, I am tracking how far CVS gets in installing Half Life 2, and here's the list of error messages if anyone's interested.
Half Life 2 will also require Steam support, which is currently broken. Curiously, it isn't in Crossover Office 4.1. It shouldn't be too hard to get Steam working again, if someone who actually knows more about it wants to try. Thanks, Scott Ritchie
--- Scott Ritchie <scott(a)open-vote.org> wrote:
On Wed, 2005-02-16 at 01:37 -0500, Ivan Gyurdiev wrote:
Speaking of games, I am tracking how far CVS gets in installing Half Life 2, and here's the list of error messages if anyone's interested.
Half Life 2 will also require Steam support, which is currently broken. Curiously, it isn't in Crossover Office 4.1. It shouldn't be too hard to get Steam working again, if someone who actually knows more about it wants to try.
I think there are patches for steam support about. (i.e. they remove the steam requirement from steam games) http://www.mgforums.com/forums/showthread.php?t=34356
Thanks, Scott Ritchie
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Hi,
Hi,
I don't want to rush anything in this department since I know there's a massive transition from the d3d* architecture to wine3d, and I think it's a really great idea to funnel everything through opengl and only need one rendering library. It's hard for me to say as a WoW addict myself, but I would rather have a complete implementation of d3d9 than one that is only able to play WoW. So I guess what I'd like to say on this front is this: awesome work guys!
:)
fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet
I don't think this is a real problem
The error I am able to get (when I change my winver to win2k) is an actual game error (not given by wine). This one looks like this:
ERROR #0 (0x85100000) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !("CGMinimapFrame::Initialize(): can't get render target for minimap")
Well, it would better if we have the source :) But seems the game need Render On Texture support who is not supported by current Wine OpenGL implementation as on windows is an WGL extension (and GLX extensions mapping isn't done)
I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it.
As to lionel why he dont look for openGL bugs reports :p
I'd appreciate it if someone could give me one of two pieces of information (both would be spectacular!):
1) What exactly is causing the problem with the opengl version, and is it easy to fix?
If its really render on texture the problem, it shouldn't be too difficult to implement (using GLX buffers/pixmaps extensions i think)
2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those "It will be done when it's done" sort of things?
:) Well Oliver is working a lot on this tree to split into small patches, and i have to send some patches. I think it shouldn't be long before an almost working d3d9.dll
Thanks in advance, Darckness
Regards, Raphael
Hey, On Wed, 16 Feb 2005 09:17:13 +0100, Raphael <fenix(a)club-internet.fr> wrote:
ERROR #0 (0x85100000) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !("CGMinimapFrame::Initialize(): can't get render target for minimap")
The game worked for quite a while in the beta until Blizard had a patch a few months back breaking it. This broke both Wine and Cedega. Transgaming has now some hack in place. Their minimap will work only in the main area. As soon you go indoors (hiding it is the workaround) you will have the same error as Wine. Transgaming now advices people to run in d3d mode. So this opengl problem could be non trivial to fix. Paul
ERROR #0 (0x85100000) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !("CGMinimapFrame::Initialize(): can't get render target for minimap")
Well, it would better if we have the source :) But seems the game need Render On Texture support who is not supported by current Wine OpenGL implementation as on windows is an WGL extension (and GLX extensions mapping isn't done)
Yeah, this must be linked to our lack of support for either 'render to texture' (which should come soon for GLX) or even basic PBuffer support (as I suppose that any well programmed application would support both possibilities). I started a long time ago to add PBuffer support to Wine's OpenGL layer but never finished (just went as far as sending the patch making it possible in the WGL extension handling, did not do any actual code).
I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it.
As to lionel why he dont look for openGL bugs reports :p
I must have missed this bug as otherwise I would have at least asked for an +opengl log. Anyway, I won't have time to work on any Wine stuff till .. errm ... let's say mid April (with the snow that is still falling, I may be busy for a while :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
ERROR #0 (0x85100000) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !("CGMinimapFrame::Initialize(): can't get render target for minimap")
Well, it would better if we have the source :) But seems the game need Render On Texture support who is not supported by current Wine OpenGL implementation as on windows is an WGL extension (and GLX extensions mapping isn't done)
Yeah, this must be linked to our lack of support for either 'render to texture' (which should come soon for GLX) or even basic PBuffer support (as I suppose that any well programmed application would support both possibilities).
I started a long time ago to add PBuffer support to Wine's OpenGL layer but never finished (just went as far as sending the patch making it possible in the WGL extension handling, did not do any actual code).
ATI supports render to texture today. and OpenGL has render to texture as part of the spec. I'm going to be taking a look at the DirectX 9 render to texture implementation as soon as I've merged DirectX 9 with head, so I'll see if there's anything that could be used in OpenGL/ WGL. I'm just freeing some HDD, so that I can do a make clean, build with the DirectX 9 patches, so expect to see something today. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
On Wed, Feb 16, 2005 at 12:03:23PM +0100, Lionel Ulmer wrote:
I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it.
As to lionel why he dont look for openGL bugs reports :p
I must have missed this bug as otherwise I would have at least asked for an +opengl log.
Hopefully this is enough to be relevant. 128x128 certainly sounds about the right size for a minimap. Let me know if you need more of the output, or if there is anything you want me to take a look at. I'm going to be playing with it anyway to see if I can get anywhere. Not that I've any real experience with the wine codebase or OpenGl ;) trace:opengl:wglSwapLayerBuffers (0x7b8, 00000001) trace:opengl:X11DRV_SwapBuffers (0x5591b808) trace:opengl:wine_glClearColor (0.000000, 0.000000, 0.000000, 1.000000) trace:opengl:wine_glDepthMask (1) trace:opengl:wine_glViewport (0, 0, 2048, 1536) trace:opengl:wine_glDepthRange (0.000000, 1.000000) trace:opengl:wine_glScissor (0, 0, 2048, 1536) trace:opengl:wine_glClear (16640) trace:opengl:wine_glDepthMask (0) trace:opengl:wine_glBindTexture (3553, 2014) trace:opengl:wine_glPixelStorei (3314, 128) trace:opengl:wine_glTexSubImage2D (3553, 0, 0, 0, 128, 128, 32993, 33639, 0x66d70008) fixme:debug_buffer:RtlCreateQueryDebugBuffer (0, 0): stub fixme:debug_buffer:RtlCreateQueryDebugBuffer (96, 0): returning 0x61f703e8 fixme:debug_buffer:RtlQueryProcessDebugInformation (8, 80000001, 0x61f703e8): stub fixme:debug_buffer:RtlDestroyQueryDebugBuffer (0x61f703e8): stub err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 err:dsound:DSOUND_MixOne underrun on sound buffer 0x55951980 fixme:system:SystemParametersInfoW Unimplemented action: 113 (SPI_SETMOUSESPEED) trace:opengl:X11DRV_OpenGL_Init GLX is up and running error_base = 77 fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=28672) fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=4664 < primary_done=28672) -- Alex
On Sat, Feb 19, 2005 at 06:36:31PM +0000, Alex Woods wrote:
Hopefully this is enough to be relevant. 128x128 certainly sounds about the right size for a minimap. Let me know if you need more of the output, or if there is anything you want me to take a look at. I'm going to be playing with it anyway to see if I can get anywhere. Not that I've any real experience with the wine codebase or OpenGl ;)
Well, I think the best would be to have a +relay,+tid,+opengl trace (compressed of course :-) ) attached to the bug report. This way I can see if ever it tries to find for extensions that we do not support in the WGL extension string (if it uses standard string functions to search in it that is). The problem here is that with that code snipped, I do not really know what goes wrong (as none of these GL functions return any error). And if the log does not help, we can just cheat and say that we support PBuffers and / or Render to Texture, implement stubs for those functions, and see if the game goes further :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
On Sun, Feb 20, 2005 at 11:29:51AM +0100, Lionel Ulmer wrote:
On Sat, Feb 19, 2005 at 06:36:31PM +0000, Alex Woods wrote:
Hopefully this is enough to be relevant. 128x128 certainly sounds about the right size for a minimap. Let me know if you need more of the output, or if there is anything you want me to take a look at. I'm going to be playing with it anyway to see if I can get anywhere. Not that I've any real experience with the wine codebase or OpenGl ;)
Well, I think the best would be to have a +relay,+tid,+opengl trace (compressed of course :-) ) attached to the bug report.
This way I can see if ever it tries to find for extensions that we do not support in the WGL extension string (if it uses standard string functions to search in it that is).
The problem here is that with that code snipped, I do not really know what goes wrong (as none of these GL functions return any error).
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?
And if the log does not help, we can just cheat and say that we support PBuffers and / or Render to Texture, implement stubs for those functions, and see if the game goes further :-)
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? I guess it's not just a case of passing through like the bulk of the opengl functions or they'd be done already. Cheers. -- Alex
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/
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 -0000 1.23 +++ opengl32.spec 20 Feb 2005 16:09:21 -0000 @@ -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 -0000 1.2 +++ wgl_ext.c 20 Feb 2005 16:09:43 -0000 @@ -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 wglReleasePbufferDCARB(HPBUFFERARB hPbuffer, HDC hdc) +{ + TRACE("(%p, %p)\n", hPbuffer, hdc); + return 0; +} + +GLboolean WINAPI wglDestroyPbufferARB(HPBUFFERARB hPbuffer) +{ + TRACE("(%p)\n", hPbuffer); + return GL_TRUE; +} + +GLboolean WINAPI wglQueryPbufferARB(HPBUFFERARB hPbuffer, int iAttribute, int *piValue) +{ + TRACE("(%p, %d, %p)\n", hPbuffer, iAttribute, piValue); + return GL_TRUE; +} + +GLboolean WINAPI wglBindTexImageARB(HPBUFFERARB hPbuffer, int iBuffer) +{ + TRACE("(%p, %d)\n", hPbuffer, iBuffer); + return GL_TRUE; +} + +GLboolean WINAPI wglReleaseTexImageARB(HPBUFFERARB hPbuffer, int iBuffer) +{ + TRACE("(%p, %d)\n", hPbuffer, iBuffer); + return GL_TRUE; +} + +GLboolean WINAPI wglSetPbufferAttribARB(HPBUFFERARB hPbuffer, const int *piAttribList) +{ + TRACE("(%p, %p)\n", hPbuffer, piAttribList); + return GL_TRUE; +} + /* Putting this at the end to prevent having to write the prototypes :-) */ WGL_extension wgl_extension_registry[] = { { "wglGetExtensionsStringARB", (void *) wglGetExtensionsStringARB, NULL, NULL}, { "wglGetExtensionsStringEXT", (void *) wglGetExtensionsStringEXT, NULL, NULL}, { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}, - { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL} + { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}, + { "wglGetPixelFormatAttribivARB", (void *) wglGetPixelFormatAttribivARB, NULL, NULL}, + { "wglGetPixelFormatAttribfvARB", (void *) wglGetPixelFormatAttribfvARB, NULL, NULL}, + { "wglChoosePixelFormatARB", (void *) wglChoosePixelFormatARB, NULL, NULL}, + { "wglCreatePbufferARB", (void *) wglCreatePbufferARB, NULL, NULL}, + { "wglGetPbufferDCARB", (void *) wglGetPbufferDCARB, NULL, NULL}, + { "wglReleasePbufferDCARB", (void *) wglReleasePbufferDCARB, NULL, NULL}, + { "wglDestroyPbufferARB", (void *) wglDestroyPbufferARB, NULL, NULL}, + { "wglQueryPbufferARB", (void *) wglQueryPbufferARB, NULL, NULL}, + { "wglBindTexImageARB", (void *) wglBindTexImageARB, NULL, NULL}, + { "wglReleaseTexImageARB", (void *) wglReleaseTexImageARB, NULL, NULL}, + { "wglSetPbufferAttribARB", (void *) wglSetPbufferAttribARB, NULL, NULL} }; int wgl_extension_registry_size = sizeof(wgl_extension_registry) / sizeof(wgl_extension_registry[0]); -- Alex
On Sun, Feb 20, 2005 at 04:20:57PM +0000, 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/
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 -0000 1.23 +++ opengl32.spec 20 Feb 2005 16:09:21 -0000 @@ -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 -0000 1.2 +++ wgl_ext.c 20 Feb 2005 16:09:43 -0000 @@ -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 wglReleasePbufferDCARB(HPBUFFERARB hPbuffer, HDC hdc) +{ + TRACE("(%p, %p)\n", hPbuffer, hdc); + return 0; +} + +GLboolean WINAPI wglDestroyPbufferARB(HPBUFFERARB hPbuffer) +{ + TRACE("(%p)\n", hPbuffer); + return GL_TRUE; +} + +GLboolean WINAPI wglQueryPbufferARB(HPBUFFERARB hPbuffer, int iAttribute, int *piValue) +{ + TRACE("(%p, %d, %p)\n", hPbuffer, iAttribute, piValue); + return GL_TRUE; +} + +GLboolean WINAPI wglBindTexImageARB(HPBUFFERARB hPbuffer, int iBuffer) +{ + TRACE("(%p, %d)\n", hPbuffer, iBuffer); + return GL_TRUE; +} + +GLboolean WINAPI wglReleaseTexImageARB(HPBUFFERARB hPbuffer, int iBuffer) +{ + TRACE("(%p, %d)\n", hPbuffer, iBuffer); + return GL_TRUE; +} + +GLboolean WINAPI wglSetPbufferAttribARB(HPBUFFERARB hPbuffer, const int *piAttribList) +{ + TRACE("(%p, %p)\n", hPbuffer, piAttribList); + return GL_TRUE; +} + /* Putting this at the end to prevent having to write the prototypes :-) */ WGL_extension wgl_extension_registry[] = { { "wglGetExtensionsStringARB", (void *) wglGetExtensionsStringARB, NULL, NULL}, { "wglGetExtensionsStringEXT", (void *) wglGetExtensionsStringEXT, NULL, NULL}, { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}, - { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL} + { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}, + { "wglGetPixelFormatAttribivARB", (void *) wglGetPixelFormatAttribivARB, NULL, NULL}, + { "wglGetPixelFormatAttribfvARB", (void *) wglGetPixelFormatAttribfvARB, NULL, NULL}, + { "wglChoosePixelFormatARB", (void *) wglChoosePixelFormatARB, NULL, NULL}, + { "wglCreatePbufferARB", (void *) wglCreatePbufferARB, NULL, NULL}, + { "wglGetPbufferDCARB", (void *) wglGetPbufferDCARB, NULL, NULL}, + { "wglReleasePbufferDCARB", (void *) wglReleasePbufferDCARB, NULL, NULL}, + { "wglDestroyPbufferARB", (void *) wglDestroyPbufferARB, NULL, NULL}, + { "wglQueryPbufferARB", (void *) wglQueryPbufferARB, NULL, NULL}, + { "wglBindTexImageARB", (void *) wglBindTexImageARB, NULL, NULL}, + { "wglReleaseTexImageARB", (void *) wglReleaseTexImageARB, NULL, NULL}, + { "wglSetPbufferAttribARB", (void *) wglSetPbufferAttribARB, NULL, NULL} }; int wgl_extension_registry_size = sizeof(wgl_extension_registry) / sizeof(wgl_extension_registry[0]);
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
On Mon, Feb 21, 2005 at 08:58:26AM +0000, 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/
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 function (0x56191a40) 0009:trace:opengl:wglGetProcAddress (glProgramEnvParameter4fvARB) 0009:trace:opengl:wglGetProcAddress returning function (0x561a8570) 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:wglGetProcAddress (glLoadProgramNV) 0009:trace:opengl:wglGetProcAddress returning function (0x561a1180) 0009:trace:opengl:wglGetProcAddress (glBindProgramNV) 0009:trace:opengl:wglGetProcAddress returning function (0x56191ad0) 0009:trace:opengl:wglGetProcAddress (glProgramParameters4fvNV) 0009:trace:opengl:wglGetProcAddress returning function (0x561a8f60) 0009:trace:opengl:wglGetProcAddress (glDeleteProgramsNV) 0009:trace:opengl:wglGetProcAddress returning function (0x56196b70) 0009:trace:opengl:wglGetProcAddress (glGenProgramsNV) 0009:trace:opengl:wglGetProcAddress returning function (0x5619a000) 0009:trace:opengl:wglGetProcAddress (glIsProgramNV) 0009:trace:opengl:wglGetProcAddress returning function (0x561a0900) 0009:trace:opengl:wglGetProcAddress (GetProgramivNV) 0009:warn:opengl:wglGetProcAddress Did not find extension GetProgramivNV in either Wine or your OpenGL library. 0009:trace:opengl:wglGetProcAddress (glVertexAttribPointerNV) 0009:trace:opengl:wglGetProcAddress returning function (0x561b6680) 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB) 0009:warn:opengl:wglGetProcAddress Did not find extension wglGetExtensionsStringARB in either Wine or your OpenGL library. 0009:trace:opengl:wine_glGetIntegerv (34047, 0x5a45c2e0) 0009:trace:opengl:wine_glGetFloatv (34045, 0x5a45c2ec) -- Alex
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 ;)
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/
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
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
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
On Mon, Feb 21, 2005 at 09:25:05PM +0000, 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/
On Monday 21 February 2005 22:46, Lionel Ulmer wrote:
On Mon, Feb 21, 2005 at 09:25:05PM +0000, 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
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
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
On Wed, Feb 23, 2005 at 09:26:25AM +0000, 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
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
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/
2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those "It will be done when it's done" sort of things?
...Last month! I'm putting together Directx9 patches today that should bring DirectX9 beyond the current DirectX 8 level, with the exception of Shaders. After that I've got a few patches to get expressions working in winedbg that need checking over. I'm not sure what I'm going to work on next, possibly more 'completeness' and performance in DirextX 9 to give applications a good chance of running as well as games, or maybe some d3dx9 work so that winelib can compile more DirextX 9, or maybe try getting Microsofts new GUI Avalon working under wine. http://www.microsoft.com/downloads/details.aspx?FamilyID=C8F904E1-B4CA-402B-...
Thanks in advance, Darckness
-- Stop searching forever. Happiness is unattainable.
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
How will this work affect Direct3D8 apps? Will this work make those apps run any better (or is work to do that being done?) Also, how does the work we have here in this project compare to what TransGaming have as far as Direct3D functionality?
--- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote:
How will this work affect Direct3D8 apps? Will this work make those apps run any better (or is work to do that being done?)
It won't at the moment, but the work has been done in a way that allows DirectX8 to wrap the functionlity at a later stage, so that DirectX9 and DirectX8 share most of the same codebase.
Also, how does the work we have here in this project compare to what TransGaming have as far as Direct3D functionality?
on the downside.. Shaders aren't working yet, but the DirectX 8 shaders can be migrated reasonably easly. Stencil buffers aren't working properly either, which affects shadows and odd shaped windows etc... Offscreen textures aren't working fully. on the up side. Stateblock support seems to be more complete than TransGamings. Swapchains are working, transgaming doesn't have them. Non-power of two textures should work on all opengl video cards, transgaming only support a subset of cards. Querys are stubbed, and I've got a version of Occlusion query to test (but I think ATI's drivers are broken), occlusion queries may give fairly large performance increases in some games. A few other minor things like point sprites are working. With the exception of a few areas performance is on-par with cedega. I'm looking at offscreen surfaces soon. There are lots of easy performance boosters that can be implemented at somepoint. Of the games I've tested this version works more often than Cedega, but that doesn't mean too much since most games are failing with non DirectX related issues. I've been developing with an ATI graphics card, so there shouldn't be the odd dropout because of ATI driver bugs that happens with Cedega. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Hi, On Wed, Feb 16, 2005 at 02:08:47PM +0000, Oliver Stieber wrote:
2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those "It will be done when it's done" sort of things?
...Last month!
Good attitude! :)
I'm not sure what I'm going to work on next, possibly more 'completeness' and performance in DirextX 9 to give applications a good chance of running as well as games, or maybe some d3dx9 work so that winelib can compile more DirextX 9, or maybe try getting Microsofts new GUI Avalon working under wine.
http://www.microsoft.com/downloads/details.aspx?FamilyID=C8F904E1-B4CA-402B-...
I'm certainly not authorized to tell you what to do, but what benefit would Avalon bring us? It's not even really released, i.e. its applicability should be very limited. OTOH almost perfect support for DX9 games would be MUCH more useful IMHO, since lack of gaming support is the #1 reason for many people for not being able to switch to Linux... Thanks for the incredible work so far! Andreas Mohr
Andreas Mohr wrote:
Hi,
On Wed, Feb 16, 2005 at 02:08:47PM +0000, Oliver Stieber wrote:
2) Is there any sort of goal that the people working on d3d9 dlls have set as far as a date they would like to have it done by? Or is it just one of those "It will be done when it's done" sort of things?
...Last month!
Good attitude! :)
I'm not sure what I'm going to work on next, possibly more 'completeness' and performance in DirextX 9 to give applications a good chance of running as well as games, or maybe some d3dx9 work so that winelib can compile more DirextX 9, or maybe try getting Microsofts new GUI Avalon working under wine.
http://www.microsoft.com/downloads/details.aspx?FamilyID=C8F904E1-B4CA-402B-...
I'm certainly not authorized to tell you what to do, but what benefit would Avalon bring us? It's not even really released, i.e. its applicability should be very limited.
OTOH almost perfect support for DX9 games would be MUCH more useful IMHO, since lack of gaming support is the #1 reason for many people for not being able to switch to Linux...
I would only add that the "Key features missing" section of: http://www.oliverthered.f2s.com/projects/wine/ would be nice to see as well. most notably "DirectX 8 intergration of the above" and there is still some room for improvements even in DX 1-7. As Andi has already pointed out, were not the ones to try and tell someone what to do :-) Thanks from me as well...... Hell of a job thus far! Tom
Thanks for the incredible work so far!
Andreas Mohr
http://www.microsoft.com/downloads/details.aspx?FamilyID=C8F904E1-B4CA-402B-...
I'm certainly not authorized to tell you what to do, but what benefit would Avalon bring us? It's not even really released, i.e. its applicability should be very limited.
Well, to be there when it is released, and soon it won't be limited, just like DirectX 9 isn't limited.
OTOH almost perfect support for DX9 games would be MUCH more useful IMHO, since lack of gaming support is the #1 reason for many people for not being able to switch to Linux...
Avalon depends heavily on DirectX 9, I'm not out to do Transgaming out of work so I'd prefer to focus on what isn't currently supported by Cedega/Crossover office, this would be things like Directx 9 applications, and games that aren't FPS's or RTS's. If Half Life 2 happens to work so be it, but I'm even less a fan of DRM/steam then I am of duplicating Transgamings work. If you would like me to work on something just ask. (I have to get a Job soon though, so my output will drop quite a bit!)
Thanks for the incredible work so far!
Andreas Mohr
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
On Thu, 17 Feb 2005 16:23:46 +0000 (GMT), Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
OTOH almost perfect support for DX9 games would be MUCH more useful IMHO, since lack of gaming support is the #1 reason for many people for not being able to switch to Linux...
Avalon depends heavily on DirectX 9, I'm not out to do Transgaming out of work so I'd prefer to focus on what isn't currently supported by Cedega/Crossover office, this would be things like Directx 9 applications, and games that aren't FPS's or RTS's.
If Half Life 2 happens to work so be it, but I'm even less a fan of DRM/steam then I am of duplicating Transgamings work.
Don't forget, there are several business-type windows applications that use D3D. 3D Modeling and animation packages are one. These apps will likely go hidden under Transgaming's radar. Really, your work helps everyone. Jesse
On Thu, Feb 17, 2005 at 04:23:46PM +0000, Oliver Stieber wrote:
If you would like me to work on something just ask. (I have to get a Job soon though, so my output will drop quite a bit!)
Well, I'd also like to see World of Warcraft working. I've been trying to get the UK version to work. It all looks very promising until it patches itself up to version 1.2.3, when it just crashes at startup. Very odd considering a fresh install loads up and lets you log in the account with no problems (with -opengl, didn't try dx). Both opengl and dx crash at startup after the update. See below for the error messages as reported by WoW - the application is catching the error. Very nice to see the pictures of Pirates running under wine - I'm sorely tempted. Thanks for the excellent work :) ============================================================================== World of WarCraft: Assertions Enabled Build (build 4211) Exe: C:\Program Files\World of Warcraft\WoW.exe Time: Feb 18, 2005 9:37:37.761 PM User: alex Computer: shikra ------------------------------------------------------------------------------ This application has encountered a critical error: ERROR #132 (0x85100084) Program: C:\Program Files\World of Warcraft\WoW.exe Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:556F3661 The instruction at "0x556F3661" referenced memory at "0x00000000". The memory could not be "written". WoWBuild: 4211 ------------------------------------------------------------------------------ ---------------------------------------- x86 Registers ---------------------------------------- EAX=00000000 EBX=5571CC2C ECX=59A21600 EDX=01C51602 ESI=556F3630 EDI=00000000 EBP=59A214A4 ESP=59A21494 EIP=556F3661 FLG=00010202 CS =0023 DS =002B ES =002B SS =002B FS =005B GS =0063 ---------------------------------------- Stack Trace (Manual) ---------------------------------------- Address Frame Logical addr Module 556F3661 59A214A4 0001:00022661 c:\windows\system\ntdll.dll 556F9CF0 59A214F4 0001:00028CF0 c:\windows\system\ntdll.dll 556FA155 59A21588 0001:00029155 c:\windows\system\ntdll.dll 557205C5 59A215C8 0002:000045C5 c:\windows\system\ntdll.dll 0042946C 59A215D8 0001:0002846C C:\Program Files\World of Warcraft\WoW.exe 00429643 59A216A8 0001:00028643 C:\Program Files\World of Warcraft\WoW.exe 0042949B 59A216CC 0001:0002849B C:\Program Files\World of Warcraft\WoW.exe 55A3CA36 59A2179C 0001:0006BA36 c:\windows\system\kernel32.dll 55708C8D 59A21FEC 0001:00037C8D c:\windows\system\ntdll.dll ---------------------------------------- Stack Trace (Using DBGHELP.DLL) ---------------------------------------- 556F3661 <unknown module> <unknown symbol>+0 (0x59A21600,0x00000000,0x0000004A,0x556E0EB6) 556F9CF0 <unknown module> <unknown symbol>+0 (0x59A21594,0x00429267,0x59A2152C,0x00000002) 556FA155 <unknown module> <unknown symbol>+0 (0x00429267,0x59A21600,0x00000000,0x7551744E) 557205C5 <unknown module> <unknown symbol>+0 (0x00000000,0x585D1F58,0x59A216A8,0x00429643) 0042946C <unknown module> <unknown symbol>+0 (0x59A215F0,0x00429490,0x0000000B,0x00000000) 00429643 <unknown module> <unknown symbol>+0 (0x006476BC,0x00000000,0x59920E0C,0x59920F10) 0042949B <unknown module> <unknown symbol>+0 (0x000020B8,0x00000001,0x00647680,0x585D0108) 55A3CA36 <unknown module> <unknown symbol>+0 (0x5591BA28,0x00000002,0x5591BA48,0x00000140) 55708C8D <unknown module> <unknown symbol>+0 (0x5591BA48,0x00000000,0x00000000,0x00000000) 5564C8DA <unknown module> <unknown symbol>+0 (0x00000000,0x00000000,0x00000000,0x00000000) ---------------------------------------- Loaded Modules ---------------------------------------- ---------------------------------------- Memory Dump ---------------------------------------- Code: 16 bytes starting at (EIP = 556F3661) 556F3661: C7 00 80 96 98 00 C7 40 04 00 00 00 00 31 C0 8B .......(a).....1.. Stack: 1024 bytes starting at (ESP = 59A21494) * = addr ** * 59A21490: 4D 36 6F 55 98 14 A2 59 DC C2 AD 10 02 16 C5 01 M6oU...Y........ 59A214A0: 2C CC 71 55 F4 14 A2 59 F0 9C 6F 55 00 16 A2 59 ,.qU...Y..oU...Y 59A214B0: 00 00 00 00 4A 00 00 00 B6 0E 6E 55 02 00 00 00 ....J.....nU.... 59A214C0: D8 1B A2 59 4A 00 00 00 00 15 A2 59 21 1C A2 59 ...YJ......Y!..Y 59A214D0: 0F 00 00 00 C4 12 58 55 FF FF FF FF 00 00 00 00 ......XU........ 59A214E0: F4 14 A2 59 37 DB 57 55 EC 9B 6F 55 2C CC 71 55 ...Y7.WU..oU,.qU 59A214F0: FF FF FF FF 88 15 A2 59 55 A1 6F 55 94 15 A2 59 .......YU.oU...Y 59A21500: 67 92 42 00 2C 15 A2 59 02 00 00 00 ED 72 71 55 g.B.,..Y.....rqU 59A21510: 90 15 A2 59 02 00 00 00 ED 72 71 55 9C 15 A2 59 ...Y.....rqU...Y 59A21520: 6B 65 02 00 C0 05 72 55 94 15 A2 59 6E 74 64 6C ke....rU...Yntdl 59A21530: 6C 2E 4E 74 51 75 65 72 79 50 65 72 66 6F 72 6D l.NtQueryPerform 59A21540: 61 6E 63 65 43 6F 75 6E 74 65 72 00 00 00 00 00 anceCounter..... 59A21550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 59A21560: 00 00 00 00 00 00 00 00 00 00 00 00 FE A0 6F 55 ..............oU 59A21570: 8D 10 5D 58 F0 89 AA 55 FE A0 6F 55 08 10 5D 58 ..]X...U..oU..]X 59A21580: F0 15 A2 59 08 10 5D 58 C8 15 A2 59 C5 05 72 55 ...Y..]X...Y..rU 59A21590: 67 92 42 00 00 16 A2 59 00 00 00 00 4E 74 51 75 g.B....Y....NtQu 59A215A0: 65 72 79 50 65 72 66 6F 72 6D 61 6E 63 65 43 6F eryPerformanceCo 59A215B0: 75 6E 74 65 72 00 6F 55 6E 74 64 6C 6C 2E 64 6C unter.oUntdll.dl 59A215C0: 6C 00 5D 58 00 16 A2 59 D8 15 A2 59 6C 94 42 00 l.]X...Y...Yl.B. 59A215D0: 00 00 00 00 58 1F 5D 58 A8 16 A2 59 43 96 42 00 ....X.]X...YC.B. 59A215E0: F0 15 A2 59 90 94 42 00 0B 00 00 00 00 00 00 00 ...Y..B......... 59A215F0: 36 8F 6C 18 6C 08 00 00 33 AB 00 00 90 16 A2 59 6.l.l...3......Y 59A21600: DC C2 AD 10 02 16 C5 01 0B 00 00 00 34 16 A2 59 ............4..Y 59A21610: 00 00 00 00 F7 38 64 00 A0 78 AA 55 01 00 00 00 .....8d..x.U.... 59A21620: ED 72 71 55 A0 16 A2 59 2E 44 01 00 60 1A 72 55 .rqU...Y.D..`.rU 59A21630: 9C 16 A2 59 6E 74 64 6C 6C 2E 52 74 6C 4C 65 61 ...Yntdll.RtlLea 59A21640: 76 65 43 72 69 74 69 63 61 6C 53 65 63 74 69 6F veCriticalSectio 59A21650: 6E 00 63 65 73 73 00 00 FE A0 6F 55 E0 E3 A7 00 n.cess....oU.... 59A21660: 90 DF A7 00 00 01 5D 58 84 16 A2 59 FE A0 6F 55 ......]X...Y..oU 59A21670: 00 00 00 00 0B 00 00 00 90 94 42 00 A8 16 A2 59 ..........B....Y 59A21680: FE A0 6F 55 00 00 00 00 0B 00 00 00 90 94 42 00 ..oU..........B. 59A21690: A8 16 A2 59 65 1A 72 55 F7 38 64 00 5C E7 A7 00 ...Ye.rU.8d.\... 59A216A0: 7D 4F 64 00 0B 00 00 00 CC 16 A2 59 9B 94 42 00 }Od........Y..B. 59A216B0: BC 76 64 00 00 00 00 00 0C 0E 92 59 10 0F 92 59 .vd........Y...Y 59A216C0: E8 35 AA 55 0C 0E 92 59 0B 00 00 00 9C 17 A2 59 .5.U...Y.......Y 59A216D0: 36 CA A3 55 B8 20 00 00 01 00 00 00 80 76 64 00 6..U. .......vd. 59A216E0: 08 01 5D 58 80 76 64 00 FF FF FF FF 48 B4 AA 55 ..]X.vd.....H..U 59A216F0: 10 52 9F 55 E8 35 AA 55 10 0F 92 59 0C 0E 92 59 .R.U.5.U...Y...Y 59A21700: 9C 17 A2 59 D4 16 A2 59 CD C9 A3 55 01 00 00 00 ...Y...Y...U.... 59A21710: 00 00 00 80 00 00 00 00 00 00 89 55 2C CC 71 55 ...........U,.qU 59A21720: 40 BA 91 55 38 00 00 00 68 17 A2 59 58 9D 6E 55 @..U8...h..YX.nU 59A21730: 38 00 00 00 57 00 00 00 C8 44 72 55 17 FB 6D 57 8...W....DrU..mW 59A21740: A0 62 0D 78 2C CC 71 55 03 AE 6E 55 01 00 00 00 .b.x,.qU..nU.... 59A21750: 00 00 89 55 00 00 89 55 00 00 89 55 2C CC 71 55 ...U...U...U,.qU 59A21760: D9 FB 6D 55 2C CC 71 55 9C 17 A2 59 03 B5 6E 55 ..mU,.qU...Y..nU 59A21770: 1C 00 89 55 01 00 00 00 17 FB 6D 55 C8 44 72 55 ...U......mU.DrU 59A21780: 2C CC 71 55 D9 FB 6D 55 2C CC 71 55 9C 17 A2 59 ,.qU..mU,.qU...Y 59A21790: D0 CA 6F 55 29 C9 A3 55 2C CC 71 55 EC 1F A2 59 ..oU)..U,.qU...Y 59A217A0: 8D 8C 70 55 28 BA 91 55 02 00 00 00 48 BA 91 55 ..pU(..U....H..U 59A217B0: 40 01 00 00 00 00 00 00 40 00 00 00 CC 17 A2 59 @.......(a)......Y 59A217C0: 28 BA 91 55 20 C9 A3 55 00 00 92 59 00 10 00 00 (..U ..U...Y.... 59A217D0: 88 1A A2 59 D8 1B A2 59 4C 22 44 42 47 48 45 4C ...Y...YL"DBGHEL 59A217E0: 50 5F 44 42 47 4F 55 54 22 00 22 43 3A 5C 5C 50 P_DBGOUT"."C:\\P 59A217F0: 72 6F 67 72 61 6D 20 46 69 6C 65 73 5C 5C 57 6F rogram Files\\Wo 59A21800: 72 6C 64 20 6F 66 20 57 61 72 63 72 61 66 74 22 rld of Warcraft" 59A21810: 00 22 43 3A 5C 5C 50 72 6F 67 72 61 6D 20 46 69 ."C:\\Program Fi 59A21820: 6C 65 73 5C 5C 57 6F 72 6C 64 20 6F 66 20 57 61 les\\World of Wa 59A21830: 72 63 72 61 66 74 22 00 4C 22 43 3A 5C 5C 50 72 rcraft".L"C:\\Pr 59A21840: 6F 67 72 61 6D 20 46 69 6C 65 73 5C 5C 57 6F 72 ogram Files\\Wor 59A21850: 6C 64 20 6F 66 20 57 61 72 63 72 61 66 74 22 00 ld of Warcraft". 59A21860: 22 6E 74 64 6C 6C 2E 64 6C 6C 22 00 22 6E 74 64 "ntdll.dll"."ntd 59A21870: 6C 6C 2E 64 6C 6C 22 00 4C 22 6E 74 64 6C 6C 2E ll.dll".L"ntdll. 59A21880: 64 6C 6C 22 00 22 52 74 6C 51 75 65 72 79 50 72 dll"."RtlQueryPr 59A21890: 6F 63 65 73 73 44 65 62 75 67 49 6E 66 6F 72 6D ocessDebugInform ------------------------------------------------------------------------------ -- Alex
On Wed, 16 Feb 2005 01:23:08 -0500, cyrix12(a)cox.net <cyrix12(a)cox.net> wrote: Hi
Hi, I'm the maintainer for World of Warcraft, and I've noticed a few things which have been pointed out before (on irc, bugzilla, mailing list) but have not really gotten any attention. As this is one of the most popular, if not THE most popular pc game at the moment, it seems as though it would be worthwhile to look into getting this to work if it does not require a complete rewrite of wine to do so.
There are currently two things preventing operation of the game. Firstly, I'll start off by saying that there are two separate modes to run the game in. d3d9, and opengl.
The d3d9 mode doesn't currently work since the support for this dll is not complete. I have been following it closely though, and I constantly find myself impressed with the amount of work being poured into it lately.
I highly recommend that you try Oliver Stieber's patch. Even if buggy, I think you'll find WoW works very well. I've recently found that Star Wars: Battlefront works with it. The problem with Battlefront is it experiences heap corruption at the menu screen. I think it's related to some stencil operation. Oliver, if you read this, I have a 10 MB +heap,+d3d,+d3d_surface log, compressed bz2 no less, that may help solve this problem. Though I may wait till your next patch and then get back to you. :)
As for the opengl mode, it crashes strangely just after the character loading screen, but before actually getting into the game. I'm not really sure exactly what is causing the crash. I've run several traces, and all that comes up is a large group of fixmes which look like this:
fixme:thread:GetThreadTimes Cannot get kerneltime or usertime of other threads fixme:thread:NtQueryInformationThread info class 9 not supported yet
The error I am able to get (when I change my winver to win2k) is an actual game error (not given by wine). This one looks like this:
ERROR #0 (0x85100000) Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\Ui\MinimapFrame.cpp Line: 1287 Expr: !("CGMinimapFrame::Initialize(): can't get render target for minimap")
I posted a bug about this on December 7, 2004 at this location: http://bugs.winehq.org/show_bug.cgi?id=2603 Nothing has happened yet with this bug except for someone else confirming it.
Well, I would actually like to try WoW myself. I have a friend that has the full game. I just know that the full game will load, because I brought my computer over to his house once. While he was playing the game himself, I though it might be intersesting to see if it will still run (I tried it in beta days). I mounted his samba share, and let out a snicker, because he was too involved in the game to know what I was doing. But this hinted to him I was up to something -- I told him nothing. Then when the music started playing he knew.... Of course I could not log in to his account while he was playing. Maybe next time. Again, you should see Oliver's patch and see if it has bugs with the minimap. I think it might cause opengl doesn't quite work there either and the d3d stuff is just an opengl wrapper. But at least we will know. I guess this is a fixable problem? Jesse
I highly recommend that you try Oliver Stieber's patch. Even if buggy, I think you'll find WoW works very well. I've recently found that Star Wars: Battlefront works with it. The problem with Battlefront is it experiences heap corruption at the menu screen.
I've just put together a new patch against head. http://www.oliverthered.f2s.com/projects/wine/ This versions a had a lot of code separation work done, rendertargets are more or less fixed and texture addressing should be working properly now. I've also gone through and put in NULL checks where they seemed to be missing, including IDirect3DDevice9Impl_SetVertexShader Let me know if you get any obvious problems like applications bailing out because of missing NULL checks and I'll put them in the patches I send to wine patches. (or note the problems in the code if there non-trivial) I
think it's related to some stencil operation. Oliver, if you read this, I have a 10 MB +heap,+d3d,+d3d_surface log, compressed bz2 no less, that may help solve this problem. Though I may wait till your next patch and then get back to you. :)
Can you mail it to me and I'll have a look. WINEDEBUG=trace+d3d9 would also be very usefull as it logs all the relay calls between wined3d and d3d9.
Again, you should see Oliver's patch and see if it has bugs with the minimap. I think it might cause opengl doesn't quite work there either and the d3d stuff is just an opengl wrapper. But at least we will know. I guess this is a fixable problem?
Rendertargets are working in DirectX9, and I've got a better version in the pipeline that should be useable for wgl.
Jesse
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
On Wed, 16 Feb 2005 21:26:58 +0000 (GMT) Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I highly recommend that you try Oliver Stieber's patch. Even if buggy, I think you'll find WoW works very well. I've recently found that Star Wars: Battlefront works with it. The problem with Battlefront is it experiences heap corruption at the menu screen.
I've just put together a new patch against head. http://www.oliverthered.f2s.com/projects/wine/
This versions a had a lot of code separation work done, rendertargets are more or less fixed and texture addressing should be working properly now.
I've also gone through and put in NULL checks where they seemed to be missing, including IDirect3DDevice9Impl_SetVertexShader
Let me know if you get any obvious problems like applications bailing out because of missing NULL checks and I'll put them in the patches I send to wine patches. (or note the problems in the code if there non-trivial)
I
think it's related to some stencil operation. Oliver, if you read this, I have a 10 MB +heap,+d3d,+d3d_surface log, compressed bz2 no less, that may help solve this problem. Though I may wait till your next patch and then get back to you. :)
Can you mail it to me and I'll have a look.
WINEDEBUG=trace+d3d9 would also be very usefull as it logs all the relay calls between wined3d and d3d9.
Again, you should see Oliver's patch and see if it has bugs with the minimap. I think it might cause opengl doesn't quite work there either and the d3d stuff is just an opengl wrapper. But at least we will know. I guess this is a fixable problem?
Rendertargets are working in DirectX9, and I've got a better version in the pipeline that should be useable for wgl.
Jesse
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Wow...it works! Kind of. First thing I'd like to point out is that your patch doesn't add the new stuff (d3dx9 and wineguid) to the configure script, only to the configure.ac. That caused a little problem for me since I didn't autoconf it, but was easily fixed. Compilation went perfectly and, then the fun began. Upon loading, it shows the usual intro screen. Unfortunately, there's no textures yet (as you've mentioned). It still runs though, and I can kind of make stuff out. When I began to load my character, it crashed at the same place that the opengl version crashed! It gave me this error: err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c "?" wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ae7f90c "DSOUND_mixlock" wait timed out in thread 0012, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c "?" wait timed out in thread 0025, blocked by 0009, retrying (60 sec) I tried to get something more complete (traces and whatnot), but it seems that my wine has compiled without --debugmsg for some reason. I'll see if I can fix that at some point. Next thing I noticed was that it crashes on exit, just like cedega does (I don't care what anyone says, tg did NOT fix it in the new release and I'm still pissed at them for sucking). Here's the error message for that: ERROR #0 (0x85100000) Program: H:\.wine\drive_c\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\ENGINE\Source\gx\CGxDeviceD3d\CGxD3dDevice.cpp Line: 614 Expr: newRefCount == 0 I'll try and get more info to send in as soon as I get debug messages working again. Thanks again for the great work!
___________________
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Wow...it works! Kind of. First thing I'd like to point out is that your patch doesn't add the new stuff (d3dx9 and wineguid) to the configure script, only to the configure.ac. That caused a little problem for me since I didn't autoconf it, but was easily fixed. Compilation went perfectly and, then the fun began.
opps.
Upon loading, it shows the usual intro screen. Unfortunately, there's no textures yet (as you've mentioned). It still runs though, and I can kind of make stuff out. The lack of shaders may be causing texture problems.
When I began to load my character, it crashed at the same place that the opengl version crashed! It gave me this error:
err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c "?" wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ae7f90c "DSOUND_mixlock" wait timed out in thread 0012, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c "?" wait timed out in thread 0025, blocked by 0009, retrying (60 sec)
That a problem with mmtimer/dsound it's been giving me no end of grief. The CriticalSection, of semephore or something is getting corrupt and the semephore isn't being released properly causing a dead lock. I've been trying to stabalise DirectX 9 and havn't looked much deaper into the fault. Try changing to alsa with hardware emmulation, it's bad and you'll probably loose sound and have mmtimer eat your CPU but it's better than a deadlock.
I tried to get something more complete (traces and whatnot), but it seems that my wine has compiled without --debugmsg for some reason. I'll see if I can fix that at some point.
Next thing I noticed was that it crashes on exit, just like cedega does (I don't care what anyone says, tg did NOT fix it in the new release and I'm still pissed at them for sucking). Here's the error message for that:
ERROR #0 (0x85100000) Program: H:\.wine\drive_c\Program Files\World of Warcraft\WoW.exe File:
C:\build\buildWoW\ENGINE\Source\gx\CGxDeviceD3d\CGxD3dDevice.cpp
Line: 614 Expr: newRefCount == 0
This looks like a reference counting problem on exit, I've got some more work to do in that area, as part of getting being able to reset the device.
Thanks again for the great work!
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
On Wed, 16 Feb 2005 23:59:55 +0000 (GMT) Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
___________________
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Wow...it works! Kind of. First thing I'd like to point out is that your patch doesn't add the new stuff (d3dx9 and wineguid) to the configure script, only to the configure.ac. That caused a little problem for me since I didn't autoconf it, but was easily fixed. Compilation went perfectly and, then the fun began.
opps.
Upon loading, it shows the usual intro screen. Unfortunately, there's no textures yet (as you've mentioned). It still runs though, and I can kind of make stuff out. The lack of shaders may be causing texture problems.
When I began to load my character, it crashed at the same place that the opengl version crashed! It gave me this error:
err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c "?" wait timed out in thread 000f, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ae7f90c "DSOUND_mixlock" wait timed out in thread 0012, blocked by 000f, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x3ada001c "?" wait timed out in thread 0025, blocked by 0009, retrying (60 sec)
That a problem with mmtimer/dsound it's been giving me no end of grief.
The CriticalSection, of semephore or something is getting corrupt and the semephore isn't being released properly causing a dead lock.
I've been trying to stabalise DirectX 9 and havn't looked much deaper into the fault.
Try changing to alsa with hardware emmulation, it's bad and you'll probably loose sound and have mmtimer eat your CPU but it's better than a deadlock.
It's most likely not sound related since I don't have sound enabled in wine. I tried it anyway just to make sure though, and nothing happened.
I tried to get something more complete (traces and whatnot), but it seems that my wine has compiled without --debugmsg for some reason. I'll see if I can fix that at some point.
Next thing I noticed was that it crashes on exit, just like cedega does (I don't care what anyone says, tg did NOT fix it in the new release and I'm still pissed at them for sucking). Here's the error message for that:
ERROR #0 (0x85100000) Program: H:\.wine\drive_c\Program Files\World of Warcraft\WoW.exe File:
C:\build\buildWoW\ENGINE\Source\gx\CGxDeviceD3d\CGxD3dDevice.cpp
Line: 614 Expr: newRefCount == 0
This looks like a reference counting problem on exit, I've got some more work to do in that area, as part of getting being able to reset the device.
Thanks again for the great work!
___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Another difference I noticed between this and cedega is that it loads approximately 6000x faster. I love it.
Whoops...I feel adequately retarded. It's OBVIOUSLY a sound-related error. I'm going to go hang myself now. When I get back, I'm going to send you some traces (unless you don't want them?) of the various things that go wrong.
I tried to get something more complete (traces and whatnot), but it seems that my wine has > compiled without --debugmsg for some reason. I'll see if I can fix that at some point.
wine no longer uses the --debugmsg option. Use the WINEDEBUG environment variable from now on. See http://winehq.org/site/docs/wine-user/x1824 for more information. -- James Hawkins
On Wed, 16 Feb 2005 18:56:44 -0600 James Hawkins <truiken(a)gmail.com> wrote:
I tried to get something more complete (traces and whatnot), but it seems that my wine has > compiled without --debugmsg for some reason. I'll see if I can fix that at some point.
wine no longer uses the --debugmsg option. Use the WINEDEBUG environment variable from now on. See http://winehq.org/site/docs/wine-user/x1824 for more information.
-- James Hawkins
I'm aware of this, but winedbg doesn't work without it. Plus, it turns out that I compiled wine with debug completely disabled.
On Wed, Feb 16, 2005 at 06:42:28PM -0500, cyrix12(a)cox.net wrote:
Wow...it works! Kind of. First thing I'd like to point out is that your patch doesn't add the new stuff (d3dx9 and wineguid) to the configure script, only to the configure.ac. That caused a little problem for me since I didn't autoconf it, but was easily fixed. Compilation went perfectly and, then the fun began.
Hmm, didn't notice a wineguid problem, I just added this around the same line for d3dx8 in configure.ac, ran autoconf and went on as normal: dlls/d3dx9/Makefile
Upon loading, it shows the usual intro screen. Unfortunately, there's no textures yet (as you've mentioned). It still runs though, and I can kind of make stuff out. When I began to load my character, it crashed at the same place that the opengl version crashed! It gave me this error:
It's not entirely without textures, and I get a lot further into the game with these patches than in opengl mode. I ran around for a bit seemingly without problems for a while, but the very first time I tried it did bomb out right at the start like with opengl. I made a screenshot of just outside a start room. The terrain seems to be textured, whereas everything else isn't. I guess terrain is handled differently. If you want to see it I've got it up on a webpage: http://giblets.org/games/wow/ If a fullsize screenshot is useful to anyone let me know and I'll email one over. Performance in this state is rather good. It seems to be very smooth running forward. Turning is less smooth, but definately playable. The machine is relatively powerful though - 3500+ Athlon 64, 1GB ram and a GeForce 6800. On the OpenGL front, I too get scuppered by the minimap error. It looks very promising otherwise though. -- Alex
Alex Woods wrote:
On the OpenGL front, I too get scuppered by the minimap error. It looks very promising otherwise though.
Hello Alex, There is a some what work around here: http://forums.worldofwarcraft.com/thread.aspx?fn=wow-interface-customization... I know the best solution would be to fix the minimap but this might help you to get further into the game so you will see how well it renders. just cd to interface/addons and place the hack there it should then load with the minimap turned off. Tom
On Fri, Feb 18, 2005 at 07:28:04PM -0500, Tom wrote:
There is a some what work around here: http://forums.worldofwarcraft.com/thread.aspx?fn=wow-interface-customization... I know the best solution would be to fix the minimap but this might help you to get further into the game so you will see how well it renders.
just cd to interface/addons and place the hack there it should then load with the minimap turned off.
Thanks, I've given it a try, but with no luck. At first it was showing version mismatch in the addons menu so I changed the Interface version in the toc file to match the game. It still bombs out on the minimap, so possibly something has changed in the API. -- Alex
Alex Woods wrote:
On Fri, Feb 18, 2005 at 07:28:04PM -0500, Tom wrote:
There is a some what work around here: http://forums.worldofwarcraft.com/thread.aspx?fn=wow-interface-customization... I know the best solution would be to fix the minimap but this might help you to get further into the game so you will see how well it renders.
just cd to interface/addons and place the hack there it should then load with the minimap turned off.
Thanks, I've given it a try, but with no luck. At first it was showing version mismatch in the addons menu so I changed the Interface version in the toc file to match the game. It still bombs out on the minimap, so possibly something has changed in the API.
Do you have Cosmos installed ? Tom
On Fri, 18 Feb 2005 19:28:04 -0500, Tom <twickline(a)sitestar.net> wrote:
Alex Woods wrote: There is a some what work around here: http://forums.worldofwarcraft.com/thread.aspx?fn=wow-interface-customization... I know the best solution would be to fix the minimap but this might help you to get further into the game so you will see how well it renders.
just cd to interface/addons and place the hack there it should then load with the minimap turned off.
Somehow just hiding the minimap is not ennough for Wine (it is for cedega). I use this (well, an edit of the cosmos files) to get the game working in cedega. But for wine there is something going wrong before you can hide the minimap with an interface script. Paul
On Wed, 16 Feb 2005 21:26:58 +0000 (GMT), Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I've just put together a new patch against head. http://www.oliverthered.f2s.com/projects/wine/
OK I've tried the new patch. As for Battlefront, it fixed the heap corruption bug. So that log is obsolete. And guess what? I can load into a game match now. I played it for a minute or so. There are several graphical problems that make it hard to play. For one, it doesn't get the transparency right around the crosshairs -- ie moving around a solid block. Another problem is that the game font gets corrupted after beginning a match. I think I'll let yall get some more stuff in before I start documenting the graphical problems. It does seems stable so far, but if I do find a crashing bug I'll let you know. Maybe I'll get around to reading more on D3D. Jesse
On Wed, 16 Feb 2005 21:26:58 +0000 (GMT), Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote:
I highly recommend that you try Oliver Stieber's patch. Even if buggy, I think you'll find WoW works very well. I've recently found that Star Wars: Battlefront works with it. The problem with Battlefront is it experiences heap corruption at the menu screen.
I've just put together a new patch against head. http://www.oliverthered.f2s.com/projects/wine/
Yeah great work. The opening screen and character selection (which is already partly ingame) of World of Warcraft now works. Had to turn off all debug output because it was printing so many lines the game would run slow. Loading failed somewhere at 1/3 (opengl does load completely) tough. And the game runned in some kind of semi-managed mode. Not sure how to descripe it. Performance of the main screen actually looked better than cedega. Thanks, Paul ps. You forgot to diff configure...
On Thu, Feb 17, 2005 at 10:50:46PM +0100, Paul van Schayck wrote:
And the game runned in some kind of semi-managed mode. Not sure how to descripe it. Performance of the main screen actually looked better than cedega.
I've only seen the game load up to the account login stage, but I think I might know what's causing what you're describing. I know that my current AMD64 build of wine doesn't hook up to XRandR properly, and so stuff keeps the size and refresh rate of my desktop. I know WoW is meant to set 60Hz, but in my case it couldn't and didn't and looked lovely ;) -- Alex
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
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) :(
participants (14)
-
Alex Woods -
Andreas Mohr -
cyrix12＠cox.net -
Holly Bostick -
Ivan Gyurdiev -
James Hawkins -
Jesse Allen -
Jonathan Wilson -
Lionel Ulmer -
Oliver Stieber -
Paul van Schayck -
Raphael -
Scott Ritchie -
Tom