Seems like multisampling, which appears to be enabled by default for some people even if disabled in glfw, does weird stuff when the positions are not pixel aligned.
Should fix#177
This finally fixes#171 (although CPUs with even more threads, or a future game with even better optimized terrain generation will still have this problem)
Instead of one general purpose allocator per thread, there now is one stack allocator per thread, which behaves like a basic stack.
Using this allocator for all the trivial allocations, makes the game overall more efficient, even if some larger allocations now require going through the global allocator.
Maybe in the future the stack allocator could be extended with a temporary arena allocator functionality?
This should help with #171 by almost halfing the CPU usage of the receiving network thread. However the issue remains.
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.
