On 24 April 2014 12:10, Stefan Dösinger stefan@codeweavers.com wrote:
Since palettes only really matter on frontbuffers we could also consider removing them from wined3d entirely and performing the ddraw frontbuffer present with a d3d draw and d3d shaders. This would mean that the shadow frontbuffer remains in ddraw, and that Shader Model 2 cards are required for hardware P8 conversion. (Unless we implement full d3d shader support for older HW, which I consider unlikely.)
Or we could just attach them to the swapchain.
This might work. A possible problem is that our code uses palettes to set up the device context when getdc is called. This needs some more tests...
2014-04-24 12:46 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 24 April 2014 12:10, Stefan Dösinger stefan@codeweavers.com wrote:
Since palettes only really matter on frontbuffers we could also consider removing them from wined3d entirely and performing the ddraw frontbuffer present with a d3d draw and d3d shaders. This would mean that the shadow frontbuffer remains in ddraw, and that Shader Model 2 cards are required for hardware P8 conversion. (Unless we implement full d3d shader support for older HW, which I consider unlikely.)
Or we could just attach them to the swapchain.
On 24 April 2014 13:45, Stefan Dösinger stefandoesinger@gmail.com wrote:
This might work. A possible problem is that our code uses palettes to set up the device context when getdc is called. This needs some more tests...
Provided it's supposed to work at all, we could probably move most of that to ddraw.
Yes, it apparently works. GetDC also seems to honor individual palettes on sublevels, although I'm not fully done with tests there yet.
I think we can handle this in ddraw, but in that case ddraw will have to assume that SetDIBColorTable can be called on DCs returned by wined3d. The gdi backend in wined3d will partially duplicate this work for the frontbuffer.
2014-04-24 14:18 GMT+02:00 Henri Verbeet hverbeet@gmail.com:
On 24 April 2014 13:45, Stefan Dösinger stefandoesinger@gmail.com wrote:
This might work. A possible problem is that our code uses palettes to
set up
the device context when getdc is called. This needs some more tests...
Provided it's supposed to work at all, we could probably move most of that to ddraw.