Re: [5/5] wined3d: Fix NaN and Inf generation in msvc
On 02/08/2010, Henri Verbeet wrote: > On 2 August 2010 13:20, GOUJON Alexandre wrote: > > Why don't you use math.h NAN macro ? > > A quick search on google gave me > > http://www.gnu.org/software/libc/manual//html_node/Infinity-and-NaN.html > > > > That's not portable enough. > The INFINITY macro is part of C99, but for NaN, why not use something like sqrt(-1) ?
Re: Small Direct3D milestone
Martin Owens wrote: Woot, thank you so much! Stefan D�singer, is this a time to ask you for help getting the really really easy bug in X11DRV_DIB_MapColor, oh go on pretty please with sugar on top? http://bugs.winehq.org/show_bug.cgi?id=6670 It looks like a duplicate of http://bugs.winehq.org/show_bug.cgi?id=2666 I sent some patches to the mailing list earlier, so when they are applied it should be fixed. http://www.winehq.org/pipermail/wine-patches/2007-May/039073.html http://www.winehq.org/pipermail/wine-patches/2007-May/039074.html http://www.winehq.org/pipermail/wine-patches/2007-May/039075.html
Re: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)
Dmitry Timoshkov wrote: "Vitaly Budovski" <[EMAIL PROTECTED]> wrote: Please show me how an unsigned int can represent values greater than 2^32. This is why a float is used. Of course int can't, but neither float can. Perhaps you confuse it with double? I'm pretty sure I'm not confusing it with double. http://steve.hollasch.net/cgindex/coding/ieeefloat.html http://en.wikipedia.org/wiki/IEEE_754#Single-precision_32_bit
Re: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)
Dmitry Timoshkov wrote:
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
+struct tinn
+{
+/* Pointer to an element in the list. */
+const RGBQUAD *data;
+/* Distance from the reference element. */
+float distance;
+};
Vitaly, why do you keep resending the same patch which uses float
values internally? Again, float neither doesn't allow you to process
larger values, nor is acceptable for speed or adds more flexibility.
I actually discussed this with Alexandre on irc and he said that it was
okay to leave it like that. Please show me how an unsigned int can
represent values greater than 2^32. This is why a float is used.
Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)
Dmitry Timoshkov wrote: "Vitaly Budovski" <[EMAIL PROTECTED]> wrote: Both floats and integers have their share of problems. Since the square root operation has been removed, we are dealing with much larger numbers, potentially larger than can fit into unsigned int without looping back around. This is why I think keeping distances as floats is a good idea, since they can represent a much larger range of values. Not really. sizeof(float) == 4, i.e. same as sizeof(int), but a float type carries much more information, therefore can't "deal with much larger numbers". Yes, but you agree that a float can represent much larger values than 4294967295? This is the point I'm trying to make. As I mentioned earlier, there is no noticeable performance difference between using floats and integers (cheap operations +-*) for the distances so I really don't see the reason for all the resistance. Even if it looks like a "cheap" operation, floating point operations are much slower than an integer ones. Really, the performance difference is not noticeable in this instance. But I'm open to any ideas you may have as to how we could avoid using floats, yet not run into the overflow situations so easily. We could probably use division somewhere but I don't think that's actually any better performance-wise.
Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)
Jesse Allen wrote: On 5/7/07, Duane Clark <[EMAIL PROTECTED]> wrote: Dmitry Timoshkov wrote: > "Vitaly Budovski" <[EMAIL PROTECTED]> wrote: > >>> Now that you got rid of sqrt calls usage of float numbers internally >>> doesn't look justified (to me) anymore. >>> >> Only because in this instance it is used with integer data. It doesn't >> need to be limited to just integer values. Besides, what would be gained >> by changing it to integers as you suggest? > > What would be gained is an additional speed. Since this code is supposed > to be used to handle palette/color data there is no need to use floats at > all. While I cannot vouch for the accuracy, this might be of interest: http://lua-users.org/wiki/FloatingPoint Vitaly, I think I recommend using just integers, and make this private for DIBs. Speed is nice for what we can use it for. If someone later needs the float use, then we can create a separate float version and included where-ever it's used. There is nothing wrong with having two versions when each is justified. If you can get your code accepted I'll probably move it over to the DIB engine eventually. If the wined3d people want to use it, I could make it available somehow? Jesse Both floats and integers have their share of problems. Since the square root operation has been removed, we are dealing with much larger numbers, potentially larger than can fit into unsigned int without looping back around. This is why I think keeping distances as floats is a good idea, since they can represent a much larger range of values. As I mentioned earlier, there is no noticeable performance difference between using floats and integers (cheap operations +-*) for the distances so I really don't see the reason for all the resistance. As for making this private for dibs, are you suggesting that I move the algorithm into the winex11 directory? I'm certain it could be useful in other areas too. There is a nearest colour function in gdi32 also, so once this patch gets accepted I will probably make use of it there too. Stefan also mentioned a possible use for the algorithm in wined3d.
Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)
Dmitry Timoshkov wrote: "Vitaly Budovski" <[EMAIL PROTECTED]> wrote: Now that you got rid of sqrt calls usage of float numbers internally doesn't look justified (to me) anymore. Only because in this instance it is used with integer data. It doesn't need to be limited to just integer values. Besides, what would be gained by changing it to integers as you suggest? What would be gained is an additional speed. Since this code is supposed to be used to handle palette/color data there is no need to use floats at all. As I explained previously, this algorithm makes no assumptions about the data that is being queried. Just because in this case (patch 3) we are working with RGB colour data doesn't mean it is limited to only that. It will work with *any* values, as long as you can provide an appropriate distance function. For this reason, I do not think that limiting the distances to integer values makes much sense. Getting rid of the square root has some benefit because it is generally an expensive operation. I do not think that getting rid of floats would give any noticeable performance improvements.
Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups.
Vitaliy Margolen wrote: Vitaly Budovski wrote: Vitaliy Margolen wrote: Thanks for the tip. Unfortunately in this instance it will not work as I do in fact query more than a < b. See the nearest function in patch 2. And what is so special about subtracting one from the other? A lot actually. As an example with squared distances: a^2 - b^2 <= c^2. If a^2 = 27, b^2 = 16, c^2 = 9, then 27 - 16 <= 9 is false. However, if we use the square root in distance calculations, sqrt(27) - 4 <= 3 is true. As you can see, we get entirely different results. The qsort function I use internally takes that particular function pointer. And the problem is what? Any pointer is compatible with void* (not other way around). Vitaliy Margolen. I get a warning from gcc: passing argument 4 of ‘qsort’ from incompatible pointer type.
Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups.
Vitaliy Margolen wrote:
Vitaly Budovski wrote:
Make use of the Triangle Inequality Nearest Neighbour algorithm to find the
nearest colour more efficiently than a simple linear search. The improvements
are most noticeable with a palette of 256 colours. Testing shows approximately
3-4x performance increase for 256 colours.
---
Overall idea looks good, however the big problem with it is use of float
point numbers. Fortunately you can get rid of them and use integers
instead. Because you never use the distance in the calculations, but
only to compare against other distances, you can skip "sqrt" and just
compare squares, as the original code does. That will give you even more
speed improvements.
Thanks for the tip. Unfortunately in this instance it will not work as I
do in fact query more than a < b. See the nearest function in patch 2.
Few more nitpicks about this and other patches in the series:
+static int compare_distance(const void *left, const void *right)
+{
+const struct tinn *l = left;
+const struct tinn *r = right;
Please don't use void pointers. Use typed pointers, especially that you
cast them to a hard-coded type.
The qsort function I use internally takes that particular function pointer.
+const void *init_tinn(struct tinn *dest, const void *buf, size_t num,
+size_t size, float (*distance)(const void *, const void *))
+{
+size_t i;
+size_t ref = rand() % num;
I'm not so sure using random reference point really necessary.
This is actually very important. By randomly selecting a reference
point, the chance that we get worst-case linear performance out of the
algorithm becomes extremely small.
+static struct tinn tinnPalette[256];
+
This won't work well with multi-threaded apps. You probably should make
it on the stack for each X11DRV_DIB_SetImageBits_* function. Especially
that some need only 2 elements. Btw, how big of the gain/loss whill
there be for 1-bit and 4-bit DIBs?
I'm sure you are right. I'll change the array allocation as you suggest.
I'm sure you mean the X11DRV_DIB_GetImageBits_* though. As a percentage
probably quite significant, linear would be reasonably fast for small
sized palettes though. Although this algorithm will never really be any
slower.
+q.rgbRed = srcval.peRed;
+q.rgbGreen = srcval.peGreen;
+q.rgbBlue = srcval.peBlue;
Looks much better, if written as:
q = srcval;
I guess it does. I had to do a lot of copy+paste though so I kept the
format the same throughout, since colors are not always retrieved in
that way.
- ((srcval >> 7) & 0xf8) | /* r */
- ((srcval >> 12) & 0x07),
- ((srcval >> 2) & 0xf8) | /* g */
- ((srcval >> 7) & 0x07),
- ((srcval << 3) & 0xf8) | /* b */
- ((srcval >> 2) & 0x07) ) << (7-(x&7)) );
+
+q.rgbRed = ((srcval >> 7) & 0xf8) |
+((srcval >> 12) & 0x07);
+q.rgbGreen = ((srcval >> 2) & 0xf8) |
+((srcval >> 7) & 0x07);
+q.rgbBlue = ((srcval << 3) & 0xf8) |
+((srcval >> 2) & 0x07);
What happened to the comments and alignment?
Vitaliy Margolen.
The comments are not really needed now. First of all they weren't very
descriptive, and also I'm now assigning the colors to individual bytes
which are named appropriately so it is easy to see what they refer to.
The code looks to be aligned I think.
Re: [PATCH 2/3] Implement TINN algorithm.
Michael Stefaniuc wrote: Vitaly Budovski wrote: Implement the Triangle Inequality Nearest Neighbour algorithm as described in http://post.queensu.ca/~greensm/papers/tinn.pdf --- include/wine/tinn.h | 154 Do you need that somewhere else then in the X driver? If not putting that directly into dlls/winex11.drv/ makes more sense. +++ 1 files changed, 154 insertions(+), 0 deletions(-) bye michael The algorithm is quite generic really. It basically exists to solve the nearest neighbour problem, so anywhere that such a solution is needed this algorithm could be used. I had a bit of a look and I think there are another few sections that this could be used.
Re: D3D9: Rework the converted vertex declaration management (try 3)
Stefan � wrote: Another patch which grows by 0.5 * existing size You could as well just grow it to twice the existing size. It would be easier.
Re: D3D: Enumerate Palettized formats for ddraw
Stefan � wrote: apps. D3D8 is unaffected because it passes WINED3DFMT_UNKNOWN to wined3d. Wouldn't it be better to not pass WINED3DFMT_UNKNOWN and then treat it in a special way? I think it would make more sense to just check for the supported formats in D3D8 much like you do for DDRAW now.
Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes
Chris Robinson wrote: On Saturday 31 March 2007 02:25:52 am you wrote: You can change WineD3D to allow WINED3DFMT_P8, but you have to modify d3d8 and d3d9 to filter it out. This is the correct approach then. Injecting P8 in ddraw will work too, but it is not correct from the design point of view(since then wined3d says "I can't do that", and ddraw says "But I insist you can do it" How about the attached patch? If not given an explicit mode, DDraw will loop over known good formats and not pass WINED3DFMT_UNKNOWN to WineD3D at all. Someone can then fix D3D8 to not pass it either, then fix WineD3D to not have special handling for enumerating WINED3DFMT_UNKNOWN. That should fix the current DDraw problem fine, and not immediately risk breaking D3D8 in the process. Vitaly Budovski, does this fix the problem as well? I think that's probably a good idea. Handling everything in WINED3DFMT_UNKNOWN causes far too many problems. This does fix the regression in AOE (as long as you add the WINED3DFMT_P8 format to the switch statements). Thanks Chris!
Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes
Chris Robinson wrote: On Friday 30 March 2007 08:11:54 pm Vitaly Budovski wrote: Make 8bpp a valid depth in EnumAdapterModes. This allows Age of Empires to start. --- dlls/wined3d/directx.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) This causes the d3d8 device test to fail for me: device.c:755: Test failed: Unexpected display mode returned for mode 42: 0x29 ...all the way through to... device.c:755: Test failed: Unexpected display mode returned for mode 83: 0x29 D3D8 only supports 32-bit X8R8G8B8 and 16-bit R5G6B5 modes as far as Windows testing has shown, and passing WINED3DFMT_UNKNOWN to WineD3D for mode enumeration makes it work on D3D8 modes only. You'll probably need to wait for Stefan or Henri to respond to figure out what to do. Though, it appears DDraw can be patched to do a second enumeration loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but it's an idea I just had. I haven't really tested this patch much and I don't expect it to be applied. There was just a regression that prevented AOE from starting due to it not finding an 8bpp mode. The regression was caused by this patch: http://www.winehq.com/pipermail/wine-cvs/2007-February/030394.html BTW.
Re: wined3d: declaration/FVF conversion test
Ivan Gyurdiev wrote:
Hi, I'm attaching test, which demonstrates incorrect behavior of
SetFVF and SetVertexDeclaration.
Windows converts one to the other and backwards (at least partially),
and we do not such thing - this breaks at least 2 demos (dx9_hlsl_*)
I'm posting it here, because:
- I don't have Windows, and I need someone to try it on machine with
pixel shader support (preferably 3.0, will need to enable pshaders and
GLSL registry key). The whole first part of the test checks decl to
fvf conversions, and they're almost all set to 0 in order to pass on
H. Verbeet and V. Margolen's setups [ which have no pshaders ]. MSDN
has a whole page on how to convert to an fvf, and the values there are
definitely *not* 0, so that's why I'm suspicious.
- Secondly, I am leaving for NYC in 2 days to look for a place to
live, so I have limited time to clean up the test (ok/trace usage and
the like), and I have no time to implement the fix. I am hoping
someone else can finish it, because afterwards I go to Denver for a
month, where I will have limited computing capabilities. Then I start
a full time job back at NYC, so I'll be pretty busy. Anyway, I'm sure
Jave has shaders under control and will be done with sm 2, 3, 4, 5..
10 by the end of the summer whether I help or not :)
Hi,
I've attached a patch which seems to fix the first set of failures. This
sets FVF values(from converted declarations) which were not set before.
I'm still getting a lot of 0 results myself. Pretty sure I have
everything enabled.
Comments?
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index e635352..7116d2f 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -4480,6 +4480,66 @@ static HRESULT WINAPI IWineD3DDeviceImpl
}
if (NULL != pDecl) {
+DWORD fvf = 0;
+D3DVERTEXELEMENT9 * declaration = ((IWineD3DVertexDeclarationImpl
*)pDecl)->pDeclaration9;
+if(D3DDECLTYPE_FLOAT3 == declaration->Type &&
+D3DDECLUSAGE_POSITION == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = D3DFVF_XYZ;
+} else if(D3DDECLTYPE_FLOAT4 == declaration->Type &&
+D3DDECLUSAGE_POSITIONT == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = D3DFVF_XYZRHW;
+} else if(D3DDECLTYPE_FLOAT1 == declaration->Type &&
+D3DDECLUSAGE_BLENDWEIGHT == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_XYZB1*/;
+} else if(D3DDECLTYPE_FLOAT2 == declaration->Type &&
+D3DDECLUSAGE_BLENDWEIGHT == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_XYZB2*/;
+} else if(D3DDECLTYPE_FLOAT3 == declaration->Type &&
+D3DDECLUSAGE_BLENDWEIGHT == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_XYZB3*/;
+} else if(D3DDECLTYPE_FLOAT4 == declaration->Type &&
+D3DDECLUSAGE_BLENDWEIGHT == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_XYZB4*/;
+} else if(D3DDECLTYPE_UBYTE4 == declaration->Type &&
+D3DDECLUSAGE_BLENDINDICES == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_XYZB5*/;
+} else if(D3DDECLTYPE_FLOAT3 == declaration->Type &&
+D3DDECLUSAGE_NORMAL == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_NORMAL*/;
+} else if(D3DDECLTYPE_FLOAT1 == declaration->Type &&
+D3DDECLUSAGE_PSIZE == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_PSIZE*/;
+} else if(D3DDECLTYPE_D3DCOLOR == declaration->Type &&
+D3DDECLUSAGE_COLOR == declaration->Usage &&
+0 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_DIFFUSE*/;
+} else if(D3DDECLTYPE_D3DCOLOR == declaration->Type &&
+D3DDECLUSAGE_COLOR == declaration->Usage &&
+1 == declaration->UsageIndex) {
+fvf = 0/*D3DFVF_SPECULAR*/;
+} else if(D3DDECLTYPE_FLOAT1 == declaration->Type &&
+D3DDECLUSAGE_TEXCOORD == declaration->Usage) {
+fvf = 0/*D3DFVF_TEXCOORDSIZE1(declaration->UsageIndex)*/;
+} else if(D3DDECLTYPE_FLOAT2 == declaration->Type &&
+D3DDECLUSAGE_TEXCOORD == declaration->Usage) {
+fvf = 0/*D3DFVF_TEXCOORDSIZE2(declaration->UsageIndex)*/;
+} else if(D3DDECLTYPE_FLOAT3 == declaration->Type &&
+D3DDECLUSAGE_TEXCOORD == declaration->Usage) {
+fvf = 0/*D3DFVF_TEXCOORDSIZE3(declaration->UsageIndex)*/;
+} else if(D3DDECLTYPE_FLOAT4 == declaration->Type &&
+D3DDECLUSAGE_TEXCOORD == declaration->Usage) {
+fvf = 0/*D3DFVF_TEXCOORDSIZE4(declaration->UsageIndex)*/;
+}
+IWineD3DDeviceImpl_SetFVF(if
Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()
Tomas Carnecky wrote: Huw D M Davies wrote: On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote: Ah right, glDrawBuffer alters the rendering state, that's bad. We should presumably be calling glXSwapBuffers here (but only in the GLXPixmap case). Which of course won't work either. We need to find out what happens to the render state under Windows when we make call wglMakeCurrent on a bitmap (I know that even with the rendering state set for GL_BACK then the bitmap gets drawn on) and whether we restore the rendering context when we switch back to using some other dc afterwards. We probably shouldn't do anything in the pbuffer case (which is what's causing your problem I guess). The big issue is that pbuffers and bitmap rendering are getting confused all over the place. Feel free to take http://dbservice.com/tom/LinuxTest.cpp, change it and test it.. it's a win32 application, despite its name :) tom You need to call wglMakeCurrent right before you test for the presence of ARB/EXT wgl functions. On windows I get the following result: initial drawBuffer: 0x405 after setting back buffer: 0x405 after activating pbuffer: 0x405 On wine I get (NVidia Geforce 6800): X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 13 (X_GLXCreateGLXPixmap) Serial number of failed request: 135 Current serial number in output stream: 136 and the log is partially filled to: initial drawBuffer: 0x405 after setting back buffer: 0x405
Re: [Compile problem] GL_STENCIL_BACK_FAIL vs. GL_STENCIL_BACK_FAIL_ATI
Uwe Bonnes wrote: "H" == H Verbeet <[EMAIL PROTECTED]> writes: ... >> Appended patch lets me circumvent that problem. H> I'm not sure if GL_STENCIL_BACK_FAIL and GL_STENCIL_BACK_FAIL_ATI are H> interchangeable, but more importantly it makes the same kind of H> assumptions about what's going to be defined. I said "circumvent" not "solve"... This patch http://www.winehq.org/pipermail/wine-patches/2006-March/024775.html should solve the problem with missing defines.
Re: wined3d: Fix compile for older OpenGL headers.
H. Verbeet wrote: Although #ifdef GL_VERSION_2_0 will make compilation work with older OpenGl headers, it's not the way to fix this. Basically, wined3d should check for functionallity during runtime with GL_SUPPORT and call extensions with GL_EXTCALL. The issue has come up a few times before with patches from the same author, and I think he should be aware of the issue by now. That takes care of functions as part of an OpenGL extension. What about core functions of a newer GL version? Would all of those need to be defined in the wined3d_gl.h file?
wined3d: CheckDeviceMultiSampleType
Can I have some feedback on the attached patch? I'm not entirely sure
it's correct.
Thanks,
Vitaly
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 7aa8d5d..8394362 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -1245,6 +1245,13 @@ HRESULT WINAPI IWineD3DImpl_CheckDeviceM
BOOL Windowed,
D3DMULTISAMPLE_TYPE MultiSampleType, DWORD* pQualityLevels) {
IWineD3DImpl *This = (IWineD3DImpl *)iface;
+HDC deviceContext;
+Display * pDisplay;
+GLXFBConfig * pConfig;
+int attributeList[5] = {GLX_SAMPLE_BUFFERS_ARB, 1, GLX_SAMPLES_ARB,
MultiSampleType, 0};
+int configCount;
+int attributeValue;
+
TRACE_(d3d_caps)("(%p)-> (STUB) (Adptr:%d, DevType:(%x,%s),
SurfFmt:(%x,%s), Win?%d, MultiSamp:%x, pQual:%p)\n",
This,
Adapter,
@@ -1267,7 +1274,32 @@ HRESULT WINAPI IWineD3DImpl_CheckDeviceM
*pQualityLevels = 1; /* Guess at a value! */
}
-if (D3DMULTISAMPLE_NONE == MultiSampleType) return D3D_OK;
+if(D3DMULTISAMPLE_NONE == MultiSampleType) return D3D_OK;
+
+/* Get the display */
+deviceContext = GetDC(0);
+pDisplay = get_display(deviceContext);
+
+ENTER_GL();
+
+pConfig = glXChooseFBConfig(pDisplay, 0, attributeList, &configCount);
+if(pConfig) {
+if(!glXGetFBConfigAttrib(pDisplay, *pConfig, GLX_SAMPLES,
&attributeValue)) {
+XFree(pConfig);
+
+LEAVE_GL();
+ReleaseDC(0, deviceContext);
+
+return D3D_OK;
+}
+} else {
+FIXME("Error retrieving FBConfig\n");
+}
+XFree(pConfig);
+
+LEAVE_GL();
+ReleaseDC(0, deviceContext);
+
return D3DERR_NOTAVAILABLE;
}
Is there something wrong with the wined3d patches?
Is there something wrong with the patches dated 20060201? Could someone please point it out? Thanks.
Re: wined3d: Fixed render states
H. Verbeet wrote: On 31/01/06, Vitaly Budovski <[EMAIL PROTECTED]> wrote: H. Verbeet wrote: On 31/01/06, Vitaly Budovski <[EMAIL PROTECTED]> wrote: wined3d: Fixed up render states You probably want to split the patch up in smaller pieces. How would I do this? The changes to eg. EDGEANTIALIAS and POINTSPRITENABLE don't depend on eachother, and aren't really related, except for both of them being renderstates, so you could probably split those changes up into separate patches. Same problem as with your patch for d3d8, wined3d doesn't currently check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps). Will be submitted as a separate patch. Falls back to the EXT version for now. I think it is preferrable to check in working code as much as possible. Although it doesn't directly break stuff, it would probably be best to submit the checks for ARB_POINT_PARAMETERS support before trying to use it. -/* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but then ATI drivers are buggered! */ -glDisable(GL_POINT_SMOOTH); Did you verify that this isn't required anymore? Otherwise that's a potential regression. This seems to be a bug with (some?) ATI hardware/drivers. Point smoothing should normally be supported I believe. Well yes, but I doubt we want to break stuff that was previously working. Some more information confirming that it is indeed a problem with some ATI cards/drivers: http://www.openscenegraph.org/index.php?page=Tasks.OpenGLConformance It would be good if someone with an ATI card could download the point_sprite_bug sample mentioned on that page and test it out to see if it is still an issue.
Re: wined3d: Fixed render states
H. Verbeet wrote:
On 31/01/06, Vitaly Budovski <[EMAIL PROTECTED]> wrote:
wined3d: Fixed up render states POINTSCALEENABLE, POINTSPRITENABLE,
EDGEANTIALIAS, MULTISAMPLEANTIALIAS
You probably want to split the patch up in smaller pieces.
How would I do this?
+if(This->stateBlock->renderState[D3DRS_POINTSCALEENABLE]) {
+att[0] =
*((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_A]) /
+(This->stateBlock->viewport.Height *
This->stateBlock->viewport.Height);
+att[1] =
*((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_B]) /
+(This->stateBlock->viewport.Height *
This->stateBlock->viewport.Height);
+att[2] =
*((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_C]) /
+(This->stateBlock->viewport.Height *
This->stateBlock->viewport.Height);
+}
You're not supposed to use D3DRS_ stuff in wined3d, rather use the
respective WINED3DRS_ defines, as the original code did.
Typo, I'll fix that.
+if(GL_SUPPORT(ARB_POINT_PARAMETERS)) {
Same problem as with your patch for d3d8, wined3d doesn't currently
check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps).
Will be submitted as a separate patch. Falls back to the EXT version for
now.
-/* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but
then ATI drivers are buggered! */
-glDisable(GL_POINT_SMOOTH);
Did you verify that this isn't required anymore? Otherwise that's a
potential regression.
This seems to be a bug with (some?) ATI hardware/drivers.
Point smoothing should normally be supported I believe.
+checkGLcall("glEnable(Gl_LINE_SMOOTH)");
+checkGLcall("glDisable(Gl_LINE_SMOOTH)");
That should probably say Gl_LINE_SMOOTH, but it's not really critical
Non-critical typo, but will be fixed when I resend the patch.
Re: Wine 0.9.6 glext.h / DirectX Compiler Error
Hi, Could you try applying this patch. This may fix it. Also, would you let me know what the value of GL_GLEXT_VERSION is as defined in your glext.h header? Vitaly Roland Kaser wrote: Hello all I just tried to compile 0.9.6 on a SuSE 10 system and got the following compiler error: /usr/X11R6/include/GL/glext.h:1167:1: warning: this is the location of the previous definition device.c: In function ‘IDirect3DDevice8Impl_SetRenderState’: device.c:3106: error: ‘GL_ARB_multisample’ undeclared (first use in this function) device.c:3106: error: (Each undeclared identifier is reported only once device.c:3106: error: for each function it appears in.) make[2]: *** [device.o] Fehler 1 make[2]: Leaving directory `/install/wine-0.9.6/dlls/d3d8' make[1]: *** [d3d8] Fehler 2 make[1]: Leaving directory `/install/wine-0.9.6/dlls' make: *** [dlls] Fehler 2 This is the first time i got such an error. 0.9,3, 0.9.4 and 0.9.5 compile clean on that system. Roland Kaeser Index: d3dcore_gl.h === RCS file: /home/wine/wine/dlls/d3d8/d3dcore_gl.h,v retrieving revision 1.20 diff -u -r1.20 d3dcore_gl.h --- d3dcore_gl.h19 Jan 2006 11:49:39 - 1.20 +++ d3dcore_gl.h20 Jan 2006 09:15:16 - @@ -599,6 +599,19 @@ #define GL_COORD_REPLACE_ARB 0x8862 #endif +/* GL_ARB_multisample */ +#ifndef GL_ARB_multisample +#define GL_MULTISAMPLE_ARB0x809D +#define GL_SAMPLE_ALPHA_TO_COVERAGE_ARB 0x809E +#define GL_SAMPLE_ALPHA_TO_ONE_ARB0x809F +#define GL_SAMPLE_COVERAGE_ARB0x80A0 +#define GL_SAMPLE_BUFFERS_ARB 0x80A8 +#define GL_SAMPLES_ARB0x80A9 +#define GL_SAMPLE_COVERAGE_VALUE_ARB 0x80AA +#define GL_SAMPLE_COVERAGE_INVERT_ARB 0x80AB +#define GL_MULTISAMPLE_BIT_ARB0x2000 +#endif + /*** * OpenGL Official Version * defines
