sprite edge flickering
by Dan Pascal · in Torque X 2D · 02/11/2010 (3:05 pm) · 8 replies
this seems to happen with tgb people, txb doesn't have a filter map option however..
I can post a sample of whats happening, but basically, the animated sprite, on it's edge pixles, flickers either white or is playing the pixle edge of the other side of the sprite, (or something), when the camera is moving around. After repositioning the camera abit it will go back to normal, but then flickers again while moving about
this is when using animated sprites like tiles in a tile map
I can post a sample of whats happening, but basically, the animated sprite, on it's edge pixles, flickers either white or is playing the pixle edge of the other side of the sprite, (or something), when the camera is moving around. After repositioning the camera abit it will go back to normal, but then flickers again while moving about
this is when using animated sprites like tiles in a tile map
About the author
#2
04/27/2010 (9:55 pm)
I don't know if you found a solution to this or not, but I found making the sprite's total dimensions on a side to be some power of 2 (e.g. 128, 256, etc.) stops the flickering in Torque Game Builder 1.7.4. I haven't found any other solution yet. 
#3
04/28/2010 (12:43 pm)
That looks like the TGB Adventure kit sprites? 128x128. I've had this problem too, its driving me insane!! lol. 
#4
You can achieve this manually and therefore ensuring that your frames are not edge to edge with each other.
If you don't do this you get frames bleeding into each other as the graphics card samples each texel.
You should not see this if you were to set the texture sampling to nearest-neighbour (as a test) but that sampling method gives you pixellation.
Look at the Wikipedia link above in the "Special Cases" section. There it discusses briefly this issue albeit in technical terms of pixel coordinates that lie outside of the grid of texel coordinates (frames) and how to handle them. In other words, your "frame" texels are not the only ones used in all cases, bilinear filtering uses the texels that surround those texels and in the case of your "frame", the ones above, below, left & right. If those surrounding texels are other frames then it'll sample those texels (bleeding). Padding makes a copy of the frames texels above, below, left & right so that when this happens, it only sees the same texel.
Hope this helps.
04/29/2010 (1:12 am)
The filter padding option I added to TGB simply copies a single texel frame around each frame (padding). This is due to the way that bilinear texture sampling (filtering) works on all graphics cards (nothing to do with TGB or TX).You can achieve this manually and therefore ensuring that your frames are not edge to edge with each other.
If you don't do this you get frames bleeding into each other as the graphics card samples each texel.
You should not see this if you were to set the texture sampling to nearest-neighbour (as a test) but that sampling method gives you pixellation.
Look at the Wikipedia link above in the "Special Cases" section. There it discusses briefly this issue albeit in technical terms of pixel coordinates that lie outside of the grid of texel coordinates (frames) and how to handle them. In other words, your "frame" texels are not the only ones used in all cases, bilinear filtering uses the texels that surround those texels and in the case of your "frame", the ones above, below, left & right. If those surrounding texels are other frames then it'll sample those texels (bleeding). Padding makes a copy of the frames texels above, below, left & right so that when this happens, it only sees the same texel.
Hope this helps.
#5
I'm not sure that this same option exists in TX. I've had variations of this problem since I began working on my prototype in Torque X.
If it does exist...I'm not sure where how to turn it on. If it doesn't exist...it'd be a nice feature to have.
The only way I've seen this disappear is by making sure your objects are always positioned on "whole number" coordinates. IE...make sure you don't perform any movements of any sprites that would land you on a fractional coordinate (IE SomeSceneObject.Position == [100.4, 200.6]). This also requires the source code and a change to the default SimpleMaterial shader code.
If you do not have the source code, then you have to compensate for the default shader by making sure all of your scene objects are positioned at "point-five" coordinates...this is counter to the solution I mentioned in the previous paragraph. Without the source code you need to make sure that all movements will land your scene object's on coordinates that end in .5 (IE 100.5, 200.5). That will compensate for the default shader.
Once you start moving your camera...then things get ugly...because now the position of the scene object relative to the camera is what you have to be cautious of.
I learned all of this from Duncan Colvin in this thread:
www.torquepowered.com/community/forums/viewthread/105873
With any luck...Duncan will drop by this thread and give some pointers. He's much more knowledgeable about this engine than I am.
--RB
04/29/2010 (6:29 am)
@Melv MayI'm not sure that this same option exists in TX. I've had variations of this problem since I began working on my prototype in Torque X.
If it does exist...I'm not sure where how to turn it on. If it doesn't exist...it'd be a nice feature to have.
The only way I've seen this disappear is by making sure your objects are always positioned on "whole number" coordinates. IE...make sure you don't perform any movements of any sprites that would land you on a fractional coordinate (IE SomeSceneObject.Position == [100.4, 200.6]). This also requires the source code and a change to the default SimpleMaterial shader code.
If you do not have the source code, then you have to compensate for the default shader by making sure all of your scene objects are positioned at "point-five" coordinates...this is counter to the solution I mentioned in the previous paragraph. Without the source code you need to make sure that all movements will land your scene object's on coordinates that end in .5 (IE 100.5, 200.5). That will compensate for the default shader.
Once you start moving your camera...then things get ugly...because now the position of the scene object relative to the camera is what you have to be cautious of.
I learned all of this from Duncan Colvin in this thread:
www.torquepowered.com/community/forums/viewthread/105873
With any luck...Duncan will drop by this thread and give some pointers. He's much more knowledgeable about this engine than I am.
--RB
#6
04/29/2010 (6:31 am)
No, automatic padding doesn't exist AFAIK but creating your artwork so it's suitable is entirely possible. :)
#7
In short, the simplest solution is to place your art appropriately in your scene, as Ron noted. The other option is to implement TGB style padding.
04/29/2010 (8:03 am)
@Ron: yep, basically see the other thread for details :)In short, the simplest solution is to place your art appropriately in your scene, as Ron noted. The other option is to implement TGB style padding.
#8
TGB style padding: copy the pixels around the edge and paste them outside the tile (so the tile size increases), then in TXB overlap the sprites by 1 pixel??
or copy & paste pixel edge inside the sprite (before the copied edge so the tile size remains the same)??
06/06/2010 (9:23 am)
@Darthu: did you get the sprites to work yet? I gave up.TGB style padding: copy the pixels around the edge and paste them outside the tile (so the tile size increases), then in TXB overlap the sprites by 1 pixel??
or copy & paste pixel edge inside the sprite (before the copied edge so the tile size remains the same)??
Torque Owner Dan Pascal
without flicker edge