[PATCH] wined3d: Restore WINEDDBLT_ALPHATEST support.

[Henri Verbeet]

On 9 December 2015 at 00:39, Stefan Dösinger <stefandoesinger at gmail.com> wrote:
>> Am 08.12.2015 um 10:42 schrieb Henri Verbeet <hverbeet at gmail.com>:
>> You shouldn't need this. context_apply_blit_state() invalidates
>> WINED3D_RS_ALPHATESTENABLE, but even if it didn't, disabling the alpha
>> test isn't necessarily the right thing to do. Not that
>> arbfp_blit_surface() necessarily needs all the invalidation
>> context_apply_blit_state() does though.
> Notice the last_was_blit check. Future blits might break if we keep the alpha test on.
>
Right. Can't say I particularly like it, but that's how it works.

> We could discuss more fine-grained state tracking for blits, but I don't think 1.8 is the time for that, and even beyond that I don't think it's worth it. GLSL would just swap most of them by selecting its shader. I can do the same in ARB, but I don't think it matters either way.
>
Yeah. I think context_apply_blit_state() only makes sense for the
fixed function blitter, but it's not a big issue.

>> Some basic tests probably wouldn't hurt. If we had had any the
>> regression might not have happened in the first place.
> Agreed, but I probably won't get around to writing some before the weekend. The nature of the software cursor makes it a bit difficult. You can spot it via GetDC(NULL), but not through GetFrontBufferData on native. I'll see if I can find a way to write the test that doesn't fail on OSX by design. Also, Fullscreen only, windows doesn't do SW cursors in windowed mode. Alexandre will love another fullscreen test :-) .
>
Oh, I somehow thought DDBLT_ALPHATEST was a real thing, in which case
it would have been easy to write some basic ddraw tests. Since it
isn't though, I have to wonder if you wouldn't get pretty much the
same effect by just using a color keyed blit and setting the color key
values to 0x00000000 and 0x00ffffff?