为什么这些有符号字节被 LWJGL 读取为无符号字节？

Question

当您使用 LJWGL 函数 glBufferData() 上传存储有符号字节的 ByteBuffer（java 语言对象）时，openGL 解释相应缓冲区上的数据的正确方法是使用 GL_UNSIGNED_BYTE。

这是为什么？ LWJGL 似乎没有将 ByteBuffer 转换为其他格式，这里是 glBUfferData() 函数的源代码。

public static void glBufferData(int target, ByteBuffer data, int usage) {
    ContextCapabilities caps = GLContext.getCapabilities();

    long function_pointer = caps.glBufferData;

    BufferChecks.checkFunctionAddress(function_pointer);
    BufferChecks.checkDirect(data);

    nglBufferData(target, data.remaining(), MemoryUtil.getAddress(data), usage, function_pointer);
}

知道为什么吗？

编辑：

我明白为什么你们可能认为不需要转换，因为无符号字节和字节的存储方式相同。但是让我澄清一下，我将 1 2 3 4 5 等的整数值放入这个字节缓冲区，大概是有符号字节，因为这是 java 处理的。因此，大概在使用有符号解释时，这些字节存储了 12345。那么为什么 openGL 用无符号解释而不是有符号解释来读取 12345，这就是问题所在。

注意数据的意义是一个索引缓冲区。

Answer 1

首先，不要将GL_UNSIGNED_BYTE 用于顶点缓冲区索引。 OpenGL 在 API 级别支持这一点，但过去约 14 年制造的桌面 GPU 硬件通常在硬件级别不支持它。驱动程序会将索引转换为 16 位以满足硬件限制，因此您实际上所做的只是增加驱动程序的工作量。如果您不想给驱动程序造成不必要的负担，GL_UNSIGNED_SHORT 确实是您应该使用的最小索引大小。归结为未对齐的内存访问，如果需要，您可以使用 8 位索引，但如果您使用 16/32 位，则会获得更好的顶点性能。

为了解决这个问题中的实际问题，您使用 GL_UNSIGNED_BYTE 来解释顶点索引，在这种情况下，数据类型的范围与 GL_UNSIGNED_BYTE 与 GL_SIGNED_BYTE 真的只有解释颜色值很重要，因为 GL 进行定点缩放以重新映射 [-128, 127] -> [-1.0, 1.0] 中的值（有符号）或 [0, 255] -> [0.0, 1.0]（无符号）用于内部表示。

然而，在顶点索引的情况下，数字 5 在它之后是 仍然 5从无符号转换为有符号或相反。解释顶点索引不需要定点到浮点的转换，因此值的范围并不是特别重要（假设没有溢出）。

为此，您在使用顶点索引时别无选择。唯一有效的枚举是GL_UNSIGNED_BYTE、GL_UNSIGNED_SHORT 和GL_UNSIGNED_INT。如果您的语言不能表示无符号值，那么 OpenGL 的语言绑定将负责弄清楚这些枚举的确切含义以及如何处理它们。

Answer 2

有符号字节和无符号字节之间的主要区别在于您对位的解释方式：负值与超过 127 的值具有相同的位模式。两者不需要不同类型的存储，并且转换（这真的是无操作）使用二进制补码系统自动工作。