Apparently there is still some weird synchronization issue in there?
I tried many things to make it work, but ultimately I gave up.
I'm now using glMapBufferRange, which doesn't seem to have any issues.
Fixes#181
* Update README.md
I fixed grammar, capitalization, formality and I altered the YouTube link at the end, so that it skips the intro (not the video will start at the 11 second mark).
* Update README.md
Changed "(AKA a Minecraft clone)" to "(inspired by Minecraft)," as this is more fitting.
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.
