The contents of the barycentric coordinatess in the vertex data don't
matter for the dummy vertices, so skip the if and just use the first
barycentric coordinate.
Most important change is to use the arrays directly rather than using
element indices. I don't remember why I did it that way as it gained
nothing and using arrays directly is much simpler.
Also, the "dummy" vertices at either end of the trail are no longer
duplicates of the end vertices, but are now extrapolations. This fixes up
the weirdness at either end of the trails.
The script format is the same as the console command-line, so no new
format :). The scripts are compiled to byte code and cached. They are
referenced by name (eg, "pt_fire"), though the names are likely to change.
It seems to work quite well and should prove to be a good basis for
scripting particle effects in general.
They're actually guaranteed for the first and last segments due to the
first and last points being duplicated in the buffer (simplifies design).
This also handles the rare case where a vector appears to go directly into
or out of the screen.
Everything works nicely if only one of n1 or n2 is 0, and for the very rare
case of both n1 and n2 being 0, then a final normal of 0 is reasonable.
It seems mesa still has the bug where non-array attributes don't work
when set as attribute 0, and that the allocation order changed sometime
since I last tested with mesa. This fixes the black world and flickering
alias models on my eeepc.
So far, alias model rendering is the only victim, but things are working,
even if only color map lookup and fog blending are broken out at this
stage.
I expect the effect naming scheme will go through some changes until I'm
happy with it.
Again, based on The OpenGL Shader Wrangler. The wrangling part is not used
yet, but the shader compiler has been modified to take the built up shader.
Just to keep things compiling, a wrapper has been temporarily created.
I'd missed a set of bit->lightnum conversions that resulting in lightnum
becoming much greater than 128 and thus trashing memory when the surface
was marked.
The seed is currently 0xdeadbeef, but I intend on fixing that soon. Now the
particle velocities and origins use fully independent bits (though a big
chunk is wasted right now).
This is a quick fix until I get a random number generator into QF.
Mingw's RAND_MAX is only 0x7fff and so the (((rnd >> 10) & 63) - 31.5) / 63.0
used for the z component of origin and velocity would never go positive.
For now, change the 10 to 9 (reusing another bit from Y). I plan on
implementing a full 32-bit PRNG in QF so we always have a reliable
generator.
It was properly cleared after drawing water chains and sky chains, but I
had missed normal surfaces. It took the use of the same texture for both
normal surfaces and water surfaces to trigger the bug. Thanks go to Simon
'Sock' O'Callaghan and his In The Shadows mod.
