remove includes of qdefs.h and compat.h
pr_comp.h:
merge pr_comp.h from quake and qfcc, removing the copy in qfcc
cmdlib.[ch]:
nuke the endian code.
qendian.c:
initialise the LittleLong etc pointers at compile time rather than run
time
com.c (both nq and qw):
nuke the LittleLong etc init code
everything else:
fix up after the qtypes.h cleanup
however I've removed the stupid limits that I'd accidentally left behind
in my panic to comment out the messed up code in r_part.c so software
clients now can use a setting of zero. Particles in sw clients will not
default to 2048 if you use a number less than 1 - it will now use 0.
Otherwise, I made comments to myself for when I actually fix this and
cleared up some silliness in comments I'd made. Nothing special.
Special note: To use cl_max_particles *right now* you can either set it
while playing and then restart the client (I think this should work,
it's archived. May not however) Or do this which I absolutely am
*positive* works:
clientname othercommands +set cl_max_particles number othercommands
So, again, while changing in game does not work, it at least is still
useful somewhat.
Misty-chan
I goofed up my code. cl_max_particles will not dynamically update with
this change, but ATM, this is safer until I can grok what I need to know
to fix the code I wrote.
Sorry guys,
Misty-chan
new cvar: cl_max_particles. This cvar is archived, has no lower or
upper limits (well, less than 1 is not allowed) and can be changed in
game at any time.
BUGS:
Only one so far. I can't figure out why it's doing this, but in software
clients, (well, at least X11) if you set it to 1 particle, it acts like
you set it far higher. 2 acts like you set it to zero... Or maybe
it's showing 2 and I just can't see it on my 320x200 window. In any
case, the vagary must be something in the software particles code,
because I basically used the same code from the GL particles code for
this as I used for the software renderer.
If nobody can find fault with my code, I'll just make a special note in
the console help.
In any case, let me know of any problems.
Misty-chan
slight api change: the getkey and free functions now take a user data
parameter (which is an aditional parameter to Hash_New.
cmd.c, cvar.c, quakefs.c:
clean up the resulting errors.
pr_edict.c:
use hash tables for lookups of function, global and field definitions.
should speed things up a bit, ESPECIALLY when type checking is enabled.
thinks:
o Full progs modularity
o CSQC should now be just a matter of creating the builtin functions and
loading the code.
o total independence from progs globals, functions and entity field layouts
on the conditoin that their definitions have not been stripped from the
progs file.
o optional (though currently forced on) type checking on access to progs
entity fields from C
o the progs engine is fully shared between nq and qw.
(or now unconditionally nothing since I killed the menu), it works as the
console. In the future, when the new menu is implemented, it will fall
back to console if there's a problem with the menu (like there isn't one.)
progs globals and edict fields accessors, but I'm not so sure that's the cause
of the run-time error:
SV_Error: SV_ModelIndex: model progs/player.mdl not precached
Fatal error: SV_Error: SV_ModelIndex: model progs/player.mdl not precached
I suspect I failed to find the spawn function.
use of Con_Printf in the code and it was appropriate for logging anyway.
As a result, Con_DPrintf now uses Con_Print directly for a slight speedup
there having two layers of function calls and varargs parsing to get to
the console. Also ran the file through indent while I'm at it.
subsystem in favor of Cvars*. These new cvars are:
o snd_device defaults to "" which selects the default device of the system
(eg, plug:0,0 for ALSA 0.9 or /dev/dsp for OSS)
o snd_rate defaults to 0 which selects the system default rate.
o snd_bits defaults to 0 which selects the system default bit depth.
o snd_stereo defaults to 1 (0 is mono)
* actually, not that thorough: alsa and oss only. The rest have just ws :/
nq for abyss etc (ie, the magical -<mod> args).
The interface to the message subsystem got a revamp and all the mods to the .c
files reflect this. currently a little ugly, but I plan on abstracting msg
further to clean it up and make it more oo.
checksum.c) and then move the resutlting checksum.c into libs/utils
ditching nq's. Due to net_com.c, qw's libqfnet.a will need to be deleted or
you will get duplicate symbol link errors. Also merge crc.[ch] and move
qfplits.[ch] to their final homes. Also, remove a slightly overzealous use
of "static" in qfplist.[ch].
New naming convention, all libs will be libqf<subsys>.a (should we instead
use libQF<subsys>.a?). The .so libs, when we get to them, will have to be
sorted out then.
give you a little more screen real-estate. It does, but you still have a
big gun blocking most of your screen in the center. If you turned off the
HUD, you got more screen and less gun. That now happens whenever the HUD
is displayed.
This is a temporary measure. At a later point, the gun will always be at
the bottom of the view area regardless of fov.
defaults in non-win32 targets. BASEDIR/SKINBASE are gone and the Cvars
which use them in the code are just given the oldstyle defaults now. Use
of "base" is gone. It was a half-assed solution to a problem that doesn't
exist yet. When it finally does exist, we'll fix it right.
ever used were CVAR_NONE, CVAR_ARCHIVE, CVAR_USERINFO, CVAR_SERVERINFO,
CVAR_ROM, and CVAR_USER_CREATED. I kept CVAR_NOTIFY and CVAR_LATCH as
well since the latter was supposed to actually be implemented at some
point and the former would make a useful debug feature.
cougar-(qw|nq)-cl-*
cougar-(qw|nq)-sv
If someone really wants to a S&R on cougar in configure.in and the two
Makefile.am files will change it to something else.
Bill Currie
Adam Olsen
Jeff Teunissen
Chris Ison
Timothy C. McGrath
Forest Hale
Ragnvald Maartmann-Moe IV
Joseph Carter
Zephaniah E. Hull