These happen sometimes, like name too long and on mac you can only rename a thread from within.
And since the thread name is really only used for debugging, there is no need to crash the game in that case.
This improves alignment, so memcpy should be slightly faster.
Additionally this simplifies the code that uses this buffer.
And only allowing one type prevents future accidents from mixed alignment.
Now it also supports buffers that are (slightly) bigger than the i32 integer limit.
This is should be faster than glBufferSubData, since I know better what to synchronize than the driver.
Additionally on some drivers this should avoid stalls, fixing #137
This was useful in the java version, since there the LOD chunks were faster to render due to having no light/transparency.
Since this is not true anymore and since the settings created a lot of confusion for players(and myself), I decided to remove it.
Fixes#166
The proposed solution in #166 top use a seperate slider for the max lod distance doesn't make much sense either since changing only the lod0 render distance separately wouldn't actually improve performance significantly. It's better to switch to different LOD byond that.
The solution was simply to cache the side data of chunk meshes instead of regenerating all sides on update.
This probably makes first-time loading a bit slower due to requiring making more copies of the mesh data, but it's not a big deal.
Fixes the remaining half of #94.
Now it only checks the surface chunks, meaning it's now O(r²) instead of O(r³), where r is the render distance. There might be an even better way, but I don't see it yet.
Sadly the performance stays constant due to updating the visibilityMask each frame. But if I find a better solution for it then there should be some great improvements here.
Now there is only one mutex left inside the process for updating and rendering chunks on the client-side.
This is a bit of a step back here. A lot of processes are now locked to the render thread.
Once I implemented lighing #61 I will need to look for better options.
When I started to use zig, I mostly used `var`. But over time I adapted to using `const` where possible which is more readable and the compiler is currently optimizing it better.
Resolves#110Resolves#117 (I did however decide to use static linking, I had some issues with dynamic linking)
Also getting closer to #118
Additionally this avoids the problem caused by https://github.com/ziglang/zig/issues/17652 since harfbuzz is precompiled.
Having zig bindings was certainly nice to have, but overall the code isn't too different really.
One nice advantage of building freetype and harfbuzz directly is that we can get rid of some unnecessary dependencies, like brotli.
Also, since that was the only zig dependency outside the standard library, this finally gives me the freedom to update zig whenever I want.
This is a necessary step for #117.
Resolves#139
