After some long discussions it was realizied that the old README had way
too much informations and was too unspecified on some topics. This new
README was written from scratch and focus on installing Quake II.
The old whitelist was a leftover from the early days of YQ2. It should
run on most / all architectures, as long SDL supports them. As suggested
by smcv in issue #138 generate the OSTYPE and ARCH defines by the build
system instead of hardcoding it.
Savegame compatibility is provided by bumping the savegame version. Old
savegames are compared against the old OSTYPE and ARCH defined, new ones
against the new defines. This compatibility code should be removed
somewhere in the distant future.
Hardware gamma is broken, especially in fullscreen, and a Mac user told me
that setting HW/screen gamma on OSX is a bad idea anyway, because it resets
the monitor calibration.
The game /should/ look ok with vid_gamma 1 (if your display is configured
properly), but if you think it's too dark set it a bit higher and do
vid_restart.
Multitexturing was enabled by default in 0f7b422. It gives a small but
on todays hardware neglectable performance boost, but caused several
problems over the years. For example gl_showtris doesn't work with it
and there's at least one render glitch in city3.bsp.
not sure if this has any drawbacks, seems to work good so far.
No idea why id apparently deactivated this at some point, maybe to
optimize performance?
turns out the if the console is opened while no game is currently
running, cls.key_dest is not key_console but still key_game.
Changing it to key_console in those cases blows up in interesting ways.
So in Char_Event() we send events to the console in those cases.
The first row of AZERTY-Keyboards (used in France and Belgium) doesn't
have numbers as keys but ², &, é, ", ', (, -, è, _, ç, à, ), =
(with small differences between France and Belgium).
For some of those keys we don't have keycodes - and neither does SDL2.
See also https://bugzilla.libsdl.org/show_bug.cgi?id=3188
As a workaround, just map those keys to 1, 2, ..., 9, 0 anyway, as those
are keys Quake2 already knows (and those chars are printed on the keys
too, for typing they're reachable via shift).
This workaround only works for SDL2, as SDL1.2 doesn't have scancodes
which we need scancodes to identify the keys.
While at it I unified handling of SDL_KEYDOWN and SDL_KEYUP, the code
is almost identical anyway, apart from one bool argument to Key_Event().
We track this problem in #81
This clamps the UI scale, limiting the relative size of the UI
elements to what they would be at scale 1 in a 320x240 resolution.
Allowing bigger scales is not useful, and would make it possible
for the user to shoot him-/herself in the foot by setting a
"too big" UI scale value in the menu. (Since this would mess up
the menu, it could be hard te recover from for a casual user.)
