I think that if a library is properly defined I would only need find_package and target_link_libraries?
This seems to compile and I can include Tileson.h but as you can see I had to actually include two directories. If you rename those or add a third one my app wouldn’t compile. This is not a big issue in this single instance and I was basically just asking if you are aware of this thing.
I don’t intend to touch Tileson unless I find a bug or find I need something. In this case I’ll submit a pull request.
The point this blog post seems to make is mostly that by doing a bit more work to use some modern CMake features, we can keep the stuff that needs to be written in CMake files downstream to an absolute minimum. This has both the benefit of simplifying things for the users of a library as well as being able to change certain things (like include paths, dependencies, etc.) without breaking builds downstream.
To me, those features remind me a lot about how Qbs works, the build system I’m using for Tiled. It just calls things a little different, but there are products (targets in CMake) with properties and they can export stuff (like include paths, which library to link, etc.) to products depending on them. Personally I wish Qbs would become more popular, but I’m glad to see such concepts have been added to CMake (even though I find their syntax incredibly verbose and repetitive).
Anyway, as it often is with free software, if you want to improve something, you may just have do to it yourself. I’m sure @SSBMTonberry would gladly review a pull request to improve the CMake files.
I would love to do something like that but my experience with CMake so far is in the single digit hours. If I get around learning enough I might do that. I think I already know about as much about it as I have learned about gmake’s syntax in the past 15 or so years.
But your comments are exactly how I understood the idea behind that blog post.
Thanks! Now it got more clear to me what you were talking about
There is definitely room for improvement for the CMake file by adding support for find_package() and related properties. As for now there sadly isn’t. That you have to add “external_libs” as an additional include_directory is not ideal either, and it shouldn’t be like that. I may implement a proper find_package() support at a later time, but I may find a way to prevent you from needing to add that extra include dir soon.
What I usually do, personally, is to add things as subdirectories. When they are not subdirectories, they still can work as such by adding a full relative path to the library folder and where it is built. For instance, if debug: add_subdirectory(${PROJECT_SOURCE_DIR}/external_libs/source/tileson ${PROJECT_SOURCE_DIR}/external_libs/source/tileson/cmake-build-debug)
Then I can just simply do: target_link_libraries(my_app tileson)
Not saying this is the best way of doing things, but I have found it simple to do it that way Which may also be the reason why I haven’t thought of the issues you describe. I do like the fact that you are trying to do CMake in a proper and modern way, as there are many things that can be quite a mess otherwise, and I am not afraid to admit that I have done quite a mess with CMake myself over the years, and still am.
I have to say I’m not quite sure how I’m supposed to use this. I want to use SDL2 to draw the graphics so what I’d like to do is to get the tileset image name so I can open it as I can’t figure out how I’m supposed to use the data in the layer with SDL2. I’d also like to get the order of the layers somehow but this doesn’t seem to work for me either.
I’m using the desert scene from Tiled for testing. It has a layer, Ground, and I added another, Roof. I made a simple helper function:
What gives? Is the order of the layers returned by getLayers() guaranteed to be correct? Where is the file name and what does getImage() return then (it has a return value of std::string after all)?
The image of a layer is probably only set when the layer is an image layer, which is a simple kind of layer in Tiled that can be used to display an image. For the tileset image, you’d need to look at the tilesets referenced by the map. See map.getTileset and tileset->getImagePath.
Hm, I thought every layer can have a different tileset in Tiled?
That ordering thing is obviously necessary so maybe it really is already ordered. How else to draw them in the correct order?
Hm, still not getting anything. Trying to print stuff from the tileset produces empty strings and zeros. Must have an issue parsing the file but it’s funny I can print the layer names.
If you download the latest master branch (not latest release), there is a demo showcasing how to draw stuff with SFML, using a demo map. Maybe that will help you
The idea should be the same with SDL. Please note: It only shows how to draw stuff, and is inefficient, but should give you an idea how to use the data.
I must have an issue saving the json files. Code reads the map file ok except for the tileset part (ok, I’m not quite sure about some of the fields). I saved that as a json file as well (I’m using the rpg example from Tiled). I created these json files by simply opening the island map and then saving the map and tileset as json.
Or could there be some sort of version issue between the examples in Tiled and Tileson? The example json for the SFML demo looks quite different from the files I generated.
E. Yep, something odd with the files I saved. Tried with your test map (ultimate_test.json) and things work.
Yes, actually one layer can even use multiple tilesets. But all the tilesets are referenced by the map, and you can use map.getTileset to retrieve them by name (or getTilesets to retrieve the list). Once you have the tileset you can get the file name of its image.