Sprites

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Sprites

Post by Baker »

The sprite calculation code in GLQuake looks like it takes the "long way".

In particular:
{ // normal sprite
up = vup;
right = vright;
}

...

glTexCoord2f (0, 1);
VectorMA (e->origin, frame->down, up, point);
VectorMA (point, frame->left, right, point);
glVertex3fv (point);

glTexCoord2f (0, 0);
VectorMA (e->origin, frame->up, up, point);
VectorMA (point, frame->left, right, point);
glVertex3fv (point);

glTexCoord2f (1, 0);
VectorMA (e->origin, frame->up, up, point);
VectorMA (point, frame->right, right, point);
glVertex3fv (point);

glTexCoord2f (1, 1);
VectorMA (e->origin, frame->down, up, point);
VectorMA (point, frame->right, right, point);
glVertex3fv (point);
It is taking the up and right vectors (angle vectors output) for the player angles and multiplying (+adding) them into the vertices.

Shouldn't it just ignore the sprite angles and use the player's own view angles and use those to calculate the modelview matrix (i.e. translate on origin, rotate on the viewing player angles, maybe scale on something if any sprites even do that in Quake)?

Or am I missing something here? The reason I ask is that the RMQ Engine seems to take the "long route" too, so I am wondering if there is some factor I am not taking into consideration. I mean I wouldn't think MH would take the "long way" for no reason since he always rewrites anything he thinks is wasteful into "properness".

[I'm referring to standard sprites (i.e. always facing you, like explosion sprites) here, not the oriented ones, etc ...]
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Sprites

Post by mh »

There is a "short route" available for sprites involving some creative vertex shader use, that allows you to use instancing (one vertex per sprite) and store your sprite verts in a static VBO. Even if instancing isn't available the static VBO option still is. I just never got round to implementing it.

In Quake 2/D3D9 terms (probably the most comparable) the drawing function looks like this:

Code: Select all

void R_DrawSpriteModel (entity_t *e)
{
	// don't even bother culling, because it's just a single polygon without a surface cache
	dsprite_t *psprite = (dsprite_t *) e->model->extradata;
	int framenum = e->frame % psprite->numframes;
	dsprframe_t *frame = &psprite->frames[framenum];

	d3d_State->SetTexture (0, &d3d_SpriteSampler, e->model->skins[framenum]->d3d_Texture);

	d3d_State->SetVertexShader (d3d_SpriteVS);
	d3d_State->SetPixelShader (d3d_SpritePS);

	d3d_State->SetVertexDeclaration (d3d_SpriteDecl);
	d3d_State->SetStreamSource (0, d3d_SpriteBuffers[e->model->bufferset].VertexBuffer, 0, sizeof (spritevert_t));

	d3d_State->SetVertexShaderConstant3fv (10, e->origin);
	d3d_State->SetPixelShaderConstant1f (c_ps_alpha, (e->flags & RF_TRANSLUCENT) ? e->alpha : 1.0f);

	d3d_Device->DrawPrimitive (D3DPT_TRIANGLESTRIP, framenum << 2, 2);
}
And the vertex shader like this:

Code: Select all

float4x4 WorldMatrix : register(c0);

float3 upVec : register(c6);
float3 rightVec : register(c7);
float3 entOrigin : register(c10);

PS_INPUT SpriteVS (VS_INPUT vs_in)
{
	PS_INPUT vs_out;

	vs_out.Position = mul (WorldMatrix, float4 (rightVec * vs_in.Position.y + (upVec * vs_in.Position.x + entOrigin), 1));
	vs_out.TexCoord = vs_in.TexCoord;

	return vs_out;
}
The full instanced/batched/aligned/etc D3D11 code is of course quite a deal more complex.

In practice I consider sprites to be something of a micro-optimization as there's never many of them on-screen at once and there's not much potential to be had from optimizing the vertex submission. Batching them can be more useful for maps that make heavy use of the light globe sprite, or that replace particle effects with sprites, but they're far more likely to bottleneck on fillrate.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Sprites

Post by Spike »

changing matricies is generally quite expensive, as a simple matrix change will break your batch after every single sprite.
this is true even with glBegin, as the driver will generally auto-batch those for you.
if you do submit a matrix you're uploading a 4*4 modelview matrix, vs the 4 * 3 vertex coord floats you'd otherwise upload.
at the end of the day it makes little difference.

besides, the up+right stuff is basically a matrix anyway.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Sprites

Post by mh »

And when you think about it, sprites actually share a lot of properties with particles (especially if your engine does sexy textured particles) so a reasonable approach may be to amalgamate the two.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Sprites

Post by Baker »

Spike wrote:changing matricies is generally quite expensive, as a simple matrix change will break your batch after every single sprite.
Ok, I see. Obviously, I wasn't aware of the batching thing. Makes a great deal of sense why MH didn't do the "non-optimization" I thought of as simpler code. :D

Stuff I didn't get -1.

@MH yeah particles + sprites ... makes sense now that I am aware of the above infos. And I see from the notes above that you don't view them worthy of culling.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: Sprites

Post by frag.machine »

mh wrote:And when you think about it, sprites actually share a lot of properties with particles (especially if your engine does sexy textured particles) so a reasonable approach may be to amalgamate the two.
Makes sense, if you restrict it to non-oriented sprites.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Sprites

Post by leileilol »

now what if those sprites supported scaling and were integrated into the particle system.......... in software?

Heretic II and Half-Life did this.
i should not be here
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Yay 3D Ortho!

Post by Baker »

3D Ortho!

I'm sure Spike will find this anti-climatic since Quake III throws models into the HUD --- and I didn't actually check out Quake 3 source, but looked a little @ "csqctest" but mostly ignored what I saw not liking it.

Fun part of this is that 3D ortho really requires having an open-source version of glFrustum to inspect the matrix calculation (like in Remake Quake engine) or there are glFrustum open source codes out there at github for various stuff including, say, the PSP (just coincidence that the PSP version is easy to find). And you need gluUnproject to validate your expectations (otherwise it would be near impossible hit and miss trying to guess). Had to muck around with the FOV values to get a number that created nice matrix values (you know, like 1 or some number that is an obvious X/Y) versus some floating point # with a crapton of digits. Then write a couple of functions translating the ortho coordinates you want to pretend you are using to the ones where Z = 1.

But the fun thing, and I haven't done this yet: but I should be able to translate, rotate, scale the modelview matrix at will. Which means I can draw 2D and spin it, rotate it, bob it up or down. Or any kind of 3D treatment I want. While I haven't done any 3D effects, I certainly have 3D ortho working after 2 hours of tweaking, inspecting, planning (and a few failures where concepts failed).

Kind of nice how the possibilities increase when you know more stuff and actually reach the threshold of understanding topics that were once out-of-reach :D

/ I wasn't actually shooting for 3D ortho when I asked the sprite question ... but the discussion about not recalcing the matrix with each sprite/particle got me thinking of 2D vertices and I kind of spontaneously thought of something I wanted to try.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Sprites

Post by mh »

Nothing special about glFrustum - the matrix it calculates is given here: http://msdn.microsoft.com/en-us/library ... 85%29.aspx
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Sprites

Post by Baker »

mh wrote:Nothing special about glFrustum - the matrix it calculates is given here: http://msdn.microsoft.com/en-us/library ... 85%29.aspx
I didn't think of that, I used a "man page" description of glFrustum at first --- I couldn't tell you why --- and it had incomplete information not giving me enough info about what glFrustum does (causing me to come up with a couple of ideas which failed).

Either that or I wasn't paying enough attention to what I was reading or didn't scroll down :D
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Post Reply