cute_tiled.h - Add support for externally referenced tilesets

[jonstvns]

Embedded tilesets are fine for smaller projects, but they are less friendly for versioning and more difficult to organize/manage when you have many different tilesets (such as animations) in multiple maps.

It would be really nice to have support for loading externally referenced tilesets, but I wonder if there's some major complication that prevents this. If I wanted to do this myself and submit a pull request, do you have any suggestions on how to go about it?

[ghost]

My Tiled loader only loads external tilesets. What I do is start to parse the map file, then when I get the name of the tileset file, I load that and parse it.

On August 23, 2020 3:19:25 PM MDT, Jon Stevens notifications@github.com wrote:

Embedded tilesets are fine for smaller projects, but they are less friendly for versioning and more difficult to organize/manage when you have many different tilesets (such as animations) in multiple maps.

It would be really nice to have support for loading externally referenced tilesets, but I wonder if there's some major complication that prevents this. If I wanted to do this myself and submit a pull request, do you have any suggestions on how to go about it?

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/RandyGaul/cute_headers/issues/217

[RandyGaul]

I was thinking the same thing actually. It would be very trivial to add this as a feature. It’s just a matter of calling the parse function. I can add this feature in today. I’d say go ahead and try making a pull request yourself, but there’s a small specific refactor I think should be done, so I’ll go ahead and do that :)

[RandyGaul]

@fluffrabbit Yeah exactly, I'll let the user get the path to the tileset file, but also can re-use the parser to make a standalone tileset parsing function.

[ghost]

IMHO the fewer files the user has to specify, the better. Maybe an optionally-null string as an optional parameter.

On August 23, 2020 5:09:48 PM MDT, RandyGaul notifications@github.com wrote:

@fluffrabbit Yeah exactly, I'll let the user get the path to the tileset file, but also can re-use the parser to make a standalone tileset parsing function.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/RandyGaul/cute_headers/issues/217#issuecomment-678836867

[RandyGaul]

The entire idea of parsing an external tileset will be optional :)

[RandyGaul]

Give this a try and let me know how it goes!

https://github.com/RandyGaul/cute_headers/commit/235426393a920a34401f8d51fb5de9684989f148

[jonstvns]

Appears to be working, thanks! I had to add a line to skip the editorsettings field that can show up in external tilesets.

Pull Request here: https://github.com/RandyGaul/cute_headers/pull/218

This solution is totally workable, but it's slightly cumbersome to load the external tilesets this way since you gotta loop through the map->tilesets, load each external tileset, update that loaded tileset's firstgid, and then manually manage those external sets somewhere.

Ideally the loading is all handled internally as the original tilemap is parsed, but maybe that would require a lot more work.

Here's my good enough solution for now.

cute_tiled_map_t *map = 0;
result &= LoadTilemap("../resources/tilemaps/test-map.json", &map, NULL);

cute_tiled_tileset_t *ts = map->tilesets;
cute_tiled_tileset_t *tileset = 0;

while (ts)
{
    char *tilesetPath= TextJoin(tilemapDir, ts->source.ptr);

    // TODO(jstevens): store the `tileset` somewhere b/c we'll have more than one soon
    LoadTileset(tilesetPath, &tileset, NULL);
    tileset->firstgid = ts->firstgid;

    ts = ts->next;
}

[ghost]

Helper function?

On August 23, 2020 10:29:06 PM MDT, Jon Stevens notifications@github.com wrote:

Appears to be working, thanks! I had to add a line to skip the editorsettings field that can show up in external tilesets.

Pull Request here: https://github.com/RandyGaul/cute_headers/pull/218

This solution is totally workable, but it's slightly cumbersome to load the external tilesets this way since you gotta loop through the map->tilesets, load each external tileset, update that loaded tileset's firstgid, and then manually manage those external sets somewhere.

Ideally the loading is all handled internally as the original tilemap is parsed, but maybe that would require a lot more work.

Here's my good enough solution for now.

   cute_tiled_map_t *map = 0;
result &= LoadTilemap("../resources/tilemaps/test-map.json", &map,
NULL);

   cute_tiled_tileset_t *ts = map->tilesets;
   cute_tiled_tileset_t *tileset = 0;

   while (ts)
   {
       char *tilesetPath= TextJoin(tilemapDir, ts->source.ptr);

// TODO(jstevens): store the `tileset` somewhere b/c we'll have more
than one soon
       LoadTileset(tilesetPath, &tileset, NULL);
       tileset->firstgid = ts->firstgid;

       ts = ts->next;
   }

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/RandyGaul/cute_headers/issues/217#issuecomment-678896833

[RandyGaul]

cute_tiled is a rather low-level tool, so I don't want to start making decisions about how to handle the data. The intent is for users to pull data out of the cute_tiled structs and store whatever they need in their own data structures. Of course, you can use the cute_tiled objects as-is in your own code, but wrapping is encouraged.

If I start making decisions about hash tables or maps then I have to consider memory allocation concerns, the API design of it all, how to document things, and the scope starts to balloon.

Making tables and maps is something users can do in their own runtime with their own code exactly the way they prefer, without cute_tiled getting in the way.

Thanks for the pull request, and feel free to comment more or re-open the issue if you like!