@Shadow001: I took a quick look at your map, and noticed that you data is base64 encoded. At this point this is not supported by Tileson, so the parser will not know what to do. You should be able to load the map if you go to map properties and change the Tile Layer Format to CSV. Also the Tile Render Order might affect how the tiles are drawn. The demo map uses “Left Down”, while you are using “Right Down”.
I now have a full example that draws all the parts of the demo map using SFML in my latest commit. Now got it building on Linux (GCC) and Windows (using MSVC). Should build on OS X as well, using the homebrew version of llvm, but I have yet to get that verified. I got an old mac lying around, but I won’t have the time to verify that it works today.
Hi again,
I have a question a little bit off topic:
As soon as I made my render function in a standard game loop, my framerate become too slow to be pleasent to see (8<framerate<20 FPS)
My question: is the idea of rendering all my map (not only the displayed part) is absurd (even for quite small maps (ie. 50x50))? or should I consider a new loop pattern?
50x50 isn’t big at all and should not cause problems. Are you sure you’re rendering the map in a performant way? For example, are you perhaps rendering each tile with its own draw call, instead of batching them into fewer draw calls? Are you perhaps generating the drawable object(s) from the data on every frame, instead of having your drawable(s) created once and reusing it?
(This is very off-topic for this forum though, so I’d recommend taking it to DMs or another forum, as this one doesn’t have an off-topic section.)
Hi,
I am really a noob with c++ game development. I have to do this for school so…
How do I run your project? I passed my path to a tiled json file in the main.cpp.
tson::Map map = parser.parse(fs::path("./src/level/level1.json"));
I have already added a tiled json file in the project and the path is correct.
But keeps saying file not found. It seems to be ignoring the main.cpp
How can I run this project?
Hopefully this is not a stupid question.
Thanks in advance!
How did you make sure the path is correct? Note that you are passing a relative path, which the program will resolve as relative to its working directory. This may not be where you think it is (you can check using std::filesystem::current_path() to be sure).
Good luck with your assignment, sounds like fun!
Thank you for your reply :).
How can I run the main.cpp? The main.cpp is not being called. It only calls the tileson_tests.exe
Hmm, that depends on how the project is set up and your development environment. Maybe @SSBMTonberry can help with that. If this is a Visual Studio usage question, you may just need to activate a different project in the solution view.
But do you know how to install this in my project with cmake? I don’t find a guide for this.
@ffbodie: Sorry for the late reply. I have been very busy lately…
First of all I think @bjorn is right when he says that your path probably isn’t pointing to a file. “./” means the folder relative to the running executable, and unless you actually have created the folder “./src/level/” exactly where the .exe runs, it will not be valid. You can easily check if you have a valid path, by doing something like this:
fs::path path = fs::path("./src/level/level1.json");
bool pathExists = fs::exists(path);
Keep in mind that fs is an alias for std::filesystem that is used by Tileson.
If pathExists has the value true, then you are right, if not: then the path is not valid.
Since Tileson uses this functionality itself, I am fairly certain that the path you specified is not valid from where your .exe is running.
Sounds like you have recently started programming in C++. If this is the case, I would suggest you try making a regular C++ program using Visual Studio. Tileson uses CMake because it is designed to be cross-platform, but I would not recommend you to start there. Sounds like you have been able to build Tileson with its examples, which is a good start! When you built the project there is a Tileson.lib(default) or Tileson.dll file created (depending on how you configured CMake). You will need to use this when linking with your new Visual Studio project. You will also need all the header-files (*.h) related to Tileson for your project to recognize Tileson’s functions. You will need to read up on how you link libraries with Visual Studio, but it’s easy to find on the internet. Good luck! 
Additional note: .lib is libraries used for static linking (they will be built into your .exe), while .dll files are not built into your .exe, and will be required inside the same folder as where your .exe is for your program to work.
@ffbodie: Also: Check out SFML if you want to make a 2D game (handles drawing, input, sound, networking etc.). If you go to their home page they have very good tutorials how you use their library, and how you link SFML using Visual Studio.
I cloned this for my own attempt at using Tiled with C++ since this one supports the newest C++ standard (which I’m trying to learn). I did run into a slight issue, however, with the cmake system. I was trying to convert my CMakeLists.txt to be something like this: https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
He makes a compelling case but Tileson doesn’t really support this style. Now, I’m not going to argue about CMake since this is the first project I’m doing with it (I’ve never liked gmake and decided to give this a try) but what are your thoughts? Could Tileson support this?
@Makis: I’m not completely certain what you tried to do. Were you trying to rewrite the CMakeLists.txt of Tileson, or of your own? If you could compile the project using a unmodified CMakeLists.txt of Tileson, then have issues compiling because you rewrite it to fit what that guy wrote in the article, you are kinda on your own. If you however have issues using the original CMakeLists.txt for builing, I will gladly help you solve your issue.
Please keep in mind that this library is made to work cross-platform, which is the reason why CMake is used. I also have Continuous Integration for every platform, making sure everything compiles and unit tests are okay with each build for every system, with several compiler version that supports C++17. For the demo using SFML, I made something quick to showcase how to use the library, as there were several questions on how it should be used with a Tiled map.
As for the CMakeLists.txt for Tileson itself, I really see no value changing it, unless there is a bug with it. I’m sure many people have different opinions on how things should be done, but there is really nothing complicated with the linking of the library, and the way I see it, there is really no value added in rewriting it to do it like the guy in the article, when the options that are provided works.
You are of course free to do whatever you want with your own CMakeLists.txt in your project. If you have issues compiling your application using Tileson, I gladly help. That is, if you have not modified the original CMakeLists.txt.
If there is a bug with anything, please give me some more detailed information on what your issue is, so I can solve it. I do, of course, want the library to be as stable as possible
So what is the correct way of adding the library and include path? Just target_link_libraries and target_include_directories?
If I understand that article correctly one potential issue is if you move Tileson.h or add another interface header or rename the target. My build system breaks because I’m fixing those to current values.
There are several ways of doing it, but you will need to use the target_link_libraries() eventually, to link the library.
Why would you want to move Tileson.h or even rename it? Since it uses relative paths to files below the level it’s at, the result will be that you get errors if you move it. If you rename it, you would also need to rename it in the CMakeFiles.txt. I honestly still don’t see the issue, because you are not supposed to those things.
"My build system breaks because I’m fixing those to current values."
What is broken, and what are you fixing? I’ve used the library myself for personal projects, and I have never really had any issues linking it, so I am wondering what you are doing. Still don’t know if you are tampering with the CMakeLists.txt of the project or your own. If you want any help at all, I would need some details.
With that said, CMake can be quite a mess. I am in no way an expert myself, but there are a hundred ways you can do things. If there are any direct errors, I am of course interested in fixing them, but I have not experienced any such errors by using the library myself, or by the CI building the project on OSX, Linux and Windows. I will need some kind of information to have any idea of what is going on.
If you just want help linking Tileson, I can show you some alternatives, but I will need to see your CMakeLists.txt file. This is of course considering that you have not tampered with Tileson itself, which you of course are free to do, but then it’s your responsibility (and I strongly discourage it) 
I don’t want to move it but you might. I did the linking like this in my own engine (will creates a library):
include_directories(rev_engine
PUBLIC
$<INSTALL_INTERFACE:include>
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/gfx/inc>
PRIVATE
${SDL2_INCLUDE_DIRS} ${SDL2_IMAGE_INCLUDE_DIRS}
${CMAKE_CURRENT_SOURCE_DIR}/tileson/src
${CMAKE_CURRENT_SOURCE_DIR}/tileson/external_libs
)
And then in the main makefile that creates the executable I added tileson to target_link_libraries but I also need
add_library(tileson STATIC IMPORTED)
set_target_properties(tileson PROPERTIES
IMPORTED_LOCATION "${CMAKE_SOURCE_DIR}/engine/tileson/libtileson.a")
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.