Tests, please. Also, at least with the current code this is still going to fail because wined3d disallows setting RT0 to NULL.
On Friday 22 April 2011 12:40:04 Henri Verbeet wrote:
Tests, please. Also, at least with the current code this is still going to fail because wined3d disallows setting RT0 to NULL.
We have a test. It didn't catch the problem because it tests setting both the depth stencil and RT to NULL, so the check if the depthstencil is NULL in SetRenderTarget prevented the crash. Well, I guess I can add a test for that...
Also the current code doesn't fail because it passes the old RT if the new RT is NULL. This behavior is also tested.
On 22 April 2011 13:29, Stefan Dösinger stefan@codeweavers.com wrote:
We have a test. It didn't catch the problem because it tests setting both the depth stencil and RT to NULL, so the check if the depthstencil is NULL in SetRenderTarget prevented the crash. Well, I guess I can add a test for that...
Yeah, I wrote that test. But please add the one for a NULL rt with non-NULL DS as well, it should be pretty trivial.
Also the current code doesn't fail because it passes the old RT if the new RT is NULL. This behavior is also tested.
I meant in the sense that it would fail to set the render target to NULL, but true, it won't actually attempt to do that.
Yeah, I wrote that test. But please add the one for a NULL rt with non-NULL DS as well, it should be pretty trivial.
Working on it. I'd still consider the existing tests to be enough for this NULL pointer regression fix to go in before the snapshot release.
The tests will take a little longer, the recent d3d changes broke my msvc build setup.
---
An unrelated issue I am ignoring for now: void * __cdecl wined3d_buffer_get_parent(const struct wined3d_buffer *buffer);
in the .idl file is compiled by Microsoft's midl to
void *__cdecl wined3d_buffer_get_parent( struct wined3d_buffer *buffer);
ie, the const is lost, leading to complaints from msvc that the implementation function doesn't match the declaration. Any idea how to fix it?
PS: The stupid gmx webmail doesn't understand mailing list replies. I hope this mail works properly.
On 22 April 2011 14:25, "Stefan Dösinger" stefandoesinger@gmx.at wrote:
An unrelated issue I am ignoring for now: void * __cdecl wined3d_buffer_get_parent(const struct wined3d_buffer *buffer);
in the .idl file is compiled by Microsoft's midl to
void *__cdecl wined3d_buffer_get_parent( struct wined3d_buffer *buffer);
ie, the const is lost, leading to complaints from msvc that the implementation function doesn't match the declaration. Any idea how to fix it?
Odd. But I think we can ignore it unless there's an easy fix, the IDL file should go away anyway once COM is gone from wined3d. Though maybe widl should match that behaviour.