give vid_fbdev VID_SetGamma
mame vid_common_gl and vid_common_sw of their gamma code (vid_common_sw is
now empty:/)
rewrite VID_InitGamma to do the right thing with cvars with callbacks
gl clients have [temporarily?] lost the CVAR_ROM on vid_gamma
snd_dma.c, {nq,qw}/source/cl_parse.c:
change the type of snd_worldmodel from * to ** and init snd_worldmodel
with the ADDRESS of cl.worldmodel so its changes get seen by snd_dma
snd_mixa.S:
picize
it seems somebody forgot to commit this. just compied direct from qw
libs/video/targets/.gitignore:
better ignore rules
nq/source/Makefile.am:
libqfsys.a is dead :)
the rest:
gamma compile fixes
configure.in:
foo/Makefile MUST come before foo/bar/Makefile or foo/bar will NOT be
created.
libs/*...*/Mkaefile.am: add INCLUDES so $(top_scrdir)/include gets searched
{qw,nq}/source/Makefile.am: fix fbset compiling (and cleaning for nq)
egg temporarily until easter - They'll randomly choose between 255
colors. I'll eventually change this into a cvar, but for now enjoy ;)
This stuff is easily removed for the people who don't like colors: Just
remove my added lines, and uncomment the old ones :)
Misty-chan
gl_dyn_part.c:
Now uses a (non-locked) vertex array to reduce GL calls.
Gives a slight speed gain, I'll optimize it a bit more soon.
gl_rlight.c:
Fixed much of the dlightframecount issues.
(This gives cleaner code and a speed up.)
gl_rmain.c: A slight reorg of the dlight call order.
gl_rmisc.c: Enable some of the vertex arrays. (vertex, texcoord, color.)
gl_rsurf.c:
Reworked R_BuildLightMap, smaller now code wise, also more optimized,
and it builds a 0-2 lightmap in more cases now.
Playing with GL_UploadLightmap.
For non-lighthalf non-mtex lightmaps use a 0-2 range.
(Makes gl_lightmode look a /lot/ better.)
gl_screen.c: More stuff with the gl_lightmode callback.
r_view.c: R_PushDlights is called elsewhere now.
sw_rmain.c:
Moved the R_PushDlights call.
Also killed the unused PASSAGES define.
are now sane and match current code, I moved things around in GL so they
more closely match the sw code, as the sw code makes more sense now that
I *finally* understand what in gods name I was doing wrong. ;)
I also made minor changes to the help to indicate the minimum values of
the variables (sw can deal with 1, gl 0) as well as that you really
ought to use r_particles 0 instead of a setting of cl_max_particles 0 in
GL :P
Thanks for all the help taniwha, those last two bugs were kicking my
butt.
Misty-chan
cl_max_particles now lives in *part.c - in GL it dynamically changes the
amount of particles on the fly! Needless to say this is fun, and this is
proboably the third cvar that uses the callbacks function at all - which
IMHO is really a cool trick Taniwha.
However I'm losing my SANITY in r_part.c - if someone could take a look,
I'd be greatly appreciative. It should be obvious to any developer that
I'm having a few problems. :P Basically the dynamic code is completely
and totally disabled, and I hacked in code which *works* but shouldn't
EVER EVER EVER be left there after we fix this as it is downright EVIL
the way I implimented it. SW client does work, and does still work with
+set cl_max_particles - however the hacks I made to get it to do that...
*shakes head* Tread softly in there, it's a mess.
Other notes of interest:
I changed show_time so it archives its setting. Got annoyed with it. If
someone finds this change to be bad, change it back. :)
glspeed.cfg got updated with a setting of 60 for cl_max_particles. 60
works nicely, and doesn't use too much speed on my aging hardware, so
I'm sure newer systems will just plain FLY with this on.
I also changed the cl_maxfps setting as 72 is great if you aren't using
a modem !.! due to the way cl_maxfps works, the higher it goes, the more
data is sent to you by the server. This causes a heck of a lot of lost
packets if you don't have the bandwidth OR if your card can't keep up
with the framerate. Either of which is bad. I set it to 30, the default
of the cvar is 0/32 so go figure out what works best for you I say.
Let me know if this blows up in your face and ESPECIALLY let me know if
you can fix the r_part.c problems!
Misty-chan
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.)
