The new command line option -display lets the user select the display on
which Descent 3 should be displayed.
This is useful in multi-monitor setups where the game now can be run on any of
the given monitors.
Use orphaned "buffer update streaming" to eliminate synchronization
delays, due to CPU->GPU latency, causing framerate slowdowns. This sends
vertex data to the GPU via partial updates to a buffer and reallocates
the buffer once it fills up, ensuring that no synchronization is ever
needed. The buffer is sized to balance memory usage vs allocation rate,
and the GL driver ensures that "orphaned" buffers are only destroyed
when all GL commands using them are retired.
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).
