Instead of creating new entities for the text views. This approximately
halves the number of entities required to display flowed text, but also
tests the ability to have an entity in multiple hierarchies (the goal of
the ECS component and system changes).
Font and text handling is very much part of user interface and at least
partially independent of rendering, but does fit it better with GUI than
genera UI (ie, both graphics and text mode), thus libQFgui as well as
libQFui are built in the ui directory.
The existing font related builtins have been moved into the ruamoko
client library.
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 is meant for a "permanent" tear-down before freeing the memory
holding the VM state or at program shutdown. As a consequence, builtin
sub-systems registering resources are now required to pass a "destroy"
function pointer that will be called just before the memory holding
those resources is freed by the VM resource manager (ie, the manager
owns the resource memory block, but each subsystem is responsible for
cleaning up any resources held within that block).
This even enhances thread-safety in rua_obj (there are some problems
with cmd, cvar, and gib).
The palette is a modified version of the default VGA colormap as
explained by Noah Johnson (https://github.com/canidlogic/vgapal) and the
generation code is heavily influenced by his code. However, I've
reversed the HSV groups so I could have the pure bright colors in the
fullbright range and added a few colors in the 248-255 range (mostly
greens and ambers meant to be close to the old phosphor monitors).
The colormap is generated by laying the colors from the palette across
the middle of the map (rows 31 and 32) then linearly interpolating from
0 to the color, and the color to 2x the color (clamped) and then
converting back to a palette. Mr Fixit actually looks ok still in the
software renderer (unaffected in the others) though quakeguy is a hoot
in all the renderers :).
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.
The goal is to have somewhere to put entities so they can be rendered. I
suspect I could have used a bsp tree to partition space for frustum
culling, but it's probably not worth it at this stage (but shouldn't
require any changes to the engine: just the model).
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.
This is the bulk of the work for recording the resource pointer with
with builtin data. I don't know how much of a difference it makes for
most things, but it's probably pretty big for qwaq-curses due to the
very high number of calls to the curses builtins.
Closes#26
Now that the data is fetched from the correct location, the locals view
is useful again :). However, there seems to be a problem with array
views: not sure they're showing the correct data as I was getting
unexpected values in the display but normal vars seem to be ok.
It now takes the function name to print in error message (passed on to
PR_Sprintf) and the argument number of the format string. The variable
arguments (in ...) are assumed to be immediately after the format
argument.
or 512kW (kilowatts? :P). Barely enough for vkgen to run (it runs out if
auto release is run during scan_types, probably due to fragmentation). I
imagine I need to look into better memory management schemes, especially
since I want to make zone allocations 64-byte aligned (instead of the
current 8). And it doesn't help that 16 words per allocation are
dedicated to the zone management.
Anyway, with this, vgken runs and produces sufficiently correct results
for the rest of QF to build, so long as qfcc is not optimizing.
It doesn't do much good for dynamic progs memory because zone currently
aligns to 8 bytes (oops, forgot to fix that), but at least the stack and
globals are properly aligned.
This cleans up dprograms_t, making it easier to read and see what chunks
are in it (I was surprised to see only 6, the explicit pairs made it
seem to have more).
This is part of the work for #26 (Record resource pointer with builtin
function data). Currently, the data pointer gets as far as the
per-instance VM function table (I don't feel like tackling the job of
converting all the builtin functions tonight). All the builtin modules
that register a resources data block pass that block on to
PR_RegisterBuiltins.
This will make it possible for the engine to set up their parameter
pointers when running Ruamoko progs. At this stage, it doesn't matter
*too* much, except for varargs functions, because no builtin yet takes
anything larger than a float quaternion, but it will be critical when
double or long vec3 and vec4 values are passed.
Update qdb_get_string's mangling for qfcc's new unsigned int support and
fix an incorrect cast of the param pointer passed by prd_runerror that
caused a segfault when trying to use the string. Attempting to use
qwaq-app (ie, the qc debugger) on Ruamoko ISA progs mostly works, but
the defs are decidedly unhappy (due to the base registers).
Terminal apps effectively always have focus (unless I find a way to know
when an xterm loses/gains focus). Fixes input-app not updating on evdev
events.
They are both gone, and pr_pointer_t is now pr_ptr_t (pointer may be a
little clearer than ptr, but ptr is consistent with things like intptr,
and keeps the type name short).
It's very much a hack, but it will do for now until I can rewrite the
whole thing: it's not at all thread safe, but it is over eight years
old and has survived a lot of bit-rot.
And create rua_game to coordinate other game builtins.
Menus are broken for key handling, but have been since the input rewrite
anyway. rua_input adds the ability to create buttons and axes (but not
destroy them). More work needs to be done to flesh things out, though.
Until now, the new qwaq startup was used only in command-line tools and
console applications where things like Ruamoko security and having a
hunk were not an issue. Now the start up code (qwaq-*.c) can specify
that Ruamoko is to be secured and provide a hunk on a per-thread basis,
and the thread data is passed into the progs code via a progs resource.
It now uses the advanced command line parsing used by qwaq-curses and
qwaq-cmd, but currently disables multi-threading (I don't want to deal
with threading in the engine just yet). The int file is -graphics
because qwaq-x11 is really just the X11 target, qwaq-win is built for
windows, but they use the same basic startup (I hope).
This is needed for cleaning up excess memsets when loading files because
Hunk_RawAllocName has nonnull on its hunk pointer (as the rest of the
hunk functions really should, but not just yet).
