The current approach to managing chunk data is misconceived. This new approach uses genuine paletted containers and does not suffer from complexities caused by caching. As a result, memory usage (according to htop) in the terrain example with render distance = 32 has gone from 785 megs to 137 megs. That's 17.4% of the memory it used to use. Terrain generation speed was not affected.
Adding all the items, just like the blocks are. This will adress 1. and 2. bullet from issue #53
This will also make it easier to convert between block <-> item.
* Expose extracted enchantments to Rust.
* Give enchantments a `level: i16` field.
* Update enchantment derive impls
* Restructure how enchants are exposed to Rust through C-like enums
* Update build/enchant.rs
Co-authored-by: Ryan Johnson <ryanj00a@gmail.com>
* Update build/enchant.rs
Co-authored-by: Ryan Johnson <ryanj00a@gmail.com>
* Move enchantment sources to their own struct.
* make id() function return it's discriminant instead of matching
Co-authored-by: Ryan Johnson <ryanj00a@gmail.com>
This change was made to make it easier for invariants to be upheld. When
the spatial partition is added, we can ensure that changes to entities
are immediately reflected in the partition. Additionally, chunks being
shared between worlds was a leaky abstraction to begin with and is now
removed. A method in `Config` is now necessary to determine what world a
client should join.
Along with this, most mutable references have been wrapped in a newtype
to ensure that `mem::swap` cannot be used on them, which would break
invariants. This is analogous to `Pin<&mut T>`. The reason we can't use
Pin directly is because it would require unnecessary unsafe code
within the library.