Sprite Blitting question - Wondering if this is still a problem

Sprite Blitting question - Wondering if this is still a problem

• Grueneis Markus

  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.
  
  

• Florent SANTIN

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

• Kevin Jacobson

  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 ) ) ) );
  

• Stretchcoder

  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.

  
  
  

• cpurick

  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.

  
  
  

• VBwant2B

  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.

  
  
  

• Alger

  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.
  
  

• ink innovations

  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.
  

• DanglingChap

  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;

  
  

• David Graton

  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.
  
  

• GetCode

  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
  
  
  
  

• rternier

  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.
  
  

• Tryin2Bgood

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

• mreitano

  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).
  
• Sprite Blitting question - Wondering if this is still a problem