Simple Tiled Implementation - STI v1.2.3.0

[pevzi]

Tile object probably shouldn't have an outline, eh?

Yeah, I guess? I'd simply put a check for gid property before drawing a shape, like this:

Code: Select all

	for _, object in ipairs(layer.objects) do
		if not object.gid then -- here
			if object.shape == "rectangle" then
				drawShape(object.rectangle, "rectangle")
			elseif object.shape == "ellipse" then
				...

It also makes it unnecessary to set vertices for tile objects in Map:setObjectCoordinates if I'm not missing anything out.

[Eamonn]

I'm getting an error with the latest daily build of Tiled on Ubuntu 15.04 and the latest version of STI. I hadn't gotten this error since before I installed Tiled on my fresh build of 15.04. After I added about 3 tiles to my map, and re-exported to a Lua file, I got the error. If I remove those tiles and export the map exactly as it was before the update, the error still occurs.



What happened? Did I mess up somewhere? I haven't modified any of my game code, and worked in the last version of Tiled that I used before I updated to 15.04 (which was 0.12.1, but I could be wrong). Thanks!

[stakira]

First of all, I do want to thank you for this library. I can see the the effort and thoughts you put into it.

But (yea), just after briefly trying it out, the API design is somewhat awkward. At least two things at a glance. First, scale is set at draw call, which is a thing I have never seen. Usually in a game engine, scale is treated as an attribute of node/entity/object, therefore map.scaleX = 2 is a pretty standard thing. This also means you don't have to keep a variable for it if it doesn't change. And in update call you can still always set it.

Second, the translation of map coordinate relies on love.graphics.translate. Really, love.graphics.translate itself is a awkward thing already. By translating all the coordinates, your GUI has to be translated against that translation. This makes things complicated. Even a simple FPS counter at corner would float around without additional work. Not need to say, all the GUI frameworks goes funny. Just like any other objects in game scene, map should have a x and a y to offset itself.

Still I appreciate the quality of this implementation in terms of efficiency. It just has minor stuff need be fixed.
Thanks.

[Karai17]

I'm getting an error with the latest daily build of Tiled on Ubuntu 15.04 and the latest version of STI. I hadn't gotten this error since before I installed Tiled on my fresh build of 15.04. After I added about 3 tiles to my map, and re-exported to a Lua file, I got the error. If I remove those tiles and export the map exactly as it was before the update, the error still occurs.

What happened? Did I mess up somewhere? I haven't modified any of my game code, and worked in the last version of Tiled that I used before I updated to 15.04 (which was 0.12.1, but I could be wrong). Thanks!

It looks like Tiled 0.12 must have changed something. I'll need to go back and figure out what that was. Until then, try using Tiled 0.11.

First of all, I do want to thank you for this library. I can see the the effort and thoughts you put into it.

But (yea), just after briefly trying it out, the API design is somewhat awkward. At least two things at a glance. First, scale is set at draw call, which is a thing I have never seen. Usually in a game engine, scale is treated as an attribute of node/entity/object, therefore map.scaleX = 2 is a pretty standard thing. This also means you don't have to keep a variable for it if it doesn't change. And in update call you can still always set it.

Second, the translation of map coordinate relies on love.graphics.translate. Really, love.graphics.translate itself is a awkward thing already. By translating all the coordinates, your GUI has to be translated against that translation. This makes things complicated. Even a simple FPS counter at corner would float around without additional work. Not need to say, all the GUI frameworks goes funny. Just like any other objects in game scene, map should have a x and a y to offset itself.

Still I appreciate the quality of this implementation in terms of efficiency. It just has minor stuff need be fixed.
Thanks.

Yeah I'm not happy with the way scaling works either, but I don't think I'll be changing it to a map property. I might just remove it and give people tips in the docs on scaling using love.graphics.scale. As for love.graphics.translate, it's not an issue. If you wrap it in a love.graphics.push/pop then it resets when it's done so you don't need to manually undo it.

Code: Select all

function love.draw()
   love.graphics.push()

   love.graphics.translate(500, 500)
   love.graphics.scale(2, 2)
   map:draw()

   love.graphics.pop()

   gui:draw()
end

[stakira]

Yeah I'm not happy with the way scaling works either, but I don't think I'll be changing it to a map property. I might just remove it and give people tips in the docs on scaling using love.graphics.scale. As for love.graphics.translate, it's not an issue. If you wrap it in a love.graphics.push/pop then it resets when it's done so you don't need to manually undo it.

Oh OK. I think I get your point. Your are thinking at gl level. I think I'm fine with that. Two push/pop does worth it for entire map, and it saves all additional transformation of tiles. Thanks for the explaination.

[Eamonn]

I ran the latest stable build of 0.12.3 and the game runs totally fine, so it's either a nightly bug inside of Tiled or it's an STI incompatibility. I guess that's why they're nightlies

[Hargam]

Pevzi, thank you for sharing you way of solving a problem with tile objects! I was going to ask here about the exact same problem, but the answer was already here.
I am using object's width and height to manually check collisions with it. So, my tile objects have width and height.
I guess, my code isn't very good, and maybe I was using something the wrong way. (For example, at one point I found out that one of my problems could be solved solved with Map:setObjectSpriteBatches function. And the documentation doesn't recommend to use it manually.)
So, I don't know if this is a problem or not, but now I have a temporary solution and I am fine with it.
Oh, and thank you, Karai, for this great library.

[Eamonn]

Sorry for yet another question, but I'm having another issue with STI. Again, still using Ubuntu 15.04, still using the latest stable version of Tiled 0.12.3, still using the latest version of STI. The latest tiled Nightly doesn't work.

So, I'm getting a problem where some tile objects aren't collidable, even though they're on the layer I'm looping through. The strange part, however, is that if there are X amount of tiles on the layer in a line, then they'll become collidable (I say X because the value changes each time the game starts up, unless the tiles are already collidable, then they stay that way). Say I have one block on it's own in the world, and it has the collidable property, there's a chance it'll be collidable/not collidable. If I place an object around it, there's a chance it'll be collidable, or that it'll remove the collidable value from the block I placed previously. Usually though, what happens is that if it's collidable, it stays collidable, no matter what's placed around it (though I have encountered some strange cases where I need to re-export the map a couple of times). For arguments sake, let's say that I place a block and it's not collidable, and all the blocks I place after that are not until this magical number of X blocks I mentioned earlier is met. If I place a block at the side of it, nothing will happen. I place another, and nothing happens. This could go on for 5 blocks, it could go on until the edge of the map (since the width/height of the map guarantees that it'll be collidable, even if the last block at width of map - 1 isn't). Let's say the value is 10 blocks, and we're at the ninth block. All 9 blocks in a line aren't collidable, but once I place block 10, all the blocks become collidable. I'll provide you with some pictures of my specific case of this.

Before (Note that I only show one block here, because posting several images of just adding one block might get a bit long and annoying)


After (The block before this was placed wasn't collidable)


As you could probably guess based on the information I've provided, if a block is placed on top of it, the block might be collidable, or it might not, it's really just a game of chance.

I've tried this in a few separate projects using the same version of Tiled and STI, all producing the same problem. How can I resolve this?

Thanks!

[Karai17]

It looks like Tiled 12 might break compat with STI. I am going to have to look into fixing things I've been putting off.

[Karai17]

Released a new version of STI. This is mostly a maintenance release but it has a new versioning system so I'll explain. STI's version number will now contain four sections as opposed to the previous three. The first three sections will be the same as the version of Tiled that the release was designed against and the last section will be the STI release within the Tiled release.

Examples:

1) Tiled's current version number is 0.12.3. STI has its first release based on this version of Tiled so STI's version is 0.12.3.0.
2) If STI is updated before Tiled, it will get the version number of 0.12.3.1.
3) If Tiled is updated before STI then Tiled may be released as 0.13.0 or 0.12.4. STI 0.12.3.x should still be used and will not get a version bump without merit (which is to say, I will not auto-bump numbers unless I make changes).

Many releases of Tiled do not affect STI in any way, they are fixes for the Tiled editor itself so you may not see an update to STI even if there are several updates to Tiled.

Now, with that out of the way, the changes to STI are as follows:

1) You must now type in the full file name (including extension) when loading a new map. Previously you could write sti.new("map01"). You must now write sti.new("map01.lua"). While writing ".lua" might seem redundant, it is consistent with everything else in LOVE and most other places so I feel like it is better to be consistent than to be lazy.

2) Map:setDrawRange no longer auto-inverts your translations so you must pass in negative translations yourself. This is again for consistency's sake.

3) Map:draw no longer accepts scale values. Please use love.graphics.scale if you want to scale the map.

4) STI still does not support Tile Collections, but it does give you a better error message now!

5) There is a new table, Map.objects. It indexes all unique objects by their new IDs (this was added in Tiled 0.11.0).

Code: Select all

local object = map.objects[5]

6) You can now check which version of Tiled that your map was exported from by printing Map.tiledversion! Make sure the version at least matches STI's or else you might get weird errors! Remember you can also print STI's version with STI._VERSION!

Code: Select all

local sti = require "sti"
print(sti._VERSION) -- 0.12.3.0

local map = sti.new("map01.lua")
print(map.tiledversion) -- 0.12.3