摘要: 这个例程中我们将学习怎么使用irrlicht中的分屏(比如在赛车类游戏中）{
我们将创建一个被分为4个部分的视口，有3个固定摄相机和一个用户可以控制的摄相机好，让们从头文件开始吧（我想没有再多说的必要了）
阅读全文
摘要: 理清一个引擎，不得不先理清它的层次结构，进而理清渲染流程。 本文给出了鬼火引擎中的设备抽象层，有助于对鬼火引擎源码的快速阅读
阅读全文
摘要: 游戏开发中，计算机图形学是必不可少的东西。许多人也是从接触图形开始而进入游戏行业的。3D管线导论这本书诠释了3D管线的细节。为大家解开了萦绕已久的迷团。
阅读全文
http://www.guibian.com/article.asp?id=87我在这个行业呆了快2年半了。其中辗转过2，3个公司，有业内很大的知名公司，也有业内名不见经传的小公司。从业过程中也认识了不少在各大公司的同行。如果不出意外的话，基本上我不打算继续在这个行业呆下去了，尽管我现在收入颇丰，但是我觉得这不是我想要的生活方式。
那么我们来讨论下目前整个国内游戏行业的状况。我觉得是非常糟糕的。据我估算，有一定游戏制作水平的人员应该不到万分之一，而这当中很多老人已经从事行政工作，另外一些虽然在技术的一线，但是由于年长或者其他原因，工作时长较少，也不足以面对纷繁复杂的行业进步。当然更重要的原因是以下几个方面：
1.策划：估计策划是整个目前游戏行业里最受非议的职业了，策划之所以受到如此待遇，我想差不多两个方面原因，主观上，是从业人员素质低下，游戏行业的迅速发展人员奇缺，导致迅速扩张后无法控制人员素质。大部分策划在我看来不是不适合做这项工作，而根本上就不适合工作。他们自以为比别人多玩了几个游戏就知道什么策划，简直的是莫大的笑话。极其混乱的思维，缺乏理性的规划，以及少的可怜的经验，加上不努力工作几乎已经导致策划成为整个开发的瓶颈了。
由于策划的水平过低，导致程序必须关注他们本来不熟悉的系统及逻辑，而把大部分时间浪费在逻辑上。策划的水平也直接影响到美术制作过程中对数据，质量的规划，最终多次返工。（后面我会说好的团队的样子）
当然没有经验也有很多客观因素，在目前中国这个急功近利的社会。策划从一开始就没有办法按照自己的思路来规划游戏本身，他们只能东抄西抄。形成一种恶性循环。不要忘记宫本茂也不是一天练成的，他也是经历了无数的失败以后才创造了马里奥，如果只是一味的模仿，怎么会有进步？
2.其他两个职业，程序与美术。游戏的高速发展，也把两个本不值得关注的职业推上社会的舞台。
美术说白了就是一群成绩差的孩子为自己找一个出路，尽管美术是一个我觉得很高尚的职业，但你不得不承认在中国这种缺乏人文精神，艺术气息的国家里，美术是不受尊重的。当然我们并不缺乏热爱美术的人，但是如果一个人真的热爱美术，我想他是决计不会再游戏行业呆多久的，因为这里只会扼杀美术。游戏行业里美术如果细分，至少可以分为艺术与技术两个部分，技术不用说，从我工作至今，认识的美术中技术很强的少之又少，因为要让一个画画的人去了解图形显卡是件很困难的事情。艺术呢？也没好到哪里去，原因我刚才已经分析过，国外的游戏往往能刺激美术这项工作的发展，而在国内，美术越来越往民工发展。
程序也没好到哪里去，游戏行业的高薪水吸引很多原先并不被看好的IT界“精英”们挤到游戏界，另外越来越多的水品差的新人也选择把游戏作为走入社会的第一份职业。结果就是代码质量低下，层次结构乱。而且为了应付项目进度，不用谈架构了，连代码都是凑出来的。因为逻辑系统复杂，需求不断再变，所以程序就可以冠冕的说不容易设计好的架构，在我看来这是非常混账的说法。好的程序不会因为项目的大小，而做出好赖差别很大的设计。做不出好设计的程序员，我想不仅是项目设计不好，也许就连一个类他们也抽象不出来，这是程序水平低，而不是游戏程序设计水平低的问题。
3.公司大小的矛盾。小的创业公司，有激情却没有好的技术人员，大的成熟公司，有好的技术人员却没有激情。我曾经呆过小公司，在小点的公司。技术是非常缺乏的，往往只有一个稍微有经验的从业人员，但是由于没有系统的规范，没有完整的流程，大家几乎都在不断的尝试着失败，直到磨平最初的激情与意志。
当然大公司在我看来更糟糕，虽然有重金请来技术人员，但是没有激情。复杂的领导裙带关系，散漫的工作态度是大公司最大的弊病。由于领导不懂开发环节，而对开发人员的过度干涉，导致项目进度迟缓设置流产。下属员工不思进取，每天消磨时间，领导在的时候做做工作，不在的时候各自活动，聊天的聊天，上SNS的上SNS，泡论坛的泡论坛。各级主管也有很大的问题，国内目前主管的水平在国外也顶多就是个一线工作的新人，所以主管如果不努力提高自己的水准势必导致游戏制作水品底下。但是很不幸，我在各个公司看到的结果就是，各级主管毫无激情，固守着自己可怜的一点点过时的技术。美术主管不懂图形，甚至对制作非常放松，造成最终难看的效果，过度的浪费与消耗。我听得最多的一句话就是，无数美术抱怨引擎的局限性，我想说的是，不管多么不好的引擎都不会给游戏画面本身带来多大的限制，如果做不好只是自己的水平问题跟引擎毫无关系。程序主管就更可悲了，我认识的有的人当中只是会写几句if ... else ... for循环，不知道什么事模板，甚至搞不清楚继承与虚函数。他们只是固守着陈旧的经验或者依赖于早年工作遗留下来的几个库维系着自己可怜的位置。
4.在中国这个畸形的社会，游戏界基本靠的是市场运作，而不是产品本身。所以不需要高品质的游戏，也就使开发人员自暴自弃。进而越来越差。我认为没有了激情的公司势必不会在历史的长河中存在太久。试想卡马克这样的天才还要一天努力工作16个小时，我们有怎么有可能超过别人？去看看暴雪，去看看Epic总部，那里人的工作状态，再看看我们，差距只会越拉越大。每一个游戏工作者都可以扪心自问，我是否真的热爱游戏这项事业，而不是热爱那可怜的几千块钱或上万块钱的月收入。我是否真的每天为只付出了我最大的努力，而不是混混日子得过且过，固守着自己貌似安逸的生活。我身边的每一个人好像都无所适从等待着公司上市这样的奇迹发生，我觉得真是可笑和可悲。
5.附上一个我心里的优秀团队的样子：
首先，要有资深的从业人员讨论定义所有的制作规范，开发流程，项目进度等。
其次需要一个优秀的开发团队，团员每个人无论是否有经验，至少要有激情，他们愿意付出比别多出多倍的时间精力来投入到项目中去，在游戏逻辑方面我认为并没有太多技术障碍，头脑清楚，肯于思考的策划都可以往逻辑程序员方面发展。而从事图形相关的程序却需要比较专业的基础知识。游戏开发不是一个轻松的工作，至少比起IT同行业，我认为要付出更多的努力。
策划人员要对游戏内容有精确的定义，框架，大方向，游戏逻辑都要事先确定的非常清晰。保证程序员不用浪费太多的时间去关注复杂的游戏逻辑，而把时间花费在游戏架构设计本身，以及开发更多更便捷的工作，帮助策划和美术提高工作效率。策划人员同时也要协同程序人员帮助美术制作者，用最好的方式把效果在游戏中发挥到最大化。当然管理人员要安排好测试人员，版本构建人员的随时跟踪，以保证项目稳定健壮的发展。
成员之间要相互信任，互相敞开心扉，承认自己的确认和弱点。针对不通的意见要多辩论，不要做一些无关痛痒的讨论。积极投入到决策和行动计划中去，不要事不关己高高挂起，每个人都应该为游戏本身付出更多，改进更多。对影响工作计划的行为负责，不要推卸责任，项目中谁都可能犯错误，但是自己一定要通过努力弥补过来，不要觉得由于其他的人问题导致自己的怎么怎么样。要把重点放在集体成绩上，不要以为自己的分内工作完成了就万事大吉了。
也许你觉得我的要求很高，也许是你不热爱这项工作吧。
材质，这个词有各行各业都有自己的解释。
美工把物体贴图和物体颜色，高光等统称为材质。D3D和OPENGL这样的图形接口则把物体表面贴图单独叫做纹理，而把漫反射，高光等叫做材质。
而在游戏引擎或图形引擎中提到的材质，则与此不同。 引擎中提到的材质不仅上面的的内容。 引擎中所谓的材质，是指物体在渲染时一系列的状态控制。 如，ALPHA混合开关以及ALPHA混合因子、纹理过虑方式，纹理通道状态、纹理矩阵、裁剪模式等，在D3D中，就是SetRenderState,SetTextureStageState,SetSamplerStateState等所控制的。在OPENGL中，则大多数由glEnable所控制。
我们所提到的材质系统，则是以此为基础展开的。 上面提到的这些因子，组成了我们的材质。 也是我们在渲染一个物体的时候，提交到设备的状态控制值。 一个物体的一次渲染，我们称作一个PASS。于是我们顺其自然地将这个渲染时的材质控制的最小单位命名为Pass,则：
struct TextureState
{
void* Texture;
int ColorOp;
int ColorAgr1;
int ColorAgr2;
int AlphaOp;
int AlphaAgr1;
int AlphaAgr2;
.....//更多内容
};
class CPass
{
CColor mAmbient;
CColor mDiffuse;
....更多内容
bool mAlphaEnable;
int mScrBlend;
int mDstBlend;
int mCullMode;
TextureState[4] mTextureStates;
...更多内容
};
当我们渲染一个物体的时候，只需要将这个类里面的状态应用到设备，即可完成对物体的绘制。
材质系统的基本内容就是这些，这也是最容易做到的事情。
但是，我们都知道，像D3D或OPENGL这样的图形接口每设置一次GPU状态的时候，都会有一定的开销（通过查看相关文档可以看到某些函数的具体开销值）。而为了保证我们的渲染流畅，我们不得不减少这样的开销。
很自然地，我们会想到，尽量减少切换。而如何减少切换呢。我们可以记录下自己的硬件状态，在设置下一个的时候，先判断当前硬件状态是否相同，如果相同。则不用再设置。 虽然某些图形接口在其层底做了类似的功能。但我们外部判断一下，也未尝不可。从D3D上来讲，外部判断比让其内部判断效率更佳。需要注意的是，由于我们在自己的程序里做了相同判断。因此，当有另一个程序也修改设备状态的时候，就会产生意想不到的效果。所以，我们应该适当的查询一下设备状态，并更新自己的状态记录表。至于这个查询间隔，就要根据自己的实际情况来测试了。
通过记录状态的方法来提升的效率是很不明显的，因此，我们需要对材质进行排序，至于怎么排序，这算法上的问题，在此先不作过多解释。 总之，我们将相似的材质排在一起。由于材质很相似，绘完一个再绘下一个的时候，减少了切换，从而大大提升了效率。
既然已经是涉及到设备了，我们总得考虑一下设备问题。 如果设备不支持我们当前给定的材质状态，怎么办？ 返回FALSE不渲染。还是让程序DOWN掉？ 对于一些重要的性能，设备不支持让程序DOWN掉是最好的做法，但是，对于像纹理混合通道不足的情况，让其DOWN掉就显得划不来了。毕竟我们设计的游戏程序是想让更多的玩家能玩不是？ 这样就会涉及到PASS的拆分问题。
对于PASS的拆分，OGRE已经做得很好了。根据用户的设备性能，如果不满足，就一直拆分，拆到用户满足为止，最后让一个物体渲染多次，来实现多个纹理通道混合的效果。 而多PASS则是在渲染的时候不得不考虑的地方，毕竟有些物殊效果非得用多PASS不可。
对于多PASS的设计，我们可以参考OGRE的材质方法或是D3DX的效果框架。我们把完成一个最终效果的方案称作一个渲染技术 Technique ，一个技术可由多个Pass来完成。
class Technique
{
...更多内容
vector<CPass*> mPasses;
};
这样就满足了我们的需求。 对于同一种效果，我们可以提供多种Technique供程序选择。 而这个选择的条件则可以是根据硬件性能，或是玩家手动选择的配置来实现。
最后结构如下：
class CMaterial
{
public:
...更多内容
vector<CTechnique*> mRenderTechs
};
乱七八糟地说了一通，希望没晕死人！！！