I have no idea why it was necessary, and certainly should not be now as
any such portability issues should be tucked away such that the client
code never sees such.
Everything is set up so default recipes work as expected (by me) for a
3Dconnexion SpaceNavigator:
translation axes move quakeguy in the direction the puck is moved
tilting the puck forward pitches forward (look down)
tilting the puck to the left rolls to the left
twisting the puck clockwise (looked at from the top) turns quakeguy
to the right.
This does mean that the default pitch motion for a regular mouse is now
push forward to pitch forward (look down) (inverted from before).
Mouse scaling is out (too small), but that's because in_amp etc are
ignored for now (thinking about how to integrate cvars with axis
recipes). Joystick input will be the same.
There's now an internal event handler for taking care of device addition
and removal, and a public event handler for dealing with device input
events in various contexts In particular, so the clients can check for
the escape key.
Saving is not so important, but for loading, while the input system
doesn't make much use of cvars at this stage, it makes sense for them to
be loaded before the input system configuration is loaded.
The mouse bound to movement axes works (though signs are all over the
place, so movement direction is a little off), and binding F10 (key 68)
to quit works :)
This has smashed the keydest handling for many things, and bindings, but
seems to be a good start with the new input system: the console in
qw-client-x11 is usable (keyboard-only).
The button and axis values have been removed from the knum_t enum as
mouse events are separate from key events, and other button and axis
inputs will be handled separately.
keys.c has been disabled in the build as it is obsolute (thus much of
the breakage).
kbutton_t is now in_button_t and has been moved to input.h. Also, a
button registration function has been added to take care of +button and
-button command creation and, eventually, direct binding of "physical"
buttons to logical buttons. "Physical" buttons are those coming in from
the OS (keyboard, mouse, joystick...), logical buttons are what the code
looks at for button state.
Additionally, the button edge detection code has been cleaned up such
that it no longer uses magic numbers, and the conversion to a float is
cleaner. Interestingly, I found that the handling is extremely
frame-rate dependent (eg, +forward will accelerate the player to full
speed much faster at 72fps than it does at 20fps). This may be a factor
in why gamers are frame rate obsessed: other games doing the same thing
would certainly feel different under varying frame rates.
For now, the functions check for a null hunk pointer and use the global
hunk (initialized via Memory_Init) if necessary. However, Hunk_Init is
available (and used by Memory_Init) to create a hunk from any arbitrary
memory block. So long as that block is 64-byte aligned, allocations
within the hunk will remain 64-byte aligned.
The fact that numleafs did not include leaf 0 actually caused in many
places due to never being sure whether to add 1. Hopefully this fixes
some of the confusion. (and that comment in sv_init didn't last long :P)
This fixes some out-by-one bugs caused by there being an obo bug in the
original SV_CalcPHS: space was being allocated for numleafs leafs, but
numleafs does not count the world-surrounding solid leaf 0, but
SV_CalcPHS generates pvs and phs data (just the "everything" set) for
leaf 0, which is later used for broadcasts and the like.
Hunk_Alloc has a rather large per-block overhead. Also, small pvs sets
(64 leafs) will fit into just the basic set structure so no need to
allocate data for the maps.
Modern maps can have many more leafs (eg, ad_tears has 98983 leafs).
Using set_t makes dynamic leaf counts easy to support and the code much
easier to read (though set_is_member and the iterators are a little
slower). The main thing to watch out for is the novis set and the set
returned by Mod_LeafPVS never shrink, and may have excess elements (ie,
indicate that nonexistent leafs are visible).
The idle scale was 114.591559 time too big (forgot both half angle for the
quaternion and converting from degrees to radians for the idle rotations).
Also, take the intermission view position and rotation direct from the
player entity, not viewstate, as while viewstate.origin is the same,
viewstate.rotation is the player's input, not the rotation set by the
server. Fixes the unlocked view angle.
The recent changes to key handling broke using escape to get out of the
console (escape would toggle between console and menu). Thus take care
of the menu (escape) part of the coupling FIXME by implementing a
callback for the escape key (and removing key_togglemenu) and sorting
out the escape key handling in console. Seems to work nicely
This sorts out the unwanted use of R_EnqueueEntity, which will help with
removing another global (r_ent_queue), which is necessary for threaded
multi-pass rendering (ie, shadows).
The renderer's LineGraph now takes a height parameter, and netgraph now
uses cl_* cvars instead of r_* (which never really made sense),
including it's own height cvar (the render graphs still use
r_graphheight).
Ping ack (A2A_ACK) is always a 1-byte packet, so check that the A2A_ACK
is the only byte in the packet before passing the packet to the server
list code. Fixes the mysterious dropped packet every 256 packets as the
low eight bits of the packet's sequence number equalled A2A_ACK.
The uptime display had not been updated for the offset Sys_DoubleTime,
so add Sys_DoubleTimeBase to make it easy to use Sys_DoubleTime as
uptime.
Line up the layout of the client list was not consistent for drop and
qport.
conwidth and conheight have been moved into vid.conview (probably change
the name at some time), and scr_vrect has been replaced by a view as
well. This makes it much easier to create 2d elements that follow the
screen size (taking advantage of a view's gravity) which will, in the
end, make changing the window size easier.
This refactors (as such) keys.c so that it no longer depends on console
or gib, and pulls keys out of video targets. The eventual plan is to
move all high-level general input handling into libQFinput, and probably
low-level (eg, /dev/input handling for joysticks etc on Linux).
Fixes#8
QF now uses its own configuration file (quakeforge.cfg for now) rather
than overwriting config.cfg so that people trying out QF in their normal
quake installs don't trash their config.cfg for other quake clients. If
quakeforge.cfg is present, all other config files are ignored except
that quake.rc is scanned for a startdemos command and that is executed.
Only 64-bit windows is tested, and there are still various failures, but
QF is limping along in windows again.
nq-sdl works for sw, and sw32, gl and glsl are mostly black (but not
entirely for gl?), vulkan is not supported with sdl.
nq-win works for sw and sw32, and sort of for vulkan (very dark and
upside-down?). gl and glsl complain about vid mode,
qw-client-[sdl,win] seem to be the same, but something is wrong with the
console (reading keyboard input).
While this caused some trouble for pr_strings and configurable strftime
(evil hacks abound), it's the result of discovering an ancient (from
maybe as early as 2004, definitely before 2012) bug in qwaq's printing
that somehow got past months of trial-by-fire testing (origin understood
thanks to the warning finding it).
