This patch collides with Victor Eremin's general convertor I think. We may still want both, because the special function is faster than code that attempts to handle all potential formats.
-----Original Message----- From: wine-patches-bounces@winehq.org [mailto:wine-patches- bounces@winehq.org] On Behalf Of Austin English Sent: Wednesday, July 23, 2008 9:34 AM To: wine-patches@winehq.org Subject: Fwd: Convert 565 to 0888
---------- Forwarded message ---------- From: Einars einars@gmail.com Date: Jul 22, 2008 11:22 PM Subject: Convert 565 to 0888 To: wine-devel@winehq.org
I had graphical problems with an online game called Angels Online, when just a black screen was visible, and complaints about missing converter from WINED3DFMT_R5G6B5 to WINED3DFMT_X8R8G8B8, so I added a converter for this format, and the game runs flawlessly now on wine, the 1.1.1 release as well as git version (at least for me). I hope this was the right way to fix it.
Kind regards,
Einars Lielmanis
While sitting on the airplane I reworked and rethought the set render states routine I sent last night and have figured out a more efficient way for it to run... Logically thinking it through 208 of the 240 states passed into this routine do nothing and have no real type checking other than to make sure the value is a dword (which MSDN is very clear that the type of value is a Dword). So what I have done is those 208 States are in one case statement in the switch that does a break. So 87% of the calls into set render state will work as they have worked before and work on windows. That leaves 32 states which have specific rules that are applied to them such as valid value ranges or values. This consists of 32 States (13% of the calls into the routine) which need Value checking. Most of these 32 states do not need individual rules applied but some do. This should not overly cause any speed issues for the routine. There are a four States :
WINED3DRS_SRCBLENDALPHA WINED3DRS_DESTBLENDALPHA WINED3DRS_DESTBLEND WINED3DRS_SRCBLEND
which have a large IF associated with them but they are grouped together in one case statement. I believe on windows these calls tend to be a bit slower than the others however I would have to test that out to confirm.
As to this patching my issues with everquest2. I forgot that I had the loader patch on this build I was using. So the actual way I have found that gets EQ sort of running or atleast the start of it running using my T60p is the libgl wine loader patch, this patch and the ATI patch which comments out line 57 and 60 from directx.c all of those get me to the point where it starts loading and I get past the ipixel issue.
Please comment on the attached patch and let me know what you think.. I would like to submit this to the patch list =). If it is alright with you I would like going through and where you have noted TODO's to start working on those. Got to have something to keep me occupied while I am on the road =)
Chris
--- device_old.c 2008-07-25 11:42:25.000000000 -0400 +++ device.c 2008-07-27 22:47:05.000000000 -0400 @@ -34,6 +34,11 @@
WINE_DEFAULT_DEBUG_CHANNEL(d3d); #define GLINFO_LOCATION This->adapter->gl_info +#define D3DBLEND_INVSRCCOLOR 4 +#define WINED3DDMT_ENABLE 0 +#define WINED3DDMT_DISABLE 1 +#define WINED3DBLEND_INVSRCCOLOR2 17 +#define WINED3DBLEND_SRCCOLOR2 16
/* Define the default light parameters as specified by MSDN */ const WINED3DLIGHT WINED3D_default_light = { @@ -3248,15 +3253,270 @@
/***** * Get / Set Render States - * TODO: Verify against dx9 definitions - *****/ + Parms + State This param will be any member of the WINED3DRENDERSTATETYPE type. + + Value This is dependent on the State value + + ****/ static HRESULT WINAPI IWineD3DDeviceImpl_SetRenderState(IWineD3DDevice *iface, WINED3DRENDERSTATETYPE State, DWORD Value) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; DWORD oldValue = This->stateBlock->renderState[State];
TRACE("(%p)->state = %s(%d), value = %d\n", This, debug_d3drenderstate(State), State, Value); + + switch(State) + { + /* These States do not need Value checking + They either contain a valid DWORD value or a TRUE == 0 + or FALSE > 0. So do not need the type checking of the + other calls */ + case WINED3DRS_BLENDOPALPHA: + WINED3DRS_FOGCOLOR: + WINED3DRS_SEPARATEALPHABLENDENABLE: + WINED3DRS_TWOSIDEDSTENCILMODE: + WINED3DRS_ENABLEADAPTIVETESSELLATION: + WINED3DRS_ANTIALIASEDLINEENABLE: + WINED3DRS_SCISSORTESTENABLE: + WINED3DRS_INDEXEDVERTEXBLENDENABLE: + WINED3DRS_MULTISAMPLEANTIALIAS: + WINED3DRS_POINTSPRITEENABLE: + WINED3DRS_POINTSCALEENABLE: + WINED3DRS_NORMALIZENORMALS: + WINED3DRS_LOCALVIEWER: + WINED3DRS_COLORVERTEX: + WINED3DRS_CLIPPING: + WINED3DRS_ZENABLE: + WINED3DRS_STENCILENABLE: + WINED3DRS_RANGEFOGENABLE: + WINED3DRS_ALPHABLENDENABLE: + WINED3DRS_DITHERENABLE: + WINED3DRS_ZWRITEENABLE: + WINED3DRS_ALPHATESTENABLE: + WINED3DRS_FOGENABLE: + WINED3DRS_SPECULARENABLE: + WINED3DRS_LIGHTING: + WINED3DRS_LASTPIXEL: + WINED3DRS_DEPTHBIAS: + WINED3DRS_SRGBWRITEENABLE: + WINED3DRS_BLENDFACTOR: + WINED3DRS_COLORWRITEENABLE1: + WINED3DRS_MULTISAMPLEMASK: + WINED3DRS_AMBIENT: + WINED3DRS_TEXTUREFACTOR: + WINED3DRS_STENCILWRITEMASK: + WINED3DRS_STENCILMASK: + WINED3DRS_COLORWRITEENABLE2: + WINED3DRS_COLORWRITEENABLE3: + WINED3DRS_ADAPTIVETESS_X: + WINED3DRS_ADAPTIVETESS_Y: + WINED3DRS_ADAPTIVETESS_Z: + WINED3DRS_ADAPTIVETESS_W: + WINED3DRS_SLOPESCALEDEPTHBIAS: + WINED3DRS_TWEENFACTOR: + WINED3DRS_COLORWRITEENABLE: + WINED3DRS_POINTSIZE_MAX: + WINED3DRS_WRAP0: + WINED3DRS_WRAP1: + WINED3DRS_WRAP2: + WINED3DRS_WRAP3: + WINED3DRS_WRAP4: + WINED3DRS_WRAP5: + WINED3DRS_WRAP6: + WINED3DRS_WRAP7: + WINED3DRS_WRAP8: + WINED3DRS_WRAP9: + WINED3DRS_WRAP10: + WINED3DRS_WRAP11: + WINED3DRS_WRAP12: + WINED3DRS_WRAP13: + WINED3DRS_WRAP14: + WINED3DRS_WRAP15: + WINED3DRS_STENCILREF: + WINED3DRS_FOGSTART: + WINED3DRS_FOGEND: + WINED3DRS_FOGDENSITY: + WINED3DRS_CLIPPLANEENABLE: + WINED3DRS_POINTSIZE: + WINED3DRS_POINTSIZE_MIN: + WINED3DRS_POINTSCALE_A: + WINED3DRS_POINTSCALE_B: + WINED3DRS_POINTSCALE_C: + break; + + case WINED3DRS_FILLMODE: + if ((Value == WINED3DFILL_POINT) || + (Value == WINED3DFILL_WIREFRAME) || + (Value == WINED3DFILL_SOLID)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_SHADEMODE: + if ((Value == WINED3DSHADE_FLAT) || + (Value == WINED3DSHADE_GOURAUD) || + (Value == WINED3DSHADE_PHONG)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_SRCBLENDALPHA: + case WINED3DRS_DESTBLENDALPHA: + case WINED3DRS_DESTBLEND: + case WINED3DRS_SRCBLEND: + if ((Value == WINED3DBLEND_ZERO) || + (Value == WINED3DBLEND_ONE) || + (Value == WINED3DBLEND_SRCCOLOR) || + (Value == WINED3DBLEND_INVSRCCOLOR) || + (Value == WINED3DBLEND_SRCALPHA) || + (Value == WINED3DBLEND_INVSRCALPHA) || + (Value == WINED3DBLEND_DESTALPHA) || + (Value == WINED3DBLEND_INVDESTALPHA) || + (Value == WINED3DBLEND_DESTCOLOR) || + (Value == WINED3DBLEND_INVDESTCOLOR) || + (Value == WINED3DBLEND_SRCALPHASAT) || + (Value == WINED3DBLEND_BOTHSRCALPHA) || + (Value == WINED3DBLEND_BOTHINVSRCALPHA) || + (Value == WINED3DBLEND_BLENDFACTOR) || + (Value == WINED3DBLEND_INVBLENDFACTOR) || + (Value == WINED3DBLEND_SRCCOLOR2) || + (Value == WINED3DBLEND_INVSRCCOLOR2)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_CULLMODE: + if ((Value == WINED3DCULL_NONE) || + (Value == WINED3DCULL_CW) || + (Value == WINED3DCULL_CCW)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_CCW_STENCILFUNC: + WINED3DRS_STENCILFUNC: + WINED3DRS_ALPHAFUNC: + WINED3DRS_ZFUNC: + if ((Value == WINED3DCMP_NEVER) || + (Value == WINED3DCMP_LESS) || + (Value == WINED3DCMP_EQUAL) || + (Value == WINED3DCMP_LESSEQUAL) || + (Value == WINED3DCMP_GREATER) || + (Value == WINED3DCMP_NOTEQUAL) || + (Value == WINED3DCMP_GREATEREQUAL) || + (Value == WINED3DCMP_ALWAYS)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_ALPHAREF: + /* Valid values are between 0 and FF */ + if ((Value >= 0) || + (Value <= 0xFF)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_FOGVERTEXMODE: + WINED3DRS_FOGTABLEMODE: + if ((Value == WINED3DFOG_NONE) || + (Value == WINED3DFOG_EXP) || + (Value == WINED3DFOG_EXP2) || + (Value == WINED3DFOG_LINEAR)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_CCW_STENCILFAIL: + WINED3DRS_CCW_STENCILZFAIL: + WINED3DRS_CCW_STENCILPASS: + WINED3DRS_STENCILPASS: + WINED3DRS_STENCILZFAIL: + WINED3DRS_STENCILFAIL: + if ((Value == WINED3DSTENCILOP_KEEP) || + (Value == WINED3DSTENCILOP_ZERO) || + (Value == WINED3DSTENCILOP_REPLACE) || + (Value == WINED3DSTENCILOP_INCRSAT) || + (Value == WINED3DSTENCILOP_DECRSAT) || + (Value == WINED3DSTENCILOP_INVERT) || + (Value == WINED3DSTENCILOP_INCR) || + (Value == WINED3DSTENCILOP_DECR)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_SPECULARMATERIALSOURCE: + WINED3DRS_AMBIENTMATERIALSOURCE: + WINED3DRS_EMISSIVEMATERIALSOURCE: + WINED3DRS_DIFFUSEMATERIALSOURCE: + if ((Value == WINED3DMCS_MATERIAL) || + (Value == WINED3DMCS_COLOR1) || + (Value == WINED3DMCS_COLOR2)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_VERTEXBLEND: + if ((Value == WINED3DVBF_DISABLE) || + (Value == WINED3DVBF_1WEIGHTS) || + (Value == WINED3DVBF_2WEIGHTS) || + (Value == WINED3DVBF_3WEIGHTS) || + (Value == WINED3DVBF_TWEENING) || + (Value == WINED3DVBF_0WEIGHTS)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_PATCHEDGESTYLE: + if ((Value == WINED3DPATCHEDGE_DISCRETE) || + (Value == WINED3DPATCHEDGE_CONTINUOUS)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_DEBUGMONITORTOKEN: + if ((Value == WINED3DDMT_ENABLE) || + (Value == WINED3DDMT_DISABLE)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_BLENDOP: + if ((Value == WINED3DBLENDOP_ADD) || + (Value == WINED3DBLENDOP_SUBTRACT) || + (Value == WINED3DBLENDOP_REVSUBTRACT) || + (Value == WINED3DBLENDOP_MIN) || + (Value == WINED3DBLENDOP_MAX)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_NORMALDEGREE: + WINED3DRS_POSITIONDEGREE: + if ((Value == WINED3DDEGREE_LINEAR) || + (Value == WINED3DDEGREE_QUADRATIC) || + (Value == WINED3DDEGREE_CUBIC) || + (Value == WINED3DDEGREE_QUINTIC)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_MINTESSELLATIONLEVEL: + WINED3DRS_MAXTESSELLATIONLEVEL: + if ((Value == WINED3DDEGREE_LINEAR) || + (Value == WINED3DDEGREE_QUADRATIC) || + (Value == WINED3DDEGREE_CUBIC) || + (Value == WINED3DDEGREE_QUINTIC)) break; + TRACE("Invalid Value\n"); + return WINED3DERR_INVALIDCALL; + break;
+ Default: + TRACE("Unkown State type = %d\n",State); + return WINED3DERR_INVALIDCALL; + } + This->updateStateBlock->changed.renderState[State] = TRUE; This->updateStateBlock->renderState[State] = Value;
@@ -3278,7 +3538,7 @@
static HRESULT WINAPI IWineD3DDeviceImpl_GetRenderState(IWineD3DDevice *iface, WINED3DRENDERSTATETYPE State, DWORD *pValue) { IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; - TRACE("(%p) for State %d = %d\n", This, State, This->stateBlock->renderState[State]); + TRACE("(%p) for State %d = %d\n", This, State, This->stateBlock->renderState[State]); *pValue = This->stateBlock->renderState[State]; return WINED3D_OK; }
2008/7/28 Chris Ahrendt celticht32@aol.com:
Please comment on the attached patch and let me know what you think..
Almost all of my comments on the original patch still stand. In addition, you're adding trailing spaces, and you've got an unnecessary whitespace change in there.
My performance concern is about the switch statement itself, less about the actual value checking. If you have something like
switch(renderstate) { case WINED3DRS_A: case WINED3DRS_B: doSomething(); break;
default: break; }
The binary code generated by the compiler still checks 239 states against D3DRS_A and D3DRS_B(the only exception is D3DRS_A, which is never compared against D3DRS_B). That is where my worries come from, not the doSomething() itself.
But beyond that, I think checking the value ranges is just wrong, at least we need a test to show Windows does that as well.
Stefan Dösinger wrote:
My performance concern is about the switch statement itself, less about the actual value checking. If you have something like
switch(renderstate) { case WINED3DRS_A: case WINED3DRS_B: doSomething(); break;
default: break;}
The binary code generated by the compiler still checks 239 states against D3DRS_A and D3DRS_B(the only exception is D3DRS_A, which is never compared against D3DRS_B). That is where my worries come from, not the doSomething() itself.
But beyond that, I think checking the value ranges is just wrong, at least we need a test to show Windows does that as well.
Ok I will work on the test case when I get a chance... (I think I can do this in a vmware session if not it is going to have to wait till I get to the house where I have a windows machine).
Ahh ok... I also this morning moved the check to see if the call is just resetting the same value over and over to before the switch statement so that if we are getting the same value it just returns like it did before however it does not set it over again.
Chris
Ok I will work on the test case when I get a chance... (I think I can do this in a vmware session if not it is going to have to wait till I get to the house where I have a windows machine).
Actually, you have to be careful with D3D and vmware. D3D is highly driver dependent, up to the point where we diverge from the reference rasterizer because games depend on a driver bug. VMware has its own D3D driver, which fails miserably in Wine tests(last someone checked).
So you can certainly use vmware to write the test, but before using it to implement the same behavior in Wine or submitting the test, you should really test with a Windows machine, preferably one that has a GeForce or Radeon card
Stefan Dösinger wrote:
Ok I will work on the test case when I get a chance... (I think I can do this in a vmware session if not it is going to have to wait till I get to the house where I have a windows machine).
Actually, you have to be careful with D3D and vmware. D3D is highly driver dependent, up to the point where we diverge from the reference rasterizer because games depend on a driver bug. VMware has its own D3D driver, which fails miserably in Wine tests(last someone checked).
So you can certainly use vmware to write the test, but before using it to implement the same behavior in Wine or submitting the test, you should really test with a Windows machine, preferably one that has a GeForce or Radeon card
Ok.... I have a machine at home that I think has a GeForce card in it or a Radeon (I cant remember) that I will run on. Would it be better to write the test code or find something like 3D mark or the like?
Chris
Ok.... I have a machine at home that I think has a GeForce card in it or a Radeon (I cant remember) that I will run on. Would it be better to write the test code or find something like 3D mark or the like?
Look at dlls/d3d9/tests/*.c for how the Wine tests work
Stefan Dösinger wrote:
Ok.... I have a machine at home that I think has a GeForce card in it or a Radeon (I cant remember) that I will run on. Would it be better to write the test code or find something like 3D mark or the like?
Look at dlls/d3d9/tests/*.c for how the Wine tests work
Ok thanks... will do =)
Chris
Stefan Dösinger wrote:
Ok.... I have a machine at home that I think has a GeForce card in it or a Radeon (I cant remember) that I will run on. Would it be better to write the test code or find something like 3D mark or the like?
Look at dlls/d3d9/tests/*.c for how the Wine tests work
Ok looking at the d3d9 directory I found visual.c which has quite a few calls to the set render state.. So would I go through and make sure that all of the calls which I added in the type checking are in the test?
What about failure tests to make sure the function is working right esp on windows?
Sorry for the questions but I am not finding anything out there on writing the wine test cases =)
chris
-
Chris Ahrendt -
H. Verbeet -
Stefan Dösinger