TheFallenOne

You can easily pre-define texture coordinates and the overhead (even when doing it as a one time only event) is minimal.

 

This is the code that I use to do option #1 for my game:

 

void get_tex_coords( struct texture_t* t, struct Rect* r, D3DXVECTOR2* tc )
{
    tc[0].x = r->x1 / t->width;
    tc[0].y = ( r->y1 / t->height );
    tc[1].x = r->x2 / t->width;
    tc[1].y = ( r->y1 / t->height );
    tc[2].x = r->x2 / t->width;
    tc[2].y = ( r->y2 / t->height );
    tc[3].x = r->x1 / t->width;
    tc[3].y = ( r->y2 / t->height );
}

 

Since it was originally written for OpenGL, I modified it a bit to make more sense for Direct3D users.  It's really simple once you understand that you're just getting the coordinates by getting the x,y position followed by the with,height while adding the x,y coordinates.  That will give you your exact coordinates for each sprite on the sheet! 

 

Shogun

Yeah, that's the easy part.  Unfortunately, I can't precalculate values in this case.

The sprites can be rotated on the sheet, and will need to have extra transparent space added on to them, which means the calculations will have to be done in the shaders. It's not the calculations I'm worried about anyways, it's the extra data being sent down the pipeline.

For instance, my model shader takes 4 textures (for various lighting effects, etc).

That means that for every model drawn, just to use sprite sheets (and remember these are ONLY in use if the texture is animated, which is the exception rather than the rule) I have to include:

-8 extra float2's (a texture coord range for each texture, specifying where on the sprite sheet to take it from)

-Another 16 float2's (final texture width/height and the texture offset, so transparent space can be added in the shader and the texture can be properly aligned)

-8 boolean values (specifying if the texture is rotated on the sprite sheet)

Plus all the calculations to make those function. All done in the shader.

Feels like a huge chunk of data to be sending down the pipeline with every shader for functionality that's not going to be used in the majority of cases... Maybe I'm worrying over something that won't really be causing any serious issues. It likely won't cause any performance hit whatsoever, just feels like I'm adding a lot of bloat to the system.

Thanks for the input though guys.

A cube map isn't sampled using uv(w)s (in the range [0.0, 1.0]), but using an (un)normalized vector, usually a (reflected) vertex surface normal.

Since you are drawing the map unto cube, you can simple use the cube's object space vertices to sample the cube map.

e.g. left top far vertex:

pVertex[0].fU = -50000.0f;
pVertex[0].fV = 50000.0f;
pVertex[0].fW = 50000.0f;

VS: output.Position = float4(TexCoords + xCameraPos, 1.0);
PS: output.Color = texCUBE(TextureSampler, TexCoords);

Awesome, this solved the issue! Thanks a million.

Sad, because I read that it uses a vector to determine texture coordinates in several different places... I guess it just never clicked.

Thanks to you other two as well!!