Scaling accuracy and spritebatches

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Scaling accuracy and spritebatches

Post by zorg »

hasen wrote: Thu Mar 01, 2018 11:00 am But didn't you say in your first response "transparent and single-colour padding doesn't help" ?
I did, but i meant it for tiles whose edges are completely "filled in", i.e. there isn't an at least 1px transparent border in the tile itself.
hasen wrote: Thu Mar 01, 2018 11:00 am
zorg wrote: Thu Mar 01, 2018 10:43 am If all the pixels at the edges of your sprites are transparent, then the padding can also be transparent;
Ok so purely square tiles for terrain would also be fine with transparent borders though right?
No, because again, if the tile itself is completely opaque, all pixels that is, then it will bleed when moved(translated) / scaled /rotated / skewed, basically transformed in certain ways.
hasen wrote: Thu Mar 01, 2018 11:00 am
zorg wrote: Thu Mar 01, 2018 10:43 am usually the problem comes in when you use sprites that fill up the whole unit (ground tiles instead of characters, for example), and there's no transparency around the edges. (That said, looking at the mario tileset you linked, some items do have a green background for some reason;if that's also transparency, i'd convert that to a transparent black, if i were you; löve doesn't need to use magic pink and other tricks)
But in short, it should fix the issue with that kind of tiles.
Ok so these ones maybe not so good then. I think the reason is often for clarity, especially with terrain tiles, without the spacing it looks like one huge block of mess lol. I'll look out for ones on a transparent background. Thanks for your help.
Yeah, those spritesheets were probably padded for clarity, or to be used in an engine that supports auto-padding; you can still edit those if you'd wish to use them of course, although i'm guessing they were only examples you wanted to show.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
no_login_found
Prole
Posts: 18
Joined: Sun Dec 31, 2017 4:04 pm

Re: Scaling accuracy and spritebatches

Post by no_login_found »

The only acceptable way to draw tiles at non-int coordinates is to first draw them to a canvas with int coordinates, and then draw this canvas with any transforms you like. This way each border pixel will be interpolated from 2/4 different tiles exactly the same as pixels inside the tile are interpolated.

If you do anything else, then it will first draw the border of first tile, then cover it with the border of another tile, and the mixture can't be good. If you don't add paddings to tile textures, it will can cut off the borders from one of the sides (just see how individual images are drawn in floor coords). If you add paddings, it can be slightly better because instead of missing border you will get mixture of double borders or something like that, which will look ugly but still have some meaningful color. Additinally,if you don't do something special with blend mode and use transparent paddings, then drawing order will be important, so borders of the tiles will not be equaly blended. Things can get especially ugly if coordinates are exactly between two ints since for different quads it can err in opposite ways.
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Scaling accuracy and spritebatches

Post by zorg »

no_login_found wrote: Thu Mar 01, 2018 12:24 pm The only acceptable way to draw tiles at non-int coordinates is to first draw them to a canvas with int coordinates, and then draw this canvas with any transforms you like. This way each border pixel will be interpolated from 2/4 different tiles exactly the same as pixels inside the tile are interpolated.
I'd argue about that being the only "correct" way, but sadly i don't currently have any good arguments on me. :3

That said, you're wrong about this part:
no_login_found wrote: Thu Mar 01, 2018 12:24 pm If you add paddings, it can be slightly better because instead of missing border you will get mixture of double borders or something like that, which will look ugly but still have some meaningful color.
You won't get a mixture of "double borders", whatever that may be, since
1. we're assuming uv-s only deviate in positive directions, and
2. we established that the 1 row and column padding on the right and bottom sides of sprites (that don't have transparent edges) will correctly be rendered because both the intended, and the adjacent pixel color value is the same;
that was the biggest issue, not that draw order and float-coord-based overdraw would blend the output pixels.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
no_login_found
Prole
Posts: 18
Joined: Sun Dec 31, 2017 4:04 pm

Re: Scaling accuracy and spritebatches

Post by no_login_found »

zorg wrote: Thu Mar 01, 2018 2:17 pm You won't get a mixture of "double borders", whatever that may be, since
Added the image and the app to illustrate border issues, including "double borders" (since 2 adjustent lines have ~border color)
In this example spritebatch is drawn at different float coords near 0.5 (full set from 0 to 1 is in the app). Quads are taken from padded texture where rows/columns around the quad have the same color.
Attachments
tileborders.love
test app which draws 2 adjustent tiles at different float coords to illustrate what happens with the borders
(625 Bytes) Downloaded 74 times
magnified image of tile borders when batch is drawn at float coords
magnified image of tile borders when batch is drawn at float coords
tiles_with_padded_quads_in_spritebatch.png (3.11 KiB) Viewed 4239 times
hasen
Party member
Posts: 157
Joined: Sat Jan 20, 2018 2:01 pm

Re: Scaling accuracy and spritebatches

Post by hasen »

zorg wrote: Thu Mar 01, 2018 11:41 am I did, but i meant it for tiles whose edges are completely "filled in", i.e. there isn't an at least 1px transparent border in the tile itself.
I thought that was what you meant by "transparent and single-colour padding", that it was in the tile itself.
hasen wrote: Thu Mar 01, 2018 11:00 am Ok so purely square tiles for terrain would also be fine with transparent borders though right?
zorg wrote: Thu Mar 01, 2018 11:41 am No, because again, if the tile itself is completely opaque, all pixels that is, then it will bleed when moved(translated) / scaled /rotated / skewed, basically transformed in certain ways.
I see, but square terrain tiles is exactly where I was seeing the problem.
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Scaling accuracy and spritebatches

Post by zorg »

Okay, so fill an extra row and column with the same color pixels and not with (0,0,0,0), which is what transparent means.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
hasen
Party member
Posts: 157
Joined: Sat Jan 20, 2018 2:01 pm

Re: Scaling accuracy and spritebatches

Post by hasen »

zorg wrote: Fri Mar 02, 2018 9:36 am Okay, so fill an extra row and column with the same color pixels and not with (0,0,0,0), which is what transparent means.
Ok so 'bigger' tiles basically. :ultraglee:
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Scaling accuracy and spritebatches

Post by zorg »

hasen wrote: Fri Mar 02, 2018 1:40 pm
zorg wrote: Fri Mar 02, 2018 9:36 am Okay, so fill an extra row and column with the same color pixels and not with (0,0,0,0), which is what transparent means.
Ok so 'bigger' tiles basically. :ultraglee:
yes, but the tile sizes should remain the same in code.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
hasen
Party member
Posts: 157
Joined: Sat Jan 20, 2018 2:01 pm

Re: Scaling accuracy and spritebatches

Post by hasen »

Just wanted to add that this is just a workaround that doesn't give a very good result. The big tiles with transparent padding solves the pixel bleed issue but the images still flicker a lot when the player moves. It may or may not be noticeable to someone playing the game but it just doesn't give a very professional look. I'm sure there must be a way to solve this...
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 51 guests