For certain values of "fix" ;). Both are brought back to life but
idealpitch is never set (always 0) and veiwheight is set in V_RenderView().
However, this brings the rest of the code in cl_view.c just that little bit
closer to merged :)
When the stufftext buffering was implemented, we forgot about
svc_serverdata...
While nq might normally not have the issue, I thought it best to implement
in nq, too.
I didn't like the way client/server code was poking around at the
implementation. Instead, provide a couple of accessor functions for the
same information.
nq now rejects anything that doesn't look like a .dem, and qw not only
rejects anything that looks like neither a .qwd nor a .mvd, but even
detects which one is being played by the contents rather than the file name
(foo.mvd.gz would be mis-detected as a qwd!!).
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 ;)
One's an actual bug, the other a bit of error checking (not sure how
necessary it is, but it's in code that we don't /want/ to run, so it can't
hurt :)
The renderer now gets initialized and things sort of work (qw-client will
idle, though nothing is displayed). However, as the viddef stuff is broken,
it segs on trying to run the overkill demo.
Still, nothing will work: no plugins are loaded and they're all broken
anyway.
glx, sgl, glslx etc are going away, just the basics will be built: fbdev
(probably go away eventually), sdl, x11 and hopefully someday win. That's
actually the only reason anything links.
Just about to do a release, and I realized windows users wouldn't have any
way of checking out the new renderer. I'll add wglsl when I get a chance to
do some testing.
o All instances of LIBADD/LDADD have a corresponding DEPENDENCIES
specificatiion.
o libraries now use a lib_ldflags macro to keep things consistent
o duplication of source/lib names has been minimized (particularly in
the libraries; more work needs to be done for the executables)
o automake spec blocks have been organized (again, more work needs to be
done for the executables)
Most subsystems that depend on other subsystems now call the init functions
themselves. This makes for much cleaner client initialization (more work
needs to be done for the server).
The renderer should now be free of any direct access to client code. Even
3d rendering is now done via a function pointer.
The cshift code is done as a 2d screen function.
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.
This has several benifits:
o The silly issue with alias model pitches being backwards is kept out
of the renderer (it's a quakec thing: entites do their pitch
backwards, but originally, only alias models were rotated. Hipnotic
did brush entity rotations in the correct direction).
o Angle to frame vector conversions are done only when the entity's
angles vector changes, rather than every frame. This avoids a lot of
unnecessary trig function calls.
o Once transformed, an entity's frame vectors are always available.
However, the vectors are left handed rather than right handed (ie,
forward/left/up instead of forward/right/up): just a matter of
watching the sign. This avoids even more trig calls (flag models in
qw).
o This paves the way for merging brush entity surface rendering with the
world model surface rendering (the actual goal of this patch).
o This also paves the way for using quaternions to represent entity
orientation, as that would be a protocol change.
After discussing things with Spike of FTE, it seems that not many clients
handle zero length mvd packets particularly well. While it the skip code
might be useful for qtv, getting the packets into one but not the other
seems to be not worth the effort at this stage.
There are some problems with menus and the console messing up the key_dest
state (they assume console/menu or game, nothing else), but otherwise
things seem to work.
I got rather tired of there being multiple definitions of mostly compatible
plane types (and I need a common type anyway). dplane_t still exists for
now because I want to be careful when messing with the actual bsp format.
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).
This also makes functionality consistent across the platforms, such as
adding support for -dedicated to sdl based nq, and various timing
calculations are now consistent.
As part of the work on getting nq to work on multi-homed nodes, I used the
existing recvmsg code in qw-master to check how things work. I figured it
might be worth keeping.
Since we clip the world properly even with skyboxes active, and the
'skybox' serverinfo doesn't do anything in any other engine I know of,
nuke the 'skybox' serverinfo entirely and use a nice short semi-standard
name ("sky") for the serverinfo containing the map's preferred skybox
(as potentially modified by the .ent file on the server).
This ensures that the map's sky is always used unless the client itself has
set its r_skyname cvar. The server's r_skyname cvar is now the default
name for the skybox for when the map does not specify one. The map's sky
worldspawn field overrides this. The r_skyname cvar is no longer a
serverinfo cvar.
in_dga -> 0 (until X is fixed)
gl_multitexture -> 1 (why was this 0? not enough support back then?)
cl_usleep -> 1 (seems to be ok)
host_mem_size -> 40 (even 32 isn't enough these days)
rate -> 10000 (we're not in the modem era any more)
cl_mem_size -> 32 (16 is not enough, 32 sounds better than 24)
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.
This allows the pvs to be used on an antity no matter how many leafs the
entity is touching. Seems to work nicely, but it will leak memory every
time a map is loaded.
This reverts commit 10232acdfe.
The problem was really in the trace code, but it got fixed by "accident"
when I had similar problems in hipnotic a couple of years later. Now to
figure out just what the trace could really should be doing.
The efrags system's usage of ent->visframe clashes with that of
CL_LinkPacketEntities. As the latter is rather bogus, and potentially
visible entities are always inserted into the map (causing ent->efrag to be
non-null), a null ent->efrag is a good indication that the entity is newly
visible.
