Graphical glitch when rescaling

[jeto143]

Hello,

First, I would like to say I'm fairly new to LÖVE and enjoying it a lot. The community also seems great!

So I've been screwing around with the framework and came across a pretty annoying glitch when zooming in/out (rescaling) the view, as you can see on the image below:

q1Eo7D9.jpg (70.67 KiB) Viewed 514 times

The borders of some of the tiles, as you can see, is not right.

I can give you more details about my project if needed, but is that a known issue by any chance?

Thanks!

[Robin]

Welcome! Could you delete the other topic? You made the same one twice.

I think calling math.floor() on the coordinates where you draw the tiles will fix the issue, but I can't say for sure without a .love file.

[jeto143]

I'm actually using a map from Tiled, loaded through Advanced Tiled Loader (ATL). So I'm not actually calling draw myself. I tried the math.floor thing within ATL itself (I don't really want to alter external libs I'm using though so hopefully something like this isn't needd), didn't seem to solve the issue.

Before posting a .love I'll try to reduce the code to a minimum sample size. I just wanted to know if it was a common issue.

Thanks.

[jeto143]

OK, there you go:
https://dl.dropboxusercontent.com/u/220 ... litch.love
(Tried to attach it here but got "Sorry, the board attachment quota has been reached.", even though it's like 600KB...)

You can play around with scale level (mouse buttons) and translation (arrow keys) but I've picked default values that display the glitch.

The map is the one from one of the Jumper library examples. And apparently it's coming directly from http://lpc.opengameart.org.

Any idea?

[markgo]

This is a fairly common issue in LOVE with spritebatches quads. Things I do to alleviate that:

- Draw/Translate objects at integer coordinates
- Use integer scales
- Set image filters to "nearest"

Good luck.

[raidho36]

I think we really should to add a note about quadsgeometry and non-integer rendering coordinates and how that affects the texture rendered to the wiki. People seem to bump into that problem all the time.

[jeto143]

- Use integer scales

That's what I was missing I guess. Can't test it right now, but I suppose that's it. Integers are pretty brutal scale levels though, I must say...

[micha]

You can also use fractions. Just make sure that after scaling the size of each tile is an integer again.

For example: One tile has a size of 40x40 Pixels. If you scale by factor 0.75, the new size gets 30x30, which is okay, too.

Maybe even write a function to give you the scale factor for a desired size:

Code: Select all

function scaleFactor(tileSize, newTileSize)
  return math.floor(newTileSize) / tileSize
end

Or a function to "round" to the nearest scale factor, that is ok according to the above condition:

Code: Select all

function roundScaleFactor(factor)
  return math.floor(factor*tileSize) / tileSize
end

[jeto143]

edit: disregard the post below. I was scaling before translating... my bad!

Thanks, but unfortunately that doesn't seem to fix it, at least using Advanced Tiled Loader:
https://dl.dropboxusercontent.com/u/220 ... tch_2.love

I'm using a scale value of 2.125, and the map has 32x32 tiles. 32 * 2.125 = 68, so...

Maybe related to ATL then, but it seems like it's a commonly used lib so I'm a bit surprised. I tried adding a bunch of math.floor's in all the calls it makes to love.graphics.draw/drawq but to no avail (maybe I've missed some).

[Lafolie]

This problem is easy to avoid if you want to retain the real co-ords instead of integers. Simply pad your tiles 2px. The inner most pixels should repeat the edge pixels of the tile. Sounds like a lot of work, but you could easily write a script that does this for you and generates image assets that will not cause this issue.