Closed fosskers closed 3 months ago
While this lets you parse external tilesets, it doesn't actually solve the problem that they seek to solve. Namely, they way you implemented it here the tileset information is duplicated for each tilemap, meaning the tileset is loaded into a fresh texture for each tilemap and loaded anew for each as well, defeating the purpose of the deduplication in the first place.
In order to solve this properly we need a separate asset that holds the tileset information, and then make the tilemap figure out the corresponding asset for the tilemap file that it finds referenced in the json. How best to do that linkup I'm not sure.
the tileset information is duplicated for each tilemap, meaning the tileset is loaded into a fresh texture for each tilemap
As it would be for the behaviour on master
, which assumes each map has its own embedded tileset. So you're right that this doesn't help deduplication within Trial itself, but as least it helps somewhat on the Tiled side.
Provided I remove the docstring, we will be able to put this PR in as a first step toward an eventual complete external tileset solution?
How best to do that linkup I'm not sure.
Same, although as my understanding of Trial grows I may think of something.
Sure
The previous logic assumed that tilesets were embedded directly into the Tiled map. When handling many maps, it can be advantageous to leave the tileset unembedded so that its configuration can be more easily shared.
When embedded, the structure of the
tilesets
field of the original.tmj
file looks like:when unembedded, it looks like:
But luckily the format found in
.tsj
is (basically) identical to what the code originally expected, so we just need to do a quick switcheroo if the unembedded file is detected.