+ 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"
