As some of you know, there was a patch initialy scheduled for last week (July 30) but never happened because I delayed it.
There were many reasons for the delays, but the main one was due to some bugs that were found during testing that still escaped me up till earlier this morning, especially a very random one causing visages to be created from a cache but not all the time, which in turn caused skins to not always display seemingly randomly.
Alongside that bug hunting, I still kept doing my normal stuff, client crash tracking and fixing and optimisations.
This blog post is to announce that the next full patch including the first iteration of the skins system and many other things will be live this Sunday (August 10)
As for the things I been working on when i was not tracking that damn bug, my recent attention was turned to the deathblossom induced lags, both server and client side.
deathblossom allowed for a lot more enemies to be killed quickly and in sync, on top of the fact a lot of projectiles / lasers were created/destroyed compared to before.
I made a simple extreme testing ground using 300 phobos for optimisations purposes, and configured my ship to fire hephaestus burning maul at maximum rof with the highest deathblossom available.
This is what it looked like on my test machine on the current beta client.
As you can see in that small gif, it lagged hardcore. There were 2 major sources of lag, the lasers creations and the objects destructions (including lasers)
The first one was due to the laser using a brightpass and how the operation of adding to the brightpass was not optimised. Everytime we added an object to the brightpass, it first checked its container to be sure the object was not already in the bright pass. Which is safe and was fine when the call was not frequent, but with 140 lasers per seconds being added and destroyed (14 at max rof), it quickly added up. This was pretty easy to improve since we can safely assume any newly created object is not already in the bright pass, we can skip that check the first time any object is added, which is most of the cases. This resulted in a noticeable improvement in performance all around.
The other problem was the amount of objects being destroyed every 0.1 seconds + the number of ships blowing up in the process. There is very little I could do directly to that, since well, the objects do need to be created and destroyed (pooling them wouldn’t had helped much since its not their memory allocation/destruction, but the whole process of placing them adding the effects etc that is causing the lag). Which is why instead I went with a distributed approach, instead of trying to delete 140lasers (which end up being about 1200nodes with all the effects and stuff) every 0.1 sec, I remove them from view and queue them for a deletion over the next few frames. As a result, the total workload is the same, but its evenly distributed so there is much less noticeable lag, especially on system where your fps is capped or your logic fps is much higher than fps in which case the only reduction is on the logic fps and not the fps.
This was the result of those optimisations in the same scenario.
Its important to note, there were no graphic alterations whatsoever in those optimisations. The visible result is exactly the same, just done slightly differently.
Discuss in the Forum