LÖVE

I'm currently trying to figure out the best way to draw images stored in a sprite sheet but have run into a problem when using quads to extract individual sprites from the sprite sheet. When offsetting the sprites on the screen to simulate movement, any time the sprite edges do not match up perfectly with the pixel edges a portion of the adjacent sprite will bleed in to fill the gap between sprite and pixel edge.

It's probably best illustrated with the tile sheet and map screens. The left map image is how it should look, the right map image is how it does look after moving the tiles a bit. The bleed from the red and blue tiles on the map (where they aren't in use) is clearly visible near the tiles adjacent to them on the tile sheet .



I'm drawing the tiles with data from a table that stores an image reference to the spritesheet and a quad to extract the tile indexed the x/y coordinates of each tile plus an offset (cxmin/cymin) from the camera. cxmin/cymin are usually not integers. I could probably render the entire map as a single image and offset that one but it seems to kinda defeat the purpose of having quads in the first place which I wanted to use for character/object sprite sheets as well.
Speaking of sprite sheets, is there a noticeable performance difference in using quads to access a texture atlas in contrast to extracting the sprite from the raw data and storing them individually at runtime?

Try adding a 1 pixel transparent border around all the sprites in the spritesheet.

Golan2781 wrote:Speaking of sprite sheets, is there a noticeable performance difference in using quads to access a texture atlas in contrast to extracting the sprite from the raw data and storing them individually at runtime?

In 0.7.2 there's little or no difference, except maybe on nvidia video cards. in 0.8.0 there is a significant performance improvement for the first option on ATI and Intel cards.

Version: 0.7.2 or 0.8.0 ?

Hi there!

Are you using floats for drawing stuff around? If so, can you try map.flooring the coordinates before you draw?

(BTW, I would try myself, but you didn't include a .love file for us to try)

slime wrote:Try adding a 1 pixel transparent border around all the sprites in the spritesheet.

This gets rid of the bleeding (the blue arrows are stored like this) but it seems somewhat impractical for tiles that are supposed to be solid (i.e. don't have a natural transparent border). I'm quite fond of the power2 sized sprites on a power2 spritesheet, they are much easier to create, manipulate and process, especially when using multiple different sizes simultaneously (32² for tiles, 64² for players etc.).

slime wrote:In 0.7.2 there's little or no difference, except maybe on nvidia video cards. in 0.8.0 there is a significant performance improvement for the first option on ATI and Intel cards.

Thanks, that's exactly the information I was looking for.

gfreak wrote:Version: 0.7.2 or 0.8.0 ?

Happens with both versions.

kikito wrote:Are you using floats for drawing stuff around? If so, can you try map.flooring the coordinates before you draw?

The camera uses float coordinates so the screen coordinates are floats too. Flooring them removes the tile bleeding but creates a very visible stuttering when the quads move slowly. This wouldn't be much of a problem for the background as the camera is supposed to move only fast or not at all in the final version, but objects can be quite slow relative to the camera.

kikito wrote:BTW, I would try myself, but you didn't include a .love file for us to try

Sorry, I'm not used to such a forthcoming community yet. See the attachment, I hope it's packed correctly.

Golan2781 wrote:This gets rid of the bleeding (the blue arrows are stored like this) but it seems somewhat impractical for tiles that are supposed to be solid (i.e. don't have a natural transparent border).

I think it would look okay for "solid" tiles if the 1pixel transparent edge is filled up for them (but not for the tiles that should be separate and not adjacent).