And fix an error in floatview.
The z-transform program is so I can test out my math and eventually
develop some hopefully interesting sound generators.
The editor now uses the vertical scrollbar for handling mouse wheel
scrolling, thus keeping the scrollbar in sync.
Scrollbar index can now cover the full range (not sure why I had that
-1), and the potential divide by zero is avoided properly.
Thumb-tab now positioned properly when the range is 0.
This gets all the basic cursor motion from my old editor working.
arrow keys: left/right/up/down char/line
home/end: beginning/end of line
page up/down
and ctrl versions where left/right are prev/next work, up/down skip over
indents, home/end are beginning/end of screen, and page up/down are
beginning/end of text.
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.
Currently, home always moves the cursor to the very first column, but
I'm considering making it move the cursor to the first non-space
character of the line if it's not already there, otherwise to the first
column (ie, the cursor will toggle between the two positions if it's in
one of them).
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.
Basic arrow key motion, and it's currently limited to not scrolling
horizontally (need to figure out how to handle max scroll), but this
also fixes the cursor handling on focus switching :)
For now, just bsearch (normal and fuzzy), qsort, and prefixsum (not in
C's stdlib that I know of, but I think having native implementations of
float and int prefix sums will be useful.
While qfcc will always align double values to 8 bytes (really, two
global words) regardless of the underlying hardware, gcc does not:
doubles are only 4-byte aligned on 32-bit hardware.
This fixes the invalid debug target handle when running on i686.
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.
This is the first step towards component-based entities.
There's still some transform-related stuff in the struct that needs to
be moved, but it's all entirely client related (rather than renderer)
and will probably go into a "client" component. Also, the current
components are directly included structs rather than references as I
didn't want to deal with the object management at this stage.
As part of the process (because transforms use simd) this also starts
the process of moving QF to using simd for vectors and matrices. There's
now a mess of simd and sisd code mixed together, but it works
surprisingly well together.
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 can't say that I like what's there even now, but at least PLItem can
be used without a lot of casting. Really, Ruamoko needs dictionary and
string classes so reading a property list can build more natural object
trees rather than this mess from when I knew too little.
