+ terminating null byte - that's the limit of threadnames on linux
Furthermore: idJobThread::Start used va() to create the threadname.
va() isn't threadsafe... so I replaced it with a local buffer and
idStr::snPrintf()
* setting threadname is now done in a seperate function
* if setting the threadname fails, it just prints a warning now
instead of terminating the game with a FatalError
* setting threadname is now done in a seperate function so it's a bit
cleaner (it's different for every platform..)
* replace/refactor signaling code (based on my SDL threading branch and
the old pthread signaling code from RB):
- The interface is like on win32 now (Sys_Signal* functions instead of
overwriting idSysSignal class)
- created a custom signalHandle_t struct for that, which contains all
needed information
- Mimic Windows functions used in win32 implementation more closely,
e.g. signal all waiting threads on manualReset signalRaise, count
waiting threads etc. I'm pretty sure the behavior on Win32 and POSIX
now is identical (as far as possible).
For some reason SDL.h (or headers included by it) need some
string functions (like strncmp) in inline-functions (that we
don't even use).
Str.h has #defines preventing their usage.. so #undef those in
the (few) sourcefiles that need SDL headers
All these files were almost identical, so there is no good reason to
have them twice..
and change CMakeLists.txt accordingly
(Not that this commit won't compile because some #includes are still
broken - will be fixed in the next one)
win_net.cpp and posix_net.cpp were almost identical, i.e. caused a lot
of duplicated code.
To get rid of that, unify both files - by adding Winsock support to
posix_net.cpp and, in the next step, moving posix_net.cpp to sys/common/
and removing win_net.cpp
The AMD drivers output a lot of useless warnings when compiling the shaders.
Those are pretty annoying, especially as idRenderProgManager::LoadGLSLShader
prints out the whole shader with them..
So I added this CVar to suppress them (when it's set to 0)
the connect commands supports adding the port with ":"
like "connect 10.1.2.3:27016" - if no port is set, it defaults to 27015
net_port is still used as the port to listen on and to send from.
In the current case (only "direct" lobby backend, i.e. connect to a
server directly), lobby and game are always on the same server anyway..
It used to send the IP of the first network interface.. that kinda works
on Windows and FreeBSD in LANs (i.e. not over the internet or even
behind a NAT), but not at all on Linux, because the first device seems
to be the loopback device there (at least on my machine)..
Now it sends net_ip (so it should even work behind NAT) or, if net_ip is
set to "localhost" (the default), 0.0.0.0 is sent, which the client
interprets as "just use the IP of the lobby you're already connected to"
And suddenly hosting a server on linux works at least locally
(with client and server on the same machine).
Even though there are still strange bugs (massive lags in one
direction, doesn't work in LAN), at least it works at all now.
* idSysSignal::Wait should now handle timeouts > 1s better (or at all)
* Use clock_gettime for Sys_Milliseconds()
* Use CLOCK_MONOTONIC_RAW (and CLOCK_MONOTONIC as fallback if
that's not available) for Sys_Milliseconds() and Sys_Microseconds()
CLOCK_MONOTONIC can behave strange when NTP is used
* Small fixes in Sys_Microseconds(): use 64bit int to store time
(like return type...), divide by 1000 (not 1000000) for nsec=>musec
D3BFG gets the username from Steam, in the GPL release it just
uses the hostname.
Now it's possible to set a custom name with the ui_name CVAR
(like in classic doom3). If ui_name is empty ("") the hostname
is used.
The window losing focus in MP resulted in the console being spammed
with "changing com_pause not allowed in Multi Player" (or similar)
messages. Added CVAR_NOCHEAT flag to com_pause to get rid of that.
On true unices malloc.h was never available and on Linux one should
include stdlib.h instead. While this change is necessary to build
rbdoom3 on FreeBSD and other true unices, the big question is what
it means to Windows.
