This was the last remaining GNU assembler code that was in its own
independent source file, as opposed to being embedded in C code with
GNU `__asm__ volatile` or MSVC `__asm` (which tends to be much easier
to deal with in a modern build system).
When the Quake 3 engine was originally written, this might have been
an "expensive" function when written in portable C, but after 25 years
of CPU development it's less likely to matter (and modern compilers
might produce faster results from the C code anyway).
Resolves: https://github.com/ioquake/ioq3/issues/778
Signed-off-by: Simon McVittie <smcv@debian.org>
The error was only displayed for Team Arena if one of the Team Arena pk3s
were found. Fix it to be display when trying to run Team Arena even with
no Team Arena pk3s present.
Default com_maxfps to 0 under Emscripten. Under Emscripten the browser
handles throttling the frame rate. Manual framerate throttling interacts
poorly with Emscripten's browser-driven event loop.
This lets the user click a link in a web browser to very easily join a Quake 3 multiplayer game. As browser-based matchmaking websites become more popular, this makes it a lot more convenient and simple to play Quake 3 with others.
The links have the following URI format: quake3://connect/example.com:27950. The format has been designed to be flexible to allow more types of links in the future and avoiding having to make a breaking change. At the moment, "connect" is the only supported command.
The engine function pointer to vmMain used variadic arguments but
the vmMain function in the dylib has explicit arguments. Evidently
the arguments are stored on the stack and/or registers differently.
Found by fretn.
The CD key defaulted to spaces. Q3 UI uses text overwrite mode by
default so typing the CD key writes over the spaces. Team Arena UI
uses text insert mode by default so to enter the CD key the user
had to delete the spaces or toggling overwrite mode by pressing
the insert key.
Now the CD key defaults to empty so in Team Arena you can just type
it in.
Unlike the Steam and GOG support I'm not doing a registry search as I don't see anything in the registry that would show us the path. If we find more official ways to search for it later we can address that, in the meantime the path is just hardcoded to where it's installed by default.
- Reorganized Xcode project
- Added missionpack support to Xcode project
- Incorporated changes from MaddTheSane for Apple Silicon support https://github.com/maddthesane/ioq3
- Built SDL 2.0.14 for Apple Siicon, added to existing SDL dylib
- Built SDLMain for Apple Silicon, added to existing libSDL2main.a
For lerped frames (refEntity_t frame not equal oldframe) IQM joint
matrices may have incorrect axis scale. This can cause significant model
distortion. The matrix lerp is linear causing each vector to move in a
straight line between frames instead of arcing like a circle. Each joint
frame can have a different scale so can't just normalize the joint
matrix.
Store joints as quaternions and spherical lerp between them and then
convert to a matrix. For my test model, setting up the skeleton is four
times slower now but it still seems to be fast enough to be usable.
Fix the output/behaviour of CVAR_CHEAT flagged cvars in case they are
also of type CVAR_LATCH (avoid the early latch case return to make it
work as intended).
This is exact root of q3msgboom bug http://aluigi.altervista.org/adv/q3msgboom-adv.txt
Unfortunately, server still need this ugly '1022 char limit' hack to support unfixed clients in some degree.
And as it affects MSG_ReadBigString() - unfixed clients can still be crashed by 8191-chars long configstrings that comes with gamestate
By default mingw-w64 uses Microsoft's broken _vsnprintf() in msvcrt.dll.
It can be overriden by defining __USE_MINGW_ANSI_STDIO but let's just
use the same behavior for both MSVC and mingw-w64.
Reported by @birdstakes.
My cvar latch system changes prevent the Game VM from changing
g_gametype when the value is out of range due to it being registed in
the engine. It's been pointed out as fragile method of security, which
was still exploitable, by Noah Metzger (Chomenor). It doesn't seem like
this is working out to be a good solution.
The issue of fs_game '..' on server being relicated on client via
systeminfo exploit is still fixed as it's not affected by latch.
There are a few cases from current values of fs_game are used which
ideally should use fs_gamedir char array which has been validated.
Revert "Don't let VMs change engine latch cvars immediately"
Partially revert "Fix fs_game '..' reading outside of home and base path"
Revert "Fix VMs forcing engine latch cvar to update to latched value"
A few commits ago I stopped VM's Cvar_Set() from instantly updating
latched values. Now VM can't call Cvar_Register() afterword to force
latched value to be used.
Reported by Noah Metzger (Chomenor).
