Tile Size per layer not per Map

[RolandasRazma]

I think "Tile Size" should be moved to layer property instead of map. It makes way more sense and enables to use tiled way more flexible.

[bjorn]

Unfortunately this will mean some major changes to the way Tiled works internally, but I fully agree this would be a good idea. As an extension of this, I'd even say the map orientation should be a layer parameter, so that you can combine orthogonal and isometric layers in one map.

[RolandasRazma]

Can't imagine situation where orientation per layer would be useful because perspective would differ. Pity that moving Tile Size need major rewrite of code...

[bjorn]

Well of course a lot of code will remain the same, but it affects for example grid rendering and tile selection, which will need to be adapted to the currently selected layer while at the moment you can select a bunch of tiles, switch layers and then do a Copy action. When the tile size of the layers differ, what should happen with the tile selection? And how is the automapping going to cope with it?

It also affects the code that keeps track of what area to repaint after changing tiles, since at the moment this happens on the Map level but then it will depend on which tile layer the tiles are changed on.

Mixing different orientations could be for performance. For example The Settlers Online [1] uses an orthogonal layer for the background since it's faster to draw (it avoids large transparent areas in the tiles), but an isometric layer for buildings and other objects since that looks nicer. The thing is mainly that once you have layers with different tile sizes, they really don't have anything in common anymore so allowing for different orientations is only a small additional change.

[1] http://www.thesettlersonline.com/

[RolandasRazma]

ah, true, didn't thought about some use cases. Was thinking about simple scenario only.

[stefanbeller]

When the tile size of the layers differ, what should happen with the tile selection? And how is the automapping going to cope with it?

We could assume there is a greatest common divisor between each of 2 layers. (Which is always true since tilewidth/height are integer) Then we can define a translationfunction, which translates a tile of one layer into another layer coordinates by linear scaling: y_1=y_2 * height1/height2 = xy,z (we will likely get real number here so float, double )

(Speaking for the automapping now:) If the remainder (parts behind comma) is the same in the current map and the automapping rulefile (which or course has to have the same tile sizes as well; As of now the tilesizes or map orientation is not checked), it matches and automapping can be applied.

[stefanbeller]

Marked https://sourceforge.net/apps/mantisbt/tiled/view.php?id=75 as duplicate of this.

[osuka]

Definitely in favour of this! Having layers have different tile sizes makes for a more flexible environment, and in particular when you have tile sets from many sources that all have different tile sizes this would allow us to use them. Understand the difficulty though...

[ragekit]

Any news on this one ?

[bjorn]

@RageKit No work has yet been done on this feature. In general, if you want to see some feature, the fastest way is always to either do it yourself or offer me a decent amount of money for it. Otherwise you're just waiting for me to feel like doing it, which could be forever.

[ragekit]

Yeah, no worries, i was just checking since there was no news.

[Bertram25]

Hi, as part of my own project, I'll definitely have a look at it, focusing first on having the tile size be a layer parameter. I'd say we should create a new branch where I could go there step by step, as there seems to be a lot of dependencies with the core of the engine, and certain features, such as the automapping support.

A few starter questions:

• Should a backward-compatible tile size map parameter stay, and why not be a fall-back when undefined in the layer? (Same goes for the orientation)
• As a short-term goal, would it be acceptable to not permit copy/pasting between layers with a different tile size or orientation?
• Should an info be displayed somewhere in the layer list window to clearly hint about the layer tile size/orientation?
• As I'm unfortunately unclear about it, how would react tilesets against that? I.e.: Will the tilesets adapt themselves against the currently selected layer? Can one tiles with a tileset that has a different tile size than the layer? (Same goes for orientation)

Best regards,

[bjorn]

To answer your questions:

• Yes, when layers do not define a tile size then the tile size of the map should obviously be chosen, if only for the sake of backwards compatibility. I would anyway suggest to keep the tileWidth/tileHeight members of the Map class and use them as a 'default' when creating new layers, for example.
• I would simply permit copy/pasting, just like it is currently permitted to copy from an orthogonal map to an isometric map. It has the somewhat predictable effect of warping your tiles around, but I don't think that hurts anybody.
• Not of great importance, I think. Can be considered later if it turns out things are confusing without.
• Tilesets have their own fixed tile size and have nothing to do with the orientation. You could use the tiles on layers with different tile sizes, but generally that is not very interesting since it doesn't cut up the tileset image differently. You'd have to add the same tileset image multiple times then, with different tile size settings.

[Bertram25]

Tilesets have their own fixed tile size and have nothing to do with the orientation. You could use the tiles on layers with different tile sizes, but generally that is not very interesting since it doesn't cut up the tileset image differently. You'd have to add the same tileset image multiple times then, with different tile size settings.

Is that an issue, or are we ok going with this? (I'm not searching for additional work ;) But just wanting to have a clear view of what you want to do about this.)

[bjorn]

Is that an issue, or are we ok going with this? (I'm not searching for additional work ;) But just wanting to have a clear view of what you want to do about this.)

As far as I can see that is not an issue and can just stay like it is.

[Bertram25]

Anyway, thanks for all the info. I'll get into that in one or two weeks while in my spring break. :)

[UliAbo]

I fully support this request, tile size should be per layer, not per map. Would be wonderful to have it implemented! (I can't find the reference option, here's another dead end thread with the same request: https://github.com/mapbox/mapbox-android-sdk/issues/151)

[bjorn]

@Ulli-RPG I already said in my first comment that I agree doing tile size per layer would be a good idea. It's just a matter of getting around to it (and solving the related problems since it won't be a trivial patch).

I'm not sure what you meant to achieve by linking to some seemingly related but totally irrelevant issue on the mapbox project, though...

[UliAbo]

Sorry, I'm new to this all stuff, I just wanted to say that I also support this idea. For the link I thought it was related, overlooked it was another project / Android.

[bjorn]

@Ulli-RPG Alright. :)

[abueide]

@bjorn how would we get a bounty going for this? I'd chip in

[bjorn]

@abueide You can set a bounty on this issue at https://www.bountysource.com/issues/128123-tile-size-per-layer-not-per-map. Usually bounties are quite successful in attracting contributors, though I'm afraid this issue will be a tough one to resolve. But we'll see. I hope to eventually also get around to it of course. Thanks in advance for your support!

[Lucrecious]

Hey @bjorn

So I think I'm going to try and add in the tile per layer support (if no one else is going to try it), but there are a few caveats.

Selection between layers with different tile size will dissipate (I don't mind losing out on this functionality - of course this will be open source, so if anyone wants to tackle it, they can).

All layers in an automapping file need to have the same tile size (in my opinion, if the input and output layer are different tile sizes, the automapping is undefined anyways). So basically, when an automapping is ran on a file with layers of different tile sizes, you'll get an error (just like if you were to omit having regions_input or regions_output).

I'm wondering if I should know about any more glaring issues you might have thought about between 2012 and now, because that would help a lot. It's going to take a while for me to figure out the chain of discrepancies for the map tileHeight and tileWidth.

Thanks, and great app.

Edit: By the way, my idea is rather simple: I'm going to have tileWidth and tileHeight on the "map" object, but instead of always returning the setup value, it first tries to get the current layer's tileWidth and tileHeight, and if it can't, it falls back to the given setup value.

This seems like all I would need to do is make sure to emit redraw events when I change layers, and then make sure the details work correctly.

Edit 2 So I've gone a little deeper into the code now, and it was not as simple as I thought. I should have trusted that the maker of Tiled said it would require a pretty large internal change. I still don't think it's hard, but it'll take longer than I thought, because lots of code needs to be moved around haha

Edit 3 If anyone is interested in progress, here's the branch I'm on: https://github.com/Lucrecious/tiled/tree/tilesize-by-layer

Edit 4 Hey! I think I'm pretty close to getting this working (the basics at least). And then I need to work out the nuances: automapping, selection, plugins, and clean up. It's only updated slightly on the branch, but I'm confident I'll be able to have something basic in the next few days :)

Another thing I need to do is pull from the latest branch... There are probably going to be lots of merge conflicts, and that's going to be a hassle, so we'll see!

[bjorn]

@Lucrecious Please open a pull request with that branch even if it's not entirely done yet. Then we can discuss the changes there. Thanks for taking on this issue!

[Lucrecious]

Here's a the pull request: #1422 I spent some time on documenting what I've done so it's easier to continue!

[Gr33nbl00d]

Really would like this feature

[Lucrecious]

@Gr33nbl00d Here's my PR for it: #1422 Once I have more time, I'll be updating it since my edits' pretty messed up right now. I'm currently working on a project of my own, so it'll be a while until I can get back to this.

As of now, you can use my fork of Tiled, which includes these changes (although very buggy). You can also do the changes yourself!

[Gr33nbl00d]

If i had the time i would do it but last time i wrote c/qt is about 8 years ago :) Java javascript or dotnet would be no problem ;) but as im also busy with my project it would take too much time get into it again... i would enjoy it but for the moment i did a workarround rendering 2 different tile maps instead of one. But if i get back to individual level design and its not done by than, i will give it a try :)

[Lucrecious]

@Gr33nbl00d #1422 is my fork which already has tile size per layer. It's just a little buggy, but I use it just fine. Try it out when you get the chance, all you have to do is clone and build.

[Gr33nbl00d]

Ok i give it a try, would make things much easier for me :)

Am 29.06.2017 9:30 nachm. schrieb "Luca Duran" notifications@github.com:

@Gr33nbl00d https://github.com/gr33nbl00d #1422 https://github.com/bjorn/tiled/pull/1422 is my fork which already has tile size per layer. It's just a little buggy, but I use it just fine. Try it out when you get the chance, all you have to do is clone and build.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bjorn/tiled/issues/149#issuecomment-312075263, or mute the thread https://github.com/notifications/unsubscribe-auth/AVm6fQyktql3RGck0BxgdPzoCSxLFAXVks5sI_s3gaJpZM4AX25X .

[bjorn]

Feature requested on the forum and again and again.

[fmscorpion]

I think I have an idea that might be good for working with different layers, that is improving the object layer, I mean, if there was a snap feature on the object layer when placing tiles it would "solve" the issue of working with different layer sizes, if, the layer sizes are multiples. An example is if I had an 64x64 layer tile size and I use the object layer with 32x32 layer size it would snap four tiles of 32x32 inside the region of 64x64. Fortunatelly it would "solve" this problem without needing to make major alterations on the code

[bjorn]

@fmscorpion Well, snapping objects to the tile grid, as well as snapping them to a subdivided grid, is already available. See View > Snapping menu and Edit > Preferences > Interface > Fine grid divisions.

[fmscorpion]

I didn knew this feature but it works very well, by the way, I realized something that could be updated, maybe multiple placings could be implemented in the objects layer, I mean, it works, but it sometimes looks like a lot of work to place tile by tile even with the snap on.

[HollowedEmpire]

I would also like this feature. I have three different sizes for tiles that have different usage purposes. I have had to use awkward workarounds varying from multiple maps to leaving large gaps in tile layers that use a large tiles and making hacky exporters skip over these gaps depending on the layer in question.

[JamesO2x]

I just had a thought on this feature. I think a simple solution would be to only allow layers use tile sizes that are multiples of the base tile size defined in the "Map" properties.

For example, if your map properties use 32x32 pixel tiles as default, you could define a property in another layer that is called "Tile Layer Multiplier". When "Tile Layer Multiplier" is set to "2" it would mean that the tile size for that layer is "64x64" pixels (a 2 multiplier of the base tile size). If you set the multiplier to 10, you could have a tile sizes of 320x320.

I think this is a reasonable implementation that shouldn't be too complex in the math/implementation side of things.

I understand that the ideal solution would be to allow exact pixel size definitions, but realistically... I can't imagine any real world use-case where someone would want to have (for example) a layer with 32x32 tiles, and another layer with something like 31x31 tiles. It would be a nightmare to design a map like that, with minor offsets that don't line up nicely.

I would think that such a truly arbitrary tile-size definition would actually cause more headache for map designers than it is worth, because it would promote bad design practice. Unless someone were to come forward with a very compelling argument on why different layers should allow tiles that don't evenly divide into each other...

I think using a multiplier approach would not only be the simplest solution for both programmers and map designers, I think its also the most sensible approach that would cover 99% of the cases where someone would need differently sized tile layers.

That said, using this "multiplier" approach would also still "technically" allow for fully arbitrary tile sizes. For example, if you set your Map's default tile size to "1x1" then you could make a new layer that is any arbitrary size of pixel multiplier. You could make a cursed map with 32x32 and 31x31 tiles, if you really wanted to.

[bjorn]

That said, using this "multiplier" approach would also still "technically" allow for fully arbitrary tile sizes. For example, if you set your Map's default tile size to "1x1" then you could make a new layer that is any arbitrary size of pixel multiplier. You could make a cursed map with 32x32 and 31x31 tiles, if you really wanted to.

I think this kind of reveals a problem with the proposal, because it means the implementation is actually not any easier than an implementation that can handle arbitrary tile sizes. It might be that an implementation that handles only power-of-two multipliers (so x2, x4, x16, etc.) could be easier, but even that leaves the problem that a tile selection of some layer can include partial tiles from another layer.

In any case, thank you for considering ways to make this easier! Maybe there is a way, but I'm afraid it's going to be a major project either way where my initial comments from 2012 highlight the pain points.

[JamesO2x]

I think my proposal is still easier than one that handles truly arbitrary tile sizes though. Consider the following:

If you attempt to use truly arbitrary tile sizes, then there needs to be some function within Tiled that takes the total number of layers in a map, finds some common denominator between all of them that is divisible by all of them, and then adjust layers grids and such accordingly. Then, every time a new layer is created, this same computation has to be done all over again. Multi-layer selection would be a real nightmare to program I would think. You might even run into floating-point issues if tiles are not evenly divisible.

With my proposal, you would never be able to create new layers with tiles smaller than the map's default size. This basic assumption simplifies a lot of the math. since all future layers must be perfect multiples of this base value, Selection matrices merely have to be multiplied/divided by whole integers (2, or 3 or 4, etc) when moving between layers. And yes you're right, you could probably simplify this further to limiting the multiplier to powers of 2.

Basically, you simplify the solution by simplifying the problem. I really don't think anyone actually needs a single map file with tiles that are 13 pixels, 458 pixels, 2 pixels, 3 pixels, 16 pixels, and 17 pixels all at the same time. So the "problem" of true arbitrary tile sizes is a bit of a silly one... its like trying to invent a machine that sorts the hair on your head by length - sure you can create such a machine if you really want to... but is that really a problem that any actual person needs solving?

To handle the "partial tiles" problem, I think a design decision just needs to be made: Either round the selection up to the nearest full tile, or round it down.. I don't think it needs to be any more complicated than that.

Anyway, that's just my suggestion. I don't know much about the actual code of Tiled, so I may be totally wrong. But my solution seems like a "good enough" solution that captures like 90% of most peoples use case.

[MarkOates]

👋 I would like this feature as well (and would prefer full arbitrary tile sizes, not power of two).

but even that leaves the problem that a tile selection of some layer can include partial tiles from another layer

I'm OK with that! My initial solution for this problem was to simply not provide support for multilayer selection, in cases where the map has different tile sizes on layers. A step forward from that would be to activate layers in the layer panel that you would want to select through, possibly with an icon of sorts.

I also like the idea of orientation and transformation being layer dependent (interesting platforming on rotated maps!). In a perfect world, you could have any layer (of any type) with unique tile sizes, orientation, and transformation.

[JamesO2x]

👋 I would like this feature as well (and would prefer full arbitrary tile sizes, not power of two).

Can you describe your use case for fully arbitrary tile sizes per layer? Describing your use case should help the programmers understand how people are using this tool (and how they might want to use it), which can help with implementation.

Also I'm genuinely curious. Because I've seen arbitrary tile sizes requested before, but I've never seen anyone actually describe a use case that would actually require truly arbitrary tile sizes per layer (that couldn't be solved with proper fore-planning).

For example, I once had a freelance client who insisted that the tiles in his project must be 23 pixels wide, even after I explained that it would leave gaps in the memory when loaded into the engine, because the tile table would likely round up reserved space to 24 or 32 pixels anyway. Sure, modern computers nowadays have enough RAM to spare, it won't tank performance, but it's also an unnecessary waste when adding one extra column of pixels would not only take advantage of the wasted space, but also fit neater onto normal screen resolutions, and be more in line with industry standard.

---

As for my own use case, I want to be able to do something akin to Donkey Kong Country or the Genesis Sonic games, where the levels are made up whole-sceeen sized "chunks" (called meta-tiles, usually 256x256 px) while the normal sprites and objects are smaller tiles of 16x16 px. The larger tiles are snapped to their own large grid, but are e a multiple of the smaller tiles, so everything aligns nicely.

Same for DKC, but I believe their tile size was 24 px. Technically in DKC the levels' larger meta-tiles are made up of small 24x24 tiles, but when designing the game the devs weren't actually placing these 24x24 tiles manually ever. The 3D level chunks were designed and rendered as 256 px images, and then later sliced up into memory as 24 px tiles as a hardware limitation convenience. (Actually I think they may have been broken down further to 8 px tiles, and used special algorithms to identify redundantly similar tiles, for compression's sake).

But modern gaming hardware wouldn't likely struggle with actual full 256 px tiles. So a modern workflow would likely have level geometry on its own 256 px tile grid layer, with a smaller 24 px tiles layer to add individual blocks for adjustment, bananas, coins, etc.

My use case would never require arbitrary tile sizes. Any layer would always be a multiple of the smallest base tile unit.

[Snowlith]

Just want to mention that with Godot's change from TileMap nodes to TileMapLayer nodes in the upcoming 4.3 release, the functionality of determining tile size per layer instead of map would be useful for Godot users.

[bjorn]

@Snowlith Oh, that's interesting. Do you know how they deal with multi-layer editing? I read you can select multiple TileMapLayer nodes at once, but I wonder what happens if you try to to select and edit with multiple selected layers that have different tile sizes.

[Snowlith]

@bjorn The Godot editor does not allow editing of multiple layers at once, even layers of the same tile size. The Godot tile editor is definitely not as complete as Tiled's editing capabilities, and I feel like Tiled is currently serving as a valuable reference for the many devs working on these features 😄 Good luck solving this difficult problem! I think this change could make Tilemaps much more flexible.