Sys_LongTime returns time in microseconds as a 64-bit int. Sys_DoubleTime
uses Sys_LongTime, converts to double and offsets 0 time by 4G (2**32).
This gives us consistent sub-microsecond precision for a very long time.
See http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/
The data needed for the checks has been gone from QF for a very long time
(since Jan 2000), and good riddance to it, really: I suspect it's in
violation of id's copyright on the game data (ok, it might be fair use, but
still...).
Something is funny with Ubuntu such that -ldl needs to be specifically
added even though QFutil's .la specifies it. I don't know if it's a libtool
issue or not, but this does work.
More will probably be necessary, but this was sufficient to get prover to
the point where qfcc segged building qwaq (0.7.2).
It is suffering some bitrot and I don't feel like fixing it right now, but
it causes problems for people trying to build QF. This should be ok because
it's one of those "if uncertain, say no" things.
Once and for all: remove the default and move the Sys_Error outside the
switch (changing appropriate breaks to returns). Now gcc will let me know
when I forget to update the switch statements.
I'd missed a set of bit->lightnum conversions that resulting in lightnum
becoming much greater than 128 and thus trashing memory when the surface
was marked.
hipdemo1.dem has a single leading space. They probably did "%2d" for the
track number, as there is no space before the minus sign in the other
hipnotic demos.
type_obj_class is no longer a class, so its ivars are not stored in
type_obj_class.t.class->ivars but rather type_obj_class.t.symtab.
This fixes the segfault Spirit and Randy were experiencing.
In passing, correct the unneeded emission of meta class ivars for non-root
classes. This should make for much smaller progs that use classes.
This give much better control over individual joystick axes. They now have
per-axis pre and post amplification, the linear controller mappings are
more intuitive, and axes can now bet setup as buttons using thresholds.
Many thanks to Johnny on Flame for his work on the "user interface".
Johnny's number->J_AXISn mapping is preserved, but I had intended for any
key to be supported (J_AXISn was just to ensure free keys were available).
This gives both methods (and some range checking on the axis button
number).
First, this completely smashes joystick input: it will not work (though it
doesn't crash). This is because there is, as of yet, no means to configure
the system.
Each joystick axis has:
- per-axis amplification (both pre and post).
- per-axis offset (offset applied after pre-amp but before post amp)
- selectable destination:
- linear delta: position and angles (as before)
- axis button: if the value crosses the threshold, the given key is
pressed or released as appropriate.
The axis amplification still uses joy_amp and joy_pre_amp (and
in_amp/in_pre_amp), but now also has the per-axis settings.
The per-axis offset is most useful for axis buttons. For example, the xbox
360 controller triggers are analong but go "all the way to negative on 0
state". Offsetting the input keeps axis button thresholds simple.
Amplification and offset is applied before anything is done with the axis
value. The formula is:
joy_amp * in_amp * axis-amp *
(offset + value * joy_pre_amp * in_pre_amp * axis-pre_amp)
Axis button thresholds are very simple: if the sign of the value is the
same as the sign of the threshold and abs(value) >= abs(threshold), the
button is pressed. While multiple thresholds and keys can be placed on an
axis, only one can be pressed at a time. The threshold furthest from 0
wins.
Bill Currie
Johnny on Flame