Sprite Blitting question - Wondering if this is still a problem

Ecrofirt

Hi all,

When Beta 1 was out I dove right in and started working on a simple demo that moved a sprite with some alpha transparancy around the screen.

The way I had it set up was something like this:
-I had a class set up for the sprite that I called Player
-The Player had a Vector2 for his screen position.
-If the user was pushing the left thumbstick in any direction, the Player class's move function was called ,where a new X and Y location was made based on the angle that the thumbstick was pointing.
-When Drawing the sprite, I'd get the sprite's screen position vector via a get property.

Doing it this way often made my screen position vector have decimal values for the X and Y screen position of my Player sprite. This caused some funky issues when blitting the sprite to the screen, where there'd be a weird outline around the sprite as I moved it around certain parts of the screen.

Eventually I realized this was because I was trying to blit the sprite to a screen point like (320.53, 240,19) as opposed to blitting to a screen location like (320,240). What I did to compensate for this was basically send back a new Vector2 location with the screen position rounded to integers whenever I wanted to get the Player's current location for blitting.

Unfortunately I've since altered the code to the point that I really don't want to go and toy with it at this point to see if it would still do the same thing in the 1.0 GSE release, and I was wondering if anyone knows if this still happens. Since I ran into that problem with Beta 1, I've always just blitted my sprites to whole number positions on screen to avoid this possible conflict.

And can someone perhaps give me an idea as to why exactly I was getting that weird outline around the sprite if I wasn't blitting the sprite to an exact integer location I'm really just wondering what the exact reason is that something like this happened.

I can post pics of the odd outline if need be, but it might take a little while to find them again.

waruwaru

when the sprite isn't moving, do you still get the weird outline If you put a breakpoint before going to the next frame, do you see the outline If no to both questions, then I guess your sprite was "jittering" between different coordinates because of how the numbers are rounded to integers.

parlance

Can you be a little more specific when you say 'weird outlines' What kind of texture were you using for the player sprite Did it have an alpha channel If so, did the opaque areas of the player sprite touch the edges of the texture Also, was either of the dimensions of the texture a non-power-of-2 number Any of these have an effect on the filtering of the texture data, which comes into play when the rasterizer has to come up with a pixel value for a fragment that isn't necessarily aligned to the pixel that resides in (this is referred to as sub-pixel filtering or accuracy).

LeeC22

It sounds like interpolation fuzz... If you have a black pixel moving over a white pixel, if the black pixel is at xx.5, I am guessing the draw system would interpolate a grey value to approximate the partial pixel...

I'd personally keep the movement as float values (as floating point movement is more flexible) and the drawing as integers... as you were doing.

Ecrofirt

here we go:
OK, for my textures I had this issue using both a .PNG fine and a .dds I made using the texture tool (from both my PNG and a .BMP after following the XNA guide).

My sprites weren't standard sizes. The player sprite was 96x54 (here's a link to a .png of it: http://img46.imageshack.us/img46/8177/playerfx0.png - note that that's a tileset with a walking animation)

At the moment I'm having trouble finding a screenshot I took that clearly shows the problem, but I'll keep looking. I do have a video of it, though:
http://www.nformant.net/XNA/movie1.avi

If you blow the video up to fullscreen, you can see that in the very beginning the player sprite looks very good. As I move it to the right side of the screen, it gets a white outline (around 3 seconds in or so), and this disappears again as it moves back left. It's not simply a video compression error, as I made the video to show off what i was noticing while playing.

I found part of the code I was using in my Move function that set the new location for the player. Here it is:
//this is the movement function. It moves the player around based on the controller values it's sent
public void Move(float x, float y)
{

//This moves the X and Y locations for the player based on how the thumbstick is pointing
location.X += 2 * ( (float) ( Math.Cos( Math.Atan2( (double)y, (double)x ) ) ) );
location.Y -= 2 * ( (float) ( Math.Sin( Math.Atan2( (double)y, (double)x ) ) ) );

LeeC22

Can't play the video, what codec did you use

parlance

Although XNA allows you to load non-power-of-2 sized textures, an important thing to realize is that the results of mipmapping and trilinear filtering become undefined because it's not possibly to generate a perfect mipmap for a texture in which each dimension cannot be divided by 2 until it reaches the 1x1 pixel mip level. Normally this wouldn't have been a problem anyway, but filtering artifacts are occuring because you are using a sprite in which the the opaque texels for each frame neighbor opaque texels for subsequent frames, and the edge of the texture itself.

The simplest solution is to disable trilinear filtering, which won't be noticable unless you plan to scale or rotate the sprite when drawing it. You'll also see the white lines return if the size of the sprite drawn on screen isn't _exactly_ the same as the frame size in pixels. A more robust solution would be to modify your texture to give a 1 pixel border of transparent pixels around each frame so that no opque pixels in a given frame neighbor the edge of the texture or any other opaque pixels of a different frame. Here is the code to disable trilinear filtering though:

graphics.GraphicsDevice.SamplerStates[0].MinFilter = TextureFilter.Point;

graphics.GraphicsDevice.SamplerStates[0].MagFilter = TextureFilter.Point;

graphics.GraphicsDevice.SamplerStates[0].MipFilter = TextureFilter.Point;

Ecrofirt

I encoded it using SUPER with the H264 MPEG4 codec. It's 640x480.

I'll try and get a blown-up screen grab of the problem. Give me a few minutes.

Ecrofirt

OK, please forgive my ignorance here, but I thought mipmaps only came into play if I was scaling the texture down. As the game was programmed, the sprite was shown at exactly the same size on screen as its corresponding tile in the tileset.

And again, forgive the ignorance here please, but how is it that this artifact only becomes apparant if the sprite is drawn on screen at locations that aren't whole numbers

Thanks for the info here, he's helping me a lot.

parlance

Saying that mipmaps only come into play when 'a texture is minified' oversimplifies what is actually happening under the hood. Texture samplers select a mimap level based on the magnitude of the screenspace derivitive of the uvw coordinates in both the x and y directions. This in part is why even though if you didn't scale a sprite, but you rotated it only, you would see different results with and without mipmapping enabled. The exact implementation of how these derivitives are calculated in hardware vary from graphics card to graphics card and are part of the reason you see image quality (usually referring to anti-aliasing or filtering) comparisons in graphics card reviews nowadays. Without getting into too much math or drawing some diagrams, it's suffice to say that the subpixel location of a vertex in screenspace is one of the things that could affect how these derivitives are calculated. Try disabling trilinear filtering using the code snippet I posted above and see if that fixes it, if not, try editing the texture to add that extra transparent border pixels to each frame like I said. I'm pretty sure that either of those should take care of the problem.

Ecrofirt

Thanks a ton for the information you provided. It'll help with stuff I do in the future.

Ecrofirt

OK, so I finally had time to go and change around my .png and my code so I could retest this.

As it stands now:
1) I'm trying to draw the character to a Vector2 destination again, rather than a Rectangle. I'm STILL noticing the white lines.
2) I've made my player tileset 128x128, and put a clear 1 pixel border around each frame, as well as along the top of the image.
3) I've got my code set up to grab each frame from the correct spot in the tileset.
4) And yes, I made sure to update the player.png that my project uses so that there's no chance of that still using my old image.

Here's a good example of the white outline:
http://img395.imageshack.us/img395/3568/outlinejf6.png
(taken with a print screen, and blown up 500x in Paint and saved as a .png for maximum color preservation and small file size.)

In fact, here's my current player tileset:
http://img157.imageshack.us/img157/9196/playerzh2.png

So, since I've gone ahead and changed this stuff around, can someone care to explain to me why this is still happening as I move the sprite around to various places on screen

If need be, I can zip up my entire source code and post it on here so I can get some answers.

Thanks a bundle as always,
James O'Meara

LeeC22

I am guessing that seeing as the image in the screen grab has more shades than the sprite sheet, there is some filtering going on. It's quite possible that it is trying to filter between the light grey and the edge of your sprite before the image is drawn onto the screen. Or even between the solid colours and pure transparent as it is drawn to the screen, which would result in areas of reduced transparency. Additive blending mode would cause the values to be added to the background colours resulting in a brighter area around the sprite. I.e. 0x008000 plus a partialy transparent grey (the result of blending black to transparent) could end up as something like 0x20A020, a lighter shade of green.

If you change your light grey background on your sprite sheet to bright magenta 0xFF00FF, does it change the colour of the outline

See this picture, which was simply created by loading the image into photoshop and increasing the size with a bicubic filter... notice how there is a white edge even though there was no white around the edge. You can get some very strange effects from filtering, often, not what you would expect.

http://www.digital-essence.co.uk/misc/white_edge.png

Sorry I can't offer any more help but after seeing the image, the filtering issue seems to be the logical conclusion.

Ecrofirt

Hey, thanks for trying to figure this out.

I guess I just find it weird that it only happens if I move the sprite around to certain regions of the screen. I'd imagine it's got something to do with the filtering taking place when I'm drawing it to a non-strict integer location (something like say (100.5,200.5) ). Perhaps the graphics card has to decide where to put it, and filtering comes into play to make it look good

For instance, here's a shot of it from the beginning of the demo where the sprite is still crystal clear.
http://img363.imageshack.us/img363/3931/outlineeo6.png

And as such, I'd imagine that means I should always make sure I'm drawing 2D sprites to strict integer locations on screen

Oh, and that light gray you were referring to is actually a 50% opaque black, but I can't imagine that really matters all that much.

LeeC22

Moving 2D objects by partial pixels is generally not a good idea. Having their movement in floats isn't bad but you should generally move them on integers to avoid any filtering problems.

What you are seeing is a trick I actually use when animating sprites. By using variations of shade, you can create subtle motion without actually moving any pixels. Works nice for hair or areas of a sprite that wouldn't move massive amounts. It only works on the inside of a sprite though as you have no control of what colour the sprite ends up next to (or on top of).

Try confining your movement though and see if that improves it.