This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• test code (test.cpp, text/plain, 2019-03-05 10:43:30 +0000, 1294 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Windows 10, x86

Comments on the original bug report:

On 2019-03-05 10:43:30 +0000, Anthony @ POW Games wrote:

Created attachment 3690
test code

This used to work in 2.0.9 and is a bug introduced in the latest HG.

If you create a SDL_WINDOW_FULLSCREEN window with a size that changes the resolution and then attach a Direct3D renderer to that window, destroying that window will not restore the display's resolution. So if you then proceed to create a normal desktop window, the display mode will still be stuck in the previous window resolution and nothing gets displayed on the screen. This bug doesn't exist in 2.0.9, or if you use openGL or a software renderer.

I'm attaching test code that reproduces the bug. Press space to toggle SDL_WINDOW_FULLSCREEN and re-create the window & renderer.

On 2019-05-18 18:48:54 +0000, Ryan C. Gordon wrote:

Tagging a bunch of bugs with "target-2.0.10" so we have a clear list of things to address before a 2.0.10 release.

Please note that "addressing" one of these bugs might mean deciding to defer on it until after 2.0.10, or resolving it as WONTFIX, etc. This is just here to tell us we should look at it carefully, and soon.

If you have new information or feedback on this issue, this is a good time to add it to the conversation, as we're likely to be paying attention to this specific report in the next few days/weeks.

Thanks!

--ryan.

On 2019-06-11 17:11:21 +0000, Ryan C. Gordon wrote:

I have to preface this by saying I don't know why this fixes it, but bisecting to here showed an obvious culprit:

https://hg.libsdl.org/SDL/rev/412a6f2078d4

I changed the vertex buffer back from D3DPOOL_DEFAULT to D3DPOOL_MANAGED and this fixes the problem here. Also, in a pathological test case (testsprite2 with 30,000 sprites) it's a few FPS faster here.

It's not clear to me why this should make a difference. It's possible we're failing to clean something up when the managed pool isn't doing it for us, so Direct3D isn't shutting down correctly when we change the window? I don't know.

For now, I believe this to be fixed in https://hg.libsdl.org/SDL/rev/706e38de05c9

--ryan.

On 2019-06-21 19:12:25 +0000, Ryan C. Gordon wrote:

A better fix for this just landed in https://hg.libsdl.org/SDL/rev/9d3f245739f8

--ryan.