Post
by kikito » Tue Apr 11, 2017 9:34 pm
Hi there,
That is not a strictly gamera-related issue. It happens frequently with any LÖVE game which tries to use quads to show tiles.
The dt variable which LÖVE uses for time, however, is *very* floating-point in nature, like 0.1274232. Which when you multiply by the scrolling velocity of your game, gives you coordinates like x=345.183523. If draw on integer-based coordinates (x=345 or x=346) you won't see those "seams". But given the way dt works in LÖVE, that is rarely an option (you chould "floor" the coordinates of your tiles before drawing them, but that would make scrolling and movement less fluid). It's when you draw in non-integer coordinates when the seams appear. The reason are complicated to explain here.
A "correct" solution to this problem would be rendering all the tiles into a big canvas, using integer-based coordinates, and then draw the canvas with a float offset. This is rarely an option, because the canvas for a complete level can be quite big, and if you split the level into smaller canvases you will still get "seams" in the separation between canvases.
Another option that you can try is "expanding the borders of your tiles a couple pixels" in your original image. This means that if you have 32x32 tiles, instead of making them 32x32 in your image, you make them 36x36: The 32x32 tile is in the middle, and the 2-pixel border around it is "padding", colored the same way as the internal 32x32 tile (if a tile is brown on the left, its left "border" will be brown. If the tile is gray on the right, its right "border" will be gray). The seams will still appear, but since they will (hopefully - this depends on how OpenGL is implemented on each machine) be of the same color of the tile, it won't be noticeable.
I don't use STI, but this problem is so common that it's possible that they already have one or two ways of dealing with it.
When I write def I mean function.