On Tue, Mar 23, 2010 at 11:05 PM, Henri Verbeet hverbeet@gmail.com wrote:
On 23 March 2010 18:41, Roderick Colenbrander thunderbird2k@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; } .. .. surface_color_fill(gl_info, dst, color, rop, ...) { blitter = select_blitter(...); blitter->color_fill(...); }
This is indeed more drastic than I thought about but it seems a nicer approach. I was already thinking about how to handle different 'fallbacks' since the current blitter isn't switchable and this approach looks like a good idea. I'll try to work it out a bit and experiment with it. When it starts working a bit, I will send some patches to this thread (unpolished ones likely though).
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.
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.
Roderick