Because demoplayback seen by the shared client code is in viewstate and
that's in cl, it gets set to 0 when connecting, thus the network icon
while playing demos.
With the hierarchy code fixed for intra-hierarchy parenting, there's no
longer any need to first pull the sub-hierarchy out of the main
hierarchy before changing the parent, resulting in less memory churn.
Setting the parent to another object in the same hierarchy still causes
a segfault (worked around for now), but the mangled views were caused by
View_UpdateHierarchy not being called prior to the first call to
set_hud_sbar (why, though? I suspect something to do with oldlen). And
ECS_SortComponentPool finally gets used to ensure the sbar panels are
behind the info pics.
Frags, minifrags and miniteam now work (mostly, the auto-switching
between them is not working yet). Switching between hud and sbar is
mostly working, except for some problems with the hierarchies corrupting
themselves: setting the parent of an object to another object in the
same hierarchy is just completely broken, and working with complex
hierarchies seems to mess up something (things getting out of phase). I
guess my unit tests were too simple.
For nq, all that remains is the various overlays (death-match,
intermission and finale) and rogue and hipnotic specific updates.
Fortunately, other than the death-match overlay, qw is just a subset of
nq for the hud (and even then, I imagine the info in qw would be nice in
nq).
While the word-level text objects aren't used (because standard center
print messages are already flowed as such), using a passage object makes
dealing with the lines and incremental printing quite easy and
efficient (everything is counted just the once or twice, not every frame).
Most of the update functions are scheduled by Sbar_Changed() using
tables to determine what update functions need to be called for which
view entities. As hud_updateonce is called, and an entity can have only
one of any component, this becomes a set of updates to call when during
hud/sbar rendering.
This includes moving the related cvars from botn nq and qw into the
client hud code. In addition, the hud code supports update and
update-once function components. The update component is for updates
that occur every frame, but update-once components (not used yet) are
for one-shot updates (eg, when a value updates very infrequently).
Now only the time portion updates every frame, and then only when the
scores are shown (no real change for that one). Not really a significant
optimization, as the information was updated only while the scores were
shown, but it's still nice.
Much of the nq/qw HUD system is quite broken, but the basic status bar
seems to be working nicely. As is the console (both client and server).
Possibly the biggest benefit is separating the rendering of HUD elements
from the updating of them, and much less traversing of invisible views
whose only purpose is to control the positioning of the visible views.
The view flow tests are currently disabled until I adapt the flow code
to ECS.
There seems to be a problem with view resizing in that some gravities
don't follow resizing correctly.
While the libraries are probably getting a little out of hand, the
separation into its own directory is probably a good thing as an ECS
should not be tied to scenes. This should make the ECS more generally
useful.
This is the fix for the grenade explosion bug. It was rather difficult
to track down because *two* explosions are rendered for the one grenade
(but that's actually another bug due to the nq/qw merge). It's also
correct as changing the model can change the BSP leafs the entity
touches.
While chasing down the grenade explosion bug, I noticed that entities
were being created and destroyed (or really, not destroyed) just to
check of the entity was valid. In the old system, this wasn't
*horrible*, but with the ECS, it does mean entities and components are
getting churned up, which wouldn't be good for the entity generation
counter (only 12 bits).
This puts the hierarchy (transform) reference, animation, visibility,
renderer, active, and old_origin data in separate components. There are
a few bugs (crashes on grenade explosions in gl/glsl/vulkan, immediately
in sw, reasons known, missing brush models in vulkan).
While quake doesn't really need an ECS, the direction I want to take QF
does, and it does seem to have improved memory bandwidth a little
(uncertain). However, there's a lot more work to go (especially fixing
the above bugs), but this seems to be a good start.
This breaks console scaling for now (con_width and con_height are gone),
but is a major step towards window resize support as console stuff
should never have been in viddef_t in the first place.
The client screen init code now sets up a screen view (actually the
renderer's scr_view) that is passed to the client console so it can know
the size of the screen. The same view is used by the status bar code.
Also, the ram/cache/paused icon drawing is moved into the client screen
update code. A bit of duplication, but I do plan on merging that
eventually.
The scaling up of the volumes when setting a channel's volume bothered
me. The biggest issue being it hasn't been necessary for over a decade
since the conversion to a float-mixer. Now the volume and attenuation
scaling from protocol bytes is entirely in the client's hands.
This does mean that the gl and sw renderers can no longer call
S_ExtraUpdate, but really, they shouldn't be anyway. And I seem to
remember it not really helping (been way too long since quake ran that
slowly for me).
More host cleanup. The client now processes input itself, as does the
server, but only if running a dedicated server. The server no longer
blocks sound when loading a map as it shouldn't know anything about
sound. This will probably need something done in the client, but moving
the server into a separate thread will have that effect anyway.
The main goal was to get visframe out of mnode_t to make it thread-safe
(each thread can have its own visframe array), but moving the plane info
into mnode_t made for better data access patters when traversing the bsp
tree as the plane is right there with the child indices. Nicely, the
size of mnode_t is the same as before (64 bytes due to alignment), with
4 bytes wasted.
Performance-wise, there seems to be very little difference. Maybe
slightly slower.
The unfortunate thing about the change is the plane distance is negated,
possibly leading to some confusion, particularly since the box and
sphere culling functions were affected. However, this is so point-plane
distance calculations can be done with a single 4d dot product.
It was added only because FitzQuake used it in its pre-bsp2 large-map
support. That support has been hidden in bspfile.c for some time now.
This doesn't gain much other than having one less type to worry about.
Well tested on Conflagrant Rodent (the map that caused the need for
mclipnode_t in the first place).
This is a particularly ancient bug, sort of introduced by rhamph when he
optimized temp entity model handling and later exacerbated by me.
However, I suspect the actual problem is limited to nq as qw's gamedir
handling would have caused the models to be reloaded, but nq doesn't
ever change game directories once running.
I got tired of being disappointed that nq didn't have colored lights for
the power-ups (especially when I'd waste time thinking it was a bug).
The problem is that the server (progs code) specifies only DIMLIGHT (qw
adds in the colors). Another problem is that the server tells us only
our own stats, so the colors are disabled for multiplayer otherwise it
might be confusing.
I really need to play more while working on the code.
Anyway, ca_active works nicely for the status bar in general, and
CL_ClearMemory needs to be called before Host_ClearMemory when doing
single-player.
Nasty because it was caused by spaghetti (normally, I like the stuff).
Drinking-age spaghetti at that. Nicely, this removes the need for one
function in sv_ded.c (which is what I think I was trying to achieve).
The error was introduced by the input memory leak fixes, but the
solution is to ensure CL_Shutdown is called before IN_Shutdown.
Some of the memory leaks were quite legitimate this time.
This replaces *_NewMap with *_NewScene and adds SCR_NewScene to handle
loading a new map (for quake) in the renderer, and will eventually be
how any new scene is loaded.
This fixes an illegible server message error on going through a teleport
in the start map (how I noticed the problem). Funnily enough, I had
spotted the mistake when editing the qw version, but forgot to correct
the nq version.
pr_type_t now contains only the one "value" field, and all the access
macros now use their PACKED variant for base access, making access to
larger types more consistent with the smaller types.
The misinterpretations were due to either the cvar not being accessed
directly by the engine, but via only the callback, or the cvars were
accesssed only by progs (in which case, they should be float). The
remainder are a potential enum (hud gravity) and a "too hard basket"
(rcon password: need to figure out how I want to handle secret strings).
This is an extremely extensive patch as it hits every cvar, and every
usage of the cvars. Cvars no longer store the value they control,
instead, they use a cexpr value object to reference the value and
specify the value's type (currently, a null type is used for strings).
Non-string cvars are passed through cexpr, allowing expressions in the
cvars' settings. Also, cvars have returned to an enhanced version of the
original (id quake) registration scheme.
As a minor benefit, relevant code having direct access to the
cvar-controlled variables is probably a slight optimization as it
removed a pointer dereference, and the variables can be located for data
locality.
The static cvar descriptors are made private as an additional safety
layer, though there's nothing stopping external modification via
Cvar_FindVar (which is needed for adding listeners).
While not used yet (partly due to working out the design), cvars can
have a validation function.
Registering a cvar allows a primary listener (and its data) to be
specified: it will always be called first when the cvar is modified. The
combination of proper listeners and direct access to the controlled
variable greatly simplifies the more complex cvar interactions as much
less null checking is required, and there's no need for one cvar's
callback to call another's.
nq-x11 is known to work at least well enough for the demos. More testing
will come.
