本帖最后由 Hueihuea 于 2020-5-2 12:16 编辑
net.minecraft.client.gui.Gui下代码
这里为什么要* 0.00390625F
这与点我提到的
有关吗
是不是因为这个DefaultVertexFormats.POSITION_TEX
那么这个7又代表什么
net.minecraft.client.gui.Gui下代码
这里为什么要* 0.00390625F
这与点我提到的
有关吗
是不是因为这个DefaultVertexFormats.POSITION_TEX
那么这个7又代表什么
本帖最后由 3TUSK 于 2020-5-2 14:28 编辑
随便找个计算器易知 0.00390625 * 256 = 1.0。
所以不是浮点数的精度问题，1/256 是可以无损精确表示的。
有鉴于 Java 编译时内联（inline）常量表达式，所以 Mojang 手里真正的源码可能写的是 1 / 256 而不是这个 0.00390625。
也从侧面说明“我们不是在跟真正的源码打交道。”
延伸阅读：https://harbinger.covertdragon.team/chapter-01/mcp.html
7 是 GL11.QUADS。这个和 256 无关。7 也是因为 Java 编译时内联常量表达式，这次是内联带 static final 修饰的 primitive 字段。
http://legacy.lwjgl.org/javadoc/ ... pengl.GL11.GL_QUADS
或者说，（因为 LWJGL 封装的是 OpenGL，）GL_QUADS。如果你也是 OpenGL 用户，请不要使用 GL_QUADS。
https://stackoverflow.com/questi ... -bad-about-gl-quads
DefaultVertexFormats.POSITION_TEX 是指最终给 GPU 的顶点数据格式。这个也和 256 无关。
POSITION_TEX 意思是先给顶点坐标，然后再给纹理（texture）的坐标。
顺带一提方块用的 VertexFormat 似乎是 position -> color -> tex -> light map -> (padding?)。顺序错了会导致非常崩坏的渲染效果。
随便找个计算器易知 0.00390625 * 256 = 1.0。
所以不是浮点数的精度问题，1/256 是可以无损精确表示的。
有鉴于 Java 编译时内联（inline）常量表达式，所以 Mojang 手里真正的源码可能写的是 1 / 256 而不是这个 0.00390625。
也从侧面说明“我们不是在跟真正的源码打交道。”
延伸阅读：https://harbinger.covertdragon.team/chapter-01/mcp.html
7 是 GL11.QUADS。这个和 256 无关。7 也是因为 Java 编译时内联常量表达式，这次是内联带 static final 修饰的 primitive 字段。
http://legacy.lwjgl.org/javadoc/ ... pengl.GL11.GL_QUADS
或者说，（因为 LWJGL 封装的是 OpenGL，）GL_QUADS。如果你也是 OpenGL 用户，请不要使用 GL_QUADS。
https://stackoverflow.com/questi ... -bad-about-gl-quads
DefaultVertexFormats.POSITION_TEX 是指最终给 GPU 的顶点数据格式。这个也和 256 无关。
POSITION_TEX 意思是先给顶点坐标，然后再给纹理（texture）的坐标。
顺带一提方块用的 VertexFormat 似乎是 position -> color -> tex -> light map -> (padding?)。顺序错了会导致非常崩坏的渲染效果。