Thanks to leilei being a diehard sw quake fan, and MH being the hacker he
is, engoo's vid_win.c drops Scitech's MGL :) (I really did not want to
resurrect that). However, I've modified it so it /compiles/ in QF: ripped
out the menu code, ripped out the input handling (that's in in_win.c) and
started trying to get it to work for vid_render. The clients at least link,
but I'm certain they'll segfault (GPF?).
The win clients are the native windows (NOT sdl!! *twitch*). Things are
already looking on the up: only three errors in in_win.c. I'm not looking
forward to vid_win.c (ex vid_wgl.c), though.
The ~ gets expanded to CSIDL_LOCAL_APPDATA, $HOME, $USERPROFILE or just
".", whichever succeeds first. The usual location will be:
"C:\windows\profiles\<user>\Local Settings\Application Data".
"." is now the fallback for *nix systems too.
The seed is currently 0xdeadbeef, but I intend on fixing that soon. Now the
particle velocities and origins use fully independent bits (though a big
chunk is wasted right now).
This gives QF a consistent qualilty PRNG on all platforms. The
implementation is slightly different from the standard, but gives the same
results for the same speed (details in mersenne.c).
This is a quick fix until I get a random number generator into QF.
Mingw's RAND_MAX is only 0x7fff and so the (((rnd >> 10) & 63) - 31.5) / 63.0
used for the z component of origin and velocity would never go positive.
For now, change the 10 to 9 (reusing another bit from Y). I plan on
implementing a full 32-bit PRNG in QF so we always have a reliable
generator.
It was pointed out by Blub\w (gmqcc) that OP_MUL_FV and friends were buggy
when the operands overlapped (eg, x = x.x * x) as the result would become
'x.x*x.x x.y*x.x*x.x x.z*x.x*x.x' (note the x.x squared for y and z). On
testing, sure enough the bug was present (and is a nice demonstration that
QF's VM does NOT have strict-aliasing bugs). As a very nice benefit: the
code produced by the fixes is actually faster than the broken version :).
The ruamoko code used for testing:
void (string fmt, ...) printf = #0;
vector foo (vector x)
{
x = x * x.x;
return x;
}
vector bar (vector x)
{
x = x.x * x;
return x;
}
int main ()
{
vector x = '2 3 4';
vector y = foo (x);
vector z = bar (x);
printf ("x=%v y=%v z=%v 2*x=%v\n", x, y, z, 2*x);
return 0;
}
Now the user can create and destroy IMTs at will, though currently
destroying IMTs is currently all or nothing (imt_drop_all).
An IMT is created via imt_create which takes the keydest name (key_game
etc), the name of the IMT (must be unique for all IMTs) and optionally the
name of the IMT to which the key binding search will fall back if there is
no binding in the current IMT, but must be already defined and on the same
keydest. This means that IMTs now have user determined fallback paths. The
requirements for the fallback IMT prevent loops and other weird behaviour.
Actual key binding via in_bind is unaffected. This is why the IMT name must
be unique across all IMTs.
The "imt" command works with the key_game keydest, but imt_keydest is
provided for specifying the active IMT for a specific keydest.
At startup, default IMTs are setup to emulate the previous static IMTs so
old configs will continue to work (mostly). New config files will be
written with commands to drop all of the current IMTs and build new ones,
with the bindings and active IMT set as well.
This fixes the status bar refresh issues in sw. The problem was that with
two viddef's hanging around, things got a little confused and recalc_refdef
wasn't getting into the renderer.
in_clear <imt>... where each argument to in_clear is an imt identifier. If
any identifiers are incorrect, the incorrect ones will be displayed and no
tables will be cleared. All or nothing.
It seems that SDL_SetColors causes a page flip, so VID_SetPalette only
queue a palette change (by checking for the need to change and storing the
requested palete) and VID_Update now checks for a queued palette change and
updates SDL's palette if required. This fixes the flickering console in sw
-sdl introduced by the cshift/centerprint change.
Need to up the precision by one due to the difference between g and e, but
much prettier. Might need to rename that function :P I wish I'd thought to
check if g would work, but thanks to divVerent for the suggestion.
