Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Oct 2010
Offline Last Active Oct 09 2014 06:59 PM

Posts I've Made

In Topic: Sprite Sheets and Texture Splitting

20 March 2013 - 06:07 PM

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! smile.png





Yeah, that's the easy part. smile.png 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.

In Topic: Skybox Rendering Issue

05 January 2013 - 05:29 PM

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. :D


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!!

In Topic: Creating a window at proper resolution

28 October 2010 - 07:42 PM

Original post by Wyrframe
I'll assume you are aware that those 14 pixels are the ones taken up by your title bar, and past the question itself to some possible solutions.

Yeah, I'm aware of that, thanks though. :)

Option 1. Calculate your aspect ratio based on the client area of the window each time the window changes size (including when it is initially made visible). These days, with screen resolutions in not just 4:3, but also 5:4, 16:9, and 16:10, you either have to letterbox, or adapt to whatever you end up with. This sounds like a case of the latter.

I've actually got a good system in place to deal with different aspect ratios, the only issue is that 1280x786 isn't, well... a traditional aspect ratio, to say the least, haha. I can make some adjustments in renderer to allow for this discrepancy between requested window size and received window size, but I would really rather not have a user get a smaller resolution (even if it is only 14 pixels smaller) than he requested simply because he wants to use windowed mode.

Option 2. Ditch the Windows titlebar and draw your own minimize/close buttons in the top corner. Lets you utilize the rest of those rows of pixels.

Actually not a bad idea at all, though a good portion of the reason the title bar is there is to allow the user to move the window. I suppose I could code a smaller little section alongside of those allowing them to move the window, but these buttons would not be visible in fullscreen mode, meaning that the top right hand corner of the screen would be unusable in fullscreen, since windowed users would not be able to see it. I don't really want to waste screen space unless absolutely necessary...

Option 3. Go traditional fullscreen.

The problem is that the user has complete control over resolution, fullscreen and windowed mode, and I'd like to keep it that way... I'm not going to force them into fullscreen mode just because of some differences in resolution between fullscreen and windowed.

Thanks for the suggestions, I'll take them into account. :) I'll play around with a few ideas you gave me. However, if anyone else has any input on bypassing the issue directly, it'd still be greatly appreciated.