zh-CHS/ch-02.md · 马梁瑞/sfmlByExample

# 第2章 添加一些结构 – 构建游戏框架
在结构较差的项目上进行工作就像在没有基础的情况下建造房屋：维护困难，极其不稳定，很可能会导致您很快放弃它。 当我们在第1章中处理代码时，它还活着！ 它还活着！ – Setup and First Program功能强大，可以在很小的规模上进行管理，如果不首先构建一个坚实的框架就对其进行扩展，很可能会导致大量意大利面条代码（不要与馄饨代码或asagna代码混淆）。 尽管听起来很美味，但这个贬义词描述的是新功能难以在源代码中实现的痛苦，而新功能在非结构化且以“纠结”方式执行的源代码中成倍增加，这是我们将重点避免的事情。

在本章中，我们将介绍：
- 设计窗口类以及主游戏类
- 代码重组和适当的架构
- 在应用程序中适当的时间管理的重要性
- 使用sf :: Clock和sf :: Time类
- 固定和可变的时间步长

# 产生于馄饨
让我们从小处开始。 每个游戏都需要有一个窗口，正如您在第一章中已经知道的那样，它还活着！ 它还活着！ –安装程序和第一个程序，需要创建，销毁它，并需要处理其事件。 它还需要能够清除屏幕并更新自身，以显示清除屏幕后绘制的所有内容。 此外，跟踪窗口是否处于关闭状态以及是否处于全屏模式以及使用一种方法来切换窗口非常有用。 最后，我们当然需要绘制到窗口。 知道了所有这些之后，我们的窗口类的头将可以预料地看起来像这样：
```
class Window{
public:
    Window();
    Window(const std::string& title, const sf::Vector2u& size);
    ~Window();

void BeginDraw();
    void EndDraw();

void Update();

bool IsDone();
    bool IsFullscreen();
    sf::Vector2u GetWindowSize();

void ToggleFullscreen();

void Draw(sf::Drawable& l_drawable);
private:
    void Setup(const std::string title, const sf::Vector2u& size);
    void Create();
    void Destroy();

sf::RenderWindow m_window;
    sf::Vector2u m_windowSize;
    std::string m_windowTitle;
    bool m_isDone;
    bool m_isFullscreen;
};
```
因为我们想在内部处理窗口的设置，所以setup方法以及destroy和create方法都设为私有。 可以将它们视为此类用户不需要了解的辅助方法。 设置完成后，最好保留一些信息，例如窗口大小或在其上方显示的标题。 最后，我们保留两个布尔变量，以跟踪关闭的窗口及其与全屏有关的状态。
```
在我们的窗口类中使用的命名约定称为匈牙利表示法。 当然，并不需要使用它，但是当处理大量代码，尝试查找错误以及与更多的人一起工作时，使用它可能会很有用。 我们将在整本书中使用它。 可以在这里找到有关它的更多信息：http://en.wikipedia.org/wiki/Hungarian_notation
```
## 实现窗口类
现在我们有了蓝图，让我们开始实际构建窗口类。 入口和出口点似乎和任何开头都一样好：
```
Window::Window(){ Setup("Window", sf::Vector2u(640,480)); }
Window::Window(const std::string& l_title, 
 const sf::Vector2u& l_size)
{
 Setup(l_title,l_size);
}
Window::~Window(){ Destroy(); }
```
构造函数和析构函数的实现都只是利用了不久将要实现的helper方法。 还有一个默认构造函数，它不带任何参数并初始化一些预设的默认值，这不是必需的，但是很方便。 话虽如此，让我们看一下设置方法：
```
void Window::Setup(const std::string l_title, 
 const sf::Vector2u& l_size)
{
 m_windowTitle = l_title;
 m_windowSize = l_size;
 m_isFullscreen = false;
 m_isDone = false;
 Create();
}
```
再一次，这很简单。 如前所述，它初始化并跟踪将要传递给构造函数的某些窗口属性。 除此之外，它还会调用另一个名为Create的方法来进一步分解代码，这是除Destroy方法之外接下来将要实现的方法：
```
void Window::Create(){
 auto style = (m_isFullscreen ? sf::Style::Fullscreen 
 : sf::Style::Default);
 m_window.create({ m_windowSize.x, m_windowSize.y, 32 },
 m_windowTitle, style);
}
void Window::Destroy(){
 m_window.close();
}
```
在这里，我们介绍SFML提供的新数据类型：sf :: Uint32。 它存储在样式局部变量中，该局部变量通过使用auto关键字自动推导为所述类型。 它只是一个无符号的，固定大小的整数类型。 在这种特殊情况下，我们使用32位整数，尽管SFML提供8、16和32位的有符号和无符号类型。 我们使用此值使用三元运算符保存窗口的当前样式，并将其分配给窗口样式枚举的默认样式或全屏样式。 这是SFML中所有可能的窗口样式的完整列表：
|枚举|描述|互斥|
|-|-|-|
None|没有边框或标题栏。最简约的风格|是
Fullscreen|全屏模式|是
Titlebar|标题栏和固定边框|否
Close|标题栏和关闭按钮|否
Resize|标题栏，可调整大小的边框和最大化按钮|否
Default|标题栏，可调整大小的边框，最大化和关闭按钮|否

互斥列仅表示该样式是否可以与其他样式串联使用。 例如，通过使用C ++中的按位或运算符将两种样式组合在一起，可以使窗口具有标题栏，可调整大小的边框，最大化按钮和关闭按钮：
```
auto style = sf::Style::Resize | sf::Style::Close;
```
但是，如果样式是互斥的，则不能以这种方式将其与任何其他样式一起使用。

一旦有了样式，就可以使用统一的初始化将其传递给窗口的create方法，以及构造的sf :: VideoMode类型之外。 就这么简单。

我们的Window类的destroy方法将仅通过调用其close方法来关闭窗口。 在这里需要特别注意的是，关闭的窗口将销毁其所有附加资源，但是您仍然可以再次调用其create方法来重新创建窗口。 如果关闭窗口，则轮询事件和调用display方法仍将起作用。 只会没有效果。

让我们通过在适当的update方法中处理窗口的事件来分解曾经是固定的代码块：
```
void Window::Update(){
 sf::Event event;
 while(m_window.pollEvent(event)){
 if(event.type == sf::Event::Closed){
 m_isDone = true;
 } else if(event.type == sf::Event::KeyPressed &&
 event.key.code == sf::Keyboard::F5)
 {
 ToggleFullscreen();
 }
 }
}
```
和以前一样，我们只是在处理事件。 但是，我们并没有立即关闭窗口，而是简单地翻转了我们保留的布尔值标志，以检查窗口是否已关闭：m_isDone。 由于我们也有兴趣在窗口的全屏状态和正常状态之间切换，因此需要注意另一种事件：sf :: Event :: KeyPressed。 每当按下键盘键时，将调度此事件，并且该事件包括有关存储在event.key结构中的该键的信息。 现在，我们只对所按下键的代码感兴趣，然后可以根据sf :: Keyboard枚举表进行检查。 收到按下F5键的事件后，我们调用ToggleFullscreen方法，由于将代码分为可管理的部分，因此实现起来非常简单。
```
void Window::ToggleFullscreen(){
 m_isFullscreen = !m_isFullscreen;
 Destroy();
 Create();
}
```
如您所见，我们在这里所做的唯一一件事就是反转布尔类成员m_isFullscreen的值，该值跟踪窗口状态。 之后，我们需要销毁并重新创建窗口，以使其遵守我们的更改。 让我们看一下绘制方法：
```
void Window::BeginDraw(){ m_window.clear(sf::Color::Black); }
void Window::EndDraw(){ m_window.display(); }
```
这里没有介绍任何新内容。 我们只是在BeginDraw和EndDraw方法中包装了清除和显示的功能。 现在剩下的就是简单的辅助方法：
```
bool Window::IsDone(){ return m_isDone; }
bool Window::IsFullscreen(){ return m_isFullscreen; }
sf::Vector2u Window::GetWindowSize(){ return m_windowSize; }
void Window::Draw(sf::Drawable&l_drawable){
 m_window.draw(l_drawable);
}
```
## 建立游戏类
我们在包装我们的窗口类的基本功能方面做得很好，但这并不是唯一需要重构的代码块。 在第1章中，它还活着！ 它还活着！ – Setup and First Program，我们已经讨论了游戏的主要循环及其内容，主要处理输入，更新游戏世界和玩家，最后将所有内容呈现在屏幕上。 众所周知，仅将所有功能都塞入游戏循环即可产生意大利面条代码，并且由于我们希望摆脱这种情况，因此，我们考虑一个允许这种行为的更好的结构：
```
void main(int argc, void** argv[]){
 // Program entry point.
 Game game; // Creating our game object.
 while(!game.GetWindow()->IsDone()){
 // Game loop.
 game.HandleInput();
 game.Update();
 game.Render();
 }
}
 ```
上面的代码代表了main.cpp文件的全部内容，并完美地说明了结构正确的游戏类的用法，该类不会无休止地以正确的顺序调用正确的方法，直到关闭窗口为止。 为了清楚起见，让我们看一下游戏类标题的简化版本：
```
class Game{
public:
 Game();
 ~Game();
 void HandleInput();
 void Update();
 void Render();
 Window* GetWindow();
 ...
private:
 void MoveMushroom();
 Window m_window;
 ...
};
```
请注意，游戏类包含我们窗口的实例。 可以采取不同的方法，但是对于我们当前的需求，这已经足够了。
## 使我们的代码生效
现在，我们准备重新实现第1章中的弹跳蘑菇演示，它是活着的！ 它还活着！ –安装程序和第一个程序。 鉴于它很简单，我们将引导您完成将以前编写的代码适应新结构的整个过程。 让我们从设置将要使用的窗口和图形开始：
```
Game::Game(): m_window("Chapter 2", sf::Vector2u(800,600)){
 // Setting up class members.
 m_mushroomTexture.loadFromFile("Mushroom.png");
 m_mushroom.setTexture(m_mushroomTexture);
 m_increment = sf::Vector2i(4,4);
}
```
因为我们没有什么要清理的，所以我们的游戏析构函数暂时将保持空白：
```
Game::~Game(){}
```
在此示例中，我们无需检查输入内容，因此现在暂时不使用该方法。 但是，我们要做的是每帧更新子画面的位置：
```
void Game::Update(){
 m_window.Update(); // Update window events.
 MoveMushroom();
}
void Game::MoveMushroom(){
 sf::Vector2u l_windSize = m_window.GetWindowSize();
 sf::Vector2u l_textSize = m_mushroomTexture.getSize();
 if((m_mushroom.getPosition().x >
 l_windSize.x - l_textSize.x&&m_increment.x> 0) ||
 (m_mushroom.getPosition().x < 0 &&m_increment.x< 0)){
 m_increment.x = -m_increment.x;
 }
 if((m_mushroom.getPosition().y >
 l_windSize.y - l_textSize.y&&m_increment.y> 0) ||
 (m_mushroom.getPosition().y < 0 &&m_increment.y< 0)){
 m_increment.y = -m_increment.y;
 }
 m_mushroom.setPosition(
 m_mushroom.getPosition().x + m_increment.x, 
 m_mushroom.getPosition().y + m_increment.y);
}
```
从字面上看，您可能会注意到的第一件事是我们的窗口类的update方法调用。 我们已经介绍了SFML中事件处理的重要性，但是仍然值得一提。 其余代码几乎相同，除了我们现在有一个单独的方法负责更新蘑菇精灵的位置。 为了增加可读性，我们使用了两个局部变量来保存窗口和纹理的大小，仅此而已。 是时候将精灵绘制到屏幕上了：
```
void Game::Render(){
 m_window.BeginDraw(); // Clear.
 m_window.Draw(m_mushroom);
 m_window.EndDraw(); // Display.
}
```
再一次，代码相当简单。 我们的窗口类完成了所有工作，我们要做的就是调用Draw方法并在包装方法之间传递sf :: Drawable，以清除屏幕并显示更改。

将所有内容放在一起并运行它，应该会产生与我们在第一章“活着”中完全相同的弹跳蘑菇。 它还活着！ –安装程序和第一个程序。 但是，您可能已经注意到，根据计算机的繁忙程度，精灵的移动方式有所不同。 在这一观察中，有一个关于游戏开发的重要教训。
## 硬件和执行时间
让我们回到1992年5月5日。Apogee Software开始发布由id Software开发的，如今广为人知的邪灵经典《 Wolfenstein 3D》：
## p27 经典游戏
具有远见的人约翰·卡马克（John Carmack）取得了长足的进步，不仅普及了，而且革新了PC上的第一人称射击游戏类型。 它的巨大成功不能被夸大，因为即使到现在也很难准确预测它已被下载了多少次。 大约在那个时候长大，有时候让人不禁怀旧，然后尝试再次玩这个游戏。 自从最初在PC上用于DOS操作系统的发行版以来，它已被移植到许多其他操作系统和控制台上。 尽管仍然可以播放，但自使用DOS以来，我们已经走了很长一段路。 我们的软件运行的环境已经发生了根本性的变化，因此过去的软件不再兼容，因此需要进行仿真。
```
模拟器可以是软件，硬件或两者的组合，可以在主系统（称为主机）上模拟某个系统（通常称为来宾）的功能。
```
用于此目的的每个仿真器不仅必须模仿与您尝试播放的标题兼容的系统软件，还必须模仿硬件。 为什么这么重要？ DOS时代的大多数游戏都认为硬件大致相似。 对于Wolfenstein 3D，它假定它在4.77 MHz系统上运行，这使开发人员可以通过不编写内部定时循环来节省一些时钟周期，以提高效率。 Wolfenstein 3D之类的游戏消耗了所有处理能力，这在当时是一个不错的策略，直到出现了功能更强大，速度更快的处理器。 如今，即使相比所有最便宜的消费级处理器，微不足道的4.77 MHz速度也相形见,，因此，对特定系统的正确仿真也需要减少CPU时钟周期，否则这些游戏将运行得太快，从而 正是当模拟器设置错误并没有充分限制速度时会发生什么。

虽然这是最极端的示例，但是速度管理是当今任何必须以恒定速度运行的软件的重要组成部分。 除了硬件和体系结构的不同选择之外，仅根据当时系统的繁忙程度或代码在呈现图像之前完成每次迭代所需的不同任务即可，您的软件可能会运行得更快或更慢。 考虑下图：
## p28 硬件快慢
左侧和右侧的更改都在1秒间隔内发生。 两种情况下的代码完全相同。 唯一的区别是主循环在该间隔内设法完成的迭代次数。 可以预见的是，速度较慢的硬件将需要更长的时间来执行代码，因此将产生更少的迭代，从而导致在1秒的时间间隔内，精灵被移动的次数更少，最终看起来像左侧。 作为游戏开发者，重要的是要确保您的产品在指定的规范准则内在所有系统上运行相同。 这就是SFML时间管理的用武之地。

## 控制帧频
SFML提供了一种为应用程序设置帧速率上限的方法。 这是sf :: RenderWindow类中的一种方法，适当地称为setFramerateLimit：
```
m_window.setFramerateLimit(60); // 60 FPS cap.
```
尽管此功能不是绝对可靠的，但只要提供的上限不太高，它就可以确保应用程序的帧速率以合理的精度限制在提供的最大值内。 请记住，限制帧速率还可以减少程序的总体CPU消耗，因为它不再需要更新和重画同一场景了多次。 但是，这确实为较慢的硬件带来了问题。 如果帧速率低于提供的值，则模拟运行也会变慢。 设置限制只能解决我们一半的问题。 让我们来看一些更实用的东西。 输入sf :: Clock！
## 使用SFML时钟
sf :: Clock类非常简单且轻巧，因此只有两种方法：getElapsedTime（）和restart（）。 它的唯一目的是以操作系统可以提供的最精确的方式测量自时钟的最后一个实例重新启动以来或自时钟创建以来所经过的时间。 使用getElapsedTime方法检索经过的时间时，它返回类型sf :: Time。 其背后的主要理由是附加的抽象层，以提供灵活性并避免强加任何固定的数据类型。 sf :: Time类也是轻量级的，它提供了三种有用的方法将经过的时间转换为秒，该时间返回浮点值毫秒（返回32位整数值）和微秒（返回64位整数值）， 如此处所示：
```
sf::Clock clock;
...
sf::Time time = clock.getElapsedTime();
float seconds = time.asSeconds();
sf::Int32 milliseconds = time.asMilliseconds();
sf::Int64 microseconds = time.asMicroseconds();
...
time = clock.restart();
```
如您所见，重新启动方法还返回sf :: Time值。 提供此功能是为了避免在调用重新启动方法之前立即调用getElapsedTime，并避免在这两个调用之间传递一些时间，否则这些时间将无法解决。 这对我们有什么用？ 嗯，我们要解决的问题是相同的代码在其他平台上的运行方式不同，因为我们无法考虑它们的速度。 我们使用以下代码在屏幕上移动精灵：
```
m_mushroom.setPosition(
 m_mushroom.getPosition().x + m_increment.x, 
 m_mushroom.getPosition().y + m_increment.y);
```
此处使用m_increment向量并假设迭代之间的时间是恒定的，但这显然是不正确的。 回忆一下速度，时间和距离公式的魔术三角形：
## p30 移动三角形
通过首先定义小精灵移动的设定速度，可以找到小精灵在两次更新之间应该经过的距离。 这里的时间值只是整个程序周期完成所花费的时间。 为了准确地衡量这一点，我们将调整Game类以利用sf :: Clock：
```
class Game{
public:
...
 sf::Time GetElapsed();
 void RestartClock();
private:
...
sf::Clock m_clock;
 sf::Time m_elapsed;
...
};
```
我们添加的两个新的公共方法可以这样实现：
```
sf::Time Game::GetElapsed(){ return m_elapsed; }
void Game::RestartClock(){ m_elapsed = m_clock.restart(); }
```
一旦完成，重要的是实际使用此功能并在每次迭代后重新启动游戏时钟。 完成所有工作后，只需在主游戏循环中调用RestartClock方法即可实现：
```
while(!game.GetWindow()->IsDone()){
 // Game loop.
 game.HandleInput();
 game.Update();
 game.Render();
 game.RestartClock(); // Restarting our clock.
}
```
循环的最后一行将确保游戏类的m_elapsed成员始终具有上一次迭代过程中经过的时间值，因此让我们使用该时间并确定我们的精灵应该移动多远：
```
float fElapsed = m_elapsed.asSeconds();
m_mushroom.setPosition(
 m_mushroom.getPosition().x + (m_increment.x * fElapsed), 
 m_mushroom.getPosition().y + (m_increment.y * fElapsed));
```
现在，我们将m_increment用作速度变量，而不是距离变量。 通过查看构造函数中的先前代码，我们已将m_increment向量的x和y值都设置为4。由于我们将经过的时间表示为秒，因此，这实际上就像是说精灵需要 每秒移动4个像素。 这确实很慢，所以让我们将其更改为更刺激的内容：
```
Game::Game(){
...
 m_increment = sf::Vector2i(400,400); // 400px a second.
}
```
编译并运行项目后，您应该看到我们的精灵在屏幕上愉快地弹起。 现在，无论帧速率多低，它在执行的每台机器上都将移动相同的距离。 要获得更多积分，请使用SFML提供的sf :: sleep函数人为地减慢游戏循环，从而自己尝试一下，如下所示：
```
while(!game.GetWindow()->IsDone()){
 // Game loop.
 game.HandleInput();
 game.Update();
 game.Render();
 sf::sleep(sf::seconds(0.2)); // Sleep for 0.2 seconds.
 game.RestartClock();
}
```
随意调整传递给sleep函数的参数。 您会注意到，无论每次迭代花费多长时间，它都会将精灵移动完全相同的距离。
## 固定时间步
在某些情况下，我们编写的时间管理代码并不能真正正确地应用。 假设我们只想以每秒60次的固定速率调用某些方法。 它可能是只需要更新一定时间的物理系统，或者如果游戏是基于网格的，则可能会很有用。 无论哪种情况，当更新速率非常重要时，固定的时间步就是您的朋友。 与可变的时间步长不同，可变的时间步长在下一个更新和绘制完成后立即进行，固定的时间步长方法将确保某些游戏逻辑仅以提供的速率发生。 实施固定的时间步非常简单。 首先，我们必须确保不要覆盖前一次迭代的经过时间值，而是像这样添加：
```
void Game::RestartClock(){
 m_elapsed += m_clock.restart();
}
```
此处显示了用于计算整个1秒间隔内单个更新的时间量的基本表达式：
## p33 更新时间
假设我们希望我们的游戏每秒更新60次。 要找到帧时间，我们将1除以60，然后检查经过时间是否超过了该值，如下所示：
```
float frametime = 1.0f / 60.0f;
if(m_elapsed.asSeconds() >= frametime){
 // Do something 60 times a second.
 ...
 m_elapsed -= sf::seconds(frametime); // Subtracting.
}
```
注意最后的减法。 这是我们重置周期并保持仿真以恒定速度运行的方式。 根据您的应用程序，您可能希望在两次更新之间使其处于休眠状态，以减轻CPU负担。 除了细节之外，这些都是固定时间步长的基础。 这是将在下一章中完成的游戏中将使用的确切技术。
## 常见错误
通常，在使用时钟时，SFML的新手往往会将其放置在错误的位置并在错误的时间重新启动它们。 这样的事情充其量只能导致“笨拙”的行为。
```
请记住，不为空或未注释掉的每一行代码都需要花费时间才能执行。 根据所调用的函数或正在构造的类的实现方式，时间值的范围可能从微小到无限。
```
诸如更新世界上所有游戏实体，执行计算和渲染之类的计算在计算上是相当昂贵的，因此请确保不要以某种方式将这些调用从时间测量范围中排除。 在主游戏循环结束之前，请务必确保重启时钟并掌握经过的时间是您要做的最后一件事。

另一个错误是时钟对象位于错误的范围内。 考虑以下示例：
```
void Game::SomeMethod(){
 sf::Clock clock;
 ...
 sf::Time time = clock.getElapsedTime();
}
```
假定此代码的目的是测量自sf :: Clock对象启动以来的时间以外的任何时间，此代码将产生错误的结果。 创建一个时钟实例只是衡量它在其范围内有效的时间，而不是其他任何时间。 这就是为什么将游戏类中的时钟声明为类成员的原因。 由于时钟是在堆栈上创建的，因此上述方法一结束，时钟将再次被销毁。

将经过的时间保持在float数据类型或任何其他非sf :: Time的数据类型中，这也是普遍不赞成的事情。 像这样的事情并不是正确使用SFML的好例子：
```
class Game{
...
private:
...
 float m_elapsed;
...
};
```
虽然有效，但这并不是完全类型安全的。 在此过程中还需要进行更多的类型转换，因为每次时钟重新启动时，您都必须调用三种转换方法之一。 密封棺材的另一个钉子是代码的可读性。 SFML提供其自己的时间类是出于某种原因和便利，因此，除非有充分的理由不使用它，否则请避免使用任何其他数据类型。

由于我们在谈论时间，因此值得一提的最后一件事是C ++中的控制台输出。 偶尔打印一些内容虽然很好，即使只是出于调试目的，但不断出现的控制台垃圾邮件会使您的应用程序变慢。 控制台输出本身很慢，无法以与程序其余部分完全相同的速度执行。 在每个上打印一些东西
例如，主游戏循环的迭代会极大地限制您的应用程序速度。
## 总结
祝贺您完成本书的第二章！ 如前所述，您必须了解本章介绍的所有内容，因为后面的所有内容将在很大程度上取决于我们在此介绍的内容。

在不同平台上和不同条件下获得平稳一致的结果与应用程序的良好结构同样重要，如果您愿意的话，这又是千层面的另一层。 在成功完成本章后，您将再次获得足够的知识来制作可以利用固定和可变时间步长的应用程序，以创建可以独立于基础体系结构运行的仿真。

最后，我们将为您提供一些好的建议。 前几章是大多数读者相对紧密地从字面上理解的内容。 尽管这是一种可接受的处理方式，但我们希望您更像指南一样使用它而不是食谱。 关于人类知识，最令人惊奇的事情是，它不只是被无休止的记忆所吸收。 实验和获得实际经验是成功掌握这一点的另一半，因此继续编写代码。 不管是好是坏，都可以编译，编译，出错，运行或崩溃，无论哪种方式都不错。 尝试新事物并惨败，以便有一天取得惊人的成功。 您已经准备好动手了，因为我们实际上将在下一章开始实施本书的第一个游戏项目。 到时候那里见！

马梁瑞/sfmlByExample

简介

发行版

贡献者

近期动态

马梁瑞/sfmlByExample .gitee-modal { width: 500px !important; }

简介

发行版

贡献者

近期动态

搜索帮助

马梁瑞/sfmlByExample