2001-02-19 21:15:25 +00:00
|
|
|
/*
|
|
|
|
gl_dyn_part.c
|
|
|
|
|
|
|
|
OpenGL particle system.
|
|
|
|
|
|
|
|
Copyright (C) 1996-1997 Id Software, Inc.
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or
|
|
|
|
modify it under the terms of the GNU General Public License
|
|
|
|
as published by the Free Software Foundation; either version 2
|
|
|
|
of the License, or (at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
|
|
|
|
See the GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to:
|
|
|
|
|
|
|
|
Free Software Foundation, Inc.
|
|
|
|
59 Temple Place - Suite 330
|
|
|
|
Boston, MA 02111-1307, USA
|
|
|
|
|
|
|
|
$Id$
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef HAVE_CONFIG_H
|
|
|
|
# include "config.h"
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_STRING_H
|
|
|
|
# include <string.h>
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_STRINGS_H
|
|
|
|
# include <strings.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
2001-03-27 20:33:07 +00:00
|
|
|
#include "QF/cmd.h"
|
2001-03-28 17:17:56 +00:00
|
|
|
#include "QF/compat.h"
|
2001-03-27 20:33:07 +00:00
|
|
|
#include "QF/console.h"
|
2001-04-15 21:11:41 +00:00
|
|
|
#include "QF/qargs.h"
|
|
|
|
#include "QF/sys.h"
|
2001-05-02 13:48:04 +00:00
|
|
|
#include "QF/varrays.h"
|
2001-04-15 21:11:41 +00:00
|
|
|
|
|
|
|
#include "client.h"
|
2001-02-19 21:15:25 +00:00
|
|
|
#include "glquake.h"
|
|
|
|
#include "host.h"
|
|
|
|
#include "r_dynamic.h"
|
2001-05-19 00:23:21 +00:00
|
|
|
#include "QF/render.h"
|
2001-02-19 21:15:25 +00:00
|
|
|
|
|
|
|
static particle_t *particles, **freeparticles;
|
|
|
|
static short r_numparticles, numparticles;
|
|
|
|
|
2001-04-06 02:12:19 +00:00
|
|
|
extern qboolean lighthalf;
|
|
|
|
|
Okay, this patch REMOVES the -particles command line option, and adds a
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
2001-03-18 07:04:47 +00:00
|
|
|
extern cvar_t *cl_max_particles;
|
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
extern int part_tex_dot;
|
2001-04-06 04:27:39 +00:00
|
|
|
extern int part_tex_spark;
|
2001-04-06 19:23:00 +00:00
|
|
|
extern int part_tex_smoke[8];
|
|
|
|
extern int part_tex_smoke_ring[8];
|
2001-02-19 21:15:25 +00:00
|
|
|
|
|
|
|
int ramp[8] = { 0x6d, 0x6b, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01 };
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
inline particle_t *
|
|
|
|
particle_new (ptype_t type, int texnum, vec3_t org, float scale, vec3_t vel,
|
2001-04-06 18:37:23 +00:00
|
|
|
float die, byte color, byte alpha, vec3_t up, vec3_t right)
|
2001-02-19 21:15:25 +00:00
|
|
|
{
|
|
|
|
particle_t *part;
|
|
|
|
|
|
|
|
if (numparticles >= r_numparticles) {
|
|
|
|
// Con_Printf("FAILED PARTICLE ALLOC!\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
part = &particles[numparticles++];
|
|
|
|
|
|
|
|
part->type = type;
|
|
|
|
VectorCopy (org, part->org);
|
|
|
|
VectorCopy (vel, part->vel);
|
|
|
|
part->die = die;
|
|
|
|
part->color = color;
|
|
|
|
part->alpha = alpha;
|
|
|
|
part->tex = texnum;
|
|
|
|
part->scale = scale;
|
|
|
|
|
2001-04-06 18:37:23 +00:00
|
|
|
VectorScale (up, 1.5, part->up);
|
|
|
|
VectorScale (right, 1.5, part->right);
|
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
return part;
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
inline particle_t *
|
|
|
|
particle_new_random (ptype_t type, int texnum, vec3_t org, int org_fuzz,
|
|
|
|
float scale, int vel_fuzz, float die, byte color,
|
|
|
|
byte alpha)
|
|
|
|
{
|
|
|
|
vec3_t porg, pvel;
|
|
|
|
int j;
|
|
|
|
|
|
|
|
for (j = 0; j < 3; j++) {
|
|
|
|
if (org_fuzz)
|
|
|
|
porg[j] = lhrandom (-org_fuzz, org_fuzz) + org[j];
|
|
|
|
if (vel_fuzz)
|
|
|
|
pvel[j] = lhrandom (-vel_fuzz, vel_fuzz);
|
|
|
|
}
|
2001-04-06 18:37:23 +00:00
|
|
|
return particle_new (type, texnum, porg, scale, pvel, die, color, alpha, vec3_origin, vec3_origin);
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
/*
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
R_MaxParticlesCheck
|
|
|
|
|
|
|
|
Misty-chan: Dynamically change the maximum amount of particles on the fly.
|
2001-05-02 13:48:04 +00:00
|
|
|
Thanks to a LOT of help from Taniwha, Deek, Mercury, Lordhavoc, and
|
|
|
|
lots of others.
|
2001-02-19 21:15:25 +00:00
|
|
|
*/
|
|
|
|
void
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
R_MaxParticlesCheck (cvar_t *var)
|
2001-02-19 21:15:25 +00:00
|
|
|
{
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
/*
|
2001-05-02 13:48:04 +00:00
|
|
|
Catchall. If the user changed the setting to a number less than zero
|
|
|
|
*or* if we had a wacky cfg get past the init code check, this will
|
|
|
|
make sure we don't have problems. Also note that grabbing the
|
|
|
|
var->int_val is IMPORTANT:
|
|
|
|
|
|
|
|
Prevents a segfault since if we grabbed the int_val of
|
|
|
|
cl_max_particles we'd sig11 right here at startup.
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
*/
|
|
|
|
r_numparticles = max(var->int_val, 0);
|
|
|
|
|
2001-05-02 13:48:04 +00:00
|
|
|
// Be very careful the next time we do something like this.
|
|
|
|
// calloc/free are IMPORTANT and the compiler doesn't know when we
|
|
|
|
// do bad things with them.
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
free (particles);
|
|
|
|
free (freeparticles);
|
2001-02-19 21:15:25 +00:00
|
|
|
|
|
|
|
particles = (particle_t *)
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
calloc (r_numparticles, sizeof (particle_t));
|
|
|
|
freeparticles = (particle_t **)
|
|
|
|
calloc (r_numparticles, sizeof (particle_t*));
|
2001-04-03 05:40:15 +00:00
|
|
|
|
|
|
|
R_ClearParticles();
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
|
Okay, this patch REMOVES the -particles command line option, and adds a
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
2001-03-18 07:04:47 +00:00
|
|
|
void
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
R_Particles_Init_Cvars (void)
|
Okay, this patch REMOVES the -particles command line option, and adds a
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
2001-03-18 07:04:47 +00:00
|
|
|
{
|
2001-04-08 04:07:19 +00:00
|
|
|
// Misty-chan: This is a cvar that does callbacks. Whenever it
|
|
|
|
// changes, it calls the function R_MaxParticlesCheck and therefore
|
|
|
|
// is very nifty.
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
Cvar_Get ("cl_max_particles", "2048", CVAR_ARCHIVE, R_MaxParticlesCheck,
|
2001-04-03 05:40:15 +00:00
|
|
|
"Maximum amount of particles to display. No maximum, minimum is 0, although it's best to use r_particles 0 instead.");
|
Okay, this patch REMOVES the -particles command line option, and adds a
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
2001-03-18 07:04:47 +00:00
|
|
|
}
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_ClearParticles (void)
|
|
|
|
{
|
|
|
|
numparticles = 0;
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_ReadPointFile_f (void)
|
|
|
|
{
|
|
|
|
QFile *f;
|
|
|
|
vec3_t org;
|
|
|
|
int r;
|
|
|
|
int c;
|
|
|
|
char name[MAX_OSPATH], *mapname, *t1;
|
|
|
|
|
2001-05-20 03:54:55 +00:00
|
|
|
mapname = strdup (r_worldentity.model->name);
|
2001-02-19 21:15:25 +00:00
|
|
|
if (!mapname)
|
|
|
|
Sys_Error ("Can't duplicate mapname!");
|
|
|
|
t1 = strrchr (mapname, '.');
|
|
|
|
if (!t1)
|
|
|
|
Sys_Error ("Can't find .!");
|
|
|
|
t1[0] = '\0';
|
|
|
|
|
|
|
|
snprintf (name, sizeof (name), "%s.pts", mapname);
|
|
|
|
free (mapname);
|
|
|
|
|
|
|
|
COM_FOpenFile (name, &f);
|
|
|
|
if (!f) {
|
|
|
|
Con_Printf ("couldn't open %s\n", name);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
Con_Printf ("Reading %s...\n", name);
|
|
|
|
c = 0;
|
|
|
|
for (;;) {
|
|
|
|
char buf[64];
|
|
|
|
|
|
|
|
Qgets (f, buf, sizeof (buf));
|
|
|
|
r = sscanf (buf, "%f %f %f\n", &org[0], &org[1], &org[2]);
|
|
|
|
if (r != 3)
|
|
|
|
break;
|
|
|
|
c++;
|
|
|
|
|
|
|
|
if (!particle_new (pt_static, part_tex_dot, org, 1.5, vec3_origin,
|
2001-04-06 18:37:23 +00:00
|
|
|
99999, (-c) & 15, 255, vec3_origin, vec3_origin)) {
|
2001-02-19 21:15:25 +00:00
|
|
|
Con_Printf ("Not enough free particles\n");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Qclose (f);
|
|
|
|
Con_Printf ("%i points read\n", c);
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_ParticleExplosion (vec3_t org)
|
|
|
|
{
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
particle_new_random (pt_smokecloud, part_tex_smoke[rand () & 7], org, 4, 30,
|
2001-05-20 03:54:55 +00:00
|
|
|
8, r_realtime + 5, (rand () & 7) + 8,
|
2001-02-19 21:15:25 +00:00
|
|
|
128 + (rand () & 63));
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-05-15 21:34:54 +00:00
|
|
|
void
|
|
|
|
R_ParticleExplosion2 (vec3_t org, int colorStart, int colorLength)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int colorMod = 0;
|
|
|
|
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < 512; i++) {
|
2001-05-20 03:54:55 +00:00
|
|
|
particle_new_random (pt_blob, part_tex_dot, org, 16, 2, 256, (r_realtime + 0.3), (colorStart + (colorMod % colorLength)), 255);
|
2001-05-15 21:34:54 +00:00
|
|
|
colorMod++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_BlobExplosion (vec3_t org)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < 512; i++) {
|
|
|
|
particle_new_random (pt_blob, part_tex_dot, org, 12, 2, 256,
|
2001-05-20 03:54:55 +00:00
|
|
|
(r_realtime + 1 + (rand () & 8) * 0.05),
|
2001-02-19 21:15:25 +00:00
|
|
|
(66 + rand () % 6), 255);
|
|
|
|
}
|
|
|
|
for (i = 0; i < 512; i++) {
|
|
|
|
particle_new_random (pt_blob2, part_tex_dot, org, 12, 2, 256,
|
2001-05-20 03:54:55 +00:00
|
|
|
(r_realtime + 1 + (rand () & 8) * 0.05),
|
2001-02-19 21:15:25 +00:00
|
|
|
(150 + rand () % 6), 255);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
static void
|
|
|
|
R_RunSparkEffect (vec3_t org, int count, int ofuzz)
|
|
|
|
{
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
particle_new (pt_smokecloud, part_tex_smoke[rand () & 7], org,
|
2001-05-20 03:54:55 +00:00
|
|
|
(ofuzz / 8) * .75, vec3_origin, r_realtime + 99,
|
2001-04-06 18:37:23 +00:00
|
|
|
12 + (rand () & 3), 96, vec3_origin, vec3_origin);
|
2001-02-19 21:15:25 +00:00
|
|
|
while (count--)
|
2001-05-02 13:48:04 +00:00
|
|
|
particle_new_random (pt_fallfadespark, part_tex_spark, org, ofuzz * .75,
|
2001-05-20 03:54:55 +00:00
|
|
|
1, 96, r_realtime + 5, ramp[rand () % 6],
|
2001-02-19 21:15:25 +00:00
|
|
|
lhrandom (0, 255));
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
static void
|
|
|
|
R_RunGunshotEffect (vec3_t org, int count)
|
|
|
|
{
|
|
|
|
int scale;
|
|
|
|
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (count > 6)
|
|
|
|
scale = 3;
|
|
|
|
else
|
|
|
|
scale = 2;
|
|
|
|
|
|
|
|
R_RunSparkEffect (org, count * 10, 8 * scale);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
static void
|
|
|
|
R_BloodPuff (vec3_t org, int count)
|
|
|
|
{
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
particle_new (pt_bloodcloud, part_tex_smoke[rand () & 7], org, 9,
|
2001-05-20 03:54:55 +00:00
|
|
|
vec3_origin, r_realtime + 99, 68 + (rand () & 3), 128,
|
2001-04-06 18:37:23 +00:00
|
|
|
vec3_origin, vec3_origin);
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_RunPuffEffect (vec3_t org, byte type, byte count)
|
|
|
|
{
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case TE_GUNSHOT:
|
|
|
|
R_RunGunshotEffect (org, count);
|
|
|
|
break;
|
|
|
|
case TE_BLOOD:
|
|
|
|
R_BloodPuff (org, count);
|
|
|
|
break;
|
|
|
|
case TE_LIGHTNINGBLOOD:
|
|
|
|
R_BloodPuff (org, 5 + (rand () & 1));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_RunParticleEffect (vec3_t org, int color, int count)
|
|
|
|
{
|
|
|
|
int i, j, scale;
|
|
|
|
vec3_t porg;
|
|
|
|
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (count > 130)
|
|
|
|
scale = 3;
|
|
|
|
else if (count > 20)
|
|
|
|
scale = 2;
|
|
|
|
else
|
|
|
|
scale = 1;
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
for (j = 0; j < 3; j++) {
|
|
|
|
porg[j] = org[j] + scale * ((rand () & 15) - 8);
|
|
|
|
}
|
|
|
|
particle_new (pt_grav, part_tex_dot, porg, 1.5, vec3_origin,
|
2001-05-20 03:54:55 +00:00
|
|
|
(r_realtime + 0.1 * (rand () % 5)),
|
2001-04-06 18:37:23 +00:00
|
|
|
(color & ~7) + (rand () & 7), 255, vec3_origin, vec3_origin);
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_RunSpikeEffect (vec3_t org, byte type)
|
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case TE_SPIKE:
|
|
|
|
R_RunSparkEffect (org, 5, 8);
|
|
|
|
break;
|
|
|
|
case TE_SUPERSPIKE:
|
|
|
|
R_RunSparkEffect (org, 10, 8);
|
|
|
|
break;
|
|
|
|
case TE_KNIGHTSPIKE:
|
|
|
|
R_RunSparkEffect (org, 10, 8);
|
|
|
|
break;
|
|
|
|
case TE_WIZSPIKE:
|
|
|
|
R_RunSparkEffect (org, 15, 16);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_LavaSplash (vec3_t org)
|
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
float vel;
|
|
|
|
vec3_t dir, porg, pvel;
|
|
|
|
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
2001-03-02 23:32:24 +00:00
|
|
|
for (i = -8; i < 8; i++) {
|
|
|
|
for (j = -8; j < 8; j++) {
|
|
|
|
dir[0] = j * 16 + (rand () & 7);
|
|
|
|
dir[1] = i * 16 + (rand () & 7);
|
2001-02-19 21:15:25 +00:00
|
|
|
dir[2] = 256;
|
|
|
|
|
|
|
|
porg[0] = org[0] + dir[0];
|
|
|
|
porg[1] = org[1] + dir[1];
|
|
|
|
porg[2] = org[2] + (rand () & 63);
|
|
|
|
|
|
|
|
VectorNormalize (dir);
|
|
|
|
vel = 50 + (rand () & 63);
|
|
|
|
VectorScale (dir, vel, pvel);
|
2001-03-16 15:25:31 +00:00
|
|
|
particle_new (pt_grav, part_tex_dot, porg, 3, pvel,
|
2001-05-20 03:54:55 +00:00
|
|
|
(r_realtime + 2 + (rand () & 31) * 0.02),
|
2001-04-06 18:37:23 +00:00
|
|
|
(224 + (rand () & 7)), 193, vec3_origin, vec3_origin);
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_TeleportSplash (vec3_t org)
|
|
|
|
{
|
|
|
|
int i, j, k;
|
|
|
|
float vel;
|
|
|
|
vec3_t dir, porg, pvel;
|
|
|
|
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = -16; i < 16; i += 4)
|
|
|
|
for (j = -16; j < 16; j += 4)
|
|
|
|
for (k = -24; k < 32; k += 4) {
|
|
|
|
dir[0] = j * 8;
|
|
|
|
dir[1] = i * 8;
|
|
|
|
dir[2] = k * 8;
|
|
|
|
|
|
|
|
porg[0] = org[0] + i + (rand () & 3);
|
|
|
|
porg[1] = org[1] + j + (rand () & 3);
|
|
|
|
porg[2] = org[2] + k + (rand () & 3);
|
|
|
|
|
|
|
|
VectorNormalize (dir);
|
|
|
|
vel = 50 + (rand () & 63);
|
|
|
|
VectorScale (dir, vel, pvel);
|
2001-04-06 04:27:39 +00:00
|
|
|
particle_new (pt_grav, part_tex_spark, porg, 0.6, pvel,
|
2001-05-20 03:54:55 +00:00
|
|
|
(r_realtime + 0.2 + (rand () & 7) * 0.02),
|
2001-04-06 18:37:23 +00:00
|
|
|
(7 + (rand () & 7)), 255, vec3_origin, vec3_origin);
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-05-13 22:57:27 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
void
|
|
|
|
R_RocketTrail (int type, entity_t *ent)
|
|
|
|
{
|
2001-04-08 04:07:19 +00:00
|
|
|
vec3_t vec, subtract;
|
|
|
|
float len, dist;
|
2001-02-19 21:15:25 +00:00
|
|
|
int j, ptex;
|
|
|
|
ptype_t ptype;
|
2001-04-06 18:37:23 +00:00
|
|
|
vec3_t porg, pvel, up, right;
|
2001-02-19 21:15:25 +00:00
|
|
|
float pdie, pscale;
|
|
|
|
byte palpha, pcolor;
|
|
|
|
|
|
|
|
if (type == 0)
|
|
|
|
R_AddFire (ent->old_origin, ent->origin, ent);
|
|
|
|
|
|
|
|
if (!r_particles->int_val)
|
|
|
|
return;
|
|
|
|
|
|
|
|
VectorSubtract (ent->origin, ent->old_origin, vec);
|
|
|
|
len = VectorNormalize (vec);
|
|
|
|
while (len > 0) {
|
2001-04-06 18:37:23 +00:00
|
|
|
VectorCopy (vec3_origin, up);
|
|
|
|
VectorCopy (vec3_origin, right);
|
2001-02-19 21:15:25 +00:00
|
|
|
VectorCopy (vec3_origin, pvel);
|
2001-05-20 03:54:55 +00:00
|
|
|
pdie = r_realtime + 2;
|
2001-02-19 21:15:25 +00:00
|
|
|
ptype = pt_static;
|
|
|
|
ptex = part_tex_dot;
|
|
|
|
palpha = 255;
|
2001-04-08 21:41:53 +00:00
|
|
|
pcolor = 0;
|
|
|
|
pscale = 6;
|
|
|
|
dist = 40;
|
2001-02-19 21:15:25 +00:00
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case 0: // rocket trail
|
2001-05-20 03:54:55 +00:00
|
|
|
pdie = r_realtime + 60;
|
2001-04-20 19:45:42 +00:00
|
|
|
// ptype = pt_smokering; // Mercury's Rings
|
|
|
|
ptype = pt_smoke;
|
2001-05-02 18:01:14 +00:00
|
|
|
pscale = lhrandom (6, 8);
|
2001-04-20 19:45:42 +00:00
|
|
|
// pcolor = (rand () & 255); // Misty-chan's Easter Egg
|
|
|
|
pcolor = (rand () & 3) + 12;
|
2001-04-08 21:41:53 +00:00
|
|
|
palpha = 128 + (rand () & 31);
|
2001-04-20 19:45:42 +00:00
|
|
|
// VectorVectors(vec, right, up); // Mercury's Rings
|
2001-04-06 19:23:00 +00:00
|
|
|
VectorCopy (ent->old_origin, porg);
|
2001-04-20 19:45:42 +00:00
|
|
|
// ptex = part_tex_smoke_ring[rand () & 7]; // Mercury's Rings
|
|
|
|
ptex = part_tex_smoke[rand () & 7];
|
2001-04-06 19:23:00 +00:00
|
|
|
break;
|
2001-02-19 21:15:25 +00:00
|
|
|
case 1: // grenade trail
|
2001-04-08 04:07:19 +00:00
|
|
|
ptype = pt_smoke;
|
2001-05-02 18:01:14 +00:00
|
|
|
pscale = lhrandom (7, 10);
|
2001-04-20 19:45:42 +00:00
|
|
|
// pcolor = (rand () & 255); // Misty-chan's Easter Egg
|
2001-05-02 18:01:14 +00:00
|
|
|
pcolor = (rand () & 3);
|
2001-04-08 21:41:53 +00:00
|
|
|
palpha = 128 + (rand () & 31);
|
2001-02-19 21:15:25 +00:00
|
|
|
VectorCopy (ent->old_origin, porg);
|
2001-04-08 04:07:19 +00:00
|
|
|
ptex = part_tex_smoke[rand () & 7];
|
2001-02-19 21:15:25 +00:00
|
|
|
break;
|
|
|
|
case 2: // blood
|
2001-05-02 18:01:14 +00:00
|
|
|
pscale = 5;
|
2001-04-08 21:41:53 +00:00
|
|
|
case 4: // slight blood
|
2001-05-02 18:01:14 +00:00
|
|
|
pscale += lhrandom (1, 4);
|
2001-04-08 21:41:53 +00:00
|
|
|
ptex = part_tex_smoke[rand () & 7];
|
2001-02-19 21:15:25 +00:00
|
|
|
pcolor = 68 + (rand () & 3);
|
|
|
|
for (j = 0; j < 3; j++) {
|
2001-04-08 21:41:53 +00:00
|
|
|
pvel[j] = lhrandom (-3, 3) * type;
|
|
|
|
porg[j] = ent->old_origin[j] + lhrandom (-1.5, 1.5);
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
ptype = pt_grav;
|
|
|
|
break;
|
|
|
|
case 6: // voor trail
|
2001-04-08 21:41:53 +00:00
|
|
|
// Use smoke ring effects here, once merged with nq? --Despair
|
2001-04-08 04:07:19 +00:00
|
|
|
dist = 3;
|
2001-02-19 21:15:25 +00:00
|
|
|
pcolor = 9 * 16 + 8 + (rand () & 3);
|
|
|
|
ptype = pt_static;
|
|
|
|
pscale = lhrandom (.75, 1.5);
|
2001-05-20 03:54:55 +00:00
|
|
|
pdie = r_realtime + 0.3;
|
2001-02-19 21:15:25 +00:00
|
|
|
for (j = 0; j < 3; j++)
|
2001-04-08 21:41:53 +00:00
|
|
|
porg[j] = ent->old_origin[j] + lhrandom (-8, 8);
|
2001-02-19 21:15:25 +00:00
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
case 5: // tracer
|
|
|
|
{
|
|
|
|
static int tracercount;
|
|
|
|
|
2001-04-08 04:07:19 +00:00
|
|
|
dist = 3;
|
2001-05-20 03:54:55 +00:00
|
|
|
pdie = r_realtime + 0.5;
|
2001-02-19 21:15:25 +00:00
|
|
|
ptype = pt_static;
|
|
|
|
pscale = lhrandom (1.5, 3);
|
|
|
|
if (type == 3)
|
|
|
|
pcolor = 52 + ((tracercount & 4) << 1);
|
|
|
|
else
|
|
|
|
pcolor = 230 + ((tracercount & 4) << 1);
|
|
|
|
|
|
|
|
tracercount++;
|
|
|
|
|
|
|
|
VectorCopy (ent->old_origin, porg);
|
|
|
|
if (tracercount & 1) {
|
|
|
|
pvel[0] = 30 * vec[1];
|
|
|
|
pvel[1] = 30 * -vec[0];
|
|
|
|
} else {
|
|
|
|
pvel[0] = 30 * -vec[1];
|
|
|
|
pvel[1] = 30 * vec[0];
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-04-08 04:07:19 +00:00
|
|
|
VectorScale (vec, min(dist, len), subtract);
|
|
|
|
VectorAdd (ent->old_origin, subtract, ent->old_origin);
|
|
|
|
len -= dist;
|
2001-02-19 21:15:25 +00:00
|
|
|
|
2001-04-06 18:37:23 +00:00
|
|
|
particle_new (ptype, ptex, porg, pscale, pvel, pdie, pcolor, palpha,
|
|
|
|
up, right);
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
R_DrawParticles (void)
|
|
|
|
{
|
|
|
|
byte i;
|
|
|
|
float grav, fast_grav, dvel;
|
|
|
|
float minparticledist;
|
|
|
|
unsigned char *at;
|
|
|
|
byte alpha;
|
|
|
|
float scale;
|
|
|
|
particle_t *part;
|
2001-04-06 18:37:23 +00:00
|
|
|
vec3_t up, right, o_up, o_right;
|
2001-04-08 04:07:19 +00:00
|
|
|
vec3_t up_scale, right_scale, up_right_scale;
|
2001-05-02 13:48:04 +00:00
|
|
|
int activeparticles, maxparticle, j, k;
|
This took half the hair on my head. Just kidding:
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
2001-04-03 02:56:39 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
// LordHavoc: particles should not affect zbuffer
|
|
|
|
glDepthMask (GL_FALSE);
|
|
|
|
|
2001-04-06 19:05:57 +00:00
|
|
|
VectorScale (vup, 1.5, o_up);
|
|
|
|
VectorScale (vright, 1.5, o_right);
|
2001-04-06 18:37:23 +00:00
|
|
|
|
2001-05-02 13:48:04 +00:00
|
|
|
varray[0].texcoord[0] = 0; varray[0].texcoord[1] = 1;
|
|
|
|
varray[1].texcoord[0] = 0; varray[1].texcoord[1] = 0;
|
|
|
|
varray[2].texcoord[0] = 1; varray[2].texcoord[1] = 0;
|
|
|
|
varray[3].texcoord[0] = 1; varray[3].texcoord[1] = 1;
|
2001-04-06 02:57:26 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
grav = (fast_grav = host_frametime * 800) * 0.05;
|
|
|
|
dvel = 4 * host_frametime;
|
|
|
|
|
|
|
|
minparticledist = DotProduct (r_refdef.vieworg, vpn) + 32.0f;
|
|
|
|
|
|
|
|
activeparticles = 0;
|
|
|
|
maxparticle = -1;
|
|
|
|
j = 0;
|
|
|
|
|
|
|
|
for (k = 0, part = particles; k < numparticles; k++, part++) {
|
2001-05-02 13:48:04 +00:00
|
|
|
// LordHavoc: this is probably no longer necessary, as it is
|
|
|
|
// checked at the end, but could still happen on weird particle
|
|
|
|
// effects, left for safety...
|
2001-05-20 03:54:55 +00:00
|
|
|
if (part->die <= r_realtime) {
|
2001-02-19 21:15:25 +00:00
|
|
|
freeparticles[j++] = part;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
maxparticle = k;
|
|
|
|
activeparticles++;
|
|
|
|
|
|
|
|
// Don't render particles too close to us.
|
|
|
|
// Note, we must still do physics and such on them.
|
|
|
|
if (!(DotProduct (part->org, vpn) < minparticledist) &&
|
|
|
|
r_particles->int_val) {
|
|
|
|
at = (byte *) & d_8to24table[(byte) part->color];
|
|
|
|
alpha = part->alpha;
|
|
|
|
|
2001-05-02 13:48:04 +00:00
|
|
|
#define mVectorCompare(x, y) ((x[0] == y[0]) && (x[1] == y[1]) && (x[2] == y[2]))
|
|
|
|
if (mVectorCompare(part->up, part->right)) {
|
2001-04-08 04:07:19 +00:00
|
|
|
memcpy(up, o_up, sizeof(up));
|
|
|
|
memcpy(right, o_right, sizeof(right));
|
2001-04-06 18:37:23 +00:00
|
|
|
} else {
|
2001-04-08 04:07:19 +00:00
|
|
|
memcpy(up, part->up, sizeof(up));
|
|
|
|
memcpy(right, part->right, sizeof(right));
|
2001-04-06 18:37:23 +00:00
|
|
|
}
|
|
|
|
|
2001-04-06 02:57:26 +00:00
|
|
|
if (lighthalf) {
|
2001-05-02 13:48:04 +00:00
|
|
|
varray[0].color[0] = (float) ((int) at[0] >> 1) / 255;
|
|
|
|
varray[0].color[1] = (float) ((int) at[1] >> 1) / 255;
|
|
|
|
varray[0].color[2] = (float) ((int) at[2] >> 1) / 255;
|
2001-04-06 02:57:26 +00:00
|
|
|
} else {
|
2001-05-02 13:48:04 +00:00
|
|
|
varray[0].color[0] = (float) at[0] / 255;
|
|
|
|
varray[0].color[1] = (float) at[1] / 255;
|
|
|
|
varray[0].color[2] = (float) at[2] / 255;
|
2001-04-06 02:57:26 +00:00
|
|
|
}
|
2001-05-02 13:48:04 +00:00
|
|
|
varray[0].color[3] = (float) alpha / 255;
|
2001-04-06 02:57:26 +00:00
|
|
|
|
2001-05-02 13:48:04 +00:00
|
|
|
memcpy(varray[1].color, varray[0].color, sizeof(varray[0].color));
|
|
|
|
memcpy(varray[2].color, varray[0].color, sizeof(varray[0].color));
|
|
|
|
memcpy(varray[3].color, varray[0].color, sizeof(varray[0].color));
|
2001-02-19 21:15:25 +00:00
|
|
|
|
|
|
|
scale = part->scale;
|
|
|
|
|
2001-04-08 04:07:19 +00:00
|
|
|
up_scale[0] = up[0] * scale;
|
|
|
|
up_scale[1] = up[1] * scale;
|
|
|
|
up_scale[2] = up[2] * scale;
|
|
|
|
|
|
|
|
right_scale[0] = right[0] * scale;
|
|
|
|
right_scale[1] = right[1] * scale;
|
|
|
|
right_scale[2] = right[2] * scale;
|
|
|
|
|
|
|
|
up_right_scale[0] = (up[0] + right[0]) * scale;
|
|
|
|
up_right_scale[1] = (up[1] + right[1]) * scale;
|
|
|
|
up_right_scale[2] = (up[2] + right[2]) * scale;
|
|
|
|
|
2001-05-02 13:48:04 +00:00
|
|
|
varray[0].vertex[0] = part->org[0] + up_right_scale[0];
|
|
|
|
varray[0].vertex[1] = part->org[1] + up_right_scale[1];
|
|
|
|
varray[0].vertex[2] = part->org[2] + up_right_scale[2];
|
2001-04-08 04:07:19 +00:00
|
|
|
|
2001-05-02 13:48:04 +00:00
|
|
|
varray[1].vertex[0] = part->org[0] - up_scale[0] + right_scale[0];
|
|
|
|
varray[1].vertex[1] = part->org[1] - up_scale[1] + right_scale[1];
|
|
|
|
varray[1].vertex[2] = part->org[2] - up_scale[2] + right_scale[2];
|
|
|
|
|
|
|
|
varray[2].vertex[0] = part->org[0] - up_right_scale[0];
|
|
|
|
varray[2].vertex[1] = part->org[1] - up_right_scale[1];
|
|
|
|
varray[2].vertex[2] = part->org[2] - up_right_scale[2];
|
|
|
|
|
|
|
|
varray[3].vertex[0] = part->org[0] + up_scale[0] - right_scale[0];
|
|
|
|
varray[3].vertex[1] = part->org[1] + up_scale[1] - right_scale[1];
|
|
|
|
varray[3].vertex[2] = part->org[2] + up_scale[2] - right_scale[2];
|
2001-04-06 02:57:26 +00:00
|
|
|
|
2001-02-19 21:15:25 +00:00
|
|
|
glBindTexture (GL_TEXTURE_2D, part->tex);
|
2001-04-06 02:57:26 +00:00
|
|
|
glDrawArrays (GL_QUADS, 0, 4);
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < 3; i++)
|
|
|
|
part->org[i] += part->vel[i] * host_frametime;
|
|
|
|
|
|
|
|
switch (part->type) {
|
|
|
|
case pt_static:
|
|
|
|
break;
|
|
|
|
case pt_blob:
|
|
|
|
for (i = 0; i < 3; i++)
|
|
|
|
part->vel[i] += part->vel[i] * dvel;
|
|
|
|
part->vel[2] -= grav;
|
|
|
|
break;
|
|
|
|
case pt_blob2:
|
|
|
|
for (i = 0; i < 2; i++)
|
|
|
|
part->vel[i] -= part->vel[i] * dvel;
|
|
|
|
part->vel[2] -= grav;
|
|
|
|
break;
|
|
|
|
case pt_grav:
|
|
|
|
part->vel[2] -= grav;
|
|
|
|
break;
|
|
|
|
case pt_smoke:
|
2001-04-08 04:07:19 +00:00
|
|
|
if ((part->alpha -= host_frametime * 90) < 1)
|
|
|
|
part->die = -1;
|
|
|
|
part->scale += host_frametime * 6;
|
2001-05-02 18:01:14 +00:00
|
|
|
// part->org[2] += host_frametime * 30;
|
2001-04-08 04:07:19 +00:00
|
|
|
break;
|
|
|
|
case pt_smokering:
|
2001-04-08 04:56:24 +00:00
|
|
|
if ((part->alpha -= host_frametime * 130) < 1)
|
2001-02-19 21:15:25 +00:00
|
|
|
part->die = -1;
|
2001-04-06 18:37:23 +00:00
|
|
|
part->scale += host_frametime * 10;
|
2001-05-02 18:01:14 +00:00
|
|
|
// part->org[2] += host_frametime * 30;
|
2001-02-19 21:15:25 +00:00
|
|
|
break;
|
|
|
|
case pt_smokecloud:
|
|
|
|
if ((part->alpha -= host_frametime * 128) < 1)
|
2001-05-02 18:01:14 +00:00
|
|
|
{
|
2001-02-19 21:15:25 +00:00
|
|
|
part->die = -1;
|
2001-05-02 18:01:14 +00:00
|
|
|
break;
|
|
|
|
}
|
2001-02-19 21:15:25 +00:00
|
|
|
part->scale += host_frametime * 60;
|
2001-05-02 18:01:14 +00:00
|
|
|
part->org[2] += host_frametime * 30;
|
2001-02-19 21:15:25 +00:00
|
|
|
break;
|
|
|
|
case pt_bloodcloud:
|
|
|
|
if ((part->alpha -= host_frametime * 64) < 1)
|
|
|
|
{
|
|
|
|
part->die = -1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
part->scale += host_frametime * 4;
|
|
|
|
part->vel[2] -= grav;
|
|
|
|
break;
|
|
|
|
case pt_fadespark:
|
|
|
|
if ((part->alpha -= host_frametime * 256) < 1)
|
|
|
|
part->die = -1;
|
|
|
|
part->vel[2] -= grav;
|
|
|
|
break;
|
|
|
|
case pt_fadespark2:
|
|
|
|
if ((part->alpha -= host_frametime * 512) < 1)
|
|
|
|
part->die = -1;
|
|
|
|
part->vel[2] -= grav;
|
|
|
|
break;
|
|
|
|
case pt_fallfadespark:
|
|
|
|
if ((part->alpha -= host_frametime * 256) < 1)
|
|
|
|
part->die = -1;
|
|
|
|
part->vel[2] -= fast_grav;
|
|
|
|
break;
|
2001-05-10 06:01:11 +00:00
|
|
|
default:
|
|
|
|
Con_DPrintf ("unhandled particle type %d\n", part->type);
|
|
|
|
break;
|
2001-02-19 21:15:25 +00:00
|
|
|
}
|
2001-05-02 13:48:04 +00:00
|
|
|
// LordHavoc: immediate removal of unnecessary particles (must
|
|
|
|
// be done to ensure compactor below operates properly in all
|
|
|
|
// cases)
|
2001-05-20 03:54:55 +00:00
|
|
|
if (part->die <= r_realtime)
|
2001-02-19 21:15:25 +00:00
|
|
|
freeparticles[j++] = part;
|
|
|
|
}
|
|
|
|
k = 0;
|
|
|
|
while (maxparticle >= activeparticles) {
|
|
|
|
*freeparticles[k++] = particles[maxparticle--];
|
2001-05-02 13:48:04 +00:00
|
|
|
while (maxparticle >= activeparticles &&
|
2001-05-20 03:54:55 +00:00
|
|
|
particles[maxparticle].die <= r_realtime)
|
2001-02-19 21:15:25 +00:00
|
|
|
maxparticle--;
|
|
|
|
}
|
|
|
|
numparticles = activeparticles;
|
|
|
|
|
2001-04-06 02:12:19 +00:00
|
|
|
glColor3ubv (lighthalf_v);
|
2001-02-19 21:15:25 +00:00
|
|
|
glDepthMask (GL_TRUE);
|
|
|
|
}
|