[SlimDX] Texture Filters

Started by
3 comments, last by RyxiaN 13 years, 1 month ago
Hi!

I recently decided to port my small 2D engine made with Managed DirectX in C# to SlimDX. Much of SlimDX 9 is the same as MDX, but I noticed one difference that I'm having problem with. I think it has something to do with texture filters. I'm using TransformedColoredTextured quads to render textures. Take a look at this figure:
TextureFilter.png?t=1299142172
The left part is how it would look in my engine in MDX, without touching any sampler states or render states (except Alpha blending). This is how I want it to look. The middle part is how it looks after I ported it to SlimDX, again without touching any sampler states or render states. The right part is like the middle, but has, as stated, linear MagFilter. It's kinda close to the MDX but not quite. The 100% scale one is kinda blurred too, which is not something I want.

So, what kind of filters do I need to mess with to get the result I get in MDX?

I also tried using the Sprite class in SlimDX, and it gives the result I want. But I would really prefer to use Quads. And I'm pretty sure the Sprite class uses the Quad method internally, so it must be possible.

Any advice? (: Thanks in advance!

// Anton
Advertisement
You have to be careful when loading your texture, to make sure that you're performing the same operations in both versions. Two things that can happen during texture loading are scaling to a power-of-2 size, and generating mip maps. So you should check the documentation for the overload of Texture.FromFile that you're using, and make sure the parameters and defaults match the equivalent from MDX.

Also, make sure you're setting the same MIP filter since that can also change the look of your sprites.
Thanks for the answer, MJP! The texture I'm messing with is 64*64 and I'm specifying 1 on the mipmap level parameter, in both versions. Actually, all parameters in both versions are identical. I also tried setting every single Sampler State to the equivalent one in MDX, but without results. So don't think any of the mentioned is causing it.
There is one thing that I really should've mentioned though... In MDX I used PositionColoredTextured vertices. I remember I tried to use TransformedColoredTextured, but I got the same blur I get now. It worked out with Positioned. But firstly: Transformed is the way to go when drawing 2D stuff right on the screen, ain't it? Secondly, Positioned in SlimDX gave the same results as Transformed, except that it was harder to code as the coordinate system is a little odd ((-1, -1) is the top left corner, (0, 0) is center, and so on...).

Any advice is appreciated! Would really like to avoid going over to the Sprite class... :)

// Anton

Thanks for the answer, MJP! The texture I'm messing with is 64*64 and I'm specifying 1 on the mipmap level parameter, in both versions. Actually, all parameters in both versions are identical. I also tried setting every single Sampler State to the equivalent one in MDX, but without results. So don't think any of the mentioned is causing it.
There is one thing that I really should've mentioned though... In MDX I used PositionColoredTextured vertices. I remember I tried to use TransformedColoredTextured, but I got the same blur I get now. It worked out with Positioned. But firstly: Transformed is the way to go when drawing 2D stuff right on the screen, ain't it? Secondly, Positioned in SlimDX gave the same results as Transformed, except that it was harder to code as the coordinate system is a little odd ((-1, -1) is the top left corner, (0, 0) is center, and so on...).

Any advice is appreciated! Would really like to avoid going over to the Sprite class... :)

// Anton


In that case it could be the half-pixel offset that's screwing you up. If you want to make the coordinates simpler, you could use an orthographic projection. Make the projection have the width and height of the screen, and then you can position your quad using screen coordinates (offset by a half unit if you want to the quads to exactly line up with pixels).
It was indeed the half-pixel offset that screwed up, thanks a bunch for pointing that out! :D Looks great now!

This topic is closed to new replies.

Advertisement