处理图形的类的最佳方法

Best approach to a class that handles graphics

本文关键字：方法最佳处理图形更新时间：2023-10-16

当我用opengl、direct3d、sdl或任何图形api（通常是游戏）编程任何类型的应用程序时，我有一个习惯，那就是创建一个名为graphics的类，它里面有绘制、加载图像、初始化窗口等所需的一切，或者任何将要使用它的东西。

随着时间的推移，我尝试了很多不同的方法来使用它，我想知道你们是否认为其中一些是好的，或者一切都是无用的垃圾，我应该用另一种方式来做。

1-在程序类中有一个Graphics实例，在程序类内有一个函数，它迭代对象（例如游戏对象，比如玩家），并调用Graphics方法来相应地绘制所有内容。

2-将指向Graphics的指针传递给每个对象，这样每个对象都可以有一个Draw函数，并通过该指针调用相应的Graphics函数。

3-让Graphics内部的一切都是静态的，并消除了创建图形实例的需要。然后你可以从任何地方调用每一个图形函数。（你只需要对每个对象都有一个Draw函数，就像主题2一样）

谢谢。

编辑：如果我做一些类似iostream对cout所做的事情，比如用'extern Graphics x；'做一个标题，会怎么样，在cpp文件中声明x，然后调用x中的所有内容。这太糟糕了吗？如果是，为什么？

好吧，我认为"graphics"类可以很好地具有一个状态，比如它正在绘制的画布。因此，将其作为一个类是很好的；通过创建一个类，您可以使同一组函数适用于不同类型的"画布"（opengl、directx、sdl等）

在你的选择中，我认为选项1是最好的，但选项2是最容易的（选项3很可怕，因为它使代码依赖于全局变量，消除了代码的可重用性——这是黑客方法：D）。

选项1很好，因为你可以编写一个图形引擎，用它绘制的东西做一些智能的事情：假设你有两个对象共享相同的纹理，但使用不同的网格。如果编程得当，图形引擎可以调用具有相同渲染设置的两个对象的"绘制网格"功能，在这种情况下是相同的纹理，从而加快渲染速度。这在选项2中是不可能的，选项2通常将单个对象的绘制函数分组在一起，从而导致对渲染设置进行更多更改。

然而，备选方案2更容易实施。如果你不需要太多的渲染速度，我会选择这个，因为它的工作量要小得多，并且会导致更合乎逻辑的程序结构。要实现选项1，如我所解释的，对象需要具有"渲染属性"或类似的属性，这些属性需要由渲染引擎匹配，并且针对不同的绘制设置使用不同的绘制例程。。。与只使用一组中心绘图函数（如Graphics类）的对象绘图函数相比非常复杂。

因此，如果您选择"大型项目"，请选择选项1。为了快速得出结果，如果你不需要画很多东西，选项2可能会更好。选项1和选项2的可用性相似。

PS：很抱歉编辑晚了，但我的语法在以前的版本中很糟糕

我会选择第四个选项，将Graphics作为名称空间，而不是类。

这听起来不像Graphics是一种数据类型，只是一组函数。这正是名称空间的用途。

我很难弄清楚什么是"Graphics"对象。软件中的对象类似于现实生活中的对象，那么Graphics对象代表什么？

我通常这样做的方式与标准UI应用程序没有太大区别：我有一个可以实例化多次的Window类和一个继承自Window并且只实例化一次的MainWindow类。在那个MainWindow类中，我拥有将在整个执行过程中使用的所有图形资源（例如Direct3D设备对象）。