On Wed, Mar 24, 2010 at 12:35 PM, Stefan Dösinger stefan@codeweavers.com wrote:
Am Mittwoch 24 März 2010 12:00:48 schrieb Henri Verbeet:
On 24 March 2010 11:55, Roderick Colenbrander thunderbird2k@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