LÖVE

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.

Thanks, fixing the camera creation and camera coords fixed the mysterious pink outline too. So now I have a working viewport system! Yay!

I guess I can go back to my "regularly scheduled" content updates

Zireael wrote:Thanks, fixing the camera creation and camera coords fixed the mysterious pink outline too

That was likely the problem you where having with hump.camera too, in case you want to consider switching back to it

Have you seen the the optimization example .love file I uploaded in my previous comment? Did it help you understand how drawing can be made faster?

Yeah, I just saw it, thanks - it's a perfect example. I will have to figure out how to draw just the tiles in camera's sight then.

Hey! So I'm using STI to load my maps made in Tiled and I just include it's draw function in gamera's draw function. It looks something like this 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!

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.

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.

Make a pull request.

Every little bit counts.

Oooh! My first pull request! I will! *lil' jazz hands of excitement*

Oh wait, shoot, it's gamera-demo.love that needs fixing, not gamera itself. No github page for that.