Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tile Size per layer not per Map #149

Open
RolandasRazma opened this issue Jan 24, 2012 · 34 comments
Open

Tile Size per layer not per Map #149

RolandasRazma opened this issue Jan 24, 2012 · 34 comments
Labels

Comments

@RolandasRazma
Copy link

@RolandasRazma RolandasRazma commented Jan 24, 2012

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
Copy link
Owner

@bjorn bjorn commented Jan 24, 2012

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
Copy link
Author

@RolandasRazma RolandasRazma commented Jan 24, 2012

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
Copy link
Owner

@bjorn bjorn commented Jan 24, 2012

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
Copy link
Author

@RolandasRazma RolandasRazma commented Jan 24, 2012

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

@stefanbeller
Copy link
Contributor

@stefanbeller stefanbeller commented Jan 24, 2012

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
Copy link
Contributor

@stefanbeller stefanbeller commented Mar 20, 2012

@osuka
Copy link

@osuka osuka commented Mar 22, 2012

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
Copy link

@ragekit ragekit commented Jan 20, 2013

Any news on this one ?

@bjorn
Copy link
Owner

@bjorn bjorn commented Jan 20, 2013

@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
Copy link

@ragekit ragekit commented Jan 21, 2013

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

@Bertram25
Copy link
Contributor

@Bertram25 Bertram25 commented Apr 4, 2013

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
Copy link
Owner

@bjorn bjorn commented Apr 4, 2013

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
Copy link
Contributor

@Bertram25 Bertram25 commented Apr 4, 2013

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
Copy link
Owner

@bjorn bjorn commented Apr 4, 2013

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
Copy link
Contributor

@Bertram25 Bertram25 commented Apr 4, 2013

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

@UliAbo
Copy link

@UliAbo UliAbo commented Aug 15, 2015

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
Copy link
Owner

@bjorn bjorn commented Aug 16, 2015

@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
Copy link

@UliAbo UliAbo commented Aug 18, 2015

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
Copy link
Owner

@bjorn bjorn commented Aug 19, 2015

@Ulli-RPG Alright. :)

@abueide
Copy link

@abueide abueide commented Oct 29, 2016

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

@bjorn
Copy link
Owner

@bjorn bjorn commented Oct 29, 2016

@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
Copy link

@Lucrecious Lucrecious commented Dec 20, 2016

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
Copy link
Owner

@bjorn bjorn commented Jan 2, 2017

@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
Copy link

@Lucrecious Lucrecious commented Jan 3, 2017

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

@Gr33nbl00d
Copy link

@Gr33nbl00d Gr33nbl00d commented Jun 28, 2017

Really would like this feature

@Lucrecious
Copy link

@Lucrecious Lucrecious commented Jun 28, 2017

@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
Copy link

@Gr33nbl00d Gr33nbl00d commented Jun 29, 2017

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
Copy link

@Lucrecious Lucrecious commented Jun 29, 2017

@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
Copy link

@Gr33nbl00d Gr33nbl00d commented Jun 29, 2017

@bjorn
Copy link
Owner

@bjorn bjorn commented Apr 5, 2018

@fmscorpion
Copy link

@fmscorpion fmscorpion commented Mar 11, 2020

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
Copy link
Owner

@bjorn bjorn commented Mar 14, 2020

@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
Copy link

@fmscorpion fmscorpion commented Mar 20, 2020

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
Copy link

@HollowedEmpire HollowedEmpire commented Apr 7, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.