Closed megabobik closed 3 years ago
Thanks for this patch. As you can certainly guess, I have not been doing much with this project in a very long time, so I'm giving myself a chance to get caught up on everything, like how to build it :). But I will hopefully incorporate this very soon.
As for the patch itself, I'm not sure why Load
had to be renamed to LoadInner
, did this clash with some existing variable? Otherwise, everything seems OK with this.
I just wanted to separate 2 definitions Load method that accept file name and just cover LoadInner, and LoadInner method that do all job from constructors.
But honestly this project need a bit more polish so it can be used as Content Pipeline project.
Let’s Make a deal: I will write Content Pipeline subproject, you will update Nuget package. Deal?
Extremely happy for you to take on Content Pipeline support! I never really understood how the thing was supposed to work anyway :laughing:
Just managed to get my ancient test case built, so I will push a NuGet update ASAP
I made a new subproject with TiledSharp as Content Pipeline project. But there was many changes: almost all classes initialized through Parameterless Contructor and the initialized through method Init() as Monogame initialize all classes and fields through Activator.CreateInstance(), changes target framework to 4.5 as Monogame 3.6 works on .net 4.5. Question is : where to commit it ? To your project (you add description) or as my project( I credit that it is fork Of your project)?
Introducing new constructors is not an issue, but I think that requiring a newer .NET target could be a problem. I know that some people use this library in Unity projects, which have (or had?) a rather old .NET backend - I want to say .NET 3.5, or some incomplete implementation of 4.5.
Forking is no problem of course, especially since I can't really claim to be working on this anymore. We could also look into exploring support for different .NET targets, though that may ultimately be too much work. Happy to do whatever best supports your work for now.
Also probably worth reassessing this project and and forks in the context of UnityTiled and Monogame.Extended, which I have not been following.
I know this pull request has been open for a while, but I'd like that add that I too would like to see constructors like this in order to make map loading compatible and useable with the MonoGame Content Pipeline. I'm going to try out the proposed patches and if they work, I will take a fork for now until it has been merged into the main project. I'll post an update once I got around implementing this, as there are some merge conflicts that have to be resolved first.
@DelightedCat Please feel free to take leadership on this, I am very far from doing any C# development and am no longer in a good position to evaluate any of this work.
Hi @marshallward
Thanks for the honest heads up. I was trying to figure out if this project is still being maintained or not but it seems I got my answer now. I don't know if @DelightedCat is actually interested in taking over leadership, but otherwise I am sort of unless one the current 84 forks is up to date? That I am also curious of.
But if I were to take leadership I would rather start from scratch than modify the source as I believe it is not only much cleaner but also easier to be up to date with modern C# standards, and since a lot of people want to use this in MonoGame it could be shaped more in their favour. Truth is, the Tiled map format is not very difficult. In fact, it so happens I have my own library already. So it would be less of a reinventing of a wheel for me. It is not public yet as it is part of a private project, but I have been thinking of making it public. It does not only parses xml but also json. Let me know what you think of this idea. I am happy to sort something out. :)
With kind regards, TheBoneJarmer
As a follow-up, I never got around making the changes I mentioned earlier. I've rolled a custom solution for my project in particular that involves the MonoGame Content Pipeline.
Although I still feel like we'd need an up-to-date library that parses Tiled formats to C#, which @TheBoneJarmer seems to have already worked on. He seems to be in a better position than me to take over leadership, although I'd be more than happy to contribute to his project.
@TheBoneJarmer If you'd like to discuss this matter in further detail, feel free to reach out to me in private (email perhaps?) or keep the thread going!
That would be great @DelightedCat. I have used MonoGame in the past but have moved focus to my own framework recently. Therefore I know how the content pipeline works but it would be very practical if someone with more recent MonoGame experience, just like yourself, would be able to test my changes.
I agree with @TheBoneJarmer; for the most part, parsing a Tiled TMX file is not much more than XML parsing, which describes almost all of the code in this project. There are a few nice features like the lower level DEFLATE support, but there are also plenty of bad decisions as well, such as the dumping of all maps into memory, regardless of size or quantity.
So I think moving to a new library is a good idea, and spinning something off from your framework sounds like a good plan.
One particular goal I tried to follow was to remain framework-agnostic, meaning that I avoided XNA/MonoGame calls and restricted myself to using .NET. This seemed to be useful for Unity developers. This could be a bit difficult if it's pulling deeply from your framework, but on the same note it could help your framework to become more modular. But given how long it's been since I worked on C# code, it may not even be feasible anymore to simply use .NET. (There was a lot of fragmentation and restructuring last I looked, and tuned out after the .NET core stuff).
As for how to proceed, I think that a complete replace of the code in this repo would probably also clobber the API, which is generally a bad idea, so directing people to a new project may be the best solution. But I may also be exaggerating the actual problem, given that this is a very low-traffic project. Either way, I am very open to any options.
Hi @marshallward
Thanks for the reply! And thanks for your trust. And no worries, I actually designed my Tiled library with the same goal in mind. It has no direct links to my own game framework or MonoGame. That was also one of the motivations for going public. It only uses functionality already present in the dotnet SDK with the exception of NewtonSoft.Json as external dependency for json parsing. And just like your library, mine also makes use of XML calls for maps in TMX format ans tilesets in TSX format.
And I also agree with you that a new project would be better than replacing the code in this one. That way it wont raise confusion to those who already use this. That still leaves me with the issue of figuring out a good name but that is no biggie. Once I got one all that is left for me to do is creating a public repo and sharing it here. Again many thanks for this opportunity!
Looks like we got a plan here!
@TheBoneJarmer Feel free to let me know how you would like me to help out with testing and contributing to the project moving forward.
Hi @DelightedCat
Will do! First of all, perhaps we should start by making communication more comfortable. I am happy to share my email address, but I also have a Discord, Twitter, Facebook and Itch account all under the same nickname: TheBoneJarmer. Whatever suits you best. :)
Hey @DelightedCat @marshallward
I have created my repo in the meantime. Decided to call my project "TiledCS". You can locate the repo here. I have one open issue which I would like to have some assistance on from @DelightedCat as he seems to be more familiar with the XNA/MonoGame content pipeline.
Like I said earlier my library uses Newtonsoft.Json as 3rd party dependency for deserializing JSON. And right now that happens like this:
var json = File.ReadAllText("path-to-map.json");
var map = JsonConvert.DeserializeObject<TiledMap>(json);
And that is perfectly fine for most projects but I don't think that will budge for MonoGame. Loading maps in XML format however is possible using a constructor:
var map = new TiledMap("path-to-map.tmx");
var tileset = new TiledTileset("path-to-tileset.tsx");
There may be a way with Newtonsoft.Json to use it in a constructor too by doing more extensive parsing. But I find that honestly to be a bit stupid since I could literally do it with two lines of code like above. There isn't a NuGet package yet and there is a tiny chance that the library could cause a runtime error when loading XML formatted maps. That is because Tiled doesn't save properties or settings that haven't been set when saving in XML. But it does when saving in JSON.
That was the biggest pain to solve. It surprised me to realize how different the structure was between the two formats. Aside of syntax, both XML and JSON data are structured with nodes. Like in root nodes and child nodes. So you'd expect that node structure to be the same. It turns out it isn't. I'll probably open up an issue about that sooner or later.
Changes and the repo is looking nice and simple so far, perfect!
@TheBoneJarmer I tried reaching out to you on Twitter yesterday as I don't have your full Discord username. I sent you my complete username there, feel free to reach out through there to talk things over.
Oh god, didn't even noticed that. My apologies! I have seen your message just now and will add you on discord.
Hi @marshallward
It has been a long time since we spoke but I can happily say we finished our library. It can be found at https://github.com/TheBoneJarmer/TiledCS. And a NuGet package is already available. As promised it supports both JSON and TMX/TSX as well as a MonoGame content pipeline.
Great news, I will put a note in the README directing others to this project.
Change to TmxMap, so it can be used in Content Pipeline projects.