Sys_BinaryPathRelative takes a parameter which is path concatenated with
Sys_BinaryPath, and resolved to a canonical path. The intended use case
is to facilitate the situation where you want the game data directory to
exist outside the same directory in which the binary lives, but relative
to it. More specifically, if you want to distriute multiple binaries for
different architectures, in the same tree, this allows for a means of
having said binaries in architecture subdirectories, with a shared data
directory, e.g.:
ioq3/x86/ioquake3.exe etc.
ioq3/x86_64/ioquake3.exe etc.
ioq3/baseq3/pak0.pk3 etc.
Here, when building you would define DEFAULT_RELATIVE_BASEDIR=".." by
appending it to the build system CFLAGS, and then the executables will
by default look in their parent directory for the data.
The macOS client and server were completely unusable when run from a
terminal. They blocked forever in `[NSApp run];` which was called by
Sys_InitProtocolHandler(). `applicationDidFinishLaunching` was never
called to exit the NSApp run loop.
Use SDL's SDL_DROPFILE event to receive URLs to handle on macOS instead.
This also handles URLs while the game is running (connect to new server)
instead of nothing happening when clicking a link while the game is
running.
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 version check is required for supporting macOS PPC with SDL 2.0.1
and Travis-CI (Ubuntu Trusty) with SDL 2.0.2.
The client now requires SDL 2.0.5 runtime if compiled against SDL 2.0.5
or newer.
- Don't expose the function in sys_local.h (it would be static if we could).
- Don't call it Sys_Cocoa_*; it'd be nonsense with q3a's naming conventions.
* Rename IN_StartupJoystick to IN_InitJoystick, add IN_ShutdownJoystick
* Add IN_Restart, which avoids calling IN_DeactivateMouse at the wrong time
* Call IN_Restart when changing r_fullscreen
* Add CVAR_ROM r_sdlDriver for easy checking of the SDL driver in use
* Random README tweaks
* Move Unix specific signal handlers to Sys_PlatformInit
* (Windows only) Don't set the SDL video driver if SDL_VIDEODRIVER is already
set externally
* (Windows only) Use the "windib" SDL video driver if in_mouse is set to -1
more or less any input event; fine for the server, not so much use for the
client
* In the main loop, don't bother sleeping if it's going to be less than 10ms as
the methods we're using to sleep at the moment aren't very precise
* Add Sys_PlatformInit for platform specific initialisation
* In win32 Sys_PlatformInit force selection of the DirectX SDL backend in order
to get better fullscreen mouse input (in conjunction with a patched SDL DLL
http://bugzilla.libsdl.org/show_bug.cgi?id=265)
* Add con_passive.c to cut down on #ifdef DEDICATED in sys_main.c
* Add Sys_ErrorDialog to report ERR_FATALs to the user
+ On Windows use a MessageBox and offer to copy the console log to the
clipboard
+ On everything else print to the terminal and save the console log as
crashlog.txt
1) NET_Sleep() no longer watches for input, Sys_Sleep() added for waiting
on input.
2) Added "CtrlHandler" for trapping Ctrl-C and other quit methods not
handled by signals on windows
3) Added history support
4) Added tab completion
5) Removed automatic cursor/scroll adjustment (too problematic)
6) Enable mousewheel scrolling
7) Stop using the InputBuffer for editing
This seems to work pretty well now, but I jumped the gun on a previous
commit message by saying you can scroll now without locking up your server.
That was only true up until the point that a server tried to print to
the console, at that point it will hang until you release the scroll bar :(
It may be possible to get around this by using a seperate thread for
console output, but that's a whole new can of worms.
