* 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)
<TylerSchwend@gmail.com>)
* (bug 3623) COMMAND is mapped to the ALT key (Matthias <Kapffer@macbay.de>)
* (bug 3665) Typo error in FS_FOpenFileByMode function (TsT <tst2006@gmail.com>)
* (bug 3669) Some files left out of Solaris Packages (Vincent Cojot
<vincent@cojot.name>)
* (bug 3680) server quit messages (Ben Millwood)
* (bug 3682) Maps with >1024 models cause a segfault (misantropia
<bnoordhuis@gmail.com>)
* (bug 3683) R_FindShader(): negative lightmap indexes cause stray pointers
(misantropia <bnoordhuis@gmail.com>)
* (bug 3688) q3asm potential segfault fix and other changes (TsT
<tst2006@gmail.com>)
* (bug 3695) Not allowing to write file with lib extention (.dll/.so/...) (TsT
<tst2006@gmail.com>)
* (bug 3696) make-macosx-ub.sh outdated by revision 1340; test for Tiger not
working (Matthias <Kapffer@macbay.de>)
* (bug 3698) #error reported as warning in q3cpp (and no #warning support)
(Ben Millwood)
* (bug 3703) restoring the valued pre-SDL window behaviour (/dev/humancontroller
<devhc97@gmail.com>)
We fake a server packet and write it directly to the demo file at the point
where we'd transmit to the server. This is a little nasty, but it seems to
be the most reasonable solution.
The Speex VAD sort of sucks, honestly, or I'm not using it right. Now
trying this algorithm, after denoising:
http://lists.xiph.org/pipermail/speex-dev/2006-March/004269.html
And I'll play around to find the threshold for considering a set of frames
to be "voice" from there.
Also worth noting: we consider the power of the set of frames as a whole, so
you need to sustain power for 0.25 seconds at a time, or it's not "voice."