摘要: 本篇是创建游戏内核（1）【C风格版】的续篇，关于该内核的细节说明请参考创建游戏内核（2）。
阅读全文
摘要: 该版本根据接口与实现分离版改的，因为接口与实现分离写起来太烦琐，所以直接使用结构体。由于结构体的数据成员可以直接访问，可以减少编写大量的接口函数，同时对于简单的数据结构采用函数封装，只对复杂的功能模块采用结构体封装，减少抽象对象的使用以最大限度增加代码的透明度。
阅读全文
摘要: 在1998年的元旦，Bjarne Stroustrup（C++之父）接受了IEEE《计算机》杂志记者的专访。编辑很自然的认为他会对于过去七年来使用他创建的语言进行面对对象设计做一个历史性的回顾。而在这个专访中，记者获得了更有价值的新闻，但是最后编辑决定为了整个IT产业，这个稿子不能发表，但是就像其它被砍掉的新闻，往往还是弄得路人皆知的。
这一篇是当时专访的完全拷贝，没有被编辑、删改或者做过什么润色处理，也没有发布过，可能看起来不像常见的杂志文章，但这是实情。
你会发现真正引人入胜的地方... ...
阅读全文
摘要: 3D图形引擎【OO改良版】的代码以创建游戏内核【OO改良版】中编写的代码为基础进行开发，关于该引擎的细节说明请参阅创建3D图形引擎。
阅读全文
摘要: 使用单一的网格模型虽然可以同时渲染整个层次，但却意味着那些没有被看到的部分在通过渲染管道时会被裁剪掉，也就是说这样做会浪费时间。不要沮丧，因为使用一个单独的网格模型进行层次的渲染仍然有一些非常好的方法。比如说，在游戏世界中包括了单独的地牢，每个地牢包含不同的房间，所有的房间通过走廊连接到一起。其实，每个房间和走廊就是一个单独的网格模型，所要做的就是在游戏的处理过程中加载以及释放那些代表地牢房间的网格模型。
阅读全文
摘要: 本篇是创建3D图形引擎（3）【OO改良版】的续篇，以创建游戏内核【OO改良版】中编写的代码为基础进行开发，细节说明请参阅创建3D图形引擎（4）。
阅读全文
摘要: 本篇是创建3D图形引擎（2）【OO改良版】的续篇，以创建游戏内核【OO改良版】中编写的代码为基础进行开发，细节说明请参阅创建3D图形引擎（3）。
阅读全文
摘要: 盲目地绘制成千的物体而没有执行任何的剪切，是导致在图形-渲染通道中时间延迟的一个主要原因。需要再次使用视锥以快速确定哪些物体位于视野中，为了确定哪些物体是可见的，可将每个三维物体包围到一个可见的球体中，称之为框界球体（bounding sphere）。
下图演示了框界球体和视锥的运用，它展示了一个场景，其中有三个物体和一个视锥，每个网格模型都有一个可见的框界球体围绕着它。当一个球体位于构成视锥的6个平面前时，它就被认为是可见的。可以看出仅两个位于视锥中的物体是可见的，而另一个物体完全位于视锥外，绘制时能完全跳过那个位于视锥之外的物体。为了实现这一点，必须计算每个物体的框界球体，然后检测球体是否位于视锥之内。
阅读全文
摘要: 在每帧中绘制所有的多边形是非常低效的，为了提高处理的速度，可以仅渲染那些位于视野内的多边形，同时应避免扫描场景中的每个多边形来确定哪些多边形是可见的。如果不每帧进行搜索，又如何知道哪些多边形是位于视野内呢？解决的方法就是将一个三维模型分解为一些较小的块（称为节点nodes），其容纳较少的多边形。然后将节点排列到一个特定的结构中（一棵树），以便进行快速搜索，并确定哪个节点是可见的，然后渲染这些可见的节点，通过使用视锥，可以找出哪些节点是可见的。取代搜索数千个多边形，通过搜索一个小小的节点集合，就能决定怎样进行绘制。节点树引擎适用于任何的网格模型，并将它拆分为节点，以便快速渲染网格模型（网格模型代表了游戏的层次）。
阅读全文
摘要: Javascript是世界上最受误解的语言，其实C++何尝不是。坊间流传的错误的C++学习方法一抓就是一大把。我自己在学习C++的过程中也走了许多弯路，浪费了不少时间。
为什么会存在这么多错误认识？原因主要有三个，一是C++语言的细节太多。二是一些著名的C++书籍总在（不管有意还是无意）暗示语言细节的重要性和有趣。三是现代C++库的开发哲学必须用到一些犄角旮旯的语言细节（但注意，是库设计，不是日常编程）。这些共同塑造了C++社群的整体心态和哲学。
阅读全文