drawprim.c and my last patchwatcher failure and question
Ok I went back blew away my git tree and got the latest one out there...
I then did one patch apply using one of my patches... and started rethinking
the way
I was doing? drawStridedSlow. Looking further into the code I found there was
another
function further down that did the switch but it was for another shader type
not the one
I am working on... it uses glVertexAttrib4svARB instead of
glMultiTexCoord4NsvARB.
So I created a new inline function like the other (dont think it should be a
inline but
following the other convention).
Now here is the question...
In looking in drawprim in the function drawStridedSlow I came across this :
??? int??? coordIdx =
This-stateBlock-textureState[textureNo][WINED3DTSS_TEXCOORDINDEX];
??? int texture_idx = This-texUnitMap[textureNo];
??? float *ptrToCoords = NULL;
??? float? s = 0.0, t = 0.0, r = 0.0, q = 0.0;
??? if (coordIdx 7) {
??? VTRACE((tex: %d - Skip tex coords, as being system
generated\n, textureNo));
??? continue;
??? } else if (coordIdx 0) {
??? FIXME(tex: %d - Coord index %d is less than zero, expect a
crash.\n, textureNo, coordIdx);
??? continue;
??? }
And as far as I can tell from that code it limits the total number texture
coordinates to
8 max. I cant find anywhere in the dx9 docs where it says that it is a hard
limit. I do
see that it is based more on the video card limit than anything else...
So the question is do we need this? If so why? so I understand...if not should
I remove
as part off this patch or submit it as another?
Next Question :
Once I finish the texture patch I am working on do I do a git commit of the
patch then
a git refresh of the tree before I do the patch export to send in? or whats the
process
so I dont get the messed up tree like I had before...
Thanks Guys
Chris
Re: Debugging Wine thoughts
Is there any documentation on the wine site how to set this up stefan??? It may be a start to what I am thinking. chris -Original Message- From: Stefan Dösinger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 11:32 am Subject: RE: Debugging Wine thoughts You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, or any graphical frontends, as well as Windows debuggers like visual studio. If you built wine from source, the Linux debuggers will see the Wine source. Probably they can also read the Windows apps source if you have it. I'm not sure if Windows debuggers can access the Wine source, but maybe dbghelp.dll can do that From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 10:17 AM To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Subject: Debugging Wine thoughts Dan / All, I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger). Then when looking at stacks you click on a variable or stack and it either winds it back or display's it. Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine So my wish list would be: 1) Some form of a Standard Gui Debugger 2) A way to select the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off... 4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window with a list of the important wine structures or resources that can be watched as the application runs. 6) Source code debugging in the GUI with step through, break points, etc..( not like no w in winedbg but more like one of the GUI's mentioned before) 7) Loading of application from gui debugger and run it 8) Ability to look at a stack and backtrace in the GUI 9) Value Watches within the GUI. 10) Code Checking Some sort of bounds checking... Uninitialized variable checking Unreachable Code Checking 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... 15) Link to whats fixed in the new GIT tree... or a list of it... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... 18) GIT integration You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. Most of these things I think could
Re: Size of SUBHEAP in heap.c
This sounds like a segment / Boundry issue... how far up does it repeat this action? or have you tried??? is it an even number of blocks that the error does not occur? Chris -Original Message- From: Martin Profittlich [EMAIL PROTECTED] To: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 12:52 pm Subject: Size of SUBHEAP in heap.c Hello, when trying to fix an issue with Guitar Rig 3 on Wine (Bug 10129, Guitar Rig 3 crashes), I found out something odd: The crash is affected by the size of the SUBHEAP structure in dlls/ntdll/heap.c. Just by adding 8 unused bytes to SUBHEAP, GR3 does not crash anymore. Add another 8 bytes, GR3 crashes again, yet another 8 bytes - no crash and so on. The bug surfaced with this commit: [1d063ae18d990343fc077dcbf650add797924018] ntdll: Remove assumptions that the subheap is at the beginning of the memory block. I don't think the commit is the cause of the problem. It merely changed the size of SUBHEAP to a problematic value. I don't really understand the inner workings of heap.c. Does anyone have an idea what the cause might be, or where to look for more information? Cheers, Martin P.S. Link to the bug: http://bugs.winehq.org/show_bug.cgi?id=10129 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: socket errors...
Ok thanks... so its safe to ignore which is what I was wondering =) Chris -Original Message- From: Damjan Jovanovic [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: wine-devel wine-devel@winehq.org Sent: Tue, 9 Sep 2008 1:01 am Subject: Re: socket errors... On Tue, Sep 9, 2008 at 5:03 AM, Chris Ahrendt [EMAIL PROTECTED] wrote: I started narrowing down some information in debugging a winemm issue and noticed the following in my logs... trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags 0, from 0x33f67c, fromlen 16, ovl (nil), func (nil) trace:winsock:WSARecvFrom fd=51, options=0 warn:winsock:WSARecvFrom - ERROR 10035 The 10035 is a buffer overflow error (I think) No, 10035 is WSAEWOULDBLOCK, which is normal for WSARecvFrom() on non-blocking sockets that currently have no data in the receive buffer. and I don't know much if at all how this set of code is supposed to work... anyone else getting this with the latest git tree? and any help on figuring out why the buffer is getting this error... I'd be more worried if it wasn't :-). thanks Chris Bye Damjan
patchwatcher online
couldn't you instead when the patchwatcher takes the patch it assigns it a patch # and require if there is a patch dependency? that the person put into a comment REQ_PATCH: 123456,15456, etc.. ? That way when a diff is done for the patch it would appear in the patch diff? Then patchwatcher would make sure thats in the tree if its accepted and if that req. patch was not accepted then the new patch is automatically rejected? Chris
Re: one liner patch to stop crash, everquest2.exe
yes I am looking at the shaders... and am noticing something as well in the traces... some reason when it goes to ask how much memory to use... on my machine it thinks it only has 16mb of texture memory.. when the laptop has 256mb of video ram...? if you look in device.c the pixel shader fails atleast on my firegl5200.? The other curiosity is that when EverQuest2.exe runs it seems to be going through the adapter initialization two times.. once when it loads then it starts loading up sound? and then it looks atleast in my traces? it initializes the adapter again getting an adapter which is the second adapter (I think) used for dual head Chris
uhandled exception error
I have finally tracked this down and have the patch for an unhandled exception
error.
The error occurs in? provider.c in routine :
static HRESULT DXDiag_InitDXDiagDirectShowFiltersContainer(IDxDiagContainer*
pSubCont) which is in provider.c in dxdiagn dll.
I won't post the whole routine as I rewrote it and cleaned it up considerably
and removed the GOTO's and so forth which are not part of the fix..
The fix is down at the bottom of the routine there is a call to
IEnumMoniker_Release(pEnum) and when the call is done for some reason pEnum is
still
NULL and is not checked for so there is the following :
fixme:dxdiag:DXDiag_InitDXDiagDirectShowFiltersContainerClassEnumerator
for clsid({cc7bfb41-f175-11d1-a392-00e0291f3959}) pEnum((nil))
trace:dxdiag:DXDiag_InitDXDiagDirectShowFiltersContainer Enum Moniker release
trace:dxdiag:DXDiag_InitDXDiagDirectShowFiltersContainer pEnum (null)
wine: Unhandled page fault on read access to 0x at address 0x61091d2b
(thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x in 32-bit code
(0x61091d2b).
by putting in a check for NULL before the call to IEnumMoniker_Release the
pagefault is now gone.
Now mind you this should be done. However, it doesnt explain why the pEnum is
NULL.
Since I cleaned up the routine and added this fix to the pagefault how would I
submit the cleaned up routine?
I know with the bug I will put the patch on the Bugzilla page for the page
fault and also put it on the patch list as well. But how do we
submit cleaned up code?
I have this thing over using goto's and started clearing the code up and found
that it was actually smaller when I was done and alot cleaner to follow.
Goto's tend to make debugging very difficult.
Chris
Re: Possible issue with win.c and help
-Original Message- From: Lei Zhang [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Sent: Tue, 1 Jul 2008 11:34 am Subject: Re: Possible issue with win.c and help On Mon, Jun 30, 2008 at 9:05 PM, Chris Ahrendt [EMAIL PROTECTED] wrote: Ok in my ever increasing search to figure out why EQ2 is getting a unhandled exception and also a no ipixel error. (I am convinced this is two separate bugs now) Bug One : This is the unhandled exception: If I have EQ2 run in anything but win98 mode (which I don't think is supported anymore by EQ2) wine dies with a unhandled exception. If I set to win98 it ends with a no ipixel format error message box (the second bug) after it begins to draw the window. The other thing is the msg box is not a typical msg box saying that something isn't supported but looks to be an exception in ClientApp.cpp which means they are getting some unhandled exception while drawing the window. What I think might be going on based on this : trace:win:WIN_SetWindowLong 0x2002c 0 0 W trace:win:WIN_SetWindowLong Fell Through trace:win:WIN_SetWindowLong Release Ptr trace:win:WIN_DestroyWindow 0x2002c trace:win:WIN_DestroyWindow 0x1002e trace:win:WIN_DestroyWindow 0x10030 trace:win:WIN_DestroyWindow 0x10032 trace:win:WIN_DestroyWindow 0x10034 trace:win:WIN_DestroyWindow 0x10036 trace:win:WIN_DestroyWindow 0x10038 trace:win:WIN_DestroyWindow 0x1003a trace:win:WIN_DestroyWindow 0x1003c trace:win:WIN_DestroyWindow 0x1003e trace:win:WIN_DestroyWindow 0x10040 trace:win:WIN_DestroyWindow 0x10042 trace:win:WIN_DestroyWindow 0x10044 trace:win:WIN_SetWindowLong 0x2002c 0 0 W These are my trace additions in SetWindowLong to help me follow the execution of the code trace:win:WIN_SetWindowLong Fell Through trace:win:WIN_SetWindowLong Release Ptr trace:win:WIN_SetWindowLong 0x2002c 12 0 W trace:win:WIN_SetWindowLong Fell Through trace:win:WIN_SetWindowLong Server Start Request trace:win:WIN_SetWindowLong Default trace:win:WIN_SetWindowLong no call Err trace:win:WIN_SetWindowLong Default get and Set Win Data trace:win:WIN_SetWindowLong Release Ptr trace:win:WIN_SetWindowLong Returning 1871960 CRASH! Unhandled Exception I think the window is being destroyed in reverse for some reason. Thats just my gut first feeling based on the above trace and the exception output. This is where my knowledge on Windows behavior ends. Does 98 destroy the windows chain differently than XP? This would explain why the exception doesn't occur in 98 but does in XP. Second Bug: This is the ipixel problem which I haven't figured out how to debug whats going on there, but think it might be related to this error: libGL error: drmMap of framebuffer failed (Cannot allocate memory) libGL error: reverting to (slow) indirect rendering libGL error: drmMap of framebuffer failed (Cannot allocate memory) libGL error: reverting to (slow) indirect rendering Which I am not sure why this is occurring yet but one bug at a time. Where would someone look to trace along the window draw chain to see where it dies. Some of the debug flags cause my machine to lock up which I know is a driver issue and other lockups could be caused by the above exception messing something up in X as the disk still runs when that lockup occurs but X is DOA. Thoughts? Ideas Suggestions?? Chris Hi, Please file bug reports on the Wine Bugzilla - http://bugs.winehq.org/ The second issue looks like 3d graphics are not set up correctly on your computer. You should ask your favorite Linux forum about that. Oh this is already reported as a bug... as to the second I know.. was just looking for some pointers... Need help actually understanding the way windows are handled in 98 vs XP . The graphic are set up correctly though... Chris
context.c
Has anyone looked at the changes put on the list for context.c? Just had not heard anything.. I assume it is because I am new and all but still...just trying to help per the request on the wine site =) chris
ok lets try this yet again
I am sorry everyone for the spam =)
been awhile since I developed stuff, been so used to designing things? =)
here in all its glorry is the diff -u context.c context.c.new diff.txt file
I couldnt get the -c option to work so here is just the -u
--- context.c??? 2008-06-26 13:52:57.0 -0400
+++ context.c.change??? 2008-06-26 14:32:48.0 -0400
@@ -116,13 +116,12 @@
int iPixelFormat=0;
short redBits, greenBits, blueBits, alphaBits, colorBits;
short depthBits=0, stencilBits=0;
-
int i = 0;
int nCfgs = This-adapter-nCfgs;
-??? WineD3D_PixelFormat *cfgs = This-adapter-cfgs;
?
-??? TRACE(ColorFormat=%s, DepthStencilFormat=%s, auxBuffers=%d,
numSamples=%d, pbuffer=%d, findCompatible=%d\n,
-? debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat),
auxBuffers, numSamples, pbuffer, findCompatible);
+??? WineD3D_PixelFormat *cfgs = This-adapter-cfgs;
+??? BOOL exactDepthMatch = FALSE;? /*Changed june 23,08 */??
+??? PIXELFORMATDESCRIPTOR pfd; /*Changed june 23,08 */
?
if(!getColorBits(ColorFormat, redBits, greenBits, blueBits, alphaBits,
colorBits)) {
ERR(Unable to get color bits for format %s (%#x)!\n,
debug_d3dformat(ColorFormat), ColorFormat);
@@ -145,84 +144,91 @@
?
DepthStencilFormat = WINED3DFMT_D24S8;
?
-??? if(DepthStencilFormat) {
-??? getDepthStencilBits(DepthStencilFormat, depthBits, stencilBits);
-??? }
+/* Changed Section June 24,08 */
+
+#if 0
+??? if(DepthStencilFormat)
+? {
+??? getDepthStencilBits(DepthStencilFormat, depthBits, stencilBits);
+??? }
+#endif
+
+/* Just call getDepthStencilBits as the above IF will always in this case be
true */
+
+??? getDepthStencilBits(DepthStencilFormat, depthBits, stencilBits);
?
/* Find a pixel format which EXACTLY matches our requirements (except for
depth) */
-??? for(i=0; inCfgs; i++) {
-??? BOOL exactDepthMatch = TRUE;
+??? for(i=0; inCfgs; i++)
+? {
cfgs = This-adapter-cfgs[i];
-
+???
/* For now only accept RGBA formats. Perhaps some day we will
? * allow floating point formats for pbuffers. */
if(cfgs-iPixelType != WGL_TYPE_RGBA_ARB)
-??? continue;
+?? continue;
?
/* In window mode (!pbuffer) we need a window drawable format and
double buffering. */
if(!pbuffer !(cfgs-windowDrawable cfgs-doubleBuffer))
-??? continue;
+?? continue;
?
-??? /* We like to have aux buffers in backbuffer mode */
+?? /* We like to have aux buffers in backbuffer mode */
if(auxBuffers !cfgs-auxBuffers)
-??? continue;
+?? continue;
?
/* In pbuffer-mode we need a pbuffer-capable format but we don't want
double buffering */
if(pbuffer (!cfgs-pbufferDrawable || cfgs-doubleBuffer))
-??? continue;
+ continue;
?
-??? if(cfgs-redSize != redBits)
-??? continue;
-??? if(cfgs-greenSize != greenBits)
-??? continue;
-??? if(cfgs-blueSize != blueBits)
-??? continue;
-??? if(cfgs-alphaSize != alphaBits)
-??? continue;
-
-??? /* We try to locate a format which matches our requirements exactly.
In case of
- * depth it is no problem to emulate 16-bit using e.g. 24-bit, so
accept that. */
-??? if(cfgs-depthSize depthBits)
-??? continue;
-??? else if(cfgs-depthSize depthBits)
-??? exactDepthMatch = FALSE;
+??? if ((cfgs-redSize != redBits) || (cfgs-greenSize != greenBits) ||
(cfgs-blueSize != blueBits) || (cfgs-alphaSize != alphaBits))
+ continue;
?
/* In all cases make sure the number of stencil bits matches our
requirements
? * even when we don't need stencil because it could affect performance
EXCEPT
? * on cards which don't offer depth formats without stencil like the
i915 drivers
? * on Linux. */
-??? if(stencilBits != cfgs-stencilSize !(This-adapter-brokenStencil
stencilBits = cfgs-stencilSize))
-??? continue;
+??? if((stencilBits != cfgs-stencilSize)
!((This-adapter-brokenStencil stencilBits) = cfgs-stencilSize))
+ continue;
?
/* Check multisampling support */
if(cfgs-numSamples != numSamples)
-??? continue;
+ continue;
?
-??? /* When we have passed all the checks then we have found a format
which matches our
- * requirements. Note that we only check for a limit number of
capabilities right now,
- * so there can easily be a dozen of pixel formats which appear to be
the 'same' but
- * can still differ in things like multisampling, stereo, SRGB and
other flags.
- */
+??? /* We try to locate a format which matches our requirements exactly.
In case of
+ * depth it is no problem to emulate 16-bit using e.g. 24-bit, so
accept that. */
+ if (cfgs-depthSize !=? depthBits)
+??? continue;
?
/* Exit the loop
Ok guys...
Thank you so much for being patient and showing me how to do this.. with much
help from everyone here is what the results are :
Patch 1 :
File : wine-1.0/dlls/wined3d/context.c
--- context.c??? 2008-06-26 13:52:57.0 -0400
+++ context.c.patch1??? 2008-06-26 15:19:15.0 -0400
@@ -145,9 +145,7 @@ static int WineD3D_ChoosePixelFormat(IWi
?
DepthStencilFormat = WINED3DFMT_D24S8;
?
-??? if(DepthStencilFormat) {
-??? getDepthStencilBits(DepthStencilFormat, depthBits, stencilBits);
-??? }
+??? getDepthStencilBits(DepthStencilFormat, depthBits, stencilBits);
?
/* Find a pixel format which EXACTLY matches our requirements (except for
depth) */
for(i=0; inCfgs; i++) {
Patch 2:
File: wine-1.0/dlls/wined3d/context.c
--- context.c??? 2008-06-26 13:52:57.0 -0400
+++ context.c.patch2??? 2008-06-26 15:37:25.0 -0400
@@ -120,7 +120,9 @@ static int WineD3D_ChoosePixelFormat(IWi
int i = 0;
int nCfgs = This-adapter-nCfgs;
WineD3D_PixelFormat *cfgs = This-adapter-cfgs;
-
+??? PIXELFORMATDESCRIPTOR pfd;
+??? BOOL exactDepthMatch = TRUE;
+???
TRACE(ColorFormat=%s, DepthStencilFormat=%s, auxBuffers=%d,
numSamples=%d, pbuffer=%d, findCompatible=%d\n,
?? debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat),
auxBuffers, numSamples, pbuffer, findCompatible);
?
@@ -151,7 +153,6 @@ static int WineD3D_ChoosePixelFormat(IWi
?
/* Find a pixel format which EXACTLY matches our requirements (except for
depth) */
for(i=0; inCfgs; i++) {
-??? BOOL exactDepthMatch = TRUE;
cfgs = This-adapter-cfgs[i];
?
/* For now only accept RGBA formats. Perhaps some day we will
@@ -180,13 +181,7 @@ static int WineD3D_ChoosePixelFormat(IWi
if(cfgs-alphaSize != alphaBits)
continue;
?
-??? /* We try to locate a format which matches our requirements exactly.
In case of
- * depth it is no problem to emulate 16-bit using e.g. 24-bit, so
accept that. */
-??? if(cfgs-depthSize depthBits)
-??? continue;
-??? else if(cfgs-depthSize depthBits)
-??? exactDepthMatch = FALSE;
-
+???
/* In all cases make sure the number of stencil bits matches our
requirements
? * even when we don't need stencil because it could affect performance
EXCEPT
? * on cards which don't offer depth formats without stencil like the
i915 drivers
@@ -198,6 +193,13 @@ static int WineD3D_ChoosePixelFormat(IWi
if(cfgs-numSamples != numSamples)
continue;
?
+?? /* We try to locate a format which matches our requirements exactly. In
case of
+ * depth it is no problem to emulate 16-bit using e.g. 24-bit, so
accept that. */
+??? if(cfgs-depthSize depthBits)
+??? continue;
+??? else if(cfgs-depthSize depthBits)
+??? exactDepthMatch = FALSE;
+
/* When we have passed all the checks then we have found a format
which matches our
? * requirements. Note that we only check for a limit number of
capabilities right now,
? * so there can easily be a dozen of pixel formats which appear to be
the 'same' but
@@ -216,12 +218,8 @@ static int WineD3D_ChoosePixelFormat(IWi
}
}
?
-??? /* When findCompatible is set and no suitable format was found, let
ChoosePixelFormat choose a pixel format in order not to crash. */
-??? if(!iPixelFormat !findCompatible) {
-??? ERR(Can't find a suitable iPixelFormat\n);
-??? return FALSE;
-??? } else if(!iPixelFormat) {
-??? PIXELFORMATDESCRIPTOR pfd;
+??? if(!iPixelFormat) {
+
?
TRACE(Falling back to ChoosePixelFormat as we weren't able to find an
exactly matching pixel format\n);
/* PixelFormat selection */
Chris Ahrendt
P.S. THANKS everyone.. so now comments please? G
yes I am trying to get feedback before I put it...
on the patch list... The first patch is for a bug I tracked down in context.c that is causing some of the behavior that wine is having with the ATI graphics driver. The second patch? was something I noticed in the code as well that looked a little off which also relates to the way iPixel shaders are init in the d3d code. So I came on here to get some feedback first before taking it to the patch group as something. This was to start getting my feet wet before I took up potentially some development task or the like. not sure about why the mailer is replacing spaces with ? that I do not know... Chris Ahrendt
Code Review and findings in d3d while working on figuring out why...
Ok I have been wandering around the code in context.c and have found a few things that I have opened a bug on (14000) but in further looking in context.c if I comment out the lines between 237 and 245 wine seems to continue working better infact? (I no longer get no iPixel errors using wine 1.0 with the latest ATI drivers) My question is this why wouldn't you want to find a compatible mode to use and just call the next few lines where it calls choose pixel format and if that fails for what ever reason then say you cant find a suitable iPixel format? If you leave the section there the following occurs. Start up EverQuest2.exe? it calls the iPixel function 3 times for some reason without the fix in bug 14000 it fails immediately. With the fix the first one succeeds then the second and third times it returns the no iPixel format to the application. If I comment out the above section it no longer fails at all but gets farther along. before throwing an unhandled exception (which happened before I started working with this problem ) which is documented in another bug (forget the number right now). Chris p.s. if needed I can post my context.c on the bug above or to the mailing list.. .just the function I have been working on
sorry forgot to cut and paste some code =)
the code is in :
wine-1.0/dlls/wined3d/context.c
here is the changed code :
/* This function takes care of WineD3D pixel format selection. */
static int WineD3D_ChoosePixelFormat(IWineD3DDeviceImpl *This, HDC hdc,
WINED3DFORMAT ColorFormat, WINED3DFORMAT DepthStencilFormat, BOOL auxBuffers,
int numSamples, BOOL pbuffer, BOOL findCompatible)
{
??? int iPixelFormat=0;
??? short redBits, greenBits, blueBits, alphaBits, colorBits;
??? short depthBits=0, stencilBits=0;
??? int i = 0;
??? int nCfgs = This-adapter-nCfgs;
??? WineD3D_PixelFormat *cfgs = This-adapter-cfgs;
??? BOOL exactDepthMatch = FALSE;? /*Changed june 23,08 */??
??? PIXELFORMATDESCRIPTOR pfd; /*Changed june 23,08 */
??? TRACE(ColorFormat=%s, DepthStencilFormat=%s, auxBuffers=%d, numSamples=%d,
pbuffer=%d, findCompatible=%d\n,
? debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat),
auxBuffers, numSamples, pbuffer, findCompatible);
??? if (!getColorBits(ColorFormat, redBits, greenBits, blueBits, alphaBits,
colorBits))
{
??? ERR(Unable to get color bits for format %s (%#x)!\n,
debug_d3dformat(ColorFormat), ColorFormat);
??? return 0;
??? }
??? /* In WGL both color, depth and stencil are features of a pixel format. In
case of D3D they are separate.
* You are able to add a depth + stencil surface at a later stage when you
need it.
* In order to support this properly in WineD3D we need the ability to
recreate the opengl context and
* drawable when this is required. This is very tricky as we need to
reapply ALL opengl states for the new
* context, need torecreate shaders, textures and other resources.
*
* The context manager already takes care of the state problem and for the
other tasks code from Reset
* can be used. These changes are way to risky during the 1.0 code freeze
which is taking place right now.
* Likely a lot of other new bugs will be exposed. For that reason request
a depth stencil surface all the
* time. It can cause a slight performance hit but fixes a lot of
regressions. A fixme reminds of that this
* issue needs to be fixed. */
??? if (DepthStencilFormat != WINED3DFMT_D24S8)
??? FIXME(Add OpenGL context recreation support to
SetDepthStencilSurface\n);
??? DepthStencilFormat = WINED3DFMT_D24S8;
/* Changed Section June 24,08 */
/*??? if(DepthStencilFormat) { Changed June 19,08*/
??? getDepthStencilBits(DepthStencilFormat, depthBits, stencilBits);
/*??? }?? This if will always be true because of the above? so just call
getDepthStencilBits */
??? /* Find a pixel format which EXACTLY matches our requirements (except for
depth) */
??? for(i=0; inCfgs; i++)
? {
??? cfgs = This-adapter-cfgs[i];
???
??? /* For now only accept RGBA formats. Perhaps some day we will
* allow floating point formats for pbuffers. */
??? if (cfgs-iPixelType != WGL_TYPE_RGBA_ARB)
?? continue;
??? /* In window mode (!pbuffer) we need a window drawable format and
double buffering. */
??? if (!pbuffer !(cfgs-windowDrawable cfgs-doubleBuffer))
?? continue;
?? /* We like to have aux buffers in backbuffer mode */
??? if (auxBuffers !cfgs-auxBuffers)
?? continue;
??? /* In pbuffer-mode we need a pbuffer-capable format but we don't want
double buffering */
??? if (pbuffer (!cfgs-pbufferDrawable || cfgs-doubleBuffer))
continue;
/* This is faster and more efficient code wise since they are all related so
evaluate them together Changed June 19,08 */
??? if ((cfgs-redSize != redBits) || (cfgs-greenSize != greenBits) ||
(cfgs-blueSize != blueBits) || (cfgs-alphaSize != alphaBits))
continue;
??? /* In all cases make sure the number of stencil bits matches our
requirements
* even when we don't need stencil because it could affect performance
EXCEPT
* on cards which don't offer depth formats without stencil like the
i915 drivers
* on Linux. */
??? if ((stencilBits != cfgs-stencilSize)
!((This-adapter-brokenStencil stencilBits) = cfgs-stencilSize))
continue;
??? /* Check multisampling support */
??? if (cfgs-numSamples != numSamples)
continue;
??? /* We try to locate a format which matches our requirements exactly. In
case of
* depth it is no problem to emulate 16-bit using e.g. 24-bit, so
accept that. */
if (cfgs-depthSize !=? depthBits)? /* Changed June 24,08 */
??? continue;
??? /* Exit the loop as we have found a format :) */
??? if (exactDepthMatch)
?? {
??? TRACE(Exact Depth Match\n);
??? iPixelFormat = cfgs-iPixelFormat;
??? break;
?? }
??? if (!iPixelFormat)
? {
??? /* In the end we might end up with a format which doesn't exactly
match our depth
* requirements. Accept the first format we found because
