warning

docs/06 In Practice/2D-Game/02 Setting up.md

@@ -6,6 +6,10 @@
 翻译     | [ZMANT](https://github.com/Itanq)
 校对     | Meow J
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 在开始真正写游戏机制之前，我们首先需要配置一个简单的框架，用来存放这个游戏，这个游戏将会用到几个第三方库，它们的大多数都已经在前面的教程中介绍过了。在需要用到新的库的时候，我会作出适当的介绍。
 
 首先，我们定义一个所谓的<def>超级</def>(Uber)游戏类，它会包含所有相关的渲染和游戏代码。这个游戏类的主要作用是（简单）管理你的游戏代码，并与此同时将所有的窗口代码从游戏中解耦。这样子的话，你就可以把相同的类迁移到完全不同的窗口库（比如SDL或SFML）而不需要做太多的工作。

docs/06 In Practice/2D-Game/03 Rendering Sprites.md

@@ -6,6 +6,10 @@
 翻译   | [ZMANT](https://github.com/Itanq)
 校对   |  Meow J
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 为了给我们当前这个黑漆漆的游戏世界带来一点生机，我们将会渲染一些精灵(Sprite)来填补这些空虚。<def>精灵</def>有很多种定义，但这里主要是指一个2D图片，它通常是和一些摆放相关的属性数据一起使用，比如位置、旋转角度以及二维的大小。简单来说，精灵就是那些可以在2D游戏中渲染的图像/纹理对象。
 
 我们可以像前面大多数教程里做的那样，用顶点数据创建2D形状，将所有数据传进GPU并手动变换图形。然而，在我们这样的大型应用中，我们最好是对2D形状渲染做一些抽象化。如果我们要对每一个对象手动定义形状和变换的话，很快就会变得非常凌乱了。

docs/06 In Practice/2D-Game/04 Levels.md

@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 Breakout不会只是一个单一的绿色笑脸，而是一些由许多彩色砖块组成的完整关卡。我们希望这些关卡有以下特性：他们足够灵活以便于支持任意数量的行或列、可以拥有不可摧毁的坚固砖块、支持多种类型的砖块且这些信息被存储在外部文件中。
 
 在本教程中，我们将简要介绍用于管理大量砖块的游戏关卡对象的代码，首先我们需要先定义什么是一个砖块。

docs/06 In Practice/2D-Game/05 Collisions/01 Ball.md

@@ -6,6 +6,10 @@
 翻译     | [aillieo](https://github.com/aillieo)
 校对     | 暂未校对
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 此时我们已经有了一个包含有很多砖块和玩家的一个挡板的关卡。与经典的Breakout内容相比还差一个球。游戏的目的是让球撞击所有的砖块，直到所有的可销毁砖块都被销毁，但同时也要满足条件：球不能碰触屏幕的下边缘。
 
 除了通用的游戏对象组件，球还需要有半径和一个布尔值，该布尔值用于指示球被固定(<def>stuck</def>)在玩家挡板上还是被允许自由运动的状态。当游戏开始时，球被初始固定在玩家挡板上，直到玩家按下任意键开始游戏。

docs/06 In Practice/2D-Game/05 Collisions/02 Collision detection.md

@@ -6,6 +6,10 @@
 翻译     | [aillieo](https://github.com/aillieo)
 校对     | 暂未校对
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 当试图判断两个物体之间是否有碰撞发生时，我们通常不使用物体本身的数据，因为这些物体常常会很复杂，这将导致碰撞检测变得很复杂。正因这一点，使用**重叠**在物体上的更简单的外形（通常有较简单明确的数学定义）来进行碰撞检测成为常用的方法。我们基于这些简单的外形来检测碰撞，这样代码会变得更简单且节省了很多性能。这些<def>碰撞外形</def>例如圆、球体、长方形和立方体等，与拥有上百个三角形的网格相比简单了很多。
 
 虽然它们确实提供了更简单更高效的碰撞检测算法，但这些简单的碰撞外形拥有一个共同的缺点，这些外形通常无法完全包裹物体。产生的影响就是当检测到碰撞时，实际的物体并没有真正的碰撞。必须记住的是这些外形仅仅是真实外形的近似。

docs/06 In Practice/2D-Game/05 Collisions/03 Collision resolution.md

@@ -6,6 +6,10 @@
 翻译     | [aillieo](https://github.com/aillieo)
 校对     | 暂未校对
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 上个教程的最后，我们得到了一种有效的碰撞检测方案。但是球对检测到的碰撞不会有反作用；它仅仅是径直穿过所有的砖块。我们希望球会从撞击到的砖块**反弹**。此教程将讨论如何使用AABB-圆碰撞方案实现这项称为<def>碰撞处理</def>(Collision Resolution)的功能。
 
 当碰撞发生时，我们希望出现两个现象：重新定位球，以免它进入另一个物体，其次是改变球的速度方向，使它看起来像是物体的反弹。

docs/06 In Practice/2D-Game/06 Particles.md

@@ -6,6 +6,10 @@
 翻译    | [ZMANT](https://github.com/Itanq)
 校对    | 暂无
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 一个微粒,从OpenGL的角度看就是一个总是面向摄像机方向且(通常)包含一个大部分区域是透明的纹理的小四边形.一个微粒本身主要就是一个精灵(sprite),前面我们已经早就使用过了,但是当你把成千上万个这些微粒放在一起的时候,就可以创造出令人疯狂的效果.
 
 当处理这些微粒的时候,通常是由一个叫做粒子发射器或粒子生成器的东西完成的,从这个地方,持续不断的产生新的微粒并且旧的微粒随着时间逐渐消亡.如果这个粒子发射器产生一个带着类似烟雾纹理的微粒的时候,它的颜色亮度同时又随着与发射器距离的增加而变暗,那么就会产生出灼热的火焰的效果:

docs/06 In Practice/2D-Game/07 Postprocessing.md

@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 如果我们可以通过几个后期处理(Postprocess)特效丰富Breakout游戏的视觉效果的话，会不会是一件很有趣的事情？利用OpenGL的帧缓冲，我们可以相对容易地创造出模糊的抖动效果、反转场景里的所有颜色、做一些“疯狂”的顶点运动、或是使用一些其他有趣的特效。
 
 !!! important

docs/06 In Practice/2D-Game/08 Powerups.md

@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 Breakout已经接近完成了，但我们可以至少再增加一种游戏机制让它变得更酷。“充电”（译注：Powerups，很多游戏中都会用这个单词指代可以提升能力的道具，本文之后也会用道具一词作为其翻译）怎么样？
 
 这个想法的含义是，无论一个砖块何时被摧毁，它都有一定几率产生一个道具块。这样的道具快会缓慢降落，而且当它与玩家挡板发生接触时，会发生基于道具类型的有趣效果。例如，某一种道具可以让玩家挡板变长，另一种道具则可以让小球穿过物体。我们还可以添加一些可以给玩家造成负面影响的负面道具。

docs/06 In Practice/2D-Game/09 Audio.md

@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 无论我们将游戏音量调到多大，我们都不会听到来自游戏的任何音效。我们已经展示了这么多内容，但没有任何音频，游戏仍显得有些空洞。在本节教程中，我们将解决这个问题。
 
 OpenGL不提供关于音频的任何支持。我们不得不手动将音频加载为字节格式，处理并将其转化为音频流，并适当地管理多个音频流以供我们的游戏使用。然而这有一些复杂，并且需要一些底层的音频工程知识。

docs/06 In Practice/2D-Game/10 Render Text.md

@@ -6,6 +6,10 @@
 | 翻译   | [aillieo](https://github.com/aillieo)    |
 | 校对   | 暂无                                       |
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 本教程中将通过增加生命值系统、获胜条件和渲染文本形式的反馈来对游戏做最后的完善。本教程很大程度上是建立在之前的教程[文本渲染](../02 Text Rendering.md)基础之上，因此如果没有看过的话，强烈建议您先一步一步学习之前的教程。
 
 在Breakout中，所有的文本渲染代码都封装在一个名为<fun>TextRenderer</fun>的类中，其中包含FreeType库的初始化、渲染配置和实际渲染代码等重要组成部分。以下是<fun>TextRenderer</fun>类的代码：

docs/06 In Practice/2D-Game/11 Final thoughts.md

@@ -6,6 +6,10 @@
 翻译    | [包纸](https://github.com/ShirokoSama)
 校对    | 暂无
 
+!!! note
+
+	本节暂未进行完全的重写，错误可能会很多。如果可能的话，请对照原文进行阅读。如果有报告本节的错误，将会延迟至重写之后进行处理。
+
 与仅仅是用OpenGL创建一个技术演示相比，这一整章的教程给我们了一次体验在此之上的更多内容的机会。我们从零开始制作了一个2D游戏，并学习了如何对特定的底层图形学概念进行抽象、使用基础的碰撞检测技术、创建粒子、展示基于正射投影矩阵的场景。所有的这些都使用了之前教程中讨论过的概念。我们并没有真正地学习和使用OpenGL中新的、令人兴奋的图形技术，更多的是在将所有知识整合至一个更大的整体中。
 
 Breakout这样的一个简单游戏的制作可以被数千种方法完成，而我们的做法也只是其中之一。随着游戏越来越庞大，你开始应用的抽象思想与设计模式就会越多。如果希望进行更深入的学习与阅读，你可以在[game programming patterns](http://gameprogrammingpatterns.com/)找到大部分的抽象思想与设计模式。（译注：《游戏编程模式》一书国内已有中文翻译版，GPP翻译组译，人民邮电出版社）