Tile Map Accelerator - High Performance Shader Based Tile Map Renderer

Merry Christmas to everyone! Here is a gift voucher : ASV-UNGW-KCV9-NF4H-WNXF-JHR3

 

Thank you!

 

After doing as much playtest and bug fixing as I can handle on my own I finally feel comfortable enough to release the latest round of updates to the Itch.io tech demo. This latest batch of updates includes two big features being Multiplayer and Save Files but also comes with a bunch of extra optimization and bugfixes, some to the asset itself.

While playing around with edit buffer size settings I've come across an edit baking bug that occurs more frequently with small edit buffer value. Essentially the current version of the asset will ignore checking neighboring tile chunks to an edit chunk already added to the bake queue which resulted in some tall sprites not being properly updated after the baking process during explosions. This does not affect single edits, only batch edits where tiles happen to be on the very edge of a neighboring chunk. Hotfixing this is very simple so anyone who runs into it can feel free to send me an email to get instructions on what to change.

As I've mentioned before everything being added to this tech demo will make it into the asset as example code on how to use it but I still have a lot of clean up to do before I push a new version to the store, especially considering I've been mostly focused on adding features for a few months so some of those features are not particularly stable.

You can find the updated tech demo on itch.io to try it out in the meantime: https://revision3.itch.io/tma-rts-tech-demo

 

So... I have a few questions on this fascinating asset:

1 - If I already have a world map built in Unity's standard tilemap system... is there a way to convert it over to your system, or will I need to rebuild from scratch?

2 - I have data scripts on each of my tilemaps to allow the game to differentiate between the different regions (i.e. field, desert, forest... etc.) so that appropriate environments are loaded during battle, can I do this with your system?

3 - I'm using A* AI (The A* Project from the asset store) and this creates a grid prior to compiling for the AI to "see" walkable/non-walkable areas based on the 2d collider and mask layer... Would this asset keep this from working or does it have a way of making this work?

... I may have more questions later.


Thanks much.

 

Sorry for missing your question, I had not checked the forum in a long time.

1. The asset currently isn't integrated with native tilemaps in a way that easily converts between the two. The shader works using arrays of set unsigned integers to represent each possible sprite. The tile maps you build can be converted to raw uint arrays using some function that you create to loop over your map, potentially using a look up table to convert native tile types to unique uint values dynamically.
2. Yes. Game logic does not affect the shader in any way. To differentiate between regions only the tile map array is checked and the shader is unaffected during this process.
3. Like the previous question, this is mostly game logic related and I see no issues. The asset does allow for spawning of 2D colliders however the included scripts do so using a pooling optimization which may not work to bake your pathfinding like a native tilemap with colliders would. It should still be possible to simply load up every collider with no pooling on game start to bake the pathfinding.

 

Version 1.4 has just been sent over for validation and should hopefully release without issue to the asset store shortly! This new version comes with the game tech demo which includes a ton of sample code / examples for stuff like multiplayer integration of shader features, saving and loading games made using the shader, integrating gameobject sprites with tile map using masks and just general usage examples of shader features in a more feature complete game project. The tech demo is ready to be tweaked and built as a standalone and also works as a new demo scene.

Also as a quick note to anyone looking into this asset, the new version will come with a price increase to $49.99 as it contains a bit over a year of work added since last version.

 

After getting a bunch of email questions about Universal Render Pipeline support over the past couple weeks, I decided to have a go at fixing some of the bugs I encountered when first trying the implementation a while back. As far as I can tell the main problem with this shader when using URP was due to color space mismatch in Linear color space. This color space mismatch causes the encoded tile types values to be incorrect on sampling resulting in a corrupted tile map. It also causes sprites to appear washed out compared to what they look like on disk.

Setting the color space to Gamma fixes the problem and works flawlessly with a version of the shader that uses URP compatible boilerplate code and function macros. Documentation and resources regarding converting shaders to URP also seems to have matured quite since the first time I tried this which made it quite a bit easier.

​

Please send me an email with your invoice number if you feel like getting an early access look at URP support, so far I have only worked in single layer non transparent tile maps URP version of the shader. After adding the shader and material files to a new URP test project, open up the "DemoScene" or "BigIsland" scene and replace the "MainRenderQuad" material with the new MapMatURP material. Finally to fix corrupted sampling:

Edit > Project Settings > Player > Other Settings > Color Space > Gamma

Then you can hit play and should be greeted with a working tile map with correct colors. Performance seems worse than on the standard rendering scheme but that might just be down to quality settings or something. I'll have to investigate more to figure out what's causing the drop in performance but it still runs very smoothly.

​

I'm also looking into better solutions to this color space mismatch problem, one promising fix would be to detect the mismatch and implement the color space correction in shader which some light research seem to show is possible.

 

Here is another feature I've been meaning to add to the asset that a user email reminded me of : artifact elimination using shader based LOD. The weird artifact and patterns that can be seen when zoomed out are caused by the sampler in conditions where it tries to fit say a 128x128 sized sprite in a 2x2 sized pixel area on screen. The first and perhaps best method to fix this issue is to simply replace the full res sprite with a solid color past a certain zoom level. This is actually done automatically in shader and so has no impact on performance since sprite data is not being replaced, a solid color is simply being drawn over it.

​

The material has UI controls that can be used to tweak distance at which the LOD kicks in (Threshold) and the Smoothing is used to control the transition between high res and low LOD. Those settings will likely need to be played with and set according to your own needs like sprite resolution, tile map size, maximum zoom levels, etc.

Currently the low LOD color is acquired by sampling the very middle of the sprite so the sampler has no chance to randomize which color is set for a certain sprite, however to make it more user friendly I believe a look up table of color values for each sprites will be way easier to customize to user liking.

A second method I'm currently still working on is more similar to mipmaps and dynamically reduces the amount of sampled pixels from sprites as the camera zooms out. I'll be back with a demonstration video for this second method once I've fixed some annoying quirks it has.

So far as I see it the color based LOD will likely be more appropriate for strategy games and games with low detail sprites where the second method looses too much detail quickly and ends up ultimately sampling a single position of a sprite which can cause odd colors to be chosen for a certain tile. More high resolution sprites in games where the artifact was not very noticeable due to lots of variation in sprites will likely see better use of the second method.

I also still have no idea how well this will work in isometric tile maps, a few key features of iso maps seem like they might cause problem especially the fake 3D effect and how hard filling tiles with color won't give a good of an illusion for things like buildings which in some cases only occupy the right half of a tile.

 

Version 1.5 of the asset is currently in validation and should release soon if all goes well, this update brings fixes for URP compatibility in Linear color space as well as the dynamic LOD feature I talked about in the previous post. That feature has been implemented on both square and isometric tile maps, even though the effect still isn't quite as good as it is with square tile maps it can still negate far zoom artifacts caused by repeating tiles. This new feature is likely to be updated at some point in the future with more customization options and sampling methods which I talked about in the previous post.

Since the asset now relies on HLSL includes in the URP shader variant the validation process minimum supported version has to be Unity 2020 however it is simple to delete the shader causing problems and get the asset working in older versions.

 

I noticed ruletiles aren't active on the auto chunking demo. Are ruletiles compatible with chunking? Also, the code for the demo's are all mangled together. Isometric is mixed in with orthographic and if you try to remove it you get errors.

The asset would be more useful if it provided a minimal example of turning an uint array to tiles on a texture.