On Tue, Mar 23, 2010 at 11:05 PM, Henri Verbeet <hverb...@gmail.com> wrote:
> On 23 March 2010 18:41, Roderick Colenbrander <thunderbir...@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
