I’ve realized I’ve been really into ampersands recently. For titles anyway. I dunno, they just look efficient.
What did I do this week though?
I knock optimization a lot, and, like, for the most part, I think I’m pretty right to do it. Like, premature optimization is the root of all evil and all that, though it’s important when the code’s causing actual problems.
I got to have fun with efficiency this week, YAY!
Well, okay, not entirely.
The idea for the Smart Tile package I’m building is to allow people to create Tile prefabs that they can drag into any scene, and that will respond accordingly to have their sprites match up, given a few input sprites.
The flow I want for people building tile maps is kinda like this:
- Create a tile prefab.
- Copy that tile prefab or drag out a new one.
That works for the most part:
It even works with the 2×2 implementation I changed it to to allow concave corners!
(trust me, that there is a concave corner sprite…)
However… the way I implemented it at first didn’t scale well with lots of tiles. There was… pretty significant lag, and this was exaggerated when I changed to the 2×2 implementation.
Each tile is (at least) one Game Object (I this is the root of another problem, which I’ll describe at the bottom), and I was calling probably the worst function I possible could to get all the tiles: GameObject.FindObjectsOfType<>()… which is O(N x M), where N is the number of Game Objects in the Scene, and M is the number of components on a given Game Object… like, real real bad.
Also, I was kinda calling the map update once for every tile I was moving, so it worked fine while dragging one tile around, but got real real sluggish when dragging lots of tiles.
SO! I changed the implementation to store each new ZAT_SmartTile (the name of the tile component) each time I add a new one to the Scene, and to remove it when it’s destroyed! I also fixed that issue with multi-updating, so now there’s only one update called per group! 😀
Still though… because there are so many Game Objects…
There are a lot of triangles… To give a comparison, a blank Scene would get me, like, 300 FPS…
This is sorta a problem I should solve, because tile maps should be allowed to be big.
In order to solve this, I may go back to some stuff I did this week that I thought was kind of a waste of time, even though it was a lot of fun…
Man, I could spend hours on these. I did, in fact.
I spent a lot of time adjusting stuff, but mostly, being bad at math.
I spent the middle of the week trying out a shader implementation that would allow me to draw the sliced sprite based on some settings for rotation and sprite of each quadrant!
I scrapped this approach initially, because it seemed like it required a lot of set-up for the user, at least as I had it, but it’s looking like I’ll have to go back to something like this if I want to not slow things down horribly.
In any case, I am happy with the changes I did make this week, and they are definitely changes that I should have made regardless. Like, faster = better generally with this kind of stuff, and now it’s written to be faster.
I’d like to put this thing up on the store by this coming weekend, so that I can call it done and funnel my energy back into Floral Kombat.
Until next time,