This post is more a note to myself, but you might find that interesting.
There was a bug that was annoying me for a while in ND2D, but I didn’t had the time to fix it: When you use spritesheets and the sprites are packed without any space between them like this one:
It’s likely that you run into issues where the GPU is drawing the pixels of another sprite around your sprite. This looks like this then (The lower image is the fixed version):
If you use mip-mapping it get’s even worse, but that’s another story…
This happens, because OpenGL / DirectX needs to have the center of uv-coordinates on the pixel and not on the edge of the pixel. The solution is pretty simple: Instead of calculating the uv-coordinates from 0 to screenwidth, you’re technically supposed to calculate from 0.5 to screenwidth – 0.5. This way the edge pixels are “cropped” out and the bleeding stops :)
Operation successful, patient alive & breathing. Nurse, I need a drink, cheers!
You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.
Very interesting, and helpful :)
Could you clarify something though …
When you say “from 0.5 to screenwidth – 0.5″ do you mean “from 0.5 to texture width – 0.5″ ?
With this in mind, I assume the following could be used to convert a pixel X coordinate to a U coordinate …
pixelU = 0.5 + pixelX * ( 1.0 / ( textureWidth – 1.0 ) )
So taking a row of pixels as an example, the center of the first pixel in the texture would be 0.5, and the center of the last pixel in the texture would be 1.0?
Thanks :)
Sorry, I just had a massive brain-fart and those calculations in my last comment are completely wrong :(
Replace 0.5 with 0.5 * ( 1.0 / ( textureWidth – 1.0 ) ) … obviously the first pixel U/V coordinate in the texture isn’t going to be 0.5
very cool post I did not know that, the new additions to ND2D are AMAZING. Something that would be handy (that I added in manually on mine) would be a way to remove animations to spritesheets incase you had dynamic bitmapdata for spritesheets. Also what is the difference between SpriteBatch and SpriteCloud? is SpriteBatch specifically for CoCo texture packer?
I introduced the Sprite2DBatch just yesterday. I’ll post details about the differences soon and comment everything. The batch behaves the same as the cloud, but works different internally. Besides that. I added TextureAtlases, so instead of the SpriteSheets, you can use a real atlas (based on the Cocos2D plist format) now… Documentation and examples will come the next days.
SpriteBatch is cool! Pivots are working there (unlike a SpriteCloud). And SpriteBatch is a bit slower. For a complete happiness, only z-sorting left :) For proper z-order of different sprites from multiple batches/clouds.
Glad to hear all these new things to come, dont be shy to post all the other impovements you made.
Really love your work :)
The Sprite2DBatch is indeed a bit slower, but in theory faster, if you are adding and removing childs every frame in the batch…
ND2D is looking very nice!
But I think this advice here is not the best – a better looking alternative to is leave a 1 pixel gap between the sprites on your sprite-sheet and not change the UV coords.
While both will eliminate the bleed of neighbouring pixels, the gap solution renders the edge pixels of the sprite at full width/height whereas your suggestion results in half width / height edge pixels with less/no softening(depending on AA) at the edge of these pixels. This is seen in the letter “J” in the bottom figure where the outside edges are 1.5 pixels with a hard/jagged edge and the border inside the letters curve is 2 pixels with a smooth falloff (the issue would be more noticeable is the letter glyphs had only pixel edges rather than 2)
Hey Nat, that’s indeed true… I’ll think about it… Maybe I can make this configurable.