On 9 December 2015 at 00:39, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 08.12.2015 um 10:42 schrieb Henri Verbeet hverbeet@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?