已弃用的OpenGL功能

Question

我最近阅读了这个列表，发现几乎我从OpenGL红宝书中学到的所有内容都被认为是过时的。

我指的是像素传输操作、像素绘制、累积缓冲区、Begin/End函数（！？）、自动mipmap生成和当前光栅位置等。

为什么他们将这些功能标记为过时的？是否仍然可以使用它们？有什么解决方法？

- Pilpel

---

欢迎来到软件开发的世界。1980年我所学的有关Zilog Z80和CP/M的知识，在第一台个人电脑出现时都变得毫无用处。因此，我们不得不学习8088和PC-DOS。但这些知识在16位Windows中也变得毫无用处，而16位Windows在32位Windows中也变得毫无用处，以此类推。这就是它的运作方式；只要不断学习！ - Bo Persson

@BoPersson 当新的硬件和系统出现时，自然会有不同的编程方式。但在OpenGL的情况下，这是一个重大变化。弃用/删除基本功能，如glBegin或基本矩阵操作，如glOrtho``glLoadIdentiy就像从C API中删除printf一样，只是因为使用puts更快。 我宁愿改变旧API来拥有glVbBegin或类似的东西，为您创建顶点缓冲区和矩阵。旧代码将更容易移植...但是没有，你必须编写不太直观且更多的样板代码，呸... - Calmarius

@Calmarius，语义差异太大，无法实现（例如“glVbBegin”），而且效率也不高。 - Display Name

据我所知，显示列表在可能的情况下已被转换为顶点缓冲区。现在我已经适应了一段时间新的方式。但是，如果有一些合理的默认设置来减少设置代码的数量仍然是很好的。 - Calmarius

@BoPersson: 你有夸大其词。基础并没有真正改变。 - Yakov Galka

Answer 1

在我看来，这是一种更好的方式。但所谓的Immediate Mode在OpenGL 3.0中已经被弃用，主要是因为它的性能不太理想。

在Immediate Mode中，您使用像glBegin和glEnd这样的调用。因此，基本图形的呈现取决于程序的命令，OpenGL无法提前获得CPU发送的适当命令。相反，您可以使用缓冲区对象来存储所有顶点和数据。然后，告诉OpenGL使用此缓冲区以命令glDrawArrays或glDrawElements等呈现其基本图形，甚至还可以使用更专业的命令，如glDrawElementsInstanced。而GPU正在执行这些命令并将缓冲区绘制到目标FrameBuffer（基本上是渲染目标）。程序可以继续发出其他命令。这样，CPU和GPU同时忙碌，没有浪费时间。

虽然这不是最好的解释，但我的建议是：尝试学习这个新的渲染管线。它远远优于Immediate Mode。我推荐像以下这样的教程：

http://www.arcsynthesis.org/gltut/index.html

http://www.opengl-tutorial.org/

http://ogldev.atspace.co.uk/

真的要试着忘记你已经知道的东西，Immediate Mode已经过时了，不应再使用，相反，请专注于新技术;)

编辑 如果我使用“intermediate”而不是“immediate”，请原谅我，我认为它实际上被称为“immediate”，我往往混淆它们。

- Invalid

---

你最推荐哪本书？ - Pilpel

第一个链接（arcsynthesis）让我开始学习OpenGL 3.0+，请注意它还没有完全完成，但我还没有找到更好的书籍。其他两个链接只是一些关于特定主题的不错且简短的教程（尤其是第三个链接，它有一些关于高级主题的教程，如阴影映射甚至延迟着色）。 - Invalid

Answer 2

为什么他们标记这些功能为过时？

首先，一些术语：它们并不是过时的。在OpenGL 3.0中，它们被弃用（意思是“可能在以后的版本中被删除”）；在3.1及以上版本中，它们中的大多数被删除了。兼容性配置文件将已删除的功能重新引入。虽然它在Windows和Linux上广泛实现，但苹果公司的3.2实现仅实现核心配置文件。

至于删除背后的原因，这取决于你所谈论的功能。我们只能就ARB为何弃用任何特定功能进行推测：

像素传输操作

像素传输操作没有被删除。如果你谈论的是glDrawPixels，那是一个像素传输操作，但它只是一个像素传输操作，而不是所有的像素传输操作。

说到这个：

像素绘制

因为这本来就是个可怕的想法。 glDrawPixels是一个性能陷阱；听起来很好，但表现非常糟糕，因为它很简单，人们会尝试使用它。

拥有易于操作但性能差的东西鼓励人们编写糟糕的OpenGL应用程序。

累加缓冲区

着色器可以很好地实现此功能。 实际上更好; 它们比积累缓冲区的选项多得多。

Begin / End函数(!?)

这是另一个性能陷阱。 直接模式渲染非常慢。

自动mipmap生成

因为这本来就是个可怕的想法。 让OpenGL决定何时执行像纹理的生成重量级操作这样的任务并不是一个好主意。 ARB的更好的想法是让您只需说，“好的，OpenGL，立即为此纹理生成一些mipmap”。

当前光栅位置。

另一个性能陷阱/坏主意。

它们仍可使用吗？

这取决于你。NVIDIA已经承诺永久支持兼容性配置文件。这意味着AMD和Intel可能也必须这样做。因此，这涵盖了Windows和Linux。

在MacOSX上，Apple更严格地控制GL实现，并且似乎致力于不支持兼容性配置文件。但是，他们似乎对推进OpenGL没有太大兴趣，因为他们止步于3.2版。即使是Mountain Lion也没有更新OpenGL版本。

有什么解决方法吗？

停止使用性能陷阱。像其他人一样使用缓冲区对象来存储顶点数据。使用着色器。使用glGenerateMipmap。

- Nicol Bolas

---

我想指出，一旦你习惯了使用现代OpenGL，你就不再想回到过去了。一旦你体验了片段着色器的便利性，即使是对于简单的事情，你也不想再接触glTexEnv了。一旦你使用顶点着色器进行纹理坐标生成，你就不会再想用glTexGen了。立即模式和显示列表很麻烦，并且会让人产生错误的工作场景感受。OpenGL矩阵堆栈总是缺少你需要的一个函数，因此你无论如何都要自己实现整个矩阵相关的东西。 - datenwolf