Unfortunately, different versions of astyle produce slighty different
formatting, so it's important that everyone uses the same version.
Thus it makes sense to provide astyle binaries for Win32 and
Linux x86 and x86_64 (to prevent usage of outdated versions from package
managers etc)
Most probably it would be easy to add an OSX astyle binary as well and
call that from astyle-code.sh if applicable.
I don't have a Mac, though, so someone else will have to do it ;-)
The SDL backend now creates SE_MOUSE_LEAVE events when the mouse leaves
the window (both SDL1.2 and SDL2). For some reason, both the SWF GUI
backend and CEGUI are interested in this.
Mostly necessary because SDL doesn't properly return mouse buttons X1/X2
on Linux/X11, see https://bugzilla.libsdl.org/show_bug.cgi?id=2310
Not sure if this is possible with Windows, DIMOFS_BUTTON7 seems to be
the highest constant there.
Also passing sdlevent.wheel.y directly as scroll delta
The d3bfg internal SE_CHAR events were documented as "evValue is an
ascii char", but are actually at least UTF-16, as returned by
Windows WM_CHAR events.
We now assume it's UTF-32 (UTF-16 has the same values mostly)
and the SDL backend now puts UTF-32 chars into SE_CHAR events.
In the Windows backend I make sure that no surrogate UTF-16 chars are
emitted + I added support for WM_UNICODE messages.
Now I can input Ümläuts intö the conßole window \o/
Sys_GetEvent()
* renamed res_none to no_more_events, because that's what the
caller assumes when getting that event
* don't return res_none on unhandled events, instead get the next event
until there is a handled event or no more events
(=> if -> while, return res_none -> continue)
* Mapping to Doom3 keynum handled differently for SDL1 vs SDL2, see below
For SDL2 we don't use SDL_KeyToDoom3Key on the keysym anymore, but map
the SDL2 scancode to Doom3/Direct-Input scancodes instead (the keynum_t
K_* constants are really used as scancodes!).
This mapping is done in sdl2_scancode_mappings.h scancodeToKeyNum[].
In sdl_events.cpp there are static SDLScanCodeToKeyNum() and
KeyNumToSDLScanCode() functions that use this scancodeToKeyNum[] array.
Sys_GetKeyName() now does something sensible for SDL2 by using
KeyNumToSDLScanCode()
This is also used to implement idKeyInput::LocalizedKeyName() for SDL-targets
(for SDL1.2 the behavior doesn't change much, though, as it doesn't have
consistent scancodes - Sys_GetKeyName() will just return NULL and
idKeyInput::LocalizedKeyName() will fall back to the old default)
turns out that both d3bfg and cegui use direct input scancode numbers
to represent keys internally.. now isn't that fucking convenient!
d3bfg was missing some, though, so I added them
strdup() and free() aren't really the right tool if the size of the
buffer is known anyway (and quite small, currently 32 chars)
while at it, I renamed s and s_pos to str and str_pos for better
readability
* Tested in Linux with both XBox360 wireless and Logitech F710 gamepads.
Should work with any XBox gamepad clone wired/wireless.
* Works well using SDL 1.2 or SDL 2.0
* SDL scan values are currently hard-coded. Note sure how to implement
remapping at the moment (config file, GUI, ...).
note, that it is expected that this libjpeg is newer, therefore some files needs to be patched
to compile.
This patch is used for Debian -- Debian uses libjpeg-turbo, but I assume that it will also compile
against a recent libjpeg.
Commit 7e21048 introduced a change in the save game files strutcure.
This makes the game crash whenever you load saved games created with a prior version of the code.
This commit tends to fix this issue.
However, save game files created between commit 7e21048 and the current one will not load correclty.
Unless the user change the saved game's saveVersion number in game.details.
renderprogs/interactionSM.pixel does not compile with the Mesa
shader compiler due to a an implicit type conversion.
This gives a console warning on a release build and fatally
asserts on an debug build:
0:135(19): error: could not implicitly convert operands to arithmetic operator
Avoid this by changing an int declaration to a float.
While the game so far has no official release on Linux, we cannot
depend on any pre-installed path for the game. Even if it were, it
would likely be a steam exclusive and constrained to
$HOME/.local/share/Steam ...
Instead, this adopts a more typical Debian-style path used for game
data, that is putting it into /usr/share/games. This is already the
path I have chosen when making the doom3bfg-data package[1] for the
Arch Linux AUR, and currently both packages for RBDOOM-3-BFG patch
this file in order to use this path. The more generic path name can
facilitate the use of any other forks of BFG Edition that may come
along, and everyone will benefit by sharing the same data path.
[1] https://aur.archlinux.org/packages/doom3bfg-data/
We can't add new graphics options without altering the original Flash menu
files which we don't have. I disabled the r_lodBias functionality which
can make the game look worse by adding a bias to the texture lookup
functions which cause choosing texture mip maps that are smaller than the
original image size in every view even though we want the first mip map
level 0 which is the best quality.
This changes the filesystem to work a bit more like previous id tech
engines and allows to run mods and custom content like the Wulfen high
resolution textures in those mods with
+set fs_game <modname> +set fs_resourceLoadPriority 0
- Implemented soft shadows using PCF hardware shadow mapping
The implementation uses sampler2DArrayShadow and PCF which usually
requires Direct3D 10.1 however it is in the OpenGL 3.2 core so it should
be widely supported.
All 3 light types are supported which means parallel lights (sun) use
scene independent cascaded shadow mapping.
The implementation is very fast with single taps (400 fps average per
scene on a GTX 660 ti OC) however I defaulted it to 16 taps so the shadows look
really good which should you give stable 100 fps on todays hardware.
The shadow filtering algorithm is based on Carmack's research which was
released in the original Doom 3 GPL release draw_exp.cpp.
- Changed interaction shaders to use Half-Lambert lighting like in HL2 to
make the game less dark
- Fixed some of the renderer debugging/development tools like r_showTris
Rename ATTRIBUTE_PRINTF to
- ID_STATIC_ATTRIBUTE_PRINTF
- ID_INSTANCE_ATTRIBUTE_PRINTF
since for instance functions, this has to be taken into account, too.
Add format analysis to idLib, DeclManager and idTokenParser functions.
Add support for clang.
Changed surf member to now be a union of a intptr_t index and a lwSurface*.
Index member has to be signed to prevent overflow (by assigning a possibly negative short).
For most platforms, sizeof(int*) should be the same as sizeof(lwSurface*), though this might still be a race condition.
+ 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.
