Re: WineD3D BltOverride overhaul

[Henri Verbeet]

On 23 March 2010 18:41, Roderick Colenbrander  wrote:
> Hi,

...
>

How about something along these general lines:

blitter_setup_context(src, dst, rop, ...)
{
    context = context_acquire(src/dst/NULL);
    select shader / setup ffp state / etc.
    return context;
}

blitter_release_context(context);
{
    /* add some cleanup here */
    context_release(context);
}

blitter->blit(...)
{
    context = blitter_setup_context();
    /* potential color key conversions go somewhere around here. */
    LoadLocation();
    draw rect / fbo blit / etc.
    ModifyLocation();
    blitter_release_context(context);
}

blitter->color_fill()
{
    ...
}

blitter->can_blit()
{
    /* check e.g. surface pool (CPU/GPU/both), color fixups, rop support. */
}

device->blitters[] =
{
    fbo_blit,
    shader_blit,
    ffp_blit,
    cpu_blit,
};

surface_select_blitter(gl_info, op, src, dst, rop, ...)
{
    foreach (device->blitters)
    {
        if (blitter->can_blit(...)) return blitter;
    }
}

surface_blit(gl_info, src, dst, rop, ...)
{
    blitter = select_blitter(...);
    blitter->blit(...);
}

surface_color_fill(gl_info, dst, color, rop, ...)
{
    blitter = select_blitter(...);
    blitter->color_fill(...);
}
> I think the design described above could work (perhaps I missed
> something, please correct me then). One of the issues is color keying.
> Right now color key conversion is performed in LoadLocation based on
> some flag magic. In case of a 2d blit using shaders this is not needed
> but for Direct3D purposes it is needed. I'm not sure how to handle
> this in a clear way. (I fear that we also get some new issues when a
> game alternates between 2d and 3d color keying).

D3D color keying is something that should be handled by the fragment pipe.