Skip to main content
GameDev.net gamedev.net
🔒 Locked

Textures looking weird.

Started by VBStrider Feb 5, 2006 at 8:27 PM 9 replies 1.8k views
Original Post
VBStrider
VBStrider
The texture coords for a DirectX8 graphics core I converted from VB6 to C++ are sometimes off by a pixel. Also, the texture grabs too much of a pixel on the edges... For example, I have a square with a 1 pixel thick black border. When I draw it, the left side of the border is 2 pixels wide and the top of the border is 2 pixels wide as well. The right and bottom seem to be fine in most cases (I suspect however that they disappear sometimes). I was originally thinking it had to do with the floating points I had to use, however I doubt a problem like this can be caused by that... It's like DX is stretching it on the left and shrinking it on the right. The graphics I'm using are 2D, not 3D model based. I'm using the following FVF: D3DFVF_XYZRHW | D3DFVF_DIFFUSE | D3DFVF_SPECULAR | D3DFVF_TEX1 Here is the vertex struct: 

// Transformed and lit vertex.
typedef struct TAG_TLVERTEX
{
	FLOAT x;
	FLOAT y;
	FLOAT z;
	FLOAT rhw;
	DWORD color;
	DWORD specular;
	FLOAT tu;
	FLOAT tv;
} TLVERTEX;
Here is a small sample of the calculations, I can give more if you need it: 

fTmpX = fX;
fTmpY = fY + iHeight;

// 0 - Bottom Left Vertex
tlVerts[0].x = fTmpX;
tlVerts[0].y = fTmpY;
tlVerts[0].z = 0;
tlVerts[0].rhw = 1;
tlVerts[0].specular = 1;
tlVerts[0].color = _RGB32BIT(bA1, bR1, bG1, bB1);
tlVerts[0].tu = (float)rctSource.left / desc.Width;
tlVerts[0].tv = (float)rctSource.bottom / desc.Height;
Oh also, this does not seem to happen all the time, and generally only if the texture's tu and tv is 0. VBStrider [Edited by - VBStrider on February 5, 2006 8:50:11 PM]
dave
dave
If you are looking at the texture surface head on and supposing it is flat, with the correct texture coordinates and a perfect texture there is no reason for it to look wrong.

Does your situation satisfy those criteria?

Dave
VBStrider
VBStrider
I'm looking at it head on, the texture is flat, the source coords are correct and the texture I'm using is perfectly normal.

I decided this would be best if you saw the effects... Here is the original graphic in the graphic file (amoung others for the game):


Here it is in the game with the problems.


VBStrider
Namethatnobodyelsetook
Namethatnobodyelsetook
Offset your UVs by 0.5 of a pixel. If your texture is say, 64x256 then add (0.5f/64, 0.5f/256) to your coords. 0,0 is the corner of the top-left texel. By adding half a texel offset you're now sampling the center of the texel.
VBStrider
VBStrider
Alright, thanks, that fixed that problem :).

However, a new one is now rearing it's ugly head... Graphics are sometimes off by 1 pixel. For example, I'm using a tile-based system to draw the map. Well, if I move to the right spot (and while I'm moving) the tiles get pushed down and to the right (or the other way around... not entirely sure) which forms a grid of nothingness...

Here's a sampling of the code that I'm using now:
fTmpX = fX;fTmpY = fY + iHeight;// 0 - Bottom Left VertextlVerts[0].x = fTmpX;tlVerts[0].y = fTmpY;tlVerts[0].z = 0;tlVerts[0].rhw = 1;tlVerts[0].specular = 1;tlVerts[0].color = _RGB32BIT(bA1, bR1, bG1, bB1);tlVerts[0].tu = (float)(rctSource.left + 0.5f) / desc.Width;tlVerts[0].tv = (float)(rctSource.bottom + 0.5f) / desc.Height;


Here's a screenshot. It does not look as bad as it did the first time, so this seems to be partially random.


Any help is greatly appreciated :).

VBStrider
VBStrider
VBStrider
Alright, it seems to just be another form of the previous problem, but appears to be associated with where it's drawn on the screen... Anyways, depending on where it's drawn on the screen it'll grab 1 extra line of pixels on the edges from the image file. So lets say I have a brown tile and a grass tile in the image file one next to the other. I draw the brown tile everywhere and sometimes while the tiles are moved around the screen (map scrolling) a green line from the grass tile would appear.

VBStrider
LeGreg
LeGreg
You should definitely read the article that says "mapping texels to pixels".

This is part of the SDK if you've installed it.

Also read the rasterization rules.

Your triangles or quads have to be unambiguously over the pixels you want to cover else you may miss some due to the imprecisions introduced by the transformation and rasterization process.

LeGreg
Namethatnobodyelsetook
Namethatnobodyelsetook
Are your X and Y coords int or float? I've never used RHW coords with non-int values, and I have no idea what it might do. Obviously you need to store them as float in the vertex, but they should be int based (ie: having no fractional part to them)
VBStrider
VBStrider
X and Y positions are floats since that is what my Time Based Modeling code requires. If I don't use floats, the value may never increase/decrease due to the fraction not being there to "pile-up" the values. If you have ever worked with Time Based Modeling code, you'll know what I mean.

Invisible
VBStrider
VBStrider
Ahhh, figured it out, thanks everyone :).

Namethatnobodyelsetook's last post is what started me thinking along the right lines. I was originally using a local RECT to store destination position information, however I moved the position code directly to fTmpX and fTmpY before I posted here to see if that was the problem. fTmpX and fTmpY are obviously floats, and since the position information almost always has a fraction, that fraction was put into .x and .y, thus causing DX to think that I was trying to place the pixel in an unusual position (such as at half a tile).

VBStrider

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.