On Thursday 15 September 2011 20:01:50 Henri Verbeet wrote:
In principle this allows us to use more than one backbuffer in ddraw. It's also a requirement for the next patch.
I think this, and the next patch should be implemented in wined3d by handling D3DSWAPEFFECT_FLIP in essentially the same way you're handling them in ddraw in your patches.
d3d8 and d3d9 apps can request multiple backbuffers and access them explicitly just like ddraw apps can.
In patch 3 I'm not sure what happens when the app draws to the frontbuffer directly. Maybe I'm a bit too tired to see it, but doesn't that result in a blit of the surface onto itself?
On 16 September 2011 01:03, Stefan Dösinger stefandoesinger@gmx.at wrote:
On Thursday 15 September 2011 20:01:50 Henri Verbeet wrote:
In principle this allows us to use more than one backbuffer in ddraw. It's also a requirement for the next patch.
I think this, and the next patch should be implemented in wined3d by handling D3DSWAPEFFECT_FLIP in essentially the same way you're handling them in ddraw in your patches.
Maybe after 1.4, it's a bit more invasive to do it in wined3d. We don't want render the frontbuffer offscreen unless the swap effect is actually flip for performance reasons. However, the swap effect can potentially change when a reset happens. It's possible to make that all work, but I'd rather wait a bit to see how this works out for ddraw first.
In patch 3 I'm not sure what happens when the app draws to the frontbuffer directly. Maybe I'm a bit too tired to see it, but doesn't that result in a blit of the surface onto itself?
No, the wined3d frontbuffer and ddraw frontbuffer are different surfaces.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 16.09.2011 um 01:29 schrieb Henri Verbeet:
On 16 September 2011 01:03, Stefan Dösinger stefandoesinger@gmx.at wrote:
On Thursday 15 September 2011 20:01:50 Henri Verbeet wrote:
In principle this allows us to use more than one backbuffer in ddraw. It's also a requirement for the next patch.
I think this, and the next patch should be implemented in wined3d by handling D3DSWAPEFFECT_FLIP in essentially the same way you're handling them in ddraw in your patches.
Maybe after 1.4, it's a bit more invasive to do it in wined3d.
Works for me.
In patch 3 I'm not sure what happens when the app draws to the frontbuffer directly. Maybe I'm a bit too tired to see it, but doesn't that result in a blit of the surface onto itself?
No, the wined3d frontbuffer and ddraw frontbuffer are different surfaces.
Ok
Another thing your second patch breaks is vsync because there won't be any swapbuffer calls. Although arguably that was kinda broken since we replaced flips with blits.
On 16 September 2011 11:17, Stefan Dösinger stefandoesinger@gmx.at wrote:
Another thing your second patch breaks is vsync because there won't be any swapbuffer calls. Although arguably that was kinda broken since we replaced flips with blits.
It was broken even before that, since it's set at context creation, while Flip tried to override it at the actual present call.
-
Henri Verbeet -
Stefan Dösinger