I understand the whole texel-pixel filtering issue that causes the problems with averaging the edges of a texture with the transparent pixels getting something ugly and halfway in between. However I don't know how to fix this while using world space and not screen space coordinates for d3dxsprite. It would seem that in screen space youd just add an 0.5 pixel offset wherever you're drawing but in 3d the coordinates dont match pixels on screen. I've seen other solutions elsewhere on searches, such as texture clamping or point filters, but it doesnt fix the issue. I don't want to use a hack like setting a D3DRS_ALPHAREF render state cutoff, either. I think i would want to be setting an 0.5 u/v offset for the loaded textures but I don't know how to do that with d3dxsprite

 http://sqpat.com/project/mysample23-spriteobjectsbetter.PNG

Right there, you can see it happen here in d3dxsprite. it's those bright green borders you see around the bushy objects. The transparent color is (0, 255, 0) in RGB, and it's halving that. 

Any ideas?

The requirement is that the texel centers be offset by 1/2 a screen pixel.  If you are positioning a textured quad in world coordinates, then you have to work backwards to figure out how much of world coordinate space corresponds to half a screen pixel.  This is a straightforward scaling operation for an orthographic projection, but for a perspective projection, it will depend on depth as well.  Of course once you're scaling a sprite, you're going to get filtering anyway and you can't map texels to pixels exactly regardless.

Well, maybe I didnt explain it well. All I want to do is prevent artifacts I get from averaging the edges of a texture with either a transparent pixel or whatever is on the other sides of the texture, because this is also happening to me on my terrain rendering as such:

http://sqpat.com/project/mysample25-morebadtextureborders.PNG

Not necessarily exact texel-> pixel mapping like it would be in 2d, i just want to prevent the edge artifacts that appear. I think its the same beast, you want to offset the u and v for the vertices by screen-size based value and maybe mess with some texture filtering properties. It's got to be possible somehow, because every 3d game uses textures somehow, and many use sprites or textured quads with transparency in some way, and I know they don't get ugly lines or edges when placing textures side-by-side. But even when I change the min/mag/mip filters to something like point filters it doesn't work, neither on D3DXsprite nor on regular triangle primitives.

Also you mention textured quads, but d3dxsprite is a bit different than a primitive with vertices in that you can't really define u and v, you just define the bounds within a texture with a rectangle; so there doesn't seem to be a way to give decimal offsets, am I correct? (I really don't want to switch to actual textured quads because batching sprites seem to be faster. But i guess I'll experiment if i have to.)

In addition, calculating the offset including pixel depths and such seems to be terribly inefficient to do for every vertex of every on screen object.

Please load that image into mspaint and draw some red circles or arrows pointing out the problem you're trying to fix.  You need to be more specific.

I meant like the following:

http://i33.tinypic.com/20sw3s4.png

sorry that i wasnt specific enough before. ANyways it looks like its averaging the far left texel with the far right texel, and top/bottom, etc.

First I'd double check that the tiles are made up of vertices that have that share the exact position values at the shared edges. The second problem that will show up next is texture sampling discontinuity..

Your best bet is to use continuous geometry with Wrap addressing and tex coordinates that span the [0,1] range. Here is an ascii art example:

 

(0,0)     (1,0)      (2,0)
-----------------------
|          |          |
|          |          |
|          |          |
|          |          |
|(0,1)     |(1,1)     |(2,1)
|----------|----------|
|          |
|          |
|          |
|          |
|(0,2)     |(1,2)
------------

The above example shows three tiles. The numbers are texture coordinates for the vertices making up the tiles. The fact that the numbers are continuous will make D3D sample the texture continuously without discontinuities.

Yes, I agree with Wessam :-).

It looks like you could either have cracks in your geometry (because the tiles don't have vertex coordinates that match exactly), and/or you are getting artifacts from blending texels "off" the texture with the texels at the edge of the texture.  The wrap addressing mode is particularly appropriate for repeated grids of tiles because the right edge of a tile is adjacent to the left edge of the next tile, so using the wrap addressing mode is the right thing to do.  If you have different tiles adjacent to each other that don't have common boundaries, then you probably want those tiles to use clamp so that the blending doesn't go off the edge of the texture.

A discussion of the addressing modes is in Chapter 11. Basic Texturing from my book "The Direct3D Graphics Pipeline".

Wessam Bahnassi:

First I'd double check that the tiles are made up of vertices that have that share the exact position values at the shared edges. The second problem that will show up next is texture sampling discontinuity..

Your best bet is to use continuous geometry with Wrap addressing and tex coordinates that span the [0,1] range. Here is an ascii art example:

 

(0,0)     (1,0)      (2,0)
-----------------------
|          |          |
|          |          |
|          |          |
|          |          |
|(0,1)     |(1,1)     |(2,1)
|----------|----------|
|          |
|          |
|          |
|          |
|(0,2)     |(1,2)
------------

The above example shows three tiles. The numbers are texture coordinates for the vertices making up the tiles. The fact that the numbers are continuous will make D3D sample the texture continuously without discontinuities.

The vertices definitely have the same texture coords because its an indexed set of vertices. As for sampling discontinuity, I know that's not it... because i'm already doing continuous wrap texture addressing! Each vertex i have increasing in u or v by a whole number like you said. As for clamping i had toyed with it a little bit with sprites, but it sounds like a good idea for textures. I'll be sure to try it.   Oh, and lastly, i think i have a solution to the sprite borders. I think i can use an alpha stencil to not draw any parts of it that are below the alpha value that i know i will specificy in the sprite->draw call. That way the border, which averaged argb with the alpha part, will have a lesser alpha value and will not be rendered.

Okay, I think i've got it figured out. Its definitely a filtering artifact and theres nothing I can do with respect to modifying texture coordinates because I have wrap coordinates with indexed vertices being reused, which I can't have multiple u/v values for to do something like clamping.

However, on the textures where this is a big problem, I can do point filtering to get by the problem. I think I'll just add some bytes to my map header to control the min/mag/mip filters for that map. Linear/anistropic looks good in general, for terrains that are grassy or rocky and generally uniform, but for cases where texture borders are important I can do point filtering to make sure I get exact results.

Setting the point filter for the sprites where borders were a problem also worked; if I did the alpha stencil solution like I said I would try, sprites become thinner and lose detail cause I lose about a half pixel of detail/dimension to those borders bein filtered out.

Then again, I've implemented loading of external objects to place on the map from file; that's how these sprites are loaded.. I can probably do the rug this way, having it use point filtering while I do the regular checkerboard floor texture by way of linear/anistropic filtering as usual to get an overall good effect.Yeah, I think that'     s what I'll do.

By the way, how do D3DTEXF_PYRAMIDALQUAD and D3DTEXF_GAUSSIANQUAD work? They seem basically the same as point filtering... maybe its just my card not supporting them?

Thats because apart from some intel IGP's it's not supported by any card look at %ProgramFiles%\Microsoft DirectX SDK (June 2008)\Samples\C++\Direct3D\ConfigSystem.