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.
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).
This fixes the infinite loop in Sock's shadows mode. Thanks to Spike for
helping me with what should be happening. However, we're still uncertain
about just how the thinktime/sv.time logic should behave.
The change to nq SV_RunThink to match that in qw finally bit my bum. I
suspect it's really a bug in the honey progs (using ltime on a non-pusher),
but QF locking up is not very friendly. I want to keep the option of having
a think loop in the same frame for progs that expect it (using
self.nextthink = time), but also NQ's original method of running think
every frame. Hopefully no progs expect "self.nextthink = time" to run
every frame rather than loop within the current frame.
Now it doesn't matter if you get 22 fps or 72, you jump the same height,
which actually happens to be slightly higher than the previous 72fps jump.
Effectively, you jump the height you would if you got infinite fps ;)
This seems to have been an optimization for QW since standard qw removed
monsters. However, since there are QW mods that brought back monsters,
this should be an improvement.
Same as the rotating entities in NQ. Unfortunately, I have some problems
with certain entities doing really weird things during collisions. I'll
sort that out later.
It seems that QW already allowed explode-box jumping, but this makes code a
little more consistent. Still need to figure out what to do about the
player physics code: the client prediction is wrong, though the server gets
it right (before the change).
nq's SV_CheckVelocity will be a little different (spherical rather than
cubical), but sv_maxvelocity defaults high enough for it to not matter to
most players. It might even improve play.
The remaining differences need some careful thought before the physics
merge is done.
all (or most, there are limits still) of the maps on a server with many
maps.
move the optional progs funcs into sv_funcs_t and add UserInfoChanged,
ChatMessage and LocalinfoChanged callback support.
clean up PF_setinfo (and SV_SetInfo_f and SV_Localinfo_f) using shared code
where possible und to use the UserInfoChanged and LocalinfoChanged
callbacks.
add chat message callback to SV_Say. if it returns zero, normal chat
handling is done, otherwise it's assumed to have been handled by the progs.
provide a hook for unkown user commands. non-zero return means it's been
handled.
physics and progs, that's what sv.time is for. Things seem to work nicely,
including map changing, and this /should/ make long uptime servers work so
long as the map gets changes occasionally.
code cleanups and general performance work to be developed in relative peace.
While cleaning up the networking code /is/ important, fixing QF's perfomance
issues is of much higher priority.
