On 15 October 2014 10:20, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 2014-10-15 08:31, schrieb Henri Verbeet:
If you really wanted to avoid mode changes in test_lost_device() you'd have to change reset_device() as well, but the test actually tests for return codes after a mode change. It doesn't work on the testbot because IIRC it starts at 1024x768.
Right, the S_PRESENT_MODE_CHANGED should have alerted me. Do you have any idea why a successful reset brings the device into this state?
I'm not entirely sure, but my guess would be that it has something to do with the order between resizing the swapchain buffers and the mode change.
Does reset_device call IDirect3DDevice9_Reset (instead of ResetEx) intentionally? The IDirect3DDevice9_ part suggests that it is unintentional, but in the context of the patch that added it (2f307a14) it makes some sense.
It was intentional, although it probably wouldn't hurt to have some more tests for ResetEx() as well.