WineD3D: glBlend* fixes

[Roderick Colenbrander]

Hi,

>  > Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does
>  > the spec. I don't know what exactly uses the min_max form. Is this a
>  > typo?
> Apart from the blend_minmax typo, it appears to be me this patch has 
> some other problems.
> 
>  >> This patch changes the detection extension detection for
>  >> glBlendColor/glBlendEquation. The function glBlendColor is part of
>  >> OpenGL 1.1 and is supported on all OpenGL implementations.
> No, it's not. Calls to it are ONLY legal on opengl up to 1.3 if either 
> ARB_imaging or EXT_blend_color are supported (the spec says "Blend Color 
> is an imaging subset feature, and is only allowed when the imaging 
> subset is supported"). It is however part of OpenGL 1.4.
> So, a really correct detection would be to check for ogl version 1.4, 
> EXT_blend_color, ARB_imaging. Maybe the check for ARB_imaging could be 
> omitted, but it is possible there are drivers out there which only 
> announce support for ARB_imaging but not EXT_blend_color, according to 
> www.delphi3d.net there are indeed some tnt2's out there which claim 
> support for ARB_imaging but not EXT_blend_color - if I'd have to guess 
> I'd suspect the call to glBlendColor results in a sw fallback.
> 

On windows the opengl32.dll exports glBlendColor by default and as opengl32.dll is opengl 1.1 I thought that it was a core function. So you say that it is backed by GL_ARB_imaging. The problem is that basicly only Nvidia advertises it and the other drivers don't. The GL version could be detected but we don't like GL version checks. Vendors should still advertise GL_ARB_imaging for backwards compatibility if they do support 1.4 or higher but ATI and friends don't :(

>  >> Further glBlendEquation is part of GL_ARB_imaging aswell. For the
>  >> same reason GL_ARB_imaging can't be used to detect glBlendEquation.
>  >> This call isn't supported on all OpenGL implementations. Luckily it
>  >> is part of 'GL_EXT_blend_min_max' so that is used now.

> This is not quite so simple. If OGL 1.4 is supported, or the version is 
> lower but ARB_imaging itself is supported, all the blend function stuff 
> >from ARB_imaging is ok. If only either EXT_blend_minmax or 
> EXT_blend_subtract is supported, then glBlendEquation is supported, but 
> only different modes are valid (FUNC_ADD, MIN, MAX for EXT_blend_minmax, 
> FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT for EXT_blend_subtract). 
> But if all you care is that glBlendEquation is available, you should 
> probably detect ogl 1.4, and EXT_blend_subtract (some cards only support 
> EXT_blend_subtract but not EXT_blend_minmax), but really for correctness 
> EXT_blend_minmax and ARB_imaging should be checked too.
> 

Right now we only use ADD/MIN/MAX/SUBTRACT/REVSUBTRACT. For correctness we would need to check for EXT_blend_subtract aswell. Right now only EXT_blend_minmax is checked. A version check is more or less out of the question (Alexandre only accepts such things when it is really needed). We could wait till problems arise as wined3d will give some GL warnings then.

Roderick



-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer