buggy resolution changing code
Brought to you by:
e6y
Menu
▾
▴
#232 buggy resolution changing code
I have foud a severe bug in the code responsible for changing the screen resolution that I was not yet able to debug. I have the folowing settings in the Video Mode section:
Video Mode: 32 bit
Screen Resolution: 1600x900 (that's my display's native resolution)
Aspect Ratio: Auto
Fullscreen Video Mode: Yes
Status Bar and Menu Appearance: Not Adjusted
Use GL Surface For Software Mode: Yes
Vertical Sync: Yes
Now, if I change Video Mode to "OpenGL" and then back to "32 bit" my screen starts flickering and the programs becomes unresponsive, so that I have to "kill -9" it from the command line. If I switch off Vertical Sync, the program simply hangs without the flicker. However, if I disable "Use GL Surface For Software Mode", changing Video Mode back and forth works without a flaw!
Another issue, and I sure they are connected: I turn off Fullscreen Video Mode and reduce Screen Resolution down to 640x480. Now I increase it back to 800x600. With either (a) Video Mode set to "OpenGL" or (b) Use GL Surface For Software Mode set to "Yes", the window will flicker back and forth between 640x480 and 800x600 geometry, leaving the program unresponsive.
I have no these issues on my Windows machine.
I've tried to investigate this issue a bit further, but it's tricky, since it only appears in OpenGL mode (and I have zero knowledge about its API). It seems that when I confirm the resolution change, the window size is changed and then OpenGL surface is reinitialized. However, then, for a reason I have not understood yet, SDL recognizes a window resize event for the previous resolution and the procedure begins anew and loops endlessly.
Do you mean SDL_VIDEORESIZE event? How about disabling it?
Right, commenting out lines 318-320 in src/SDL/i_video.c [*] fixes the issue for me.
[*] i.e. the ones that read
"
case SDL_VIDEORESIZE:
ApplyWindowResize(Event);
break;
"
So I can disable it for non Windows platforms.
case SDL_VIDEORESIZE:
ifdef _WIN32
ApplyWindowResize(Event);
endif
break;
I don't think that people even know about ability to resize window with mouse and shift+mouse
Last edit: Andrey Budko 2014-02-24
Wait a minute. It doesn't resolve the initial issue, i.e. prboom-plus will hang if I switch back and forth between OpenGL and 32-bit with "Use GL Surface For Software Mode" enabled.