On 6 July 2010 14:53, Stefan Dösinger stefan@codeweavers.com wrote:
* DirectX9 cards return 0.5, DirectX10 cards return 0.73. Some games(Half Life 2 based ones* specifically) need the DX9 behavior. DX10 Windows drivers apparently have a quirk for HL2. Wine* emulates the DX9 behavior, this tests accepts the DX10 behavior with broken().
It's really HL2 that's broken then, I don't think it would be unreasonable for wined3d to adapt the newer behaviour on appropriate cards in the future.
Am Dienstag 06 Juli 2010 16:23:51 schrieb Henri Verbeet:
It's really HL2 that's broken then, I don't think it would be unreasonable for wined3d to adapt the newer behaviour on appropriate cards in the future.
I haven't seen any game that depends on the new behavior. Since the Source 2003 engine is pretty popular it would be a lot of pain to try to adopt the dx10 fog-sRGB behavior with no gain.
It's not the only case where we declare "new" behavior as broken. E.g. the error returned due to bad buffer lock flags happens to break games, even though the new behavior is saner than the old one.
On 6 July 2010 16:50, Stefan Dösinger stefan@codeweavers.com wrote:
Am Dienstag 06 Juli 2010 16:23:51 schrieb Henri Verbeet:
It's really HL2 that's broken then, I don't think it would be unreasonable for wined3d to adapt the newer behaviour on appropriate cards in the future.
I haven't seen any game that depends on the new behavior. Since the Source 2003 engine is pretty popular it would be a lot of pain to try to adopt the dx10 fog-sRGB behavior with no gain.
We may want to use the framebuffer_sRGB extension in the future.
It's not the only case where we declare "new" behavior as broken. E.g. the error returned due to bad buffer lock flags happens to break games, even though the new behavior is saner than the old one.
Sure, I just don't think either behaviour should be considered broken at this point.
Am Dienstag 06 Juli 2010 17:02:23 schrieb Henri Verbeet:
I haven't seen any game that depends on the new behavior. Since the Source 2003 engine is pretty popular it would be a lot of pain to try to adopt the dx10 fog-sRGB behavior with no gain.
We may want to use the framebuffer_sRGB extension in the future.
In which case we'll have to fall back to the shader sRGB correction if fog is used with sRGB writing.
It's not the only case where we declare "new" behavior as broken. E.g. the error returned due to bad buffer lock flags happens to break games, even though the new behavior is saner than the old one.
Sure, I just don't think either behaviour should be considered broken at this point.
Do you think we should just accept both behaviors as OK?
On 6 July 2010 17:41, Stefan Dösinger stefan@codeweavers.com wrote:
Sure, I just don't think either behaviour should be considered broken at this point.
Do you think we should just accept both behaviors as OK?
Yeah.
-
Henri Verbeet -
Stefan Dösinger