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.
