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 brings NQ's physics a little closer to QW's. After studying both the
original WinQuake source and the progs source, this change should be
harmless, making very little difference. However, it does allow an
entity's think function to be called multiple times in the same frame (for
when the entity needs more time to think, but it would cause runaway loop
errors). Maybe need a "runaway think" check.
If a tossed entity has ONGROUND set, it won't move, but if it has an upward
velocity, it can't possibly be ONGROUND, so clear the flag if the entity is
moving upwards.
See http://forums.inside3d.com/viewtopic.php?t=1675 for inspiration.
As this might break the gameplay of certain maps, the new sv_jump_any
cvar can be used to disable this feature (bringing back the old behavior).
This is based on the code presented on
http://forums.inside3d.com/viewtopic.php?t=2376 (and updates linked from
that thread), but with modifications for hopefully supporting rotating
trains (and not duplicating big fuctions).
For now, only nq. qw will come after some more testing.
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.
