This fits in nicely with the rest of the generic type system and makes
it a little more useful. The idea is it will take a return type (already
does since type functions always require a parameter at this stage) and
a parameter list (not implemented yet). It currently resolves to the
basic void (...) function type for QC.
IN_UpdateAxis (for nice handling of axis updates, especially relative
motion for mice) and IN_Binding_HandleEvent because registering an event
handler blocks qwaq's internall call to IN_Binding_HandleEvent.
It turns out the parameter pointer save/restore I had done for detoured
functions is required for all nested calls. However, I had actually
completely forgotten about it. I updated the docs for that section.
While it breaks my little toy game I've been working on (long overdue,
really) and my test scene, at least now qwaq is a little more
independent of quake.
The config is a pre-parsed property list. Currently unsupported by
anything but Vulkan (but only a warning is given, not a hard error at
this stage), and Vulkan doesn't use it yet.
It was a right cow to get working at all due to the tangled mess of
dependencies between different hierarchies (switching to hierarchies as
components helpt), but other that some vertical positioning (paragraphs
and descenders), it's working fairly well now (and fairly quick other
than I think I need to ensure the shaping cache is used).
This is for scroll boxes (the nesting of canvases is for the clipping
they provide). There are some issues with automatic layout, but this
gets things mostly working, in particular the management of the link
between hierarchies as a canvas is always the root of its hierarchy.
This fixes the upostop-- test by auto-casting implicit constants to
unsigned (and it gives a warning for signed-unsigned comparisons
otherwise). The generated code isn't quite the best, but the fix for
that is next.
Also clean up the resulting mess, though not properly. There are a few
bogus warnings, and the legit ones could do with a review.
This relies on my fork of tracy: https://github.com/taniwha/tracy
on the wip-c-vulkan branch. Everything is still rather flaky though.
This necessitated the jump to vulkan 1.2 as a requirement.
Tracy is a frame profiler: https://github.com/wolfpld/tracy
This uses Tracy's C API to instrument the code (already added in several
places). It turns out there is something very weird with the fence
behavior between the staging buffers and render commands as the
inter-frame delay occurs in a very strangle place (in the draw code's
packet acquisition rather than the fence waiter that's there for that
purpose). I suspect some tangled dependencies.
It's there just to work around automake and libtool requirements for
EXEEXT but allowing qfcc to build menu.dat directly. Maybe someday I'll
come up with a better way.
sincos is just a wrapper around the GNU libc sincos. sincosh is the
equivalent for sinh and cosh, but there doesn't seem to be any such
function, so it's just the two wrapped. They both return their results
in a vec2/vec2d as (sih[h], cos[h]).
It's usually desirable to hide the cursor when playing quake, but when
using the console, or in various other states, being able to see the
cursor can be quite important.
Two variables declared as arrays (same size) of different typedefs to
the same base type have their type encodings both pointing to the same
short alias.
From vkgen:
51d3 ty_array [4={int32_t>i}] 207f 0 4
51d9 ty_array [4=i] 1035 0 4
51df ty_alias {>[4=i]} 16 51d9 51e6
51e6 ty_array [4={uint32_t>i}] 2063 0 4
51ec ty_union {tag VkClearColorValue-} tag VkClearColorValue
4ca0 0 float32
51df 0 int32
51df 0 uint32
uint32 should use 51e6 and int32 should use 513d,
Following the suggestions of Hamish Todd, group 0 forms the planar
quaternions (with the "complex number" in the first two components) and
transflections in group 1.
e0 is created only if there are null vectors in the algebra, and the 3d
and 2d basis groups have been rearranged to compensate in the changed
ordering in the basis blade array.
I was aware in the beginning that the signs were probably incorrect, but
I had left them as I wasn't sure how they worked. Thanks to enki
(bivector community), I was pointed in the right direction for getting
the calculations right: the product of a basis blade with its dual
(x !x) must product the positive pseudo-scalar.
I guess I had forgotten that new_mv() does *NOT* initialize the
components. Things just happened to work (usually) because memory was
not getting recycled.
According to enki (bivector community) when there are more than one null
vector in a geometry, usually all vectors are null, and it was what to
do with multiple null vectors that caused me to balk at using e0 for the
null vector. However, using e0 for the null vector makes life much
easier, especially as that's what most of the literature does. There
are plenty of places, particularly in layout handling, that still need
adjustment for the change, but things seem to work (minus duals, but
they were broken in the first place, thus the discussion with enki).
