probityrules
commented
6 years ago Nice catch!
Yes, if the map is smaller than 2048x2048, or can be comprised of two of these blocks, RenderTiles caches everything so it doesn't need to keep redrawing tiles. The bleed is to cover up the joint when the tile map is comprised of two blocks.
If the map is larger, RenderTiles will use double-buffering by default and redraw as the camera is scrolled around the map (thus 33x33 not exhibiting the issue).
I was seeing an issue where I had a 32x32 Tiled map but the last row and column were both missing in Platypus. This only happened when a dimension was 32 - if I used 31x31 or 33x33, all of the map tiles properly appeared, but if either width or height was 32, that 32nd tile would be missing. I soon realized that since my tiles were 64x64, these corresponded with pixel sizes of 2048, so I started poking around in RenderTiles, where the maximumBuffer is set to 2048.
So I guessed it had something to do with the tile size matching the maximumBuffer, and I found that setting EDGES_BLEED to 0 made those tiles appear again. I narrowed it to where updateRegion() is using the EDGES_BLEED in its calculation for ctw and cth variables - see RenderTiles.js line 737 - if (this.cacheWidth - EDGES_BLEED) is changed to (this.cacheWidth - 0), then with everything else the same, the tiles will appear again. I assume this calculation was added for good reason though, so I don't suppose just zeroing it out is the right fix.
My workaround for this was to just shrink my map down to 31x31, because I suspect these margins and edge bleeds have been carefully constructed for caching performance and clean gapless tiling and such (and I figured it would be good to have the map fit comfortably under 2048x2048 for performance anyway). But I thought I'd mention it here.