Any suggestion on where to go from here? Does this need more discussion elsewhere or should a simple return WINED3DERR_INVALIDCALL do it?
I'm having trouble understanding where I should be checking for this error and returning an the invalid call. On Mon, Jul 21, 2008 at 9:28 PM, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > Ah, so it's essentially a recursive Reset call. My guess would be that > > we don't want to allow that, but it requires some tests on native > > win32 to verify. You could try returning WINED3DERR_INVALIDCALL when > > Reset gets called from inside another Reset call, to see how the > > application reacts to that. > This also raises another question regarding the window handling in wined3d: > Are we allowed / supposed to modify the window size and position of the > destination window the app supplies like this? A lot of apps seem to need > that, otherwise the rendering is placed incorrectly or not visible because > the window is hidden. However, it could be that Windows somehow renders > correctly without changing the Window's properties. > > So the SetWindowPos() call in Reset() might be the wrong thing here. It is > not entirely unexpected that the app calls Reset when it receives a Window > position / size change. If the Window size changes, the app is supposed to > reset the D3D device, otherwise the rendering output is stretched in > Present(which can look kinda ugly) > > >