[SOLVED] Tiled Map breaking at "seams"

[TheRedRaccoon]

My computer with my RPG.love files bit the dust with a faulty hard-drive, and since the code looked bad anyways, I'm attempting a somewhat cleaner approach to my RPG project. However, I've hit a bit of a random bug...

When the character moves, occasionally the tiles on the map will break apart when the camera is in motion.
I've tried things from seeing if its my new computer's way of handling STI and Tiled, but when I run my old RPG project, it doesn't not break the tiles up at the seams.
I tried removing Maid64 (something I thought would be fun and easy to mess around with), but that did nothing to fix the issue either.
I attempted using the double-sized graphics from the old one, but that changed nothing, either. (Maid64 is what is doing the doubling in the .love provided; in the old one, the .png files held 32x32 tiles, this one has 16x16).
To be honest, I'm not sure what's happening.

Video of the "seams": https://youtu.be/-JiK73i_r3s

[pgimeno]

It seems to be a problem with using nearest neighbour and non-integer coordinates. I've fixed it this way:

In main.lua, function love.draw, I've changed some lines in the "map handling" section like this:

Code: Select all

  color("white")
  lg.push()
  local txr = math.floor(tx+0.5) -- added
  local tyr = math.floor(ty+0.5) -- added
  lg.translate(txr + (mw/2 - 8), tyr + (mh/2 - 8)) -- changed tx, ty to txr, tyr
  if map ~= nil then
    map:setDrawRange(-txr, -tyr, mw, mh) -- changed tx, ty to txr, tyr
...

And in player.lua, function player.f.draw, changed the drawing statement to this:

Code: Select all

  player.char.anim[player.char.facing]:draw(player.char.sprite, math.floor(player.char.x+0.5), math.floor(player.char.y+0.5) - 2)

I'd like to further investigate when and why this happens.

[TheRedRaccoon]

Yep, I just figured that out looking at my old code again.

In my old one, the character moves with math.ceil and math.floor accounting for those non-integer coordinates.
I couldn't quite get my new one to do so, so instead, I simply did this to the tx, ty variables in my map.lua file:

Code: Select all

function charlayer:update(dt)
    if player.char ~= nil then
      player.f.update(dt)
      tx = -(player.char.x - (player.char.x % .04))
      ty = -(player.char.y - (player.char.y % .04))
    end
  end

I messed around with various numbers, and % .04 has produced (as far as I've been able to see) perfect results.

[pgimeno]

I've researched this a bit more. It looks to me like a love2d off-by-one bug, possibly due to a discrepancy in rounding modes between GL and C, or both within GL.

Code: Select all

lg = love.graphics

local img
local quad

function love.load(argv)
  lg.setDefaultFilter("nearest","nearest")

  img = lg.newImage('bug.png')
  quad = lg.newQuad(51, 17, 16, 16, 968, 526)
end

function love.draw()
  lg.draw(img, quad, 392.495, 280)
  lg.draw(img, quad, 392.50, 300)
  lg.draw(img, quad, 392.505, 320)
end

bug.png is a 968x525 image with a 16x16 sprite whose top corner is at (51,17). Zoomed view of the area of the png where the sprite is:

love2d-off-by-1-demo-sprite.png (683 Bytes) Viewed 2968 times

The dashed line is the 16x16 area of the actual sprite. I've added different edges to the left and right in order to know for sure what was happening.

Zoomed view of the result:

love2d-off-by-1-result.png (925 Bytes) Viewed 2968 times

The top and bottom sprites are correct. The one at the centre is wrong, and is the one that caused the problems in the OP. It looks like a discrepancy between the drawing position and u-coordinate, like x is rounded down and u rounded up when at 0.5. That, or an issue of numerical precision.

.love file: