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).
This is actually a better solution to the renderer directly accessing
client code than provided by 7e078c7f9c.
Essentially, V_RenderView should not have been calling R_RenderView, and
CL_UpdateScreen should have been calling V_RenderView directly. The
issue was that the renderers expected the world entity model to be valid
at all times. Now, R_RenderView checks the world entity model's validity
and immediately bails if it is not, and R_ClearState (which is called
whenever the client disconnects and thus no longer has a world to
render) clears the world entity model. Thus R_RenderView can (and is)
now called unconditionally from within the renderer, simplifying
renderer-specific variants.
This is the first step in the long-sought goal of allowing the window
size to change, but is required for passing on getting window position
and size information (though size is in viddef, it makes sense to pass
both together).
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).
Input Mapping Tables are still at the core as they are a good concept,
however they include both axis and button mappings, and the size is not
hard-coded, but dependent on the known devices. Not much actually works
yet (nq segfaults when a key is pressed).
For drivers that support it. Polling is still supported and forces the
select timeout to 0 if any driver requires polling. For now, the default
timeout when all drivers use select is 10ms.
I had forgotten that _size was the number of rows in the map, not the
number of objects (1024 objects per row). This fixes the missed device
removal messages. And probably a slew of other bugs I'd yet to encounter
:P
This is the simplest fix for the curses/input initialization order
issue. The terminal io code should still be moved to its own file,
really, but I think it can wait.
As it is now a completely separate sub-system, there is a bit of trouble
with mouse handling in that curses must be initialized before input for
the mouse to work properly, but the basic scheme seems to be working
nicely. I suspect the solution to the init order issue is to make have
the curses sub-system initialize the terminal input driver, at least for
mouse input (ie, maybe just enable/disable mouse handing).
The queues in the curses resources struct have been cleaned up and the
threading support code (including for the queues (pipes, really)) has
been moved to its own file.
The input test app currently just prints the devices and the events as
they come in, but demonstrates the new input system working in a
separate thread (though it is currently in with the curses thread).
The common input code (input outer loop and event handling) has been
moved into libQFinput, and modified to have the concept of input drivers
that are registered by the appropriate system-level code (x11, win,
etc).
As well, my evdev input library code (with hotplug support) has been
added, but is not yet fully functional. However, the idea is that it
will be available on all systems that support evdev (Linux, and from
what I've read, FreeBSD).
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.
qwaq-curses has its place, but its use for running vkgen was really a
placeholder because I didn't feel like sorting out the different
initialization requirements at the time. qwaq-cmd has the (currently
unnecessary) threading power of qwaq-curses, but doesn't include any UI
stuff and thus doesn't need curses. The work also paves the way for
qwaq-x11 to become a proper engine (though sorting out its init will be
taken care of later).
Fixes#15.
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
The word boundaries are currently vary simple, just transitions from
alnum_ (as it was in my old editor and in Borland's editors), but the
basic logic is working.
Support for finding the first address associated with a source line was
added to the engine, returning 0 if not found.
A temporary breakpoint is set and the progs allowed to run free.
However, better handling of temporary breakpoitns is needed as currently
a "permanent" breakpoint will be cleared without clearing the temporary
breakpoing if the permanent breakpoing is hit while execut-to-cursor is
running.
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.
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).
I never liked that some of the macros needed the type as a parameter
(yay typeof and __auto_type) or those that returned a value hid the
return statement so they couldn't be used in assignments.
It now takes a context pointer (opaque data) that holds the buffers it
uses for the temporary strings. If the context pointer is null, a static
context is used (making those uses of va NOT thread-safe). Most calls to
va use the static context, but all such calls have been formatted
consistently so they are easy to find when it comes time to do a full
audit.
I think I wasn't sure at the time whether the simple variable was
required for pthread_cond_wait (and friends) to work properly, but it
is: the time between the target posting the debug event and the target
waiting on the condition variable turns out to sometimes be enough for
the debugger to handle the event and signal the target to continue,
resulting in the target waiting on a signal that will never come because
another debug event will not be sent by the target until AFTER it has
exited from the debug handler.
Same issue as for the menus. But now I know why PR_LoadProgsFile is used
instead of PR_LoadProgs (at least for qwaq): avoidance of the gamedir
restriction (however, the menus are supposed to be restricted).
There's still some cleanup to do, but everything seems to be working
nicely: `make -j` works, `make distcheck` passes. There is probably
plenty of bitrot in the package directories (RPM, debian), though.
The vc project files have been removed since those versions are way out
of date and quakeforge is pretty much dependent on gcc now anyway.
Most of the old Makefile.am files are now Makemodule.am. This should
allow for new Makefile.am files that allow local building (to be added
on an as-needed bases). The current remaining Makefile.am files are for
standalone sub-projects.a
The installable bins are currently built in the top-level build
directory. This may change if the clutter gets to be too much.
While this does make a noticeable difference in build times, the main
reason for the switch was to take care of the growing dependency issues:
now it's possible to build tools for code generation (eg, using qfcc and
ruamoko programs for code-gen).
I decided that stopping in between function calls that are on the same
line is a good thing as it gives a chance to skip over the first but
step into the second.
This allows a debugger to do any symbol lookups and other preparations
between loading progs and the first code execution. .ctors are called as
per normal if debug_handler is not set.
While this does answer the question of how I'll go about restarting the
target progs (when I get to that point), it was required just to start
full-on ruamoko progs because .ctor was getting run in the main thread
and blocking due to trace.
This puts a print command (to Sys_Printf) into the queue making it
easier to check command sequences since regular printf is asynchronous
with the stream.
For now it just manages type encodings via their encoding string,
ensuring types are fetched from the target only once, if at all (may
already have the type due to it being common).
Things were getting rather cluttered with everything being qwaq-* and
all in one directory. Now most have lost the qwaq- prefix and have been
moved into subdirectories (non-recursive make).
