koobas.hobune.stream
Identifying Windows resolution change at runtime
Trying a compiled project in a new windows powered tablet, which we were experimenting here, I noticed a problem anyone can try at a desktop Windows. In the tablet, all you have to do is rotate it, and the screen will flick.
To simulate it on a desktop windows, hold SHIFT before running the EXE and play it at full screen. CTRL+ESC out of it, right click on the desktop and open up Screen Resolution Windows Dialog. Set Orientation to anything other than the current one, press Apply, ALT+TAB back to the application.
The screen will flick a lot and if you wait for the 20 seconds for Windows to auto revert back to default settings, you'll be able to see your app running normally back again.
Plus, under [APPLICATION]_Data folder the output_log.txt may have at least a line similar to the ones I get:
(Filename: C:/BuildAgent/work/842f9557127e852/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 34)
Skipped rendering frame because GfxDevice is in invalid state (device lost)
(Filename: C:/BuildAgent/work/842f9557127e852/Runtime/Misc/Player.cpp Line: 1466)
D3D device reset failed [invalid call]
(Filename: C:/BuildAgent/work/842f9557127e852/Runtime/GfxDevice/d3d/D3D9Context.cpp Line: 456)
Skipped rendering frame because GfxDevice is in invalid state (device lost)
Any ideas on how to fix this?
Same problem. Does anybody figured out how to fix it?
@Turing_machine nothing here yet. Thankfully it is not a critical issue. But if you've got same problem, voting up the question might help getting visibility to it.
I'm curious if you see the same thing when starting another game or app that requires the graphics hardware? I actually see that in the Unity editor - if I start a game while the editor is running, when I come back to the editor the screen is black, and there are a lot of failures in the log where Unity is trying to handle the "device lost" state. The only way to recover is to select a window layout, which seems to reset everything properly. Anyway, it seems like Unity isn't properly handling "device lost", at least in some instances.
@Turing_machine that sounds like a worse solution than using `Screen.currentResolution` as Jordan suggested on his/her answer there. Have you tried that first (on your resolution checker script maybe)?
of course, and as i've mentioned, unity just gave me the same resolution that was before i've changed orientation in both fullscreen and windowed modes
i've kinda got the way to fix this - problem is that unity doesnt check how it's oriented on focus, that means it still thinks it's the same orientation, and gets Screen.height the same, despite that it becomes width. My problem was that I've got "resoulution checker" script, that tries to set corect resolution, and it worked wrong of course. So i've just got actual height and width of the screen using winAPI(user32.dll) directly, to find out actual orientation and correctly handle it.
Even though I won't be able to test this for a while, sounds like a solution and the only one so far! Thanks. :-)
Could you please share the code or the namespaces you used for this?
$$anonymous$$ost likely something like the example code at the bottom of this $$anonymous$$SDN page. Note: I'm not sure how well this behaves in multi-monitor setups ^^.
Another quick google revealed this. So GetSystem$$anonymous$$etrics always return the resolution of the primary monitor.
If you start in windowed mode, you can use Screen.currentResolution to get the current desktop resolution. You can go into full screen with Screen.fullScreen.
And would that magically solve the flickering or allow me to identify the resolution change? I'm asking because I won't be able to test it in a long while now. But Turing_machine there says it won't work.
doesn't worked for me. Screen.currentResolution just returns same value, so it doesn't helped to check if orientation was changed
