Make the game ~3x faster

[xskutsu]

This PR does a lot of invasive changes that drastically improve the performance of the game.

The source of this commit is mostly original, however some of it originates from my in-development game Polytanks.

Here is a Before and After image (look at server speed percentage). It's not a perfect demonstration, but you understand.

Before

After

There is further work that could be done such as reworking how socket views are handled and make them query the grid or reworking that stupid overly-detrimental-to-runtime-performance Proxy-config thing, however I got bored.

[xskutsu]

It's also worth mentioning that there is a good chance many of these changes can be ported to the aps++ rewrite.

Should be pretty easy to port these manually, however if explicitly requested I can make a similar PR for that project.

[Taureon]

Almost all of this looks good to me!
Only worry is that IIFE added to gameDraw.js, cuz I don't see why the caches can't just be put in the top level.

...that stupid overly-detrimental-to-runtime-performance Proxy-config thing...

Fully agreed, I think it'd be better to just make it a hashmap without any of the case-translation and without the change event.

What could work is warning in console for setting dublicate convars.

[xskutsu]

Yeah the color cache could absolutely be taken out of there to remove the IIFE. I did that to keep it isolated from the rest of the code as nothing else should ever need to read it. Also, almost always, IIFEs have no significant impact on performance, especially in cases like this where it's only initializing once. There's even the chance it helps performance by avoiding pollution of the higher scope, though we'd be measuring sub microseconds at that point...

[AE0hello]

Woa! Thats a massive changing of codes, im very impressed, i will test it soon with the aps++ rewrite.

[xskutsu]

Thank you! If you want any help or have questions about implementation ask me here or at my discord xskt. (DMs open!)

[AE0hello]

Alright, i only see one problem with the "nearest" function, wich its not working properly on the rewrite.

[Taureon]

any other problems before i merge this?

[AE0hello]

nearestDifferentMaster controller is lagging the server very hard if serveral entities uses nearestDifferentMaster controller, he may look foward to fix it, but otherwise there are no problems.

[xskutsu]

nearestDifferentMaster controller is lagging the server very hard if serveral entities uses nearestDifferentMaster controller, he may look foward to fix it, but otherwise there are no problems.

You're misunderstanding. It's not that nearestDifferentMaster is any laggier than before. (It's actually faster than it was originally.) It's that now, after optimizing the other parts, it has become the slowest thing in comparison.

[AE0hello]

Oh okay

[xskutsu]

any other problems before i merge this?

As far as I know there is not. Feel free to merge when the code has been reviewed in full.

If there are any new issues discovered later, feel free to contact me on discord about it and I'll try to fix

[NightFuryToothless]

Great pull request! There are some good optimizations.

On case with query() function in hashgrid.js file, which is used in nearestDifferentMaster. Running benchmarks, this function can take up to 95% of all entity controllers running time.

Below you can see that I'm benchmarking all controllers, not just nearestDifferentMaster controller for all entities. This is siege, so there are other controllers running as well.

[AE0hello]

Yea and that causes to lag a ton then the original nearestDifferentMaster

[xskutsu]

Again just to clarify, because I'm not sure if you are just pinpointing the lag or claiming there is an issue present, this isn't new lag introduced by the PR. nearestDifferentMaster was actually optimized here. Previously it would iterate over all entities and perform a raw distance check while now it uses the hashgrid query function which is more efficient overall.

What is happening is that after optimizing the other parts of the game, that before lagged even harder than this, nearestDifferentMaster has become the relatively most expensive part of the game loop. Not because it is worse, but because everything else that competed for compute time per tick in the game loop is faster now.

[AE0hello]

If you say so.

[AE0hello]

I have solved the massive lag on nearestDifferentMaster, appearently i had to change one line of code and that solved it.
This:

To this:

I would recommend to use the hashgrid for collision checks only, not anything else. Anyway, since that is solved, now it can go up to 1700 entities instead of 700 which was the cap before. Because of that line of code.

[xskutsu]

That literally makes no sense whatsoever. The whole point of a hashgrid is to be faster than O(n) scanning through entities, and even yourself say its faster when its used in collisions. It makes zero sense for it to be slower here, as its the same type of optimization.

[xskutsu]

I'll look into it more later though, maybe the entire controller can be redone in a better way than it was originally.

[AE0hello]

Not working, they stopped targetting entities

[NightFuryToothless]

It seems to work fine, but all the performance improvements come from cutting the range by half.

const sqrRange = range * range;
const halfrange = range / 2;
const fourThirdsSqrRange = sqrRange * 4 / 3;
let mostDangerous = -1;
let finalTargets = [];

With a for loop that looks like this for (const e of grid.query(x - halfrange, y - halfrange, x + halfrange, y + halfrange).values()) {}. But used to look like this for (const e of grid.query(x - range, y - range, x + range, y + range).values()) {}.

The whole point of a hashgrid is to be faster than O(n) scanning through entities, and even yourself say its faster when its used in collisions

I think with collisions it sorts relatively small sizes compared to ranges which can get really big.