In Choco these functions are run only once at start-up, so this will
make no difference, but for Crispy I want to support changing the
framebuffer size in-game, thus I will need to be able to re-run these
functions at run-time.
With both autotools and cmake build systems in the repository, we
can accommodate pretty much every IDE there is without needing
hand-crafted files for each one.
Closes: #1057
This required proper ordering of libraries in the main build script
and coming up with a workaround in the SDL2 finder to ensure -lmingw32
always came first in the link order.
If the keepalive last-receive time is not initialized when the
connection is established, there is a risk that the connection will
immediately time out. This was causing problems for some players
where clients were successfully connecting to servers only to find
themselves stuck in the pre-game "lobby" area with no information
about other players.
This fixes#1046. Thanks to @bradc6 for the bug report.
If the keepalive last-receive time is not initialized when the
connection is established, there is a risk that the connection will
immediately time out. This was causing problems for some players
where clients were successfully connecting to servers only to find
themselves stuck in the pre-game "lobby" area with no information
about other players.
This fixes#1046. Thanks to @bradc6 for the bug report.
This appears to match the vanilla (DMX) behavior and some of the higher-
level sound code in s_sound.c appears to depend on it. Specifically,
S_StopMusic() has code that calls I_ResumeSong() if the music is
currently paused. However, S_Start() clears the paused state, which
prevents the call to I_ResumeSong() from occurring. I interpret this as
implying that the call to DMX's I_PlaySong() will resume OPL playback.
Thanks to Fabian and Julia Nechaevsky for noticing the bug.
This got broken by some recent changes. As part of this, remove a
now-deleted wiki page and also add a Makefile target to build the page
(for Doom, at least).
malloc wasn't getting declared on MSVC, leading to calling an
implicitly decleared function. I think those return int, which caused
the return value to be truncated on x64 builds, leading to an access
violation on write.
