WineD3D BltOverride overhaul

[Roderick Colenbrander]

On Wed, Mar 24, 2010 at 12:35 PM, Stefan Dösinger
<stefan at codeweavers.com> wrote:
> Am Mittwoch 24 März 2010 12:00:48 schrieb Henri Verbeet:
>> On 24 March 2010 11:55, Roderick Colenbrander <thunderbird2k at gmail.com>
> wrote:
>> > Sure color keying needs to be handled by the fragment pipe. Though I
>> > would like to avoid touching that area right now since I don't know
>> > anything about it and I had a feeling when I talked about it with
>> > Stefan that this code is a bit fragile. So in the meantime I would
>> > like to have a way to disable color key fixups in LoadLocation when we
>> > perform a 2d blit.
>> Perhaps it's possible to implement as a different surface location.
> I'd leave color keying out of the blitter redesign and stick to the current
> alpha based color keying emulation. Fixing the blitter is complicated enough
> as it is.
>
> Implementing it in the fragment pipeline is certainly possible, if we are
> prepared to drop support for d3d color keying on cards that don't at least
> support NV register combiners(texture shader is not needed), ati fragment
> shader or ARBfp. Requiring either of those is not unreasonable, support for
> that goes back to TNT2 cards, ATI radeon 8500 and I think all Intel GPUs.
>
> However, implementing it in the fragment pipeline when possible and having a
> texture loading fallback like we currently have won't help a lot. All issues
> with the current setup know affect the code design. If we keep the fallback, we
> have to deal with the load time alpha replacement in some way anyway, and we
> don't gain anything substantial from the alternative nicer fragment pipeline
> based codepaths.
>

If you are okay in keeping the current code, As a slight improvement
the shader could do the 'alpha testing' which is nicer design wise.

Now back to the blitter design. Henri's proposal is to have several
blitters for this discussion reduce it to shader_blit and cpu_blit.
The cpu_blit would be the software fall back for a blit, colorfill or
whatever operation. A potential (but perhaps ugly) design of a cpu
fallback, could be to just call IWineD3DBaseSurface. A more drastic
approach would basically be to kill the IWineD3DBaseSurface fallbacks
and have ONE Blt and BltFast in surface.c which would just fall back
to software when OpenGL isn't around. What do you think?

Roderick