DarkPlaces effectinfo.txt

[Baker]

The effectinfo.txt file in DarkPlaces is possibly the most brilliant way of handling particles. Particles are important, but maybe not for "Quake".

Comparing this to, say, the QMB particle engine in JoeQuake/ezQuake/FuhQuake, the QMB code is mostly a hell of a lot of constants per particle type.

But with effectinfo.txt, these are not hardcoded. I've been thinking about this lately mostly because the inability to customize particles in any of the more stock Quake engines is a major liability. An effectinfo.txt style approach combined with a particle font really is quite the answer to be able to play with this on the fly.

I guess my main reason in mentioning this, is the DarkPlaces texture/graphics/models people really do great work in exposing some of the fun things effectinfo.txt is capable of ... versus, say, a couple of years ago maybe the only well-known project that really did anything with the capability was Nexuiz. Outside of that, you never saw anyone use the capability.

I'm kind of tempted to reduce the QMB particle system to an effectinfo.txt file, not any time soon, but added to the "rainy day" list ...

effectinfo.txt looks kinda of like this (pulled off a Nexuiz or Xonotic page):

Code: Select all

// item respawn effect
// flare particle and light
// used in qcsrc/server/bots.qc:		//te_wizspike(start)
// used in qcsrc/server/bots.qc:				te_wizspike(org)
// used in qcsrc/server/bots.qc:	//te_wizspike(e.origin)
// used in qcsrc/server/bots.qc:		//te_wizspike(e.nearestwaypoint.wpnearestpoint)
effect TE_WIZSPIKE
countabsolute 1
type static
color 0x63F2EA 0x63f2EA
size 20 20
alpha 128 128 128
lightradius 200
lightradiusfade 200
lightcolor 0.4 0.9 0.9
// cloud of particles which expand rapidly and then slow to form a ball
effect TE_WIZSPIKE
count 100
type static
color 0x63F2EA 0x63f2EA
size 2 2
alpha 64 64 64
airfriction 2
liquidfriction 2
originjitter 16 16 16
velocityjitter 32 32 32

// laser impact
// decal
// used in qcsrc/server/bots.qc:		//te_knightspike(end)
// used in qcsrc/server/bots.qc:			te_knightspike(start)
// used in qcsrc/server/bots.qc:						te_knightspike(org)
// used in qcsrc/server/bots.qc:		te_knightspike(org)
effect TE_KNIGHTSPIKE
countabsolute 1
type decal
tex 47 47
size 24 24
alpha 256 256 0
originjitter 16 16 16
lightradius 200
lightradiusfade 1000
lightcolor 4 0.2 0.2
// flare effect
effect TE_KNIGHTSPIKE
countabsolute 1
type static
tex 39 39
color 0xFF2010 0xFF2010
alpha 256 256 1024
size 24 24
// sparks that rapidly expand and rapidly slow down to form an interesting spherical effect
effect TE_KNIGHTSPIKE
count 256
type spark
color 0x800000 0xFF8020
alpha 256 256 1024
size 4 4
//bounce 1.5
airfriction 6
liquidfriction 6
//originjitter 32 32 32
velocityjitter 256 256 256

// machinegun bullet impact
// bullet impact decal
// used nowhere in code
effect TE_SPIKE
countabsolute 1
type decal
tex 56 59
size 5 5
alpha 256 256 0
originjitter 6 6 6
// dust/smoke drifting away from the impact
effect TE_SPIKE
count 8
type smoke
tex 0 8
color 0x101010 0x101010
size 3 3
sizeincrease 3
alpha 255 255 256
originjitter 0 0 0
velocityjitter 8 8 8
// dust/smoke staying at the impact
effect TE_SPIKE
count 1
type smoke
tex 0 8
color 0x505050 0x505050
size 4 4
sizeincrease 4
alpha 255 255 128
originjitter 0 0 0
velocityjitter 0 0 0
// bouncing sparks
effect TE_SPIKE
count 20
type spark
color 0x8f4333 0xfff31b
size 0.4 0.4
alpha 0 256 256
gravity 1
bounce 1.5
velocityoffset 0 0 80
velocityjitter 64 64 64

// electro combo explosion
// decal
// used nowhere in code
effect TE_SPIKEQUAD
countabsolute 1
type decal
tex 59 59
size 64 64
alpha 256 256 0
originjitter 34 34 34
lightradius 400
lightradiusfade 200
lightcolor 2 2.5 3
// flare effect
effect TE_SPIKEQUAD
countabsolute 1
type static
tex 38 38
color 0x80C0FF 0x80C0FF
size 48 48
alpha 256 256 128
// large sparks
effect TE_SPIKEQUAD
count 20
type static
color 0x2030FF 0x80C0FF
size 32 32
alpha 256 256 256
//gravity 1
bounce 1.5
airfriction 4
liquidfriction 16
//velocityoffset 0 0 120
velocityjitter 512 512 512

// quake effect
// decal
// used nowhere in code
effect TE_SUPERSPIKE
countabsolute 1
type decal
tex 56 59
size 3 3
alpha 256 256 0
originjitter 6 6 6
// dust/smoke drifting away from the impact
effect TE_SUPERSPIKE
count 8
type smoke
tex 0 8
color 0x101010 0x101010
size 3 3
sizeincrease 3
alpha 255 255 256
originjitter 0 0 0
velocityjitter 8 8 8
// dust/smoke staying at the impact
effect TE_SUPERSPIKE
count 1
type smoke
tex 0 8
color 0x505050 0x505050
size 4 4
sizeincrease 4
alpha 255 255 128
originjitter 0 0 0
velocityjitter 0 0 0
// sparks that disappear on impact
effect TE_SUPERSPIKE
count 30
type spark
color 0x8f4333 0xfff31b
size 0.4 0.4
alpha 0 256 768
gravity 1
bounce -1
velocityoffset 0 0 80
velocityjitter 64 64 64

// quake effect
// decal
// used nowhere in code
effect TE_SUPERSPIKEQUAD
countabsolute 1
type decal
tex 56 59
size 3 3
alpha 256 256 0
originjitter 6 6 6
lightradius 100
lightradiusfade 500
lightcolor 0.15 0.15 1.5
// dust/smoke drifting away from the impact
effect TE_SUPERSPIKEQUAD
count 8
type smoke
tex 0 8
color 0x101010 0x101010
size 3 3
sizeincrease 3
alpha 255 255 256
originjitter 0 0 0
velocityjitter 8 8 8
// dust/smoke staying at the impact
effect TE_SUPERSPIKEQUAD
count 1
type smoke
tex 0 8
color 0x505050 0x505050
size 4 4
sizeincrease 4
alpha 255 255 128
originjitter 0 0 0
velocityjitter 0 0 0
// sparks that disappear on impact
effect TE_SUPERSPIKEQUAD
count 30
type spark
color 0x8f4333 0xfff31b
size 0.4 0.4
alpha 0 256 768
gravity 1
bounce -1
velocityoffset 0 0 80
velocityjitter 64 64 64

// shotgun pellet impact
// decal
// used in qcsrc/server/bots.qc:			//te_gunshot(org)
// used in qcsrc/server/bots.qc:					te_gunshot(org)
// used in qcsrc/server/bots.qc:					te_gunshot(org)
// used in qcsrc/server/bots.qc:						te_gunshot(org)
// used in qcsrc/server/bots.qc:		//te_gunshot(end)
effect TE_GUNSHOT
countabsolute 1
type decal
tex 56 59
size 3 3
alpha 256 256 0
originjitter 6 6 6
// dust/smoke drifting away from the impact
effect TE_GUNSHOT
count 4
type smoke
tex 0 8
color 0x101010 0x101010
size 3 3
sizeincrease 3
alpha 128 128 64
originjitter 0 0 0
velocityjitter 8 8 8
// dust/smoke staying at the impact
effect TE_GUNSHOT
count 1
type smoke
tex 0 8
color 0x505050 0x505050
size 4 4
sizeincrease 4
alpha 128 128 64
originjitter 0 0 0
velocityjitter 0 0 0
// bouncing sparks
effect TE_GUNSHOT
count 10
type spark
color 0x8f4333 0xfff31b
size 0.4 0.4
alpha 0 64 64
gravity 1
bounce 1.5
velocityoffset 0 0 80
velocityjitter 64 64 64

// crylink impact effect
// decal
// used nowhere in code
effect TE_GUNSHOTQUAD
countabsolute 1
type decal
tex 47 47
size 8 8
alpha 256 256 0
originjitter 12 12 12
//lightradius 100
//lightradiusfade 300
//lightcolor 0.5 0.5 0.5
// purple flare effect
effect TE_GUNSHOTQUAD
countabsolute 1
type static
tex 39 39
color 0x504060 0x504060
size 8 8
alpha 256 256 512
// purple sparks
effect TE_GUNSHOTQUAD
count 12
type spark
color 0xA040C0 0xFFFFFF
size 1 1
alpha 128 128 384
gravity 1
bounce 1.5
velocityoffset 0 0 80
velocityjitter 128 128 128

[Irritant]

Yup, that is pretty clever.

[taniwha]

The concept is great, but the file format is ick: no structure (I like curly brackets), though it does have the plus of not needing anything other than id's (crappy) command-line parser.

[revelator]

tenebraes flex based particle parser could probably be modified to handle stuff like this, the syntax is a bit icky though so im not sure whether it would be a gain.

[Baker]

(I like curly brackets)

I think that would look nice and a regular user using notepad would really mess that up. I forget to end functions with ";" in .h files sometimes and such and I'm careful. I don't think "Hi, I'd like to start modding DarkPlaces, wats QuakeC?" newbie guy would stand a chance against a horde of curly brackets.

Although I kind of sort like curly brackets since they are natural to C and of course the .map files look like that. I think the existing format is ... well at first it seems un-ideal ... but then you think about it and realize it probably is ideal .... all you have to watch out for are typos.

[Spike]

most decent effects depend upon weird engine-specific edge cases. Some of seven's effects also seem to be heavily framerate dependant, and can drop framerates from 2000 to 300 just on their own (less noticable at low framerates, so its okay if you've got rtlights enabled).
I know this from trying to convert seven's effects to fte's custom particle system.

dp's effectinfo stuff is still pretty hardcoded, all you can really do is specify randomized colours+origins+velocities. Basically what I'm saying is 'make a tracer with it'. Also, 'type smoke' is rather ambiguous, and the sort of legacy behaviour that you're probably best without.
Its generally not practical to reimplement, without copy+pastaing the entire gl_rpart.c file or whatever it is.

There's also the fact that it doesn't work with QW-style content downloads, where the mod and all of its content is automatically downloaded from a server file-by-file (as far as I'm aware, dp also has this limitation), while (more vanilla) modified nq clients still only support maps. This limits the use to only single-player mods/content packages.
The network protocol LH added for spawning custom effects from ssqc is also flawed, limiting its reliability and thus usefulness (its based upon csqc, so uses client-specific indexes in the server, which is vile when you consider custom content packages - it should have used precaches).

Also, I like curly brackets too.
They help break up the words and give it structure, instead of it just being a huge great splurge. Makes it so much easier to find the effect you're looking for as you can look directly at the names instead of having to first figure out if it is a name.

No system is perfect, but its at least a step in the right direction.

[mh]

The concept is great, but the file format is ick: no structure (I like curly brackets), though it does have the plus of not needing anything other than id's (crappy) command-line parser.

...and that's actually a major plus. One of the things I would seriously like to subject to the blaze of a billion furnaces is the tendency for every new text file format to need it's own completely different custom parser.

DirectQ's particle system is set up to be almost 100% customizable, but that's not fully exposed through the current engine code. Nearly all particle properties (vel, dvel, grav, ramps, scales, etc) can be set and have their own individual rates of change applied; the big switch statement in R_DrawParticles is gone and everthing is controlled through a single common formula. There's a next logical step to that which is to expose a scriptable interface for it, but somehow that's something I've never really felt motivated enough to do.

[Baker]

dp's effectinfo stuff is still pretty hardcoded, all you can really do is specify randomized colours+origins+velocities. Basically what I'm saying is 'make a tracer with it'. Also, 'type smoke' is rather ambiguous, and the sort of legacy behaviour that you're probably best without.
Its generally not practical to reimplement, without copy+pastaing the entire gl_rpart.c file or whatever it is.

There's also the fact that it doesn't work with QW-style content downloads, where the mod and all of its content is automatically downloaded from a server file-by-file (as far as I'm aware, dp also has this limitation), while (more vanilla) modified nq clients still only support maps. This limits the use to only single-player mods/content packages.
The network protocol LH added for spawning custom effects from ssqc is also flawed, limiting its reliability and thus usefulness (its based upon csqc, so uses client-specific indexes in the server, which is vile when you consider custom content packages - it should have used precaches).

Heh, I love that you always have a list of the situations where X doesn't work ideally. Filed away in the "future planning department."

/My short term interest is to be able to play with particles/particle font and set blend func, etc. in essentially "real-time" so I can things looking nice in private experimentation. I've largely avoided particles in the past.

[szo]

I don't think "Hi, I'd like to start modding DarkPlaces, wats QuakeC?" newbie guy would stand a chance against a horde of curly brackets.

Well then, he should first learn how to use a decent editor, type without typos, code according to a given spec and bear the pain of fixing his mistakes. Otherwise, limiting oneself with such considerations only leads to worse results and it also doesn't help your newbie to learn properly either.

[taniwha]

mh: QF added just the one new text format: OpenStep style property lists. Quake's entity data format is actually very close. Actually, building plists from normal enity data was pretty trivial, and going from this to plists (internally) looks like it would be fairly trivial.

Baker: curlies (or other punctuation) often help (though admittedly not always).

[mh]

mh: QF added just the one new text format: OpenStep style property lists. Quake's entity data format is actually very close. Actually, building plists from normal enity data was pretty trivial, and going from this to plists (internally) looks like it would be fairly trivial.

That sounds like a sensible case; it's also good that it's based on an existing standard rather than having to go off and invent another one.

[taniwha]

Well, QF actually uses property lists in all sorts of places (including saved game data, but reads either). While it's an existing standard, it's rather obscure, not helped by OpenStep having moved on to XML (now that's something I don't want to put into QF. ick).

[Baker]

XML is what happens when you pursue perfection. It becomes a hideous, grotesque failed paradigm. But a "standardized" hideous, grotesque failed paradigm.

The original goal was user-friendly, human readable that even your grandma would feel comfortable editing. *snicker*

So how'd that all work out? *puke*

[leileilol]

One time I made one from scratch with a 256x256 particlefont.

[Spirit]

Don't forget to check out what purplehaze did with FTEQW's particle system: http://www.quakeworld.nu/forum/topic/71 ... le-effects

It looks fairly similar in style but in my memory those effects were much more advanced and custom than DP's.