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).
Lexing . as a single character makes it impossible to enter fractions.
Unfortunately, this means that . as dot product requires white space on
either side.
Currently only PGA(3) is supported, but that's because the parser is
rather simple (recursive descent with a lame lexer), but it works well
enough for playing with geometric algebra without having to recompile
every time.
Wrap the strtod, strtof, strtol, strtoul functions, supporting the end
pointer as well (if not nil, the int offset of the end pointer relative
to the string start is returned).
Also, str_unmutable creates a return string from a mutable string
(copying it).
Meaning some leaks have been plugged, and some useful functions added:
loading a file (avoids polluting progs memory), setting the single
character lexeme string, and getting the line number.
I never liked the various hacks I had come up with for representing
resource handles in Ruamoko. Structs with an int were awkward to test,
pointers and ints could be modified, etc etc. The new @handle keyword (@
used to keep handle free for use) works just like struct, union and
enum in syntax, but creates an opaque type suitable for a 32-bit handle.
The backing type is a function so v6 progs can use it without (all the
necessary opcodes exist) and no modifications were needed for
type-checking in binary expressions, but only assignment and comparisons
are supported, and (of course) nil. Tested using cbuf_t and QFile: seems
to work as desired.
I had considered 64-bit handles, but really, if more than 4G resource
objects are needed, I'm not sure QF can handle the game. However, that
limit is per resource manager, not total.
This gives the resultant point the correct sign. Though the projective
divide would take care of the sign, this makes reading the point a
little less confusing (still need to sort out automatic blade reversals
for the likes of e31).
And other graphics versions too, of course. A lot of it feels rather
like a hack, but I think the entire canvas/console setup and console
related event handling may need a rethink (it's not horribly wrong, but
it doesn't feel right), particularly the initial sizing and binding for
toggling the console.
As the dot product is a metric product, using the metric is vital to
getting the correct results. This fixes the calculation of the closest
point on a line to a point other than the origin (and a whole pile of
other issues, I imagine).
Now that arrays work well enough for this case, no point in having the
workarounds (other than they're actually faster, but I'd like to
optimize *that* sometime).
