Before this change was made, I had tried building Descent 3 on Windows
for the first time. The instructions for building Descent 3 on Windows
were unclear, inaccurate and they messed up my installation of Windows.
(See #332 for details).
I started working on this commit in order to prevent that situation from
happening again. I ended up revamping the entire build instructions
section.
The biggest change that I made was making it so that users only need to
look at the instructions for their own platforms. Before this change,
you had to look at the “Building” heading and read the sentence that was
directly beneath it. If you don’t do what that sentence says, then the
instructions won’t work. Unfortunately, the way that the instructions
were laid out drew the reader’s eye away from that sentence.
Specifically, the instructions would draw the reader’s attention towards
the subheading for their specific platform. This commit makes it so that
each platform-specific subsection contains everything that users of that
platform need to know.
Another change that I made has to do with Git. Previously, the
instructions said “Build steps below assume you have already cloned the
repository and entered it locally.” They never told users how to make
sure that Git is installed or how to create a clone of the repository.
They also didn’t tell Windows users that the clone of Descent3 should
not be entered until after VCPKG_ROOT has been set. In other words, if a
Windows user had followed the instructions exactly as they were written,
then they would have ended up with a clone of vcpkg inside of their
clone of Descent3 (not using submodules!). This commit adds explicit
instructions for installing Git and cloning Descent3. It also makes sure
that Descent3 is only cloned after all dependencies have been installed.
I also made a Visual Studio-related changes in this commit. Previously,
the instructions for Windows said “Requires Visual Studio 2022 and C++
Tools (cmake and vcpkg)”, but the instructions never told users how to
make sure that they had those things. This commit adds explicit
instructions for how to make sure that you have Visual Studio and the
required components installed.
Another change that this commit makes has to do with vcpkg. Before this
commit, the Windows build instructions had you manually set up vcpkg.
This was redundant because the instructions also had you install Visual
Studio 2022 with the “Desktop development with C++” workload. That
workload comes with vcpkg [1], so setting up vcpkg manually was
unnecessary. This commit removes the parts about installing vcpkg.
(Thanks to @Lgt2x for this idea [2].)
The commit also adds sentences to the ends of the platform-specific
build instructions that tell users where the built files get put. This
is technically redundant since the Usage instructions already tell users
where to find the built files. Even though those sentences are
redundant, I still included them because they make the instructions
easier to use.
This commit also makes a minor capitalization-related change.
Previously, the build instructions said “Building - MacOS”. The official
capitalization has been “macOS” since 2016 [3][4].
Another minor change that this commit makes has to do with the Ubuntu
and Fedora build instructions. This commit adds the sentence “Run these
commands:” to each of those sections. I only added that sentence in
order to make the Ubuntu and Fedora sections more consistent with the
Windows and macOS sections. The Windows and macOS sections use that
sentence as part of a numbered list.
[1]: <https://learn.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-community?view=vs-2022#desktop-development-with-c>
[2]: <https://github.com/DescentDevelopers/Descent3/pull/413#discussion_r1624974614>
[3]: <https://www.businessinsider.com/wwdc-2016-os-x-becomes-macos-2016-6>
[4]: <https://www.apple.com/macos>
cmake/CheckGit.cmake uses configure_file() to create d3_version.h in ${TARGET_DIR}/lib aka ${PROJECT_BINARY_DIR}/lib. But add_custom_command() and add_custom_target() calls in the root CMakeLists.txt use ${PROJECT_BINARY_DIR}/Descent3 as path to that file, expecting it in a different place. While the build still works, since the compiler looks in the right include paths for it, the dependencies between these rules/targets are technically broken. At least msbuild will generate warnings about missing build outputs.
Also removed the wrong ALL parameter from add_custom_command(), it's only a valid parameter for add_custom_target().
Use Real-time library memory functions by default which improves overall performance. Minor cleanups.
Introduce new CMake option to enable/disable RTL memory functions (enabled by default).
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).
The serverconn variable identifies the reliable socket used by the server.
However this variable is not yet initialized at the very start of the first
client connection which causes the server to crash. This fixes a bad safety
check for this issue and a further instance of the bug.
