Re: 3/2 WineD3D: add D3DPRASTERCAPS_MULTISAMPLE_TOGGLE support

[Stefan Dösinger]

Am Montag, 28. April 2008 22:08:28 schrieb Roderick Colenbrander:
> Hi,
>
> Add a missing d3d9 capability. For now add it behind a dxVersion check. We
> should get rid of those after Wine 1.0 but right now there is no filtering
> code in d3d8, so don't risk any regressions now.
> IMHO adding a caps filter to dx8 is less risky than adding multisampling 
> support, so I don't see a reason not to do that and avoid the dxVersion check

3/2 WineD3D: add D3DPRASTERCAPS_MULTISAMPLE_TOGGLE support

[Roderick Colenbrander]

> > Hi,
> >
> > Add a missing d3d9 capability. For now add it behind a dxVersion check.
> > We
> > should get rid of those after Wine 1.0 but right now there is no
> > filtering
> > code in d3d8, so don't risk any regressions now.
> > IMHO adding a caps filter to dx8 is less risky than adding multisampling 
> > support, so I don't see a reason not to do that and avoid the dxVersion
> > check

Personally I would prefer to the filtering the proper way. With this I mean to do it for all d3d8 caps and not just for this one. I think it is bad to spread the 'filtering' over wined3d and d3d8, d3d9. It should either all be in wined3d (bad) or in d3d8 / d3d9.

Roderick
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

3/2 WineD3D: add D3DPRASTERCAPS_MULTISAMPLE_TOGGLE support

[Chris Robinson]

On Monday 28 April 2008 11:00:13 pm Roderick Colenbrander wrote:
> > IMHO adding a caps filter to dx8 is less risky than adding multisampling
> > support, so I don't see a reason not to do that and avoid the dxVersion
> > check
>
> Personally I would prefer to the filtering the proper way. With this I mean
> to do it for all d3d8 caps and not just for this one. I think it is bad to
> spread the 'filtering' over wined3d and d3d8, d3d9. It should either all be
> in wined3d (bad) or in d3d8 / d3d9.

Something that has me concerned with applying all applicable flags in wined3d 
and filtering them out in d3d8/9 is, what happens if a newer d3d version has 
a flag with the same value as a different flag in the old version?

For instance, if wined3d applies a flag for an older cap, but it's used for 
the new version (which assumes that particular cap) and incorrectly reports 
an unsupported cap, or always filters out the cap even if it could work. 
Like:

wined3d:
if(SomeReallyOldExtensionIsSupported || GauranteedByOpenGL)
   flags |= OLD_CAP;
if(SomeReallyNewExtensionIsSupported)
   flags |= NEW_CAP;

d3d:
flags &= NEW_CAP|...;
// or
flags &= ~(OLD_CAP|...);

...and Wine potentially reports bad caps.

3/2 WineD3D: add D3DPRASTERCAPS_MULTISAMPLE_TOGGLE support

[Stefan Dösinger]

Am Dienstag, 29. April 2008 08:21:46 schrieb Chris Robinson:
> Something that has me concerned with applying all applicable flags in
> wined3d and filtering them out in d3d8/9 is, what happens if a newer d3d
> version has a flag with the same value as a different flag in the old
> version?
> As far as I can see this is not the case. I checked the flags when I ported 
> ddraw to wined3d. I did not re-check the flags that Microsoft added to d3d10 
> since then.

Keep in mind that Microsoft would have the same problem we have if two caps 
had the same meaning. Another interesting thing is that DCT has explicit 
checks for those old caps and complains if the d3d9 implementation reports 
them.

Currently d3d9 does something like this:
caps.something &= (ALL | POSSIBLE | FLAG | VALUES | FROM  | D3D9.H);

ddraw does the same, but d3d8 doesn't do that yet.