itch.io

Tilekit can export to the .tmx format used by Tiled -- there may exist tools for converting .tmx files to a format which is compatible with GMS2

You can pass multiple filename arguments to cel7 if you want to use multiple files, when creating a self-contained executable you can append multiple files to the end of the exe

The 1.07 update with the mentioned changes has been released.

Thanks for the kind words and for posting a screenshot of the error message! I hadn't expected anyone to reach the 64 rule limit -- I've fixed the condition which triggers the assertion and increased the rule limit from 64 to 128, both changes will be in the next release (1.07). 

Tilekit only supports a single tileset file for a map, if you want to use more than one you'll have to combine them manually into a single image. To reload the currently tileset image the Ctrl+L keyboard shortcut can be used.

I've uploaded a zip file containing a .tmx and .json export of one of the demo projects here

Tilekit exports to JSON by default -- this can be read by any JSON library (of which any language should have readily available), from there it should be trivial to get the resultant data into your engine's tilemap structure; the objects should be equally trivial to load. The structure of the exported format is detailed in the manual.

In addition to this, Tilekit can also export to plain CSV, as well as Tiled's TMX format -- the latter can be converted by Tiled to any of its own export formats.

I can upload a map exported to both JSON and TMX if you want to experiment with loading before purchasing!

Nope! cel7 doesn't provide any support for audio output

The language documentation is here. You can also check out the included demo scripts on fe's repo and cel7's demos.zip.

This might be implemented in a future version and is something I've also thought of myself! For now the Ctrl+L keyboard shortcut can be used to quickly reload the currently loaded tileset.

You could try something like this (right click and save).

Layers are currently not supported, the main issue is there not being an obvious solution to implementing them that would maintain the fast workflow Tilekit tries to provide. If layering were to be implemented, I'd want to avoid doing so in the naive way (eg. having multiple layers, each with their own map data and rulesets) without first putting effort into coming up with a better solution which doesn't involve having to manually keep two separate layers in sync with one another.

One of the core goals of Tilekit is to make tilemap editing fast and less tedious, ideally an approach to layers would keep in line with the current level of automation which is already provided.

Yes, you'll have access to all future 1.xx updates

Thanks for the kind words! macos support isn't planned at the moment, though some people have had some success running tilekit on mac using wine. See https://itch.io/t/850159/is-it-possible-to-run-this-on-mac

This particular feature doesn't merit a write-up due to its simplicity, it's achieved by the following:

1. When application is built a null byte (0x00) is written to the end of the executable
2. When the application is run it opens its own executable and scans for the last null byte in the file. If there is anything after the last null byte it's assumed to be a program and is read in, otherwise the files listed by the commandline arguments are read

This exact approach only works with text as we're assured the file we're appending to the executable won't contain a null byte of its own

In contrast to OP's issue these sound like the standard messages you would get when trying to download any executable -- my assumption is downloading another game from itch would result in the same warnings, assuming the game was very new or otherwise infrequently downloaded.

I've uploaded a new version which, at the cost of file size, doesn't use UPX -- I assume this was causing the false positives.  Let me know if this fixes the issue!

I've uploaded a new version, let me know if it fixes the issue!

Thanks for letting me know -- this is likely due to the means used to reduce the file size. I've updated the Windows version, hopefully this fixes the issue!

On windows:

type cel7.exe game_file.c7 > game.exe

on linux:

cat cel7 game_file.c7 > game

I've updated the linux executable -- let me know if this fixes the problem!

This should be fixed in the 1.03 update -- The tileset selector is scaled down on large tilesizes to better fit the UI and zoom-in/out support has been added.

Thanks for sharing the tileset! I'll continue to give it some thought and see if I can work out an elegant solution.

Cases like this aren't a good fit for tilekit currently. That being said I have some thoughts on how this might be fixed and am open to suggestions on how this could be better supported. Is there any chance I could get a copy of that tileset (or a link to it if its publicly available) so I can use it for testing?

Mac support isn't planned at this time; see https://itch.io/t/850159/is-it-possible-to-run-this-on-mac

There currently aren't any plans to support macOS; that being said, at least one person has had success running Tilekit on mac using Wine: https://itch.io/post/1578129

Large tilesets are fixed in the two menus you mentioned:

Unfortunately I didn't account for such large tile-sizes being used. The core issue is tilekit not being designed to work with tile-sizes this large, that is, even if these menus were fixed the experience of using 128x128 tiles in tilekit will likely leave something to be desired. Ideally the fix is to sort out the core issue which is more of a substantial change than fixing those particular menus; this will require some thought on my part. 

Thanks for reporting the issue!

Thanks for reporting the bug! This has been fixed and will be part of the next update (1.02):

I don't know if the rules are putting the wall there or how I'm rendering it. Either way, it's probably fixable on my end. Here's the ASCII version for what it's worth.

Changing the default return value in the exported get_tile function from 0 to 1 should fix this

This feature isn't currently planned -- In the case where the background layer isn't directly connected to the foreground layer (eg. the parallax backgrounds in cave story or shovel knight) the layer could as easily be a separate project. In cases where the background layer is connected, such that you're augmenting existing tiles, eg, adding grass/snow to a brick tile, you'd now have to concern yourself with keeping details in sync on multiple layers which would break the workflow and with it negate a lot of the advantages Tilekit provides.

I'd love to have the input map also (maybe optionally) save to the JSON. It would be nice to get to the original brush info, at least the way I'm using it

For using the input map with your project you can just use the .tkp file, which itself is JSON with the input map stored in the input_map field, and tileset information stored in the output_map field. I know this may mean having to load two files into your game, but the alternative of having the input map stored in all exported files would be an issue as in the majority of cases it would be unused; the file-size and game-loading time for the exported file would be doubled which could cause a problem with large maps. 

Regarding the animations and tags, these could also be loaded directly from the .tkp file. The intended work flow was to export the map just for the tags, animations and tileset data, and ignore the map data if it was unneeded. Let me know if I'm missing the issue here!

Looking good on the screenshot -- correct me if I'm wrong: do the indoors/outdoors happen to be swapped in it? What appear to be room shapes seem to be filled with grass.

I've added the command-line export support and it all seems to be working fine; it'll be available in the 1.02 update amongst some other features.

Thanks for the kind words!

Can you add a section to a rule to horizontally or vertically flip a result? Some tilesets just include one corner image, for example, so making the other corners requires some flipping. See this Kenney tileset: https://kenney.nl/assets/bit-pack

I'll give this one some thought about how it might be implemented nicely. With other tilemap software I have had situations where I've accidentally enabled this on a tile, and ended up in a confusing position where I have an out-of-bounds index in my resultant game. Additionally I try to approach any changes to the tiling portion carefully as I want to avoid making anything more confusing than it needs to be -- elaborate rulesets can already make things a bit difficult to keep track of sometimes!

My tiles have padding in between them but less padding on the outside of the entire atlas; do you have plans to support that weirdo configuration? ;)

I've always wondered why people end up with this setup and was convinced it was just a feature-which-no-one-uses in other editors -- would you mind sharing your reasons for it? It shouldn't be a difficult change to support this, though I'll hold off for now at least as there's another feature I want to implement that would require rewriting support for this if I added it now.

I tend to write games that build using `Makefile`s. Any plans to offer a CLI-based export?

If you mean something like the following, I'd be happy to add it into version 1.02:

tilekit -export input_file.tkp output_file.json

Let me know if this is something you still need help with!