The player global branch variable is now updated with useful information
and the location.get builtin is available to return the current location
of the player based on loc files. Fixed a bug with zooming out in zoom.gib.
battles.
(Thank you Wildcode)
Once gl_lightmap_subimage's setting of 2 is debugged (right now it goes a
teeny tiny bit whacko) I'll be using that, just FYI.
Tim/Misty-chan
cl_max_particles got changed to r_particles_max, also I added in cl_maxnetfps
at 30 and edited cl_maxfps to 72 since that should work nicely with maxnetfps
now :)
Tim McGrath
(Misty-chan)
benchmarking information, about 1 fps faster from the last time I
updated cvs. (And this is with DRI being 5 fps SLOWER than last time I
updated.)
Misty
I mangled them into something that works. Also I found out about
gl_texturemode (thanks despair) although it didn't do much for me, it
might for you. Look at it :)
I also cleaned up the configs so we can see where each section begins
and ends easier. Should be fairly obvious what I did.
Misty-chan :)
glspeed-v3.cfg. Cleared up a misleading comment about r_dynamic, found
out 0.5.0 quakeforge does weird things with gl_lightmode (see comment)
and added benchmarking information to the beginning of the files.
one should work fine for old voodoo 1/2 users. I'll update this one
generally when I do the other one, but this one I can't really test
myself on for it's target - older hardware. Please tell me if I give a
setting which is slower on a system.
Misty-chan
I didn't know about (gl_lightmap_components)
Other than that, haven't added or removed much of anything - HOWEVER
note that this config has radically changed speedwise. I've gotten a
hardware upgrade, and so changed my config around to suit it. This is
written now for a voodoo 3 2000 pci, the old voodoo 1 has been
accidentally fried and given a proper burial.
If you relied on the old config to be fast as heck with it's defaults,
sorry. - Please look through the file, read the comments, and change the
settings to however you please.
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
Ragnvald Maartmann-Moe IV
Brian Koropoff
Bill Currie
Timothy C. McGrath
Chris Ison
Timothy C. McGrath
Adam Olsen