- Fix build with SDL <=2.0.3
SDL_GetGlobalMouseState was introduced in 2.0.4
(which doesn't support OSX 10.5 or older)
- Don't include execinfo.h on Mac OS X 10.4
This file isn't included in the 10.4 SDK
- Use custom typedef for PFNGLSTENCILOPSEPARATEPROC on OSX 10.4/10.5
because the system OpenGL headers for those versions don't have it
as long as it's chars Doom3 supports, i.e. it can be converted
to ISO-8859-1
also renamed kbdNames to _in_kbdNames to reduce likelyhood of clashes
(as it can't be static)
If in_ignoreConsoleKey is set, the console can only be opened with
Shift+Esc, not `/^/whatever, so you can easily type whatever character
is on your "console key" into the game, or even bind that key.
Otherwise, with SDL2, that key (KEY_SCANCODE_GRAVE) always generates the
newly added K_CONSOLE.
in_kbd has a new (SDL2-only) "auto" mode which tries to detect the
keyboard layout based on SDL_GetKeyFromScancode( SDL_SCANCODE_GRAVE ).
Wherever Sys_GetConsoleKey() is called, I now take the current state of
Shift into account, so we don't discard more chars than necessary, esp.
when they keyboard-layout (in_kbd) is *not* correctly set.
(TBH the only reason besides SDL1.2 to keep in_kbd around is to ignore
the char generated by the "console key" in the console..)
It's set to 0 by default (which is the original behavior), if set to 1,
SDL2 will grab the keyboard, so Alt-Tab or the Windows Key etc will not
be handled by the operating system but by dhewm3 (=> you can bind the
Windows key like any normal key and it won't open the start menu)
If a key is pressed whichs SDL_Keycode isn't known to Doom3 (has no
corresponding K_* constant), its SDL_Scancode is mapped to the
corresponding newly added K_SC_* scancode constant.
I think I have K_SC_* constants for all keys that differ between
keyboard layouts (which is mostly printable characters; F1-F12, Ctrl,
Shift, ... should be the same on all layouts, which means that e.g.
SDL_SCANCODE_F1 always belongs to SDLK_F1 which the old code already
maps to Doom3's K_F1).
What's extra nice (IMO) is that when Doom3 requests a *localized* name
of the key (like for showing in the bindings menu), we actually use the
name of the SDL_Keycode that *currently* belongs to the scancode, and
esp. the "Western High-ASCII characters" (ISO-8859-1) supported by Doom3
like Ä or Ñ are displayed correctly.
(I already implemented a very similar hack in Yamagi Quake II and
reused the list of scancodes)
This should fix most of the problems reported in #323
Added Sys_FreeClipboardData(char*) so I don't have to copy the string
from SDL_GetClipboardText() into a Mem_Alloc() buffer, but can just
do the right thing per platform, which in case of POSIX/SDL2 is
SDL_free().
SDL1.2 doesn't have clipboard support, otherwise I'd have removed all
platform-specific implementations and used SDL_Get/SetClipboardText()
everywhere (IIRC AROS only supports SDL1.2?)
idStr is used in both the main thread and the async sound thread, so
it should better be thread-safe.. idDynamicBlockAlloc is not.
Use realloc() and free() instead.
For some reason this caused a lot more crashes (due to inconsistencies
in the allocator's heap) with newer Linux distros (like XUbuntu 20.04)
and when using GCC9, while they rarely reproduced with GCC7 or on
XUbuntu 18.04
fixes#391
If those functions (e.g. called by common->Printf(), common->Error())
weren't called from the mainthread and win_outputEditString was set to 1,
a deadlock could occur.
Specifically, the async thread (handling sound) was calling
common->Warning() -> Sys_Printf() -> Conbuf_AppendText() which called
SendMessageA() which blocks until the main thread handles the message.
The main thread however was in idSampleDecoderLocal::Decode() trying to
enter CRITICAL_SECTION_ONE, which was held by the async thread
(it's used to synchronize sound handling between main and async thread).
So now if Sys_Printf() (or Sys_Error() which should have the same problem)
is not called by the main thread, the text is buffered and
Conbuf_AppendText() is called for the buffered lines in the next frame
in Win_Frame().
I'm gonna use it with libbacktrace - I'll need the path of the
executable before I can use idStr (and thus before I could call
Sys_GetPath(PATH_EXE, str)).
The problem was that the editors called ChoosePixelFormat() instead of
wglChoosePixelFormatARB() - and the normal ChoosePixelFormat() has no
attribute for MSAA, so if MSAA is enabled (by SDL2 which calls the wgl
variant), ChoosePixelFormat() will return an incomaptible format and
the editors don't get a working OpenGL context.
So I wrote a wrapper around ChoosePixelFormat() that calls the wgl variant
if available, and all the necessary plumbing around that.
While at it, removed the unused qwgl*PixelFormat function pointers and
supressed the "inconsistent dll linkage" warnings for the gl stubs
Minimum required Windows version is XP again (instead of Win10).
Win_GetWindowScalingFactor() tries to use two dynamically loaded functions
from newer windows versions (8.1+, Win10 1607+) and has a fallback for
older versions that also seems to work (at least if all displays have
the same DPI).
Moved the function to win_main.cpp so the dynamically loaded functions
can be loaded at startup; so edit_gui_common.cpp could be removed again.
Otherwise especially looped sounds continue playing while the menu
is open, especially noticeable when opening the menu while firing
the chaingun (the whirring sound continues playing).
Seems to work; note that idWaveFile is only ever used in idSoundSample::Load()
As stb_vorbis doesn't support custom callbacks for reading, I feed it
the full .ogg files as a buffer. Shouldn't make much of a difference
though - either the whole file is decoded on load anyway (so the buffer
is freed after decoding, or it's streamed, but in that case the old code
also kept the whole ogg file in memory by using idFily_Memory.
I also added warning messages in places where calls to stb_vorbis_*()
can fail, where there were none in the equivalent libvorbis code.
This reverts commit 01ac144b09.
Looks like this broke the build on some systems, because some
package managers pack SDL2Config.cmake and others pack sdl2-config.cmake
in their SDL2 development packages (for some reason, SDL2 seems
to ship both in their source, and they appear to be incompatible).
Shipping our own FindSDL2.cmake might be unclean/ugly/whatever, but
at least it works (most of the time? at least it appears to work better
than not shipping it)
* Windows DLL-Load-Errors
Added error reporting using formatmessage, ignoring if the DLL just
doesn't exist, custom warning for "[193 (0xC1)] is not a valid Win32
application." (probably wrong architecture)
* update gitignore with build folder
.. but only if the file exists.
It's ok if mods don't have their own DLL/.so, but if they do have one
and loading fails it's interesting why they failed (e.g. no access
rights, 64bit lib with 32bit executable or other way around, missing
symbols due to wrong libc version, ...)
The same should be done for Windows, but that's still TODO.
I updated sdl2-config.cmake in dhewm3-libs so building on Windows with
them works again, however that required also a little change in
dhewm3's CMakeLists.txt
I also still had some uncommited changes for that fullscreen workaround
that I'm committing now.
.. that doesn't switch the display resolution, but creates a borderless
fullscreen window at current desktop resolution.
SDL2-only (SDL_WINDOW_FULLSCREEN_DESKTOP).
Doing this with an additional CVar instead of r_fullscreen 2 or similar
has the advantage that it works properly with Alt-Enter
SDL has a bug (at least on Windows) where SDL_CreateWindow() with
SDL_WINDOW_FULLSCREEN doesn't use the configured resolution (if it's
higher than the current desktop resolution).
Try to work around that - based on Yamagi Quake II code.
Also, if GLimp_Init() fails, the "safe mode" fallback is now in
windowed mode instead of fullscreen mode.
the game was frozen (the main menu and console worked though) when
switching from the Radiant to the engine (with F2 or that button).
Turned out common->ActivateTool( false ) must be called if the game window
has forcus, so idSessionLocal::Frame() doesn't return early (and thus not
run the game code).
Furthermore, there was no sound when switching from Radiant to the game,
because the SoundWorld was set to sth editor-specific. Fixed that as well.
OpenAL devices can disconnect, and with some luck they're back after
a few seconds. This especially seems to happen with Intels Windows GPU
driver and display-audio when switching the resolution or enabling
fullscreen, see #209
Now a disconnect is detected and we try to reset the device for 20
seconds, hoping it comes back. This needs at least openal-soft 1.17.0
to build and 1.20.0 or newer to actually work.
Also added missing stub functions in openal_stub.cpp (used by dedicated
server so it doesn't have to link libopenal)
On Windows, ID_INLINE does __forceinline, which is bad if the function
calls alloca() and is called in a loop..
So use just __inline there so the compiler can choose not to inline
(if called in a loop).
This didn't cause actual stack overflows as far as I know, but it could
(and MSVC warns about it).
