In the last few weeks I've played again through the game and kept an eye
on small oddities. And there're a lot of them. For example some GUIs and
videos getting stuck after the first frame (issue #192) or being unable
to protect the guy with the lamp in Alpha Labs 3. Some digging proved
that most - if not all - of these problems are caused by the compilers
optimization level. When build with -O2 both g++ 8.1 and clang 6.0.0 are
producing working code. g++ 8.1 with -O3 has some small, hard to notice
oddities, clang 6.0.0 with -O3 shows a lot of them. Since there's not
measurable difference between -O3 and -O2 just go down to the later:
x doom_o3.txt
+ doom_o2.txt
+----------------------------------------------------------------------+
| + |
| + * |
|x * x * |
| |_____________________|___A______M__A_________M___|_||
+----------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 5 173 178 177 176.4 2.0736441
+ 5 176 178 178 177.2 1.0954451
so even with many loud sounds the overall volume isn't reduced by
OpenAL - apparently OpenAL scales down all sounds temporarily if the
mixed result would be too loud or sth like that.
Just sending all sounds to OpenAL with a lower volume prevents that from
happening (just set your system speaker volume a bit higher if needed).
This problem was especially noticable when shooting at metal walls with
the shotgun (each pellet produces an impact sound so it gets kinda loud)
Sometimes memory was allocated with new[] but freed with delete instead
of delete[], which is wrong.
And there were some small memory leaks, too.
Furtunately clang's AddressSanitizer detected all that so I could easily
fix it.
(There seem to be some more small memory leaks which are harder to fix,
though)
On FreeBSD, the game used to crash when loading the last level of RoE
(d3xp), while loading models/david/hell_h7.ma.
The problem could be reproduced on Linux whith #define USE_LIBC_MALLOC 1
and clang's AddressSanitizer.
Turns out that this file specifies a vertex transform for a non-existent
vertex (index 31, while we only have 0-30) and thus the bounds of
pMesh->vertexes[] are violated.
I added a check to ensure the index is within the bounds and a Warning
if it isn't.
It should work now. If however it turns out that more files have this
problem, maybe .ma is parsed incorrectly and we need a differently fix.
(Should) fix#138
as we do int buttonIndex = ev.button.button - SDL_BUTTON_LEFT;
it's only consistent to do if(ev.button.button < SDL_BUTTON_LEFT + 8)
it doesn't really make any difference as long as SDL_BUTTON_LEFT is 1,
but this way it's safe for SDL3 or whatever future version might break
the ABI.
__builtin_trap() causes an illegal instruction and thus the process
can't resume afterwards.
raise(SIGTRAP) only breaks into the debugger and thus allows to
"ignore" the assertion while debugging.
The assertion in idBounds::operator-(const idBounds&) was triggered
from idWeapon::Event_LaunchProjectiles() (ownerBounds - projBounds)
It only happened when using the BFG.
So I added a check to make sure calling operator- is legal.
I guess this also caused #122
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 to identify the keys.
This should obsolete one part of pull request #135
.. despite the lack of depth-fail ("Carmack's Reverse"), which doesn't really matter for that reason.
I have the impression that some people didn't get this.
"source port" is the usual term for this and what people will probably google for.
mentioning the tested platforms right at beginning might also be helpful for people.
also (hopefully) clarified what EFX/EAX is about, some people who wrote comments
about the release seemed confused about that.
It's an SDL_TEXTEDITING event which we seem to get on Windows whenever
the Window gains focus (or is created). I think it can be safely
ignored, so that's what I do.
I also changed how those warnings are printed - as a hex number now,
because they're defined as hex numbers in the SDL source and it's easier
to find out what kind of event it is this way.
