[PATCH 1/5] wined3d: Don't apply fixups to converted surfaces.

[Henri Verbeet]

On 2011-11-27 21:28, Stefan Dösinger wrote:
> Am Sonntag, 27. November 2011, 17:02:01 schrieb Henri Verbeet:
>> I'm not entirely sure that we shouldn't just use either
>> EXT_texture_snorm or the NV_texture_shader formats and mark the
>> formats as unsupported otherwise though.
> That's not an option. My iMac doesn't support either extension(r500, up to 
I must say that as a Wine developer I care only marginally about running
on closed platforms. For CrossOver, OS X is more important of course,
but I'm sure we could add another hack there. I don't think OS X support
should be a deciding factor here.

> date Lion) and EXT_texture_snorm doesn't support 
> WINED3DFMT_R5G5_SNORM_L6_UNORM.
> 
You'd load it into RGB8_SNORM. That means you have to do load time
conversion, but we do that for DSDT8_MAG8_NV as well.

>> Not yet. I came across this while investigating how we should handle
>> P8 primary surfaces for ddraw. You'd have a RGBA8 frontbuffer in
>> wined3d and a P8 surface in ddraw.
> This would elimintate the need to have P8 surfaces that are ALPHA8 in the gl 
> texture and RGBA8 onscreen. However, which implications does that have for the 
> ddraw shadow frontbuffer in the long run?
> 
Not a whole lot. Note that I was only investigating this a bit, I don't
have any actual patches.

> I'm asking because of overlays and, to some extend, the software d3d8/d3d9 
> cursor. For those I need a shadow frontbuffer in wined3d. If ddraw keeps using 
> one as well we might end up with a pretty long blitting chain and redundant 
> code.
> 
> To fix some issues with overlays(tearing, moving the overlay) I have to 
> composit the primary and overlay in the wgl backbuffer and then call swapbuffers 
> to have a vsynced present. (This need some more tests, especially the vsync 
> timing).
That's a general issue with Flip() / Present(). The way it currently
works we render ddraw backbuffers offscreen and blit them directly to
the frontbuffer. However, this means we don't get vsync. To make that
work we'd probably need to blit to the backbuffer first and depend on
SwapBuffers() to sort out the vsync. It doesn't really matter if that
code lives in ddraw or wined3d, or what format the various surfaces have
in that regard.