Alfheim

是 燐(Hesperus) 的分支（或者说重写，取决于你对忒修斯悖论的理解），而燐是 磷(Phosphor) 的分支。

与燐/磷相比有什么优势？

Alfheim 的目标是在所有的场景下都能兼容。如果由于随便什么原因出现了根本性的严重不兼容问题，那么 Alfheim 会发出警告，告诉你发生了什么，而不是几乎不提供任何信息就崩溃。

Alfheim 在燐与磷上进行了全方面的优化，总体使用的内存更少。

与燐、磷相比，Alfheim 将光源方块的更新减少了 27 倍，还限制了每帧执行的光照更新数量，以此来提高客户端性能。 此外，燐与磷会无谓地强制使光照在每一帧之前更新，而 Alfheim 不会。

Alfheim 还修复了比燐与磷更多的原版光照问题：

修复更多问题

以下为燐(Hesperus)/磷 (Phosphor)修复的问题，这些修复在 Alfheim 上同样生效：

•  MC-3329；

•  MC-102162；

•  MC-116690；

•  MC-117067；

•  MC-117094。

Alfheim 在燐与磷的基础上额外修复的问题：

•  MC-92；

•  MC-50734；

•  MC-80966；

•  MC-95515；

•  MC-104532；

•  MC-249343。

为什么不直接给燐发个PR呢?

合理的问题。原因很简单，与 燐(Hesperus) 相比， Alfheim 不仅仅是修复错误的分支，而是作者对它的延续。正如上文所说，作者对燐的延续不仅仅是小修小补，而是及其深入的，内部代码几乎推倒重来。

当然，起初不是如此，作者原本只是想为燐提交一些 PR，但是在做了 PR 的一部分内容之后，其体量很明显已经超过了 PR 的范畴，所以作者转而制作 Alfheim。

现在，Alfheim 包括优化、错误修复、兼容性修复，以后还会有更多。

安装注意事项

Alfheim 通过 Mixin 来替代原版光照引擎的代码，从而实现性能提升以及错误修复。正因此，Alfheim 需要 MixinBooter 作为前置。

由于 Mixin 的独特性质，MixinBooter 的加载顺序必须要在 Alfheim 之前，否则会导致崩溃。所以请不要删除MixinBooter的jar文件名中的感叹号，这是为了保证加载顺序可控。

另外，Alfheim 、 燐(Hesperus) 、 磷(Phosphor) 三者是互不兼容的。同时安装虽然不会崩溃，但三者都修改了光照引擎的代码，同时安装时修改的代码会以难以确定的顺序先后覆盖，导致难以确定的结果。所以，三者只应当留下一个。