I'm building a randomly generated dungeon. My idea is to have an animated background behind the tilemap for which the non-walkable tiles (the tiles between the rooms) have to be transparent.
But I noticed that as soon as I use a transparent tiles for the tilemap, a weird smearing effect appears. But the effect does not appear everywhere. It only appears when you are close enough to the center of the sprite containing the tilemap.
Here is an example:
I already tried to mark the sprites with :markDirty() but that won't work. Is this a bug or am I missing something?
That looks like what would happen if the sprite is marked opaque but it's not actually filling its drawn area. If you clear that flag with sprite:setOpaque(false) that will fix it if that's what the problem is. As for why it's getting marked opaque, I'll see if I can figure that out..
Got it, thanks for the super clear demo! Turns out setOpaque() doesn't do anything for tilemap sprites. I'd completely forgotten that detail. The problem is my test for checking whether the tile image has transparent pixels isn't adequate, ignores the padding values we use to trim blank space around the edges of images. Setting the tile index to an invalid index, larger than the number of images in the source table, fixes it because those tiles will be empty so the opacity check fails.
I'll get a fix in now and flag it high priority. Looks like this is what's happening in Sam's case too, so it must be a pretty easy bug to stumble across. In the mean time, the workaround is to use an invalid image table index for the empty tiles instead of an empty tile in the image table.
So glad I found this, I was so confused! If anyone is using the LDTK importer script, I created a fork that allows you to pass in a transparent tile ID so it can be overwritten with an invalid value.
Hey Quinn! Thanks a bunch for this! Just in time too since I hit this issue recently. May I clarify how you use this adjustment? It sounds like you mark the transparent tiles with an ID in ldtk and then that ID gets omitted by this script on draw. Is that correct?
You just need to set the tiles to a transparent tile in ldtk, then figure out what the ID of that transparent tile is (tile IDs start at 1 at the upper left corner and increment horizontally before moving onto the next row). Then you can pass that tile ID into the forked script. It's a pretty hacky solution but it seemed good enough for the time being since it sounds like a fix to the Playdate SDK is incoming.
The problem is my test for checking whether the tile image has transparent pixels isn't adequate, ignores the padding values we use to trim blank space around the edges of images. Setting the tile index to an invalid index, larger than the number of images in the source table, fixes it because those tiles will be empty so the opacity check fails.