WineD3D BltOverride overhaul
Henri Verbeet
hverbeet at gmail.com
Tue Mar 23 17:05:17 CDT 2010
On 23 March 2010 18:41, Roderick Colenbrander <thunderbird2k at gmail.com> 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.
More information about the wine-devel
mailing list