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.