How tilemaps may ruin your project. And your sanity

Post reply
Not favoritedFavorited Favorited 3 favourites
From the Asset Store
2D Platformer Black Tileset
$4 USD
This is a black tileset with 2 tilemaps, props, one animated character and more.
anty21ro's avatar
anty21ro

  • I've been meaning to report this for ages but it hasn't been a real issue for us (yet).

    I noticed it when exporting a tilemap as a .tmx so we can utilize Tiled's auto-tiling features. As you said, no matter the current size, the internal "tile canvas" will persist as its maximum from any point in time. Occasionally we will find a single stray tile waaaaay off in the distance.

    Either scaling down a tilemap should scale the internal size respectively and delete tiles, or a new button should be added that does this.

  • Ashley, could we get your thoughts on this? Can Construct crop tilemaps (automatically, via a prompt, or with a setting) in both existing and new projects?

  • R0J0hound I tried your tool and it doesn't work correctly with some tilemaps. Here is an example.

    Also, there may be an issue with jszip - Construct now shows random errors when opening a large cropped C3P project, like "Error: missing file path 'objectTypes\foo.json" or "Error: missing file path 'images\bar.png", while the files are definitely present.

  • Ah, I’ll pull the link for now then.

    Edit:

    Updated link to work with your example too. I should have tested more.

    If files are reported as missing in the generated c3p I'll keep the link striked out for now. I haven't seen errors like that, but I may just need to test on a heavier project. If it's an issue with the jszip library then maybe switching to zip.js (which c3 uses) would be an option.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • By the way, I’ve noticed this issue in many official examples.

    The worst is the Avalanche game: a few tiny tilemaps are already using around 200 MB of memory. Once you start bucket-filling them with snow tiles (which people can absolutely do), memory usage quickly jumps past 1 GB. Add a few more levels, and the editor will crash. 

    "tilemapData": {
"width": 8,
"height": 6,
"max-width": 299,
"max-height": 3891,

    Each tilemap is over a million tiles!

  • I think Ashley went on New Year's break.

  • I'm curious, does it also apply to C2 tilemaps? We still have on-going projects developed on C2

  • I'm curious, does it also apply to C2 tilemaps? We still have on-going projects developed on C2

    Yes, the same thing happens in C2. I’m guessing there’s no strict memory limit there, so you’re probably fine.

    Although, the tile data format in C2 is different - each tile is stored separately. For example: "5,5,5,5,5,5,5,..." instead of "100x5".

    If you have tilemaps with millions of tiles, your project files can get huge.

  • Hi, I tested this remark. I used the "Clear Pipes Template" from the Browser examples. This really puts a load on the browser. And the program by dop2000 fixes this. Pay attention to the screenshots.

    First: I tried to increase the size of Tilemap, then change it back (without "undo").

    Second: I additionally tried to fill Tilemap.

    The problem is noticeable even by the size of the "layout" file (and program fix it).

    Result: If you accidentally add an extra zero to the size, the project will increase irreversibly (not counting the program). Again... again...

  • Thank God i don't use very big Tilemaps.

  • Construct keeps the tiles past the edge of the tilemap to preserve them essentially for undo purposes - if you slip and accidentally resize a tilemap smaller than you want, that definitely shouldn't erase all your work. So you can resize a tilemap smaller, then resize it bigger again, and see all your old tiles. I think everyone would agree that's useful.

    I do however agree that Construct shouldn't save all that extra data to the project. I think that is an oversight, and at that point the data should be truncated, much like nobody expects undo to still be there after opening a project, in order to save memory. That's straightforward to do and is implemented for the next beta. FWIW, that could have been filed as a bug report, as I don't think there is any case to preserve that data through saving and opening a project.

    I also went further and made it so the editor will only fully load all tile data for tilemaps in open Layout Views. When you close a Layout View it will then save the tile data in a more compact form until it is needed again, which should also mean the editor scales much better with large projects using tilemaps extensively, as it will only need to have full tile data loaded for your currently open Layout View tabs.

  • Ashley I think 2 buttons would be useful for the Tilemap plugin:

    1. One that will delete all the tiles in the tilemap.

    2. One that will delete all the tiles that are outside the tilemap edges.

    I mean, at least the first one I would personally need it, I am using the tilemap a lot and this could speed up the work.

  • I do however agree that Construct shouldn't save all that extra data to the project. I think that is an oversight, and at that point the data should be truncated, much like nobody expects undo to still be there after opening a project, in order to save memory.

    Ashley This sounds like a reasonable solution, thanks.

    My only concern is that some people may temporarily shrink tilemaps while working on them. For example, if a map consists of three layered tilemaps, they might shrink the top two while editing the bottom one. If the project is saved in that state, any data in the shrunken tilemaps would be permanently lost.

Post reply
Index icon Return to board index
Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)