I got this error when I tried to execute the .love: "Error: interface/ActorSkills.lua:15: cannot open data/skills.lua: No such file or directory"
I can execute it correctly by uncompressing it to a folder.
why the camera doesn't center on the player?
You are mixing up tile coordinates with world coordinates. Your map:getWidth() and map:getHeight() return the coordinates in "number of tiles", but you need them in "number of pixels" (I assume you need to multiply them by 32). Use that number when creating the camera.
Something similar happens with player.x and player.y. You need to transform them into pixel-coords before passing them to cam1:setCoords.
function World:update(dt)
-- Update every layer in the map level
self.level:update(dt)
playercam:setPosition(self.level.layers.entities.player.x, self.level.layers.entities.player.y)
end
with playercam being my instance of gamera.
Now when I end up launching it looks like the screenshot posted when I first start, then I move and those artifacts dissapear, but then once I start moving around a bit those artifacts will appear again then immediately disappear at seemingly random intervals. Just curious do you know what may be causing this or is there any more info I could provide to try to understand what's going on? Thanks for looking at this I appreciate it!
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.
I just downloaded the gamera demo, and ran into some issues running it with Love 11.0; the background was entirely white rather than being tiled, and the blue box was opaque. It took me a while to figure it out, but the problem was caused by the new color system being from 1 to 0 rather than 225 to 0. I switched the values in setColor to fit the new system, and everything was fine.
