Исправление KivApple, (текущая версия) :
У меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт (или первый апдейт изменённого блока случится только в следующий тик), но, мне кажется, это вряд ли проблема. За исключением тика воксели не обновляются (только шедулятся для обновления в специальный список локаций вокселей внутри чанка, которые надо обновить в следующий раз, когда наступит время обновлять чанк). При любой модификации чанк (или куб чанков 3х3х3) блокируется R/W mutex, так что race condition для отдельного вокселя исключён (но при этом можно иметь параллельный доступ к чанкам из разных потоков, если они достаточно далеки друг от друга).
Помимо обычного update есть slowUpdate (как такт блока в Minecraft) - вызывается для 4 случайных блоков в чанке перед тем как обновить блоки, которые были зашедулены для обновления с прошлого обновления чанка (сейчас таким образом растёт и умирает трава).
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.
Исправление KivApple, :
сУ меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт, но, мне кажется, это вряд ли проблема. За исключением тика воксели не обновляются (только шедулятся для обновления в специальный список локаций вокселей внутри чанка, которые надо обновить в следующий раз, когда наступит время обновлять чанк). При любой модификации чанк (или куб чанков 3х3х3) блокируется R/W mutex, так что race condition для отдельного вокселя исключён (но при этом можно иметь параллельный доступ к чанкам из разных потоков, если они достаточно далеки друг от друга).
Помимо обычного update есть slowUpdate (как такт блока в Minecraft) - вызывается для 4 случайных блоков в чанке перед тем как обновить блоки, которые были зашедулены для обновления с прошлого обновления чанка (сейчас таким образом растёт и умирает трава).
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.
Исправление KivApple, :
У меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт, но, мне кажется, это вряд ли проблема. За исключением тика воксели не обновляются (только шедулятся для обновления в специальный список локаций вокселей внутри чанка, которые надо обновить в следующий раз, когда наступит время обновлять чанк). При любой модификации чанк (или куб чанков 3х3х3) блокируется R/W mutex, так что race condition для отдельного вокселя исключён (но при этом можно иметь параллельный доступ к чанкам из разных потоков, если они достаточно далеки друг от друга).
Помимо обычного update есть slowUpdate (как такт блока в Minecraft) - вызывается для 4 случайных блоков в чанке перед тем как обновить блоки, которые были зашедулены для обновления с прошлого обновления чанка.
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.
Исправление KivApple, :
У меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт, но, мне кажется, это вряд ли проблема. За исключением тика воксели не обновляются (только шедулятся для обновления в специальный список локаций вокселей внутри чанка, которые надо обновить в следующий раз, когда наступит время обновлять чанк). При любой модификации чанк (или куб чанков 3х3х3) блокируется R/W mutex, так что race condition для отдельного вокселя исключён.
Помимо обычного update есть slowUpdate (как такт блока в Minecraft) - вызывается для 4 случайных блоков в чанке перед тем как обновить блоки, которые были зашедулены для обновления с прошлого обновления чанка.
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.
Исправление KivApple, :
У меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт, но, мне кажется, это вряд ли проблема. За исключением тика воксели не обновляются (только шедулятся для обновления в специальный список локаций вокселей внутри чанка, которые надо обновить в следующий раз, когда наступит время обновлять чанк). При любой модификации чанк (или куб чанков 3х3х3) блокируется R/W mutex, так что race condition для отдельного вокселя исключён.
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.
Исправление KivApple, :
У меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт, но, мне кажется, это вряд ли проблема. За исключением тика воксели не обновляются (только шедулятся для обновления в специальный список локаций вокселей внутри чанка, которые надо обновить в следующий раз, когда наступит время обновлять чанк). При любой модификации чанк (опционально куб 3х3х3) блокируется R/W mutex, так что race condition для отдельного вокселя исключён.
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.
Исправление KivApple, :
У меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт, но, мне кажется, это вряд ли проблема. За исключением тика воксели не обновляются (только шедулятся для обновления в специальный список локаций вокселей внутри чанка, которые надо обновить в следующий раз). При любой модификации чанк (опционально куб 3х3х3) блокируется R/W mutex, так что race condition для отдельного вокселя исключён.
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.
Исправление KivApple, :
У меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт, но, мне кажется, это вряд ли проблема. За исключением тика воксели не обновляются (только шедулятся для обновления в специальный список локаций вокселей внутри чанка, которые надо обновить в следующий раз).
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.
Исходная версия KivApple, :
У меня все апдейты происходят в рамках одного тика мира. Если блок за это время изменит свой тип (например, его модифицирует соседний блок), то да, потенциально может потеряться последний апдейт, но, мне кажется, это вряд ли проблема.
Вообще вот кусок кода С++ отвечающий за один воксель: https://pastebin.com/cZWreksU
Мне интересно как его переписать не таким страшным на Rust.