fixme:d3d_surface:IWineD3DSurfaceImpl_LoadTexture Surface in texture is only supported for level 0
Hi All, Im getting a lot of these errors when trying to run Everquest 2, and I was wondering if its something I could fix. Does anyone know why only level 0 is supported for this? I put some additional debug, and find EQ2 is calling this with levels up 1 - 9. Thanks in advance Kapila.
Re: Need help with SymInitializeW
Hi guys, I put some more debug in the process_find_by_handle function of dbghelp.c, and what Im seeing is the second time we call SymInitializeW, we appear to create a new process structure, so following calls to process_find_by_handle returns the new one, and not the old one. In the trace below, the first call to process_find_by_handle returns a process structure stored at 0x16c600, but the next calls locate two process structures (one at 0x16c600 and one at 0xf5ee680). Could this be an issue? Both seem to have the same process handle of 0x. Maybe when allocating a new process structure we should check if one already exists with the same handle? Thanks Kapila. fixme:dbghelp:SymInitialize Calling SymInitializeW 0x fixme:dbghelp:SymInitializeW (0x (null) 1) fixme:dbghelp:process_find_by_handle Searching for process 0x compared to 0x (0x16c600) fixme:dbghelp:process_find_by_handle Returning process handle 0x16c600 and 0x fixme:dbghelp:SymInitializeW what to do ?? fixme:dbghelp:SymInitializeW Not User search path fixme:dbghelp:SymInitializeW check live target fixme:dbghelp:SymInitializeW Invade Process fixme:dbghelp:process_find_by_handle Searching for process 0x compared to 0x (0xf5ee680) fixme:dbghelp:process_find_by_handle Searching for process 0x compared to 0x (0x16c600) fixme:dbghelp:process_find_by_handle Returning process handle 0xf5ee680 and 0x On Wed, 2007-03-14 at 20:53 +0100, Eric Pouech wrote: Paul Vriens a écrit : Eric Pouech wrote: Kapila De Silva a écrit : Hi All, Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help. I'll send a fix later on for the FIXME, but it's unlikely this is what's causing the crash So, you have to understand where the 0x as an address comes from. sometimes, +relay helps figuring that out, but YMMV A+ Hi, just wanted to report that Process Explorer also calls it with 0x when viewing the 'System Information': trace:dbghelp:SymInitializeW (0x (null) 0) trace:dbghelp:elf_load_file Processing elf file 'Lwine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/lib/qt-3.3/bin/wine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/kerberos/bin/wine-kthread' at trace:dbghelp:elf_load_file Processing elf file 'L/usr/local/bin/wine-kthread' at Could 0x mean something like system-wide? Cheers, Paul. in that cas 0x is the default handle to the current process, and is never derefenced... include/winbase.h:#define GetCurrentProcess() ((HANDLE)0x) A+
Delayed debug patch
Can someone tell me how to apply this to my git copy of wine please? This would help a lot with my debugging... Thanks Kapila
Need help with SymInitializeW
Hi All, Im trying to debug a crash in Everquest 2, (bug 7705) and am hoping someone here can help. The crash seems to be linked to the process calling SymInitializeW a second time (its called once at the start of the process, and works ok) On the second call to the function we see an error fixme:dbghelp:SymInitializeW what to do ?? By putting some tracing in here, I noticed that when the function is called the first time, the call to process_find_by_handle(hProcess) returns null, and once the SymInitializeW function calls EnumerateLoadedModules, process_find_by_handle returns a process id. In the second call, the process_find_by_handle(hProcess) returns the same process id as before, however, when the SymInitializeW function calls EnumerateLoadedModules, process_find_by_handle returns a different process id. Should SymInitializeW be called multiple times by a process? Is it possible that a problem has already occured, and this is called as a result? Or is it possible that SymInitializeW itself is the cause of the crash? Any ideas? Thanks Below is some trace I got when I put in some extra debug. First call: fixme:dbghelp:SymInitialize Calling SymInitializeW 0x(0x LC:\\Program Files\\Sony\\EverQuest II 1) fixme:dbghelp:process_find_by_handle Returning process handle (nil) fixme:dbghelp:process_find_by_handle Returning process handle 0x16c5d0 Second Call: fixme:dbghelp:SymInitialize Calling SymInitializeW 0x(0x (null) 1) fixme:dbghelp:process_find_by_handle Returning process handle 0x16c5d0 fixme:dbghelp:SymInitializeW what to do ?? fixme:dbghelp:process_find_by_handle Returning process handle 0x3a8f9a0
ATI and GL_ARB_Imaging support
Hi all, I noticed, that wine checks for GL_ARB_imaging, before performing operations like glBlendColor, glBlendEquation etc. However it appears that the ATI drivers do not support this extension, though they do support the blending operations. I posted about this on the Rage3d linux driver boards, and the response seems to suggest that it would be better to check for the individual operations rather than the GL_ARB_imaging extension. See bottom of http://rage3d.com/board/showthread.php?t=33814685 What do you guys think? Kap.
Help with git
Hi all, Hope this is the right place to post this, if not, my apologies. Im trying to track down an issue that occurred between 0.9.19 and 0.9.20, and am using git bisect to track the issue. In the process of trying to identify the cause of the issue, I would like to be able to get the code up till a certain patch, and then apply patches one by one as well. I have not been able to find out how to do this, despite several web searches and man pages. Can anyone give me any pointers to this please? Thanks in advance Kapila
Help with shader code
Hi All, can someone help me understand some code from dlls/wined3d/vertexshader.c please? Im new to shader code, but to me the following looks a bit strange: shader_addline(buffer, ADD result.position.x, TMP_OUT.x, PROJECTIONX.w;\n); shader_addline(buffer, ADD result.position.y, TMP_OUT.y, PROJECTIONY.w;\n); /* Account for any inverted textures (render to texture case) by reversing the y coordinate * (this is handled in drawPrim() when it sets the MODELVIEW and PROJECTION matrices) */ shader_addline(buffer, MUL result.position.y, TMP_OUT.y, PROJECTIONY.y;\n); Am I correct that the last line makes the second line redundant? Wont result.position.y be equal to TMP_OUT.y * PROJECTIONY.y no matter what? Thanks in advance. Kapila.
