It sounds like a pretty solid approach over all.
One idea comes to mind, in that you are letting each tile store animation and transparency data separately. I presume you do that for ALL tiles for each used layer. If you think about it, there *probably* aren't going to be that many variations of how you use a particular tile image. You might have, say, used it with 20% transparency unanimated, 50% transparency gradually animated, solid with no animation, etc. Why not have your tiles refer to `animation objects` rather than a given image, so that you only have to store the transparency/animation info once for each way that you're using a given image. Then you don't have to store animation and transparency data separately for EVERY tile. It will save memory. Your `animation object` will then describe what image it used, the transparency, and the animation. Then you can have separate image objects in some array or list that the animation objects refer to.
I think you may also get a smoother update for multiple regions if you implement what is basically a tilemap scrolling technique. Ie, as you move around the map, you spool in one strip of tile data that covers the same amount of area that you scrolled. And if it takes you say 8 frames to scroll 32 pixels then also divide up the spooling into 8 stages so it only needs to load in a few tiles per frame. This is how old-school tile engines used to keep the number of new tiles that need to be drawn per frame to a minimum. You would of course be constantly spooling whenever you scroll but the amount would be small enough that it should be smooth. As for loading in new tile image data, you could do that based on proximity to the new region, ie as you scroll closer to it you spool in more images, as you move away you spool in images for the opposite region.
I think also you might rethink your use of images. Having one Image per tile, presuming your tiles are pretty small, you are wasting a heck of a lot of video ram. You need to get a whole tileset into a single or a few large textures and then draw only rectangles from that texture to draw individual tiles. This is much more efficient for rendering speed and memory use - less memory has to be allocated, plus if you don't have to keep switching to a different texture/image for each tile it cuts down a LOT of overhead and should speed up your rendering.
Also here's another idea that you could implement .... if some areas of the tilemap are identical to others, you don't need to store them multiple times. Just have a simple relative `reference` offset for each tile, which instead of taking tile data from that tile, it takes it from the tile at the given X,Y offset (or a single offset value if you prefer). So then say if you have a 10x10 tile area which is identical in a few parts of the game, you can just store it once in its full state with all the animation data and layers, etc, then have a 1-layer 10x10 tile area elsewhere which is more or less empty and just says `use the tile data from that other tile area over there`. What this also means is that if you then edit that original 10x10 `master` tile group, all other areas that tap into that group are automatically updated.
Think about how spreadsheet software works and how it lets you make formulas and have areas automatically update etc.
One idea comes to mind, in that you are letting each tile store animation and transparency data separately. I presume you do that for ALL tiles for each used layer. If you think about it, there *probably* aren't going to be that many variations of how you use a particular tile image. You might have, say, used it with 20% transparency unanimated, 50% transparency gradually animated, solid with no animation, etc. Why not have your tiles refer to `animation objects` rather than a given image, so that you only have to store the transparency/animation info once for each way that you're using a given image. Then you don't have to store animation and transparency data separately for EVERY tile. It will save memory. Your `animation object` will then describe what image it used, the transparency, and the animation. Then you can have separate image objects in some array or list that the animation objects refer to.
I think you may also get a smoother update for multiple regions if you implement what is basically a tilemap scrolling technique. Ie, as you move around the map, you spool in one strip of tile data that covers the same amount of area that you scrolled. And if it takes you say 8 frames to scroll 32 pixels then also divide up the spooling into 8 stages so it only needs to load in a few tiles per frame. This is how old-school tile engines used to keep the number of new tiles that need to be drawn per frame to a minimum. You would of course be constantly spooling whenever you scroll but the amount would be small enough that it should be smooth. As for loading in new tile image data, you could do that based on proximity to the new region, ie as you scroll closer to it you spool in more images, as you move away you spool in images for the opposite region.
I think also you might rethink your use of images. Having one Image per tile, presuming your tiles are pretty small, you are wasting a heck of a lot of video ram. You need to get a whole tileset into a single or a few large textures and then draw only rectangles from that texture to draw individual tiles. This is much more efficient for rendering speed and memory use - less memory has to be allocated, plus if you don't have to keep switching to a different texture/image for each tile it cuts down a LOT of overhead and should speed up your rendering.
Also here's another idea that you could implement .... if some areas of the tilemap are identical to others, you don't need to store them multiple times. Just have a simple relative `reference` offset for each tile, which instead of taking tile data from that tile, it takes it from the tile at the given X,Y offset (or a single offset value if you prefer). So then say if you have a 10x10 tile area which is identical in a few parts of the game, you can just store it once in its full state with all the animation data and layers, etc, then have a 1-layer 10x10 tile area elsewhere which is more or less empty and just says `use the tile data from that other tile area over there`. What this also means is that if you then edit that original 10x10 `master` tile group, all other areas that tap into that group are automatically updated.
Think about how spreadsheet software works and how it lets you make formulas and have areas automatically update etc.