Cuberite Forum

Do you think we should promote Cuberite more, with perhaps an emphasis on performance/multithreading?

This video https://youtu.be/MBpN679o5Yk claims stock has problems with lag going above 250 players; it sounds tiny (but on the other hand we haven't done any large-scale testing either).

If we have the numbers to back our claims up, (and the game features), I could see Cuberite being game-changing.

check this out as well:
https://forum.cuberite.org/thread-3297.html

That's very helpful, and quite promising. Didn't know Java has all the Worlds ticking on one thread.

Being single-threaded actually made sense in the beginning days of Minecraft. The game logic is much simpler that way, no need to lock and unlock data, no problems with deadlocks, no out-of-order packets (like the ones we still have with invisible mobs) etc.

Look what came in the mail yesterday:



Thanks

I think the back side is even better
(and yes, I had two made for myself, too

xoft, do you recall why the terrain generator has a cache?

I can see it being used during tree placement, where trees attempt to generate chunks around them when they cross chunk borders.
As well during village generation, apparently so roads follow the lay of the original land, before any finishers changed the heightmap?

If we do need to preserve the original heightmap, I'm only seeing one call to UpdateHeightmap before the chunk concludes generation, in the tree generator. If this can be removed the heightmap in ChunkDesc should serve the purpose for village roads well.

Tree generation seems like it could be made to use the strategy of ore pocket features (that can also cross borders, but don't need to generate extra chunks to place properly), though the density of trees might make this difficult? If this is possible then we can eliminate the need to touch other chunks during tree generation.

I think achieving both of these would allow removal of the cache? Especially with the village road heightmap, it looks like we're regenerating an entire chunk just to get the height at one position; even with a cache there's still memcpy costs to consider, and it precludes threadpooling the terrain generator.

There are multiple caches in the worldgen - biome cache, height cache, composition cache. Getting rid of them would be unwise, they save a LOT of work. For example the biome cache measured more than 90 % cache hit rate during startup world generation - that means ~10x speedup just thanks to the cache.

If I remember correctly, the terrain height is used in trees generator to see if the trunk and branches (all log blocks, in fact) intersect the terrain, if not, the tree is not generated; for this to work, it needs to see into the neighboring chunk as well (bent acacia trees' trunks and branches may go off-chunk). So no, it can't be removed, otherwise you end up with tree parts on chunk borders that generate in one chunk but don't generate in the other chunk. Can you imagine how long this took to actually get right?

If you want to threadpool the worldgen, you need to make the caches thread-safe and share them among all the threads / tasks.

Heh, I just found out that the Gallery server has been piling up its daily backups on the RasPi's SD card, ever since 2016. I've got 7 GiB of gallery backups

(08-23-2020, 09:07 PM)xoft Wrote: [ -> ]Heh, I just found out that the Gallery server has been piling up its daily backups on the RasPi's SD card, ever since 2016. I've got 7 GiB of gallery backups

or 4 years of backups.... lol
that's a small world