On loading GL symbols we are using SDL_GL_GetProcAddress(), which only valid if we previously loaded OpenGL library with SDL_GL_LoadLibrary(). We cannot use mod_LoadModule() here, otherwise finding symbols will fail.
In windows x64, on trying to run the game, ChangeDisplaySettings will fail because the game does not use the new windows api to change these settings. Since Win95 compatibility mode is not an option for Win64, instead change the default BPP to 32.
There may be a more proper way to handle this, and make it more uniform to remove BPP 16 entirely, but this has worked for me since putting it in a fork over a month ago.
This now renders to an OpenGL Framebuffer Object at the game's resolution,
and blits it to the window at whatever resolution it is currently using,
scaling and letterboxing if necessary.
Which is to say: display resolutions are now imaginary, and we never change
the physical display mode now. A smaller resolution is simply drawing less
pixels and scaling them up with the GPU for display. This solves a few
problems: no more resizing background windows or desktop icons shuffling
around, no more being stuck in a weird resolution when debugging or if the
game crashes, no more waiting on monitors to click over to a new mode, and
no more weird rendering when the display didn't exactly support the requested
mode.
This also means the game doesn't have to drop down to 640x480 for the config
menu screen when it was otherwise using some other resolution.
Some caveats:
- This _requires_ OpenGL Framebuffer Object support; there is currently no
fallback if it's missing and the game will refuse to start. But any desktop
hardware of the last ~20 years should support it. For weird embedded things
or whatnot, it will be possible to add a fallback.
- This currently requires SDL. The OpenGL pieces should work on Windows, but
someone would need to adjust the existing win32 code to create a fullscreen
window and not change the physical display mode. It should still compile on
windows and work as before (untested by me, though).
- This is only OpenGL; it does not touch the Direct3D renderer, which should
continue to work as before (again, untested by me).
