Solution 0: The current method
The current solution have each part of the border, and the variations of the center, in different images.
Pros:
We can have multiple images for the same terrain, and (semi-)randomly distribute them on the map. This avoids repeating patterns.
The solution can be extended with multi-tile (center) images that are used automatically if specific conditions are met (for example an image that is only used if there are four adjacent tiles of the same type).
The solution can be extended with specific border tiles for all combinations of neighboring tiles.
Low memory requirements.
Cons:
The artist making the tile graphics needs to ensure that all variations of the same tile can be placed adjacent to one another without needing border tiles / transitions.
Solution 1: Tile images with borders
This solution is the same as our current method (solution 0), but with the borders included in the same image as the center image.
Please note that this solution should only be used if we want to have the same border also apply to transitions between terrain of the same type. If not, we should probably just keep solution 0.
Pros:
We can have multiple images for the same terrain, and (semi-)randomly distribute them on the map. This avoids repeating patterns.
The artist no longer need to ensure that borders and center tiles are non-overlapping, since we automatically extract them from a single image.
Fairly low memory requirements.
Cons:
All tile variations need to have a border included in the image.
The solution cannot be extended with specific border tiles based on neighboring tiles.
Solution 2: The tile images with borders and separate masks for alpha blending
Change the tile images so that they include the overlapping regions used for blending. The green tile, in the image "solution2.png", is the tile itself – while the yellow parts will be used for blending (other parts of the image would be ignored).
Please note that this solution should only be used if we want to have the same border also apply to transitions between terrain of the same type. If not, we should probably just keep solution 0.
Pros:
We can have multiple images for the same terrain, and (semi-)randomly distribute them on the map. This avoids repeating patterns.
The artist just need to provide an image that is of sufficient size and the transition gets handled by a separate mask.
It is possible to define several different border masks and apply them (semi-)randomly. For example, we can add variations to the alpha blending so that we avoid straight edges.
It would probably be easier adding new base terrain types than our current solution.
Cons:
Clearly identifiable features will look strange when alpha blended onto another terrain type. The artist will need to only add such features to the center of the image.
The solution cannot be extended with specific border tiles based on neighboring tiles.
Moderate memory requirements.
A bit more complicated to implement.
Solution 3: Large textures
Have a very large repeating texture and retrieve multiple tiles from this texture.
The texture would (logically) be repeated across the entire map – starting in the upper left corner. See the image "solution3.png" for how individual tiles would be retrieved from the texture.
Pros:
Great for ocean (especially if animated).
It would probably be easier adding new base terrain types than our current solution.
It is possible to define several different border masks and apply them (semi-)randomly. For example, we can add variations to the alpha blending so that we avoid straight edges.
Cons:
Clearly identifiable features will look strange when alpha blended onto another terrain type. This can be mitigated by placing such features only within parts of the texture that will be in a single tile (as shown in "solution3.png").
The solution cannot be extended with specific border tiles based on neighboring tiles.
The texture should preferably be the the same size as, or larger than, the screen size. If not, the repeating pattern can become an eyesore.
Using "Solution 3: Large textures" only for the ocean and high seas -- including support for animation.
Keeping the current method for all other base tiles.
Allow embellishments (overlay images) to be added semi-randomly after rendering all the base images. This could be stuff like small rocks, ponds for swamp tiles etc.
Allow terrain like forests, hills and mountains to have images on two layers: The first layer would be above the base images, but below stuff like units and settlements. The second layer could be used to have features above units and settlements on neighbouring tiles. A mountain could then have an image on the first layer extending far into the neighbouring tiles, with just a rocky background, while the second layer would have the mountain peak.
Yes, the ocean deserves to receive special treatment. The animated water might bring the much needed life to the game. In Civ, and Col games the beaches always were treated a bit different than the normal borders. For example, if there were 3 or more tiles aligned diagonally, the beach would load the longer, smooth-looking image to avoid the unnatural looking 'stair' formation. A single land tile would form a nice, small, round island. ETC.
Good idea! I would also add docks visibe next to coastall colonies etc.
The Alpha blending gave good results with the 32x32 tiles but what is going to work best for the 500something by 200 something isometric tiles, it remains to be seen :)
You know what sucks in Free Col? When 3 or 4 different land tiles intersect it's a mess at the center! Worse still, when they are contrasting colours. I'm not sure, how to resolve that.
Last edit: Misiulo 2021-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The solution we currently use for handling 4 different land tiles is assigning priorities on the tile types, and extending the border of prioritized tiles onto the other tiles. This reduces the blending to 3 different land tiles.
This technique would work even better if we have special transition images based on tile types.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But there is so many combinations, and every potential new terrain type wold multiply this number, I think we'll need some smart solution to cover every possible 3 and 4-way conjunction.
Last edit: Misiulo 2021-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We might be able to solve the problem by adding embellishments, like boulders and shrubs, above the intersections. This would probably look okay if we add embellishments randomly on other places on the tile as well.
Another solution is ensuring the map generator never produces maps with four different neighboring tiles (except for ocean/lakes -- as these are solved by beaches). More generalized, we could have a rule that at least one of the tiles need to be of a specific type when there are four different neighboring types.
A third solution would be using a good ordering of tile types -- and just have one transition per tile type like we have now. For example, sand and snow should be drawn above other base tiles and be spread out onto neighboring tiles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And how a bout a 4 colour mask for 4 different tiles 1,2,3,4 to interblend equally? Of course I could make the transitions manually; I'm just looking for the best possible solution.
Just using blending produces a rather good result. Perhaps the best solution would be just using automatic blending and spend more time making good trees and other terrain features?
In that case, we need solution 2 or 3 (as defined above).
Although, we could have a modified version of solution 2 -- where we can have variations of the center tile but without the border. All center tiles should in that case be a seamless drop-in replacement.
I've added a twist; Grassland and savannah have their 'corner' piece thrown in over the Swamp and the Plains. Sometimes simple tricks like this can make a big difference.
Maybe, for example, whenever 3 or 4 land tiles of 1 type surround a single tile another type, they could project their inverted corners on top of it, so that one tile would form a nice, round 'island'?
Here are the beaches for old grassland I once prepared. I could do that in 512x265 for all terrains if needed. On closer examination, some of the combinations seem redundant though. Well, I wanted to cover eveything in at least 2 versions :>
You could also write code to occasionaly add a few random mini-islands close to the beaches based on the closest land tile. (Just like the random trees, rocks and clumps of grass to make the shoreline look more diverse) :)
I have implemented a method for automatically drawing the transitions between base tiles. It only needs the center tile for each base terrain type, and automatically makes all the transitions based on a single image mask file.
The results looks surprisingly good even though I have not yet implemented any blending for the corners.
The attached files are from in-game rendering, but I have not committed my changes yet,
The solution above supports multiple center tiles for each terrain, as long as they can be tiled without transitions.
Beaches need to be handled separately. The easiest solution would be having a beach center tile that is only used for making transitions to land tiles -- and custom transition images for the ocean. By utilizing this approach, we only need one set of beach-ocean transitions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Should I create the dedicated beaches for each terrain type?
I think just one type of beach will suffice. Please ensure the beach is wide enough for proper blending with the land terrain (like the current version). In addition, make a center tile that tiles with all the different beach pieces. The center tile is also used for blending (in this case into the land tiles instead of the blending of the land tile into the beach).
In the future we can add more sets, and transitions between different sets. For example a rocky type of coastline.
Please note, we can also have a separate mask for the transition between a specific terrain and the beach -- although I do not think making such transitions should be a priority right now.
So are we going for the Xtra Large or 256x128?
We are definitely going for 512x256. Please make sure all pieces fit inside "mask-center-512x256" as this ensures easy down-scaling to 256x128 and 128x64.
I would strongly recommend that all the beach tiles have the same width at the edge, where they connect with other beach tiles, as this greatly simplifies making them (and later variations).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I needed to modify the grassland image slightly in order to make it tile properly. The method I used for fixing it was just tiling it in GIMP and then applying the "mask-center-256x128.png".
just to give you some background on why the current rendering is as it is: It started with cleaning up the code and enabling a larger GUI for high-dpi monitors (wish I had put it in option menu not a command line option noone uses), then needing higher resolution images, searching the old SVN for raw source images and sadly only finding very few, then extracting what was possible including trying to recombine layers. Now I had a partial set with very many missing double sized images. I event tried to get quadruple sized ones, but the base images were clearly not made with that goal in mind and would have needed to be redrawn which noone would.
Then I wanted to make as much use of the images I could extract as possible and improved the map drawing. I made it possible to have multiple versions (sizes) of images loaded at the start and then use the most fitting size as a base for resizing in the resource manager. This looked best with bilinear interpolation on in the resource manager and for map drawing. You can not disable this in one of the 2 places because then it is still interpolated once for some images gotten in some sizes.
Additionally, my goal was to make the map render glitchless and in a consistent look. If you disable the smoothing without having a complete set of double sized images, some images look smooth and some look blocky or half-smoothed from the resource manager, making for a bad inconsistent look where one part of a tile is a highres smooth image and another part of the tile and the neighboring tile look blocky. Disabling the smoothing in resource manager would make the GUI look worse, as many images are used both for the GUI and the map. The 1 pixel problem at tile transitions, which was IIRC most visible only when zooming the map maximally in would be a small price to pay for having the whole images have a more consistent look. Additionally, half the players would have the black grid drawn over it.
As for the question I saw about units always drawn above everything, it was a long time ago so I'm not sure if drawing them inbetween was even a thing and if such change happened earlier or when I reorganized the map drawing. But if I changed it, it was because there were many impossible to remove glitches with images overlapping more than one tile and it would have required partitioning, for example, forests into below and above parts, when my first priority was not having any visible glitches (like fortress on middle tile overlapping 2 other tiles, they both having other overlays and part of the fortress on one neighbor being above and on the other below that tile's overlay).
A side goal was to make the code more maintainable by splitting the map rendering into separate layers, which also helped with rendering performance from only having a few images in use at same time. The game had and still has a performance problem, especially with map rendering. Therefore, I doubt adding a complete set of quadruple size images would be possible atm (much higher memory use and even slower rendering).
Still, I hope there can be a complete double sized graphics set. You possibly still have got some more of the old source images for where the game is missing double size images?
Last edit: wintertime 2021-12-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(wish I had put it in option menu not a command line option noone uses)
I was thinking the same for the FontLibrary.DEFAULT_FONT_SIZE that was intended to be used for scaling the entire UI.
In any case, I have combined the two approaches, using a hack for the moment, so that "--gui-scale 200" both sets the scale and a better default font size.
You can not disable this in one of the 2 places because then it is still interpolated once for some images gotten in some sizes.
We should ideally deactivate interpolation only for base tiles and masks. The problem was that separate handling for base tiles and other images have been removed. This can easily be added back in, but I want to simplify (and extend) how alternate versions and sizes are handled before doing so.
I am thinking of just having a single file mentioned in "resources.properties", and automatically search for different versions and sizes in the same location, instead of having to manually define variants and sizes. Mods would still be able to override that image (and can also provide different variants and sizes).
The 1 pixel problem at tile transitions, which was IIRC most visible only when zooming the map maximally in would be a small price to pay for having the whole images have a more consistent look. Additionally, half the players would have the black grid drawn over it.
This may absolutely be true for the players, but it is important that the development version does not hide (or produces) seams while tiling. If not, we might get worse drawing artifacts over time.
But if I changed it, it was because there were many impossible to remove glitches with images overlapping [...]
No need to explain anything: You have been doing great work on the game :-D
I should perhaps not be calling changes from a decade back regressions -- as they can obviously have been made purposefully with another objective in mind. They are just regressions to me because I have outdated expectations -- although I am hoping the changes I am making will be positive for everyone :-)
The game had and still has a performance problem, especially with map rendering.
In what cases do we have problems? I am running FreeCol with 512x256 base tiles quite happily on a 10 year old laptop. Perhaps it is a problem with longer running games as I have not tried that yet -- for example a memory leak?
Therefore, I doubt adding a complete set of quadruple size images would be possible atm (much higher memory use and even slower rendering).
It works on my machine (tm). Seriously, though, please do report any problems you might encounter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok :)
The performance problems depend on OS (mainly they had been reported on some Linux distributions) and JDK+Java startup options (they influence using different drawing and smoothing algorithms and if some call gets done on GPU with many back and forth copying images between system and GPU memory) and I think even their versions. Though, if you click on the map to move and its not redrawn immediately cause of the many layers thats already too slow IMO. This probably also slowed down the AI moves if you have the options activated to see all their moves and animations.
Last edit: wintertime 2021-12-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have fixed several performance issues already. For example, we had a full repaint of the entire map every time the mouse moved 1px! We probably need better testing in order to avoid such problems in the future, as such mistakes are easy to make.
...and you were right that some systems are much slower: I have added a transition cache since some systems are poor at efficiently applying the alpha mask.
BTW, the supporting code that made the game run smoothly on a 200MHz CPU have disappeared. Like fullscreen mode, buffer strategies (page flipping etc), aggressive clipping and incremental painting.
Adding such optimizations back in might be unnecessary, though, as ten year old hardware can render the entire map in HD several times per second. In addition, we cannot add the original code back in without also converting every JDialog back into a JInternalFrame.
But then again, I think 250ms latency while moving the map is acceptable. My guess is you want the latency to be lower than 100ms?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Like this? I hope the program is up to the task; Whenever I did the resizing in Photoshop there always was a line showing up on the map, resizing artifacts, even if the tile looked impeccable on it's own. It would be fantastic if it was all done automtically now! Well, first I'll need to come up with an ideally seamless tile set in 512x128.
Solution 0: The current method
The current solution have each part of the border, and the variations of the center, in different images.
Pros:
Cons:
Solution 1: Tile images with borders
This solution is the same as our current method (solution 0), but with the borders included in the same image as the center image.
Please note that this solution should only be used if we want to have the same border also apply to transitions between terrain of the same type. If not, we should probably just keep solution 0.
Pros:
Cons:
Solution 2: The tile images with borders and separate masks for alpha blending
Change the tile images so that they include the overlapping regions used for blending. The green tile, in the image "solution2.png", is the tile itself – while the yellow parts will be used for blending (other parts of the image would be ignored).
Please note that this solution should only be used if we want to have the same border also apply to transitions between terrain of the same type. If not, we should probably just keep solution 0.
Pros:
Cons:
Solution 3: Large textures
Have a very large repeating texture and retrieve multiple tiles from this texture.
The texture would (logically) be repeated across the entire map – starting in the upper left corner. See the image "solution3.png" for how individual tiles would be retrieved from the texture.
Pros:
Cons:
Last edit: Stian Grenborgen 2021-11-27
Perhaps the best solution would be a combination:
What do you think, @misiulo?
I've red it. Phew! :)
Yes, the ocean deserves to receive special treatment. The animated water might bring the much needed life to the game. In Civ, and Col games the beaches always were treated a bit different than the normal borders. For example, if there were 3 or more tiles aligned diagonally, the beach would load the longer, smooth-looking image to avoid the unnatural looking 'stair' formation. A single land tile would form a nice, small, round island. ETC.
The Alpha blending gave good results with the 32x32 tiles but what is going to work best for the 500something by 200 something isometric tiles, it remains to be seen :)
You know what sucks in Free Col? When 3 or 4 different land tiles intersect it's a mess at the center! Worse still, when they are contrasting colours. I'm not sure, how to resolve that.
Last edit: Misiulo 2021-11-28
The solution we currently use for handling 4 different land tiles is assigning priorities on the tile types, and extending the border of prioritized tiles onto the other tiles. This reduces the blending to 3 different land tiles.
This technique would work even better if we have special transition images based on tile types.
But there is so many combinations, and every potential new terrain type wold multiply this number, I think we'll need some smart solution to cover every possible 3 and 4-way conjunction.
Last edit: Misiulo 2021-11-28
We might be able to solve the problem by adding embellishments, like boulders and shrubs, above the intersections. This would probably look okay if we add embellishments randomly on other places on the tile as well.
Another solution is ensuring the map generator never produces maps with four different neighboring tiles (except for ocean/lakes -- as these are solved by beaches). More generalized, we could have a rule that at least one of the tiles need to be of a specific type when there are four different neighboring types.
A third solution would be using a good ordering of tile types -- and just have one transition per tile type like we have now. For example, sand and snow should be drawn above other base tiles and be spread out onto neighboring tiles.
And how a bout a 4 colour mask for 4 different tiles 1,2,3,4 to interblend equally? Of course I could make the transitions manually; I'm just looking for the best possible solution.
Looking how the old game was handling it:
Last edit: Misiulo 2021-11-29
Just using blending produces a rather good result. Perhaps the best solution would be just using automatic blending and spend more time making good trees and other terrain features?
In that case, we need solution 2 or 3 (as defined above).
Although, we could have a modified version of solution 2 -- where we can have variations of the center tile but without the border. All center tiles should in that case be a seamless drop-in replacement.
Maybe the edges could be made more irregular, so it looks more natural? But I like it.
I've added a twist; Grassland and savannah have their 'corner' piece thrown in over the Swamp and the Plains. Sometimes simple tricks like this can make a big difference.
Maybe, for example, whenever 3 or 4 land tiles of 1 type surround a single tile another type, they could project their inverted corners on top of it, so that one tile would form a nice, round 'island'?
Last edit: Misiulo 2021-11-30
Here are the beaches for old grassland I once prepared. I could do that in 512x265 for all terrains if needed. On closer examination, some of the combinations seem redundant though. Well, I wanted to cover eveything in at least 2 versions :>
You could also write code to occasionaly add a few random mini-islands close to the beaches based on the closest land tile. (Just like the random trees, rocks and clumps of grass to make the shoreline look more diverse) :)
Last edit: Misiulo 2021-11-30
I have implemented a method for automatically drawing the transitions between base tiles. It only needs the center tile for each base terrain type, and automatically makes all the transitions based on a single image mask file.
The results looks surprisingly good even though I have not yet implemented any blending for the corners.
The attached files are from in-game rendering, but I have not committed my changes yet,
The solution above supports multiple center tiles for each terrain, as long as they can be tiled without transitions.
Beaches need to be handled separately. The easiest solution would be having a beach center tile that is only used for making transitions to land tiles -- and custom transition images for the ocean. By utilizing this approach, we only need one set of beach-ocean transitions.
Here is another in-game example with your grassland terrain added, @misiulo.
Wow. The grass is finally looking like grass now. Well done :)
Should I create the dedicated beaches for each terrain type?
So are we going for the Xtra Large or 256x128?
I think just one type of beach will suffice. Please ensure the beach is wide enough for proper blending with the land terrain (like the current version). In addition, make a center tile that tiles with all the different beach pieces. The center tile is also used for blending (in this case into the land tiles instead of the blending of the land tile into the beach).
In the future we can add more sets, and transitions between different sets. For example a rocky type of coastline.
Please note, we can also have a separate mask for the transition between a specific terrain and the beach -- although I do not think making such transitions should be a priority right now.
We are definitely going for 512x256. Please make sure all pieces fit inside "mask-center-512x256" as this ensures easy down-scaling to 256x128 and 128x64.
I would strongly recommend that all the beach tiles have the same width at the edge, where they connect with other beach tiles, as this greatly simplifies making them (and later variations).
I needed to modify the grassland image slightly in order to make it tile properly. The method I used for fixing it was just tiling it in GIMP and then applying the "mask-center-256x128.png".
Here's the mask for 512x256. Notice how the edge is jagged: This ensures smooth tiling with upscaled low resolution images.
Hi @stiangre,
just to give you some background on why the current rendering is as it is: It started with cleaning up the code and enabling a larger GUI for high-dpi monitors (wish I had put it in option menu not a command line option noone uses), then needing higher resolution images, searching the old SVN for raw source images and sadly only finding very few, then extracting what was possible including trying to recombine layers. Now I had a partial set with very many missing double sized images. I event tried to get quadruple sized ones, but the base images were clearly not made with that goal in mind and would have needed to be redrawn which noone would.
Then I wanted to make as much use of the images I could extract as possible and improved the map drawing. I made it possible to have multiple versions (sizes) of images loaded at the start and then use the most fitting size as a base for resizing in the resource manager. This looked best with bilinear interpolation on in the resource manager and for map drawing. You can not disable this in one of the 2 places because then it is still interpolated once for some images gotten in some sizes.
Additionally, my goal was to make the map render glitchless and in a consistent look. If you disable the smoothing without having a complete set of double sized images, some images look smooth and some look blocky or half-smoothed from the resource manager, making for a bad inconsistent look where one part of a tile is a highres smooth image and another part of the tile and the neighboring tile look blocky. Disabling the smoothing in resource manager would make the GUI look worse, as many images are used both for the GUI and the map. The 1 pixel problem at tile transitions, which was IIRC most visible only when zooming the map maximally in would be a small price to pay for having the whole images have a more consistent look. Additionally, half the players would have the black grid drawn over it.
As for the question I saw about units always drawn above everything, it was a long time ago so I'm not sure if drawing them inbetween was even a thing and if such change happened earlier or when I reorganized the map drawing. But if I changed it, it was because there were many impossible to remove glitches with images overlapping more than one tile and it would have required partitioning, for example, forests into below and above parts, when my first priority was not having any visible glitches (like fortress on middle tile overlapping 2 other tiles, they both having other overlays and part of the fortress on one neighbor being above and on the other below that tile's overlay).
A side goal was to make the code more maintainable by splitting the map rendering into separate layers, which also helped with rendering performance from only having a few images in use at same time. The game had and still has a performance problem, especially with map rendering. Therefore, I doubt adding a complete set of quadruple size images would be possible atm (much higher memory use and even slower rendering).
Still, I hope there can be a complete double sized graphics set. You possibly still have got some more of the old source images for where the game is missing double size images?
Last edit: wintertime 2021-12-05
I was thinking the same for the FontLibrary.DEFAULT_FONT_SIZE that was intended to be used for scaling the entire UI.
In any case, I have combined the two approaches, using a hack for the moment, so that "--gui-scale 200" both sets the scale and a better default font size.
We should ideally deactivate interpolation only for base tiles and masks. The problem was that separate handling for base tiles and other images have been removed. This can easily be added back in, but I want to simplify (and extend) how alternate versions and sizes are handled before doing so.
I am thinking of just having a single file mentioned in "resources.properties", and automatically search for different versions and sizes in the same location, instead of having to manually define variants and sizes. Mods would still be able to override that image (and can also provide different variants and sizes).
This may absolutely be true for the players, but it is important that the development version does not hide (or produces) seams while tiling. If not, we might get worse drawing artifacts over time.
No need to explain anything: You have been doing great work on the game :-D
I should perhaps not be calling changes from a decade back regressions -- as they can obviously have been made purposefully with another objective in mind. They are just regressions to me because I have outdated expectations -- although I am hoping the changes I am making will be positive for everyone :-)
In what cases do we have problems? I am running FreeCol with 512x256 base tiles quite happily on a 10 year old laptop. Perhaps it is a problem with longer running games as I have not tried that yet -- for example a memory leak?
It works on my machine (tm). Seriously, though, please do report any problems you might encounter.
Ok :)
The performance problems depend on OS (mainly they had been reported on some Linux distributions) and JDK+Java startup options (they influence using different drawing and smoothing algorithms and if some call gets done on GPU with many back and forth copying images between system and GPU memory) and I think even their versions. Though, if you click on the map to move and its not redrawn immediately cause of the many layers thats already too slow IMO. This probably also slowed down the AI moves if you have the options activated to see all their moves and animations.
Last edit: wintertime 2021-12-08
I have fixed several performance issues already. For example, we had a full repaint of the entire map every time the mouse moved 1px! We probably need better testing in order to avoid such problems in the future, as such mistakes are easy to make.
...and you were right that some systems are much slower: I have added a transition cache since some systems are poor at efficiently applying the alpha mask.
BTW, the supporting code that made the game run smoothly on a 200MHz CPU have disappeared. Like fullscreen mode, buffer strategies (page flipping etc), aggressive clipping and incremental painting.
Adding such optimizations back in might be unnecessary, though, as ten year old hardware can render the entire map in HD several times per second. In addition, we cannot add the original code back in without also converting every JDialog back into a JInternalFrame.
But then again, I think 250ms latency while moving the map is acceptable. My guess is you want the latency to be lower than 100ms?
OK so let's have first things first.
You want me to make all the tile sets in 3 sizes?
No, it's sufficient to make the tile set in 512x256. The other resolutions will be made automatically by downscaling.
Please ensure all base tiles (that includes all tileable images, like beaches) fit inside the mask "mask-center-512x256.png".
Like this? I hope the program is up to the task; Whenever I did the resizing in Photoshop there always was a line showing up on the map, resizing artifacts, even if the tile looked impeccable on it's own. It would be fantastic if it was all done automtically now! Well, first I'll need to come up with an ideally seamless tile set in 512x128.
Last edit: Misiulo 2021-12-07