博客园_CG迷途大熊猫

特效系统的优化

2011-10-13T17:30:00Z

1.合并渲染批次

合并同一发射器发射的粒子（材质肯定相同）；

合并相同材质的特效节点；（透明节点不用考虑排序，效果没多大问题，不用考虑用什么order independant transparency）

遇到的问题：triangle list的特效节点合并没啥难度，triangle strip的呢？要用退化三角形！

http://realtimecollisiondetection.net/blog/?p=91

Optimizing the rendering of a particle system

There are many things that can kill the frame rate in a modern game, and particles are up near the top of the list of causes. A key contributing factor is that particles are subject to a lot of overdraw that is not present in your opaque geometry.

The reason for the increase in overdraw is that for particles we tend to have lots of individual primitives (usually quads) that are overlapped, perhaps to mimic effects like fire or smoke. Normally each particle primitive is translucent (alpha-blended) so the z-buffer is not updated as pixels are written and we end up rendering to pixels multiple times. (In contrast, for opaque geometry we do write to the z-buffer, so between a possible z-prepass, sorting objects front-to-back, hierarchical z-culling on the GPU, and normal depth testing, the result is that we have very little overdraw.)

Overdraw, in turn, leads to increased uses of both fillrate (how many pixels the hardware can render to per second) and bandwidth (how much data we can transfer to/from the GPU per second), both of which can be scarce resources.

Of course, overdraw is not the only reason particles can slow your frame rate to a crawl. We can also get bitten by other problems, like setting too much state for each particle or particle system.

What to do?

OK, let’s say we all agree that particles can cause a lot of problems. What to do? Fortunately there are lots of things that can be done to optimize the rendering side of a particle system. For whatever reason, few of these are discussed in books or articles, so I thought I’d list out a few things we can do. Feel free to add more suggestions as comments.

Use opaque particles. For example, make smoke effects really thick so (some or all of) the particle billboards can be opaque, with cutout alpha. For some particles, like shrapnel, rocks, or similar, use lightweight geometry particles instead of sprites with alpha borders.
Use richer particles. Put more oomph in a single particle sprite so we need fewer of them. Use flipbook textures for creating billowing in e.g. fire and smoke, rather than stacking sprites.
Reduce dead space around cutout-alpha particles. Use texkill to not process the transparent regions of the sprite. Alternatively, trim away the transparent areas around the particle, using an n-gon fan instead of just a quad sprite. (but beware lowered quad (2×2 pixel block) utilization when increasing the triangle count, or becoming vertex bound in the distance, so LOD from fan to a quad sprite in the distance).
Cap total amount of particles. Use hardware counters on the graphics card to count how many particle pixels have been rendered and stop emitting or drawing particles when passing a certain limit (which can be set dynamically).
Use frequency divider to reduce data duplication. We can reduce bandwidth and memory requirements by sharing data across particle vertices using the frequency divider, instead of through data duplication across vertices. (Arseny Kapoulkine described this well in Particle rendering revisited.)
Reduce state changes. Share shaders between particles. We can make this happen by e.g. dropping features for distant particles (such as dropping the normal map as soon as possible).
Reduce the need for sorting. Rely on additively or subtractively blended particles where possible. E.g. additive particles can be drawn in any order, so we can sort them to e.g. reduce state changes instead of sorting on depth (as is likely needed for normal alpha-blended particles).
Draw particles after AA-resolve. Most games today use multisampled antialiasing (MSAA), drawing to a 2x or 4x MSAA buffer. These buffers must be resolved (with an AA-resolve pass) into a non-MSAA buffer before display. Due to the way MSAA works, we still run the pixel shader equally many times whether we draw particles before or after the AA-resolve, but by drawing particles after the AA-resolve we drastically reduce frame buffer reads and writes, ROP costs, etc.
Draw particles into a smaller-resolution buffer. We can also draw particles into a separate, smaller-resolution buffer (smaller than the frame buffer or the AA-resolved buffer). The exact details vary depending on e.g. whether you use RGBA or FP16 frame buffers, but the basic idea is the following. First we draw the opaque geometry into our standard frame buffer. We then shrink the resulting corresponding z-buffer down to 1/4 or 1/16 size, then draw particles to 1/4 or 1/16 size frame buffer using the smaller z-buffer. After we’re done, we scale the smaller frame buffer back up and composite it onto the original frame buffer. (Some interesting details I’ve left out are how exactly to perform the z-buffer shrinking and the composite steps.)
Use MSAA trick to run pixel shader less. On consoles (and on PC hardware if drivers allowed it) you can tell the GPU to treat, say, an 800×600 frame buffer as if it were a 400×300 (ordered) 4xMSAA buffer. Due to the way MSAA works, this has the effect of running the pixel shader only once per 2×2 pixels of the original buffer, at the cost of blurring your particles equivalently much. (Though you still get the benefit of antialiasing at the edges of the particles.)
Generate particles “on chip.” On newer (PC) hardware we can use geometry shaders to generate particles on the GPU instead of sending the vertex data from the CPU. This saves memory and bandwidth.

We can also attempt some more esoteric stuff, like:

Compose particles front-to-back premultiplied-alpha style. Using premultiplied alpha (which is associative) we can blend particles front-to-back instead of the normal back-to-front ordering. The idea here is to use the front-to-back drawing to fill in depth or stencil buffer when alpha has become (near) solid and ultimately stop drawing particles all together (when they no longer contribute much to the visual scene, off in the distance).
Group particles together into one particle entity. Instead of drawing two overlapping particles individually, we can form a single (larger) particle that encompasses the two particles and performs the blending of the two particles directly in the shader. This tends to reduce the amount of frame buffer reads we do (as we now only have to blend one particle) but it can also increase it (if the single particle covers much more area than the union of the two original particles).

My original intent was to categorize all these items in terms of what they were saving (overdraw, fillrate, ROP, pixelshader ALU, etc.) but it was a little bit more effort than I had time for to create the 2D matrix of feature vs. savings this would create. Hopefully it’s still clear what each bulletpoint-ed task would achieve.

All in all, the above’s a long list, but I’m sure I left something out, so please comment. Also, what’s your favorite “trick?”

介绍退化三角形

http://www.cppblog.com/lovedday/archive/2008/03/02/43557.html

三角网格（2）
三角带
三角带是一个三角形列表，其中每个三角形都与前一个三角形共享一边，图14.2显示了一个三角带的例子。
注意顶点列出的顺序使得每三个连续的点都能构成一个三角形。例如：
（1）顶点1、2、3构成第一个三角形。
（2）顶点2、3、4构成第二个三角形。
（3）顶点3、4、5构成第三个三角形。
在图14.2中，顶点以构成三角形带的顺序编号。"索引"信息不再需要，因为顶点顺序已经隐式定义了三角形。通常，列表前部有顶点数目，或末尾处有一特殊码表示"列表结束"。
注意到，顶点顺序在顺指针和逆时针间不断变换（见图14.3）。某些平台上，需要指出第一个三角形的顶点顺序，而有些平台上顺序是固定的。
最佳情况下，三角带可用n+2个顶点存储n个面。n很大时，每个三角形平均发送一个顶点，遗憾的是，这只是最佳情况。实践中，很多网格是一个三角形带无法表达的，不仅如此，3个以上三角形共享的顶点还是要多次发送给图形卡。从另一方面说，每个三角形至少要发送一个顶点。但在顶点缓存机制中，有可能将每个三角形发送的顶点数降到一个以下。当然，顶点缓存需要额外的簿记信息（索引和缓存管理数据），可是尽管这些额外信息对单个顶点来讲相对较大，操作速度也会相对下降，但发送顶点数最少的系统在特定平台上速度最快。
假设用一种生成三角带的直接方法，用三角带表示三角网需要的顶点数为t+2s，t为三角形数目，s为三角带数目。每个三角带的第一个三角形对应三个顶点，以后每个三角形对应一顶点。因为我们希望最小化发往图形卡的顶点数，所以三角带的数目应尽可能少，即三角带越长越好。STRIPE方法给出了一种三角带数目接近理论下限的生成手段。
另一个希望减少三角形带数目的原因在于建立各三角形需要额外时间。从另一方面说，分别渲染两个长为n的三角带所需时间长于渲染一个长为2n的三角带，即使这个三角带中的三角形数多于两个分开带中三角形数量的和。于是，我们经常通过使用退化三角形连接多个三角带，从而将整个网格置于一个连续的三角带中，退化的意思是面积为0。图14.4显示了如何重复顶点以将两个三角形合并为一个。
图14.4的含义不太明显，但这里有四个退化三角形用于连接两个三角带从而维持正确的顺指针、逆时针顺序。顶点7、8间的边实际包含两个退化三角形，图14.5指出了图14.4中包含的三角形。
退化三角形面积为0不需要渲染，所以不会影响效率。实际上要发送到图形卡的顶点仍然只是第一列的顶点：
1，2，3，4，5，6，7，8，9，10，11，12，13
这符合我们每三个连续顶点表示一个三角形的约定。
一些硬件（如PS2上的GS）可以跳过三角带中的三角形，方法是通过一个顶点上的标志位指出"不必绘制"此三角形。这给我们一种方法可以有效的从任意点开始新三角形带而不必重复顶点或使用退化三角形。例如，图14.4中的两个三角带可以如图14.6那样连接，其中灰色表示顶点被标记"不必绘制"。

三角扇
三角扇和三角带类似，但不如三角带灵活，所以很少使用。图14.7所示即为三角扇。
三角扇使用n+2个顶点存储n个面，和三角带相同。但是，第一个顶点必须为所有三角形共享，所以实践中不太经常能找到大型三角扇应用的场合。并且，三角扇不能像三角带那样连接。所以，三角扇只能在特殊场合应用，对一般应用来说，三角带更灵活。

本文链接

为啥网游开发有钱途

2011-08-28T06:00:00Z

网游不是普通民工干的活！！！

http://www.kunli.info/2009/12/27/why-netgame-is-promising/

因为网游开发的高手需要很好的系统编程思维，算法素养和性能分析能力。下面这个图是ACM Communication一篇谈USC CS系课程改革文章中来的。也就是说，国外已经有一流大学专门针对游戏开发而调整整个CS department的课程作为试点试验了。

这个图说明了三点

1 网游开发，如果想往架构走，不容易，需要多方面的知识。

2 管理网游开发的团队也不容易，因为你面对的是multi-discipline interaction的挑战

2 越不容易的东西越赚钱。所以认真学习网游开发是很有钱途的

当然这个图也是着眼与网络游戏开发的朋友学习的方向。总之很全很强大的一副图，值得参考

本文链接

每天30分钟搞Software Rendering--(0)搜集资料，阅读,了解

2011-07-28T16:22:00Z

不学这个实在不行啊！不能这么糊里糊涂地过日子！知其然不知其所以然！有木有！写blog的目的也就是让自己能坚持下去！就从这炎热的夏夜开始吧！

http://en.wikipedia.org/wiki/Software_rendering

Software rendering

In the context of rendering (computer graphics), software rendering refers to a rendering process that is unaided by any specialized graphics hardware, such as a graphics card. The rendering takes place entirely in the CPU. Rendering everything with the (general-purpose) CPU has the main advantage that it is not restricted to the (limited) capabilities of graphics hardware.

Software rendering can be split into two main categories: real-time rendering, and offline rendering. Real-time rendering is used to interactively render a scene, like in 3D computer games, and generally each frame must be rendered in a few miliseconds. Offline rendering is used to create realistic images and movies, where each frame can take hours or days to complete.

下面是puzzy3d的文章，大牛啊！受益匪浅！敬礼！

http://blog.csdn.net/puzzy3d/article/details/2709612

softcore -- CPU rasterization

回到20世纪90年代，PC上进入3D图形硬件光栅化时代。VOODOO取代了CPU 光栅化渲染。随后出现NVIDIA TNT。直到GEFORCE将3DFX吞并。现在GPU的演变已经8年，基于屏幕上每个象素的复杂计算已经可以让老shader程序员忽略C和HLSL的区别。

在下一代mmo 3d引擎工具平台开发之前，有必要重新回到GPU内部，关注几何与光栅管道。越来越复杂的shader效果一切均基于光栅器的运作机理。把工作从GPU搬回CPU目的为使图形开发人员打捞图形学基础，在次世代开发中更好的运用GPU功能。

softcore 是一个软件光栅器。用于从场景物体的geometry transform, clipping,lighting, texture mapping, gouraud shading，到最后光栅化显示的整个图形处理管道技术演示。此项目为了保持代码清晰，省略了所有优化。只在可以使用SIMD和MULTITHREAD的步骤做出了标记。为了便于学习，project整合了id software doom3 sdk中SIMD和数学库代码。

由于是两个星期业余时间制作，时间有限，主要目的在于演示3D加速核心算法，光栅化部分的tc，color数值计算和sampler部分仍然需要进一步tunning。需要去除溢出和浮点转整数规则调整。这些可由感兴趣人员自行修改。

softcore project

done:

* CPU soft rasterization

* Z-buffer

* Gouraud Shading

* Perspective Correct Texturemapping

* Near plane Clipping

* Back face culling(geometry)

* Directional lighting

not do:

x Phong shading/bump mapping

x Bilinear filter

x Mipmap

x Dynamic lightmap

x Vertex color export/import

x Optimization

以下是3DSMAX中场景原图。有了硬件BILINEAR效果还是不一样.....

多数初学者往往陷入3D API细节。认为绘制带有各种效果的三角形就是在做引擎。或者疲于把各种NV SDK或者D3D SDK的sample code加入自己的工程。当然，用orge3d这样的开源渲染器也可以做出《天龙八部》，《巨人》等商业产品，不过，想快速开发符合要求的次世代渲染器，需要大量实际工程方面的工作。针对范围很狭窄的渲染器而言，对渲染效果质量的调整，以及自行开发美术需要的效果，不是照抄fx composer或者render monkey那么简单。由于对GPU工作原理认识不深，对某些效果优化实现背后的理论基础认识不深，都会直接带来在实际工程中开发的障碍。或者导致质量下降。

按说做为图形程序员应该对3D光栅渲染的整条流水线做到倒背如流。不过3D硬件厂商加速了应用的进程。使得在屏幕上绘制三角形这件工作变得容易。也许会忽略人们对实时三维渲染的系统知识体系建立。在高级图形渲染逐渐进入更复杂光照，全局光，基于物理或模拟基于物理的技术层面之后，不对GPU工作机理做到透彻了解，在工作中会举步为艰。因为所有渲染工作逐渐移到GPU寄存器中用可编程代码进行。整条管道，从Geometry transform，clipping，vertex lighting，到pixel的shading都由程序员控制。但GPU仍然自动进行了screen space的一些工作。包括clipping，扫描线线性插值,texture sampler等。这是光栅器能够数百倍快于raytracing渲染的本质。但如果图形程序员不了解被GPU自动进行的工作，也会象C++程序员不了解缺省构造函数一样盲目。

举例，众所周知普通的shadowmap 完全不具备工程实用性。最重要的是因为出于内存限制，shadowmap texture尺寸不可能满足实际渲染精度需要。并且收到三角形在camera space中斜率影响巨大。Depth Bias问题的本质是什么。与何参数相关。目前采用的各种调节depthmap渲染精度的方法背后理论依据是什么。Perspective shadowmap，light space shadowmap等各自优化方法会遇到什么问题，各自优缺点，以及工程中如何tunning，尤其用于self-shadow的问题。基于PCF(percentage closer filter）的各种软阴影算法的应用。

在对bumpmap技术改进过程中，在tangent space使用ray-tracing的reliefmap以及relaxed cone stepping relief map，以及带有凹凸轮廓的releif map技术。以及parallax map，和其变种dynamic parallax occlusion map。如何在pixel级别用bilinear gouraud 和这些象素级别lighting进行LOD，如何改进parallax map随视角变化而产生纹理浮动的问题，如何调整线性迭代和2分查找对效率和效果的影响。甚至从本质上了解tangent space，phong shading，都要从软件光栅机理开始。

softcore -- CPU rasterization Demo&Src from H3D

http://www.horizon3d.com.cn/news.asp

vc7.1的 MFC project

像素的buffer使用了D3D9的frame buffer surface。主要是为了以后CPU/GPU共同光栅化/raytracing 混合渲染实验的方便

目前只支持透视校正纹理映射的三角形光栅器
只简单的支持3DS文件

图片支持使用ALT的 CImage
没有做任何优化...

代码花了两个星期的晚上。技术细节有空再写

集成了ID SOFTWARE 公司DOOM3 SDK中 idlib 代码

如果有人有兴趣把SIMD优化加上，我再弄个SVN吧.....

【熊猫注：要理解这些东西，买书找补是必不可缺的，大学里没好好学习，现在该补上了！！！那时感觉用不上，实在学不下去，没人指点，迷茫啊！总是要跟具体的需要结合起来才有兴趣和动力去学习！】

几本3D编程相关的书

《3D游戏编程大师技巧》是一本好书,宏篇巨著。所有的核心原理都掰得很碎。从理论证明到代码实现全部细致周详。而且有中文版。英文是《trick of 3d game programming gurus - advanced 3d graphics and resterization》。内容涵盖广泛。在900多页想把游戏编程，高级计算机图形学，光栅化原理和实现，线性代数与解析几何都讲清楚，野心非凡。当时邮电出版社要我翻译时，由于精力有限，这本书的厚度和广度让人望而却步。所以选了GPU GEMS来翻译。当时GPU的发展正在如火如荼，3D硬件从简单的光栅化处理器发展为可编程的专用处理器。但这本书则专门介绍3D的软件实现。和当时的趋势有些背道而驰。不过现在翻了下。感到在使用D3D GL API做硬件3D绘图之前，把光栅化所有原理和背后理论体系都搞清楚，将会使学习和开发进度成倍。涉及高级shader的技术也会进展迅速。大学本科的计算机图形学是门初级入门课程。只能概要的建立一个知识框架。在应用技术方面，想在图形技术领域有所收获，要往里填补的理论知识很多。读过这本书，比较强的感受是如果从一开始建立比较牢固的理论体系，之后的技术研发速度会很快。实时三维图形学只是一个旁支。图形学理论知识体系对它非常重要。想要更好的利用不断发展的GPU，对GPU工作原理，光栅化过程，背后的数学知识，都有深入了解的必要。这几年工作中，体会加深。最近偶然翻到《数值分析》对常微分方程的数值解法，这是物理引擎的积分求解理论基础。大学都教授的这门课程忘差不多了。看siggraph创立physics based modeling的paper时感到吃力。用GPU在shader里使用欧拉积分做布料也是一种很简化的数值计算方法。在书店找到几本计算几何学。是物理引擎碰撞部分的理论基础。另外物理引擎涉及到的一块是理论力学的刚体动力学部分。具体计算还要使用LCP（线性互补问题）的解法。涉及到软体的物理模拟情况就更复杂一些。感觉短时间是不太容易都找补全。用一用商业的AGEIA物理引擎可能只需要高中的数学勉强就够了。不过真要做一套，没有一些数学底子还是很困难的一件事。传闻盛大的疯狂赛车根本没用物理。当然，当初的玛利奥赛车也不用。所以说游戏制作是个很玄妙的事。。。和技术似有关似无关。。。。。。《3D游戏编程大师技巧》的作者是个非常专业的技术人员。并且在介绍技术时，对重要的原理和公式都有推导和论证的过程。这样的作法在技术应用书籍里其实很少。多数初等技术书籍都在讲述一个API有几个参数每个参数什么意思。这本书实际在用CPU实现一个简化GPU。作者一看就是对3D RENDERING和游戏编程每个细节都有大量实践。所以从理论知识到技术实现细节，包括优化，讲解很通透。做为大学游戏专业的教材是最适合不过。

在查阅书中用到的数学公式时，发现另外一个堪比《REALTIME RENDERING》的经典书籍：《Mathematics.for.3D.Game.Programming.and.Computer.Graphics》。这本书比《3D ENGINE DESIGN》要平易近人得多。本着实用的角度，用浅显易懂的描述语言对游戏和计算机图形学用到的数学知识一一进行讲解和证明。比起另外一本经典著作《3D ENGINE DESIGN》，其作者是个博士，全书都用教科书般精确简练的数学语言描述3D引擎理论体系，对没有受过专门数学训练的人读起来都是颇为吃力。《MATH FOR 3D GAME AND CG》则是从实际工程技术角度出发，用高中数学课本形式的语言详细介绍了3D图形编程中所用到的数学知识，同时还保持了广度和深度。同样类型的书籍还有《PHYSICS BASED RENDERING》和《PHYSICS BASED ANIMATION》。当然知识体系更深入。

看全局光照时，PRT着实让数学不好的人头大。手头必须常备微积分，微分方程，概率学，傅里叶变换等一些书籍。残缺不全的知识体系很挠头。这是任凭多少技术实践也无法倒推补全的。中间发现一套非常好的微积分教程。俄国菲赫金哥尔茨的《微积分学教程》全3卷。我感觉大学要是用这个当教材我现在的日子还能过得稍微舒服一点点。

【熊猫注：说到书，索性再粘贴一篇，方便经常温习！貌似对《Head First Design Patterns》推崇备至啊，好好读读！】

书
最近买了不少游戏编程相关的书，十分应景儿。只要愿意等，甚至省却了海外用美元购买的麻烦。祖国劳动人民群众玩游戏的设备走在世界风潮脚后跟，技术该前该后，有待商榷。况且游戏好坏，技术的侧重点并不在新。最重要的是，中文阅读技术书籍，感官体验甚好。
对并行程序，《并行设计模式》，《WIN32多线程编程》，《并行程序设计》，《WINDOS系统编程》（Johnson M.Hart) 介绍的比较好。尤其《并行设计模式》，犹如《设计模式》于OO。INTEL的《多核程序设计技术》也还可以，不过做为面向工程的一本书，略显松散，不少地方潜尝而止。也许和翻译也有关系。翻译有时走偏。
虽说网络盗版为常态，但电脑阅读质量比较低。面试时问到哪本书是“网上找来看了一下”，基本可认为没读。不过有本《C++ 面向对象多线程编程》没的买，里面包罗万象讲了从多态，组件，死锁，到封装并行编程所需的对象和框架。甚是奇怪。总之给人一种云山雾罩的错觉。搞不清是讲C++还是组件还是并行编程还是什么。网上有评是垃圾。外来书也有垃圾，外国人也有江湖道士。中国早期跑江湖的都被希望出版社搜罗去了。这作者不会和希望出版社有什么瓜葛吧。
《GPU GEMS2》以闪电速度翻译完，被清华出版社压了好一阵才出来。翻译质量不错。令人欣喜的邮电出版社出了《GAME PROGRAMMING 5》和6 。发现其非常务实的把GRAPHIC篇章让给了SHADERXn(1<=n<=6) 和GPU GEMSn(1<=n<=3)系列（当然投稿质量也下降了），不再有大篇幅的图形技术。在游戏编程各个部分都有涉及。 GEMS6 开篇就讲了一下无锁编程。然后是OPENMP 使用。GPG系列总能让人闻到当前GAME TECH的味道。
清华出版社的东西良莠不齐。远远不在机械出版社，电子工业出版社一个层次。所谓《3D游戏开发大全（高级篇）》，其实就是TORQUE SCRIPT使用手册，充满了江湖术士混吃混喝的味道。做为实现自己引擎的脚本系统接口参考可能有用。。。
INTEL《多核技术》的另外一本《软件优化技术》非常过瘾。从软到硬的各个层面介绍软件性能解决手段的问题。由创造技术的人讲解技术意义非凡。
最有趣的和值得推荐的书要数这个： <HEAD FIRST 设计模式 >

从来没有一本DESIGN PATTERN的书这么牛逼的深入浅出的讲解了“封装变化”这一精要。而不是永远腻歪在教科书的“多态”“继承”那些傻乎乎词汇上解释。用C++写游戏的程序员真该多读几遍《DESIGN PATTERNS》。很多熟练使用C++技法的游戏程序也许不是应对变化的基础上编程，制造灾难。书店里这本书被摆在角落，用塑料膜封上。很可惜。这样的优秀大作，当培训教材都能给游戏公司创造无尽财富。
要是一开始就有人拿几本书砸我（C++ PROGRAMMING LAUNGUAGE, C++ PRIMER, EFFECTIVE C++, DESIGN PATTERNS。。。），我相信能比现在早好几年写出不那么糟糕的代码。
其实光从C++无数暗礁爬出来混口饭就不容易。看看 EFECTIVE C++,MORE EFFECTIVE, EXCPETIONAL C++ MORE EXCEPTIONAL ,高质量C++ 那些成百上千的条目。我觉着那些写诸如《21日精通C++》的都该在封面上加一条“除非你丫智商250”。那些自己没有写过五万行C++代码的所谓“老师”，我觉着每天都在恶行不断。。。
计算机书可分两种，时髦的，和不时髦的。由时髦的技术评论家撰写的一般都是前者。他们能从长期观察中得到当前国情中，要糊口要发家，可是性格内向举止局促、内心桀骜可心态混乱的软件人员最缺什么。于是成为知名撰稿人。国外发PAPER多的，做成功项目知名的，发明技术研究科学的，是常发言的。国内因为自己没发展太多计算机相关的科学，也没什么技术，所以发言的以专注传道授业者多。当然和经济发达程度相关。月球都能去，我国科和技发达也是早晚的事。这个不急，还是猪肉要紧。所以《软件架构设计》由《程序员》撰稿人来写，很符合国情。标题很好很强大。我买了。期望对下一代引擎设计有帮助。起码，我要尝试让同事该知道这封面的标题是个很时髦很有猪肉购买力的词汇。
以上黑体字书籍通读且牢记，理解且实践后，做为C++游戏程序工程师，本公司一定以国内高薪期权而聘用之。当然，话说回来了，国外国内上市游戏公司也应该不会拒之门外。。。

http://blog.csdn.net/puzzy3d/article/details/2613128
透视投影，与Z BUFFER求值

透视投影，与Z BUFFER求值         为什么有透视。因为眼球是个透镜。假如地球生物进化的都靠超声波探测空间，那也许眼睛就不会有变成球，而是其他形状... 为什么有人玩3D头晕？其中一个重要的作用是，眼球不完全是个透镜。所以当视野大于60度，屏幕四周投影的变形就比眼球投影视网膜利害多。而且人脑习惯了矫正眼球投影的信息。突然有个屏幕上粗糙的模拟眼球成像，大脑还真一时适应不了。
    Z BUFFER数值计算，以及PERSPECTIVE PROJECTION MATRIX设置，使用D3D或者OPENGL，可以直接让显卡完成这些工作。但是弄清Z BUFFER如何计算，以及PROJECT MATRIX的原理。对于进行各种高级图像处理，非常有用。例如shadowmap的应用。目前为了得到好的shadowmap，很多人在如何加大shadowmap精度做了很多努力（改变生成shadowmap时的perspective project matrix来生成精度更合理的shadowmap）。比如透视空间的perspective shadow map，light空间的Light-space perspective shadow，perspective shadowmap变种Trapezoidal shadow maps，改正交投影为对数参数投影的 Logarithmic Shadow Maps。另外，Doom3中shadow volume采用的无限远平面透视矩阵绘制stencil shadow volume。都需要对perspective projection有透彻了解。
以下描述z buffer计算以及perspective projection matrix原理。
假设坐标在 world space 是 Pw = {Xw,Yw,Zw}
经过camera space transform 得到 Pe = {Xe,Ye,Ze}
然后经过project transform 转为 device space，这里假设转为 Zp 范围 [-1,1]（OPENG的Z BUFFER）
Pe在near平面的投影为： Xep = n* Xe/(-Ze) (n为近平面到eye距离). 注意这里OPENGL 右手系camera space是Z轴负方向为眼睛看的方向。当计算投影时，x,y都应该除以一个正的数值。所以Ze取负。
这么做的目的是为了让在view space中所有在视锥平截体内的点，X数值投影到近平面上，都在near平面上的left到right。接下来是求最后在device space里x,y,z的数值，device space是坐标为-1到1的立方体。其中x/2+0.5,y/2+0.5 分别再乘以窗口长宽就是屏幕上像素的位置。那么屏幕这个像素的Z数值就可以按以下方法求出：需要把view space中(left,right,top,bottom,near,far)的frustum转换到长宽为(-1,1)的正方体内，就是说，把Xe,Ye,Ze都映射到[-1,1]的范围内。前面已经求出了Xe在camera space near平面上的投影Xep。这个投影的数值就是在frustum平截体near平面上的位置。把平截体near平面映射到-1,1的正方形很简单，X方向按如下映射： Xp = (Xep - left)2/(right-left) -1 。
当Xep在left到right变化时，Xp在-1到1变化。Xp就是Z BUFFER数值。因为显卡硬件(GPU)的扫描线差值都是透视矫正的，考虑投影后，顶点Xp和Yp都是 1/(-Ze) 的线性关系。那么在device单位立方体内，Zp 的范围在[-1,1]之间，Zp也就是Z BUFFER的数值。根据前面推导，要保证透视校正，Zp也是以1/(-Ze)的线性关系。即，总能找到一个公式，使得 Zp = A 1/(-Ze) + B。
也就是说，不管A和B是什么，在Z BUFFER中的数值，总是和物体顶点在camera space中的 -1/Ze 成线性的关系。我们要做的就是求A 和B。求A和B，我们利用以下条件：当Ze = far 时， Zp = 1 当Ze = near时，Zp = -1(在OPENGL下是这样。在D3D下是Zp =0) 这实际是个2元一次方程。有了两个已知解，可以求出A和B。OPENGL下， A ＝ 2nf/(f-n), B = (f+n)/(f-n)
这样一来，我们就知道Z BUFFER的数值如何求得。先把物体顶点世界坐标Pw变换到camera space中得到Pe。然后再经过透视投影变换，求得Ze->Zp的数值。把这个数值填入Z buffer，就是显卡用来比较哪个像素在前，哪个像素在后的依据了。这也就是为什么near和far设置不合适的时候，很容易发生z fighting。一般情况下，离屏幕很近的一段距离，已经用掉了90%的z 浮点精度。在用于渲染视角里中远距离的场景时，深度的判别只靠剩下的10％精度来进行。具体推导可以看看http://www.cs.kuleuven.ac.be/cwis/research/graphics/INFOTEC/viewing-in-3d/node8.html
逐渐被D3D抛弃的W BUFFER，场景远近与W数值是线性的。即，100米的距离，在near=1 far=101时，每一米在D3D W BUFFER的表示中，就是差不多 1/100 那么大。但是在Z BUFFER中就完全不是均匀分配。
下面考虑perspective projection matrix。根据线性代数原理，我们知道无法用一个3x3的matrix对顶点(x,y,z)进行透视映射。无法通过一个3X3的矩阵得到 x/z 的形式。进而引进齐次坐标矩阵－－－4x4 matrix。顶点坐标(x,y,z,w)。齐次坐标中，顶点（x, y, z, w）相当于(x/w, y/w, z/w, 1)。看到这个顶点坐标，我们会联想到前面我们最终求出的z buffer数值Zp和单位device space中的Xp坐标。利用矩阵乘法，可以得到一个矩阵Mp，使得(Xe,Ye,Ze,1)的顶点坐标转换为齐次坐标规一化后的 (Xp,Yp,Zp,1) 。即： Vp = Mp * Ve . Vp是单位设备坐标系的顶点坐标(Xp,Yp,Zp,1)。Ve是camera space顶点坐标(Xe,Ye,Ze,1)。
考虑 Xp = (Xep - left)2/(right-left) -1      (Xep = -n Xe/Ze) Yp = (Yep - left)2/(right-left) -1      (Yep = -n Ye/Ze) Zp = A* 1/Ze + B
为了得到4X4 MATRIX，我们需要把(Xp,Yp,Zp,1)转为齐次坐标 (-XpZe, -YpYe, -ZpZe, -Ze) 。然后由矩阵乘法公式和上面已知坐标，就可以得到PROJECTION MATRIX。
Xp(-Ze) = M0 M1 M2 M3                  Xe Yp(-Ze) = M4 M5 M6 M7        x         Ye Zp(-Ze) = M8 M9 M10 M11                 Ze -Ze    = M12 M13 M14 M15                   1
这里拿 M0, M1, M2, M3 的求解来举例： M0* Xe + M1* Ye + M2* Ze + M3= (-Ze)(-nXe/Ze-left )2/(right-left) +Ze M1 = 2n/(right-left) M2 = 0 M3 = (right+left)/(right-left) M4 = 0
最后得到Opengl 的 Perspective Projection Matrix:
[ 2n/(right-left)   0                                  (right+left)/(right-left)    0                            ] [ 0                 2near/(top-bottom)                (top+bottom)/(top-bottom)    0                            ] [ 0                 0                                  -(far+near)/(far-near)       -2farnear/(far-near)        ] [ 0                 0                                  -1                           0                            ]
D3D 的左手系透视投影矩阵和OPENGL有以下区别。 1， D3D device space 不是个立方体，是个扁盒子。z的区间只有[0,1] 。x,y区间还是[-1,1] 2，D3D的camera space Z轴朝向正方向，计算camera space中投影时不用 Xep = nXe/(-Ze)，而是 Xep = n*Xe/Ze 3，D3D中，从camera space的视椎平截体到device space的单位体（扁盒子）摄影，采用了很奇怪的作法。把frustum右上角映射为device单位体的(0,0,0)位置
请RE D3D PERSPECTIVE PROJECTION MATRIX推导过程~
后面若有时间继续透视校正texture mapping，phong shading以及bump mapping等per-pixel processing光栅化

本文链接

如何学好游戏3D引擎编程

2011-05-07T15:07:00Z

http://www.opengpu.org/forum.php?mod=viewthread&tid=2202&extra=page%3D1

《如何学好游戏3D引擎编程》
此篇文章献给那些为了游戏编程不怕困难的热血青年，它的神秘要我永远不间断的去挑战自我，超越自我，这样才能攀登到游戏技术的最高峰
——阿哲VS自己 QQ79134054多希望大家一起交流与沟通

这篇文章是我一年半前，找工作时候写的，那时是发到学校的BBS上。现在我工作了，想法和以前也有不同，但对游戏引擎编程理念还是基本差不多。在我没遇到U3以前，一直研究WILDMAGIC，可以说是GAMEBRYO的前身吧，他们基本框架都差不多，是完全面向对象，代码容易读，但它发展存在严重的弊端，这个也是它为什么不是牛B引擎的原因。但从渲染和动画方面来看，U3的 MATERIAL TREE 和 ANIM TREEE 是2个飞跃的，当我对我自己引擎渲染材质和光照一筹莫展的时候，MATERIAL TREE带来的希望。对比 zfx (wildmagic)gamebryo 和ogre 还有U3，各有优缺点，而且你可以看到一个引擎发展，从一个以多边形为渲染单元，变成以mesh做为渲染单元（现在很少有引擎场景管理分割多边形来做的我始终喜欢zfx引擎，它是00-02之间的引擎，完全让你可以理解那时候显卡不是很强的时候，一个引擎应该具备的特征。对于架构来讲，(wildmagic)gamebryo 和ogre 做的很好，u3的特点就是架构乱，没有什么可读性的技术文档，研究起来十分吃力。做为一个商业引擎，对于渲染方面，我认为(wildmagic)gamebryo 输给了ogre，框架设计还有弊端，ogre确实是一个好引擎。而U3对于渲染过程，光照，阴影，就是一帧的渲染过程，处理的十分得当。动态生成shader是一个引擎的发展的必然趋势，而往往动态生成最多的，也就是材质和光照，它们不能分开，分开谈无意义，MATERIAL TREE 我始终认为是个太好的想法了，任何特效不需要程序员过多参与，美术可以搞定一切，什么水，反射，折射，这些效果，编写起来易如反掌，还可以实时光看效果。其他动态生成，也就是根据配置不同，来做处理，动态编译shader弊端太大，不能做到所有，而且不灵活，如果动态生成和动态编译合起来，简直牛B透顶了。现在我的引擎已经有了MATERIAL TREE这个功能，ANIM TREEE在制作中。
这里面我重点谈的是图形方面，略带些动画方面，一个引擎最基本的是内核，包含内存管理，文件读写，资源管理等等吧，也十分重要，我的引擎这些写的都很简单,基本都是wildmagic里面的。
我总结3D引擎编程的4个阶段
第一阶段是了解3D原理和数学基础，大学里面学的线性代数，概率统计和高等数学完全足够，在3D中都有充分体现。最好自己能做一个软引擎，这样整个3D流水线自己完全可以掌控，然后在学DX之类的API很容易。
第二阶段不要看引擎，还是应该以实现各种效果和基本算法为基础，包括各种图形特效，场景管理，剪裁算法，各种动画算法，等等，所有那些单一的算法，如果这些都不是了解很好，那么做引擎时引擎框架的接口也不会设计好！再添加这些算法和效果时会很困难，效率也不会很高。
第三阶段，就是看大量的引擎，对引擎有很深刻的概念，3D引擎只是引擎的一部分，引擎主要是框架，如果框架搭建好了，那么引擎的效率是很显著的，其他底层细节优化，也会有明显的优势体现。
第四阶段，再好的引擎没有成功的游戏支撑都是白费，你不仅仅是做引擎，而是做的有开发价值的引擎，可以很好的为游戏服务的引擎。
下面这段话写于一年半前～～

前言
本人不才，姑且以自己经验来谈如何学游戏编程，这个话题我酝酿了很久，它确实很难写，因为我也不是资深高手，才刚刚登堂入室，游戏编程大师功力一般都十几年左右，所以让我这样的小卒写的深入浅出更何谈容易，错误出现并不奇怪，高手见笑也在所难免，请大家指正，我会欣然笑纳。但这几年走过的路，让我知道这么学是正确的，大体过程经验告诉我，这样做是对的，高手的指引告诉我，这样做是对的。
这篇文章主要讨论如何学习游戏图形编程和游戏引擎编程，告诉没有接触游戏过编程或者现在关于怎么学好游戏编程还迷惑的PEOPLE所要走的方向，完全抛开技术和代码实现进行谈论。至于游戏逻辑这几年重点没有发到这个上面上，很难总结。
经验的限制，对于如何编写一个好的引擎（至于“好”这个词都是相对而言，能做的满意就是我所期望的），至今为止我还没有这个能力，但我相信经过我的努力，不久的将来，我会实现这个愿望，因为我的一个愿望就是实现一个好的引擎。

我从下面几个方面来说明如果学习，记住只是如何学习，要想学好就要靠你自己。
1。你真的喜欢游戏编程吗？
2。要了解游戏编程
3。学会读书，自学与思考，交流与合作
4。游戏编程需要的基础知识
5。 2D游戏编程
6。 3D游戏编程
7。游戏引擎编程
8。浅谈游戏物理和AI

一。游戏编程，你真的爱她吗？
当你听完我的介绍后，你就要决定游戏编程是否适合你。
游戏编程可简单可复杂，简单的2D 《蛇吃豆》，复杂的现在流行的3D游戏。咱们不说简单的，因为你不想学习游戏编程就为了做一个简单的游戏。确实每个人对他所向往的东西都想彻底了解清楚，可是我给你的第一个警告，复杂的3D游戏，复杂到难以想象。

1 你思想需要改变吗？

打开话题，游戏是一个结合体，她是一个音乐，美术，技术，创意相结合的艺术品，你要用艺术的眼光去欣赏的，因为好的游戏是用艺术的眼光来设计，除了某国的网游不算外，很多经典的游戏流芳百世，成为真正游戏玩家佳话。
中国的游戏为什么这么落后，你要联想下，当年中国为什么会被八国联军所侵略。腐朽的思想是根本原因，从而导致了腐朽的社会制度。游戏行业也是这样，看待游戏的中国人，始终带着眼镜，用腐朽思想看待游戏，所以现在出现腐朽的游戏行业，导致中国游戏发展缓慢，有人曾经说中国游戏不久就赶超日本和美国，我认为是扯淡，而且不是一般的扯淡，具体原因后面我会详细说明。
从小的时候，国外的电子游戏产品就跑进了我的空间，废寝忘食的玩个没玩，因为耽误学习，从此电子游戏被老师和家长全部封杀，任何事物都有利有弊，鲁迅的《拿来主义》曾说过“去其糟粕，取其精华”。在中国，电子游戏被视为过街老鼠。确实要承认电子游戏有负面影响，但这些负面影响是谁产生的，本质上是我们自己，最后本来是精华的东西从我们身边擦肩而过，从小霸王以后的国外游戏机没有任何仿造，导致了游戏机技术从此断代，现在却又想起来赶超。
而现在，国人知道努力了，国家看到有钱可赚开始支持了，腐朽的游戏思想却还在蔓延，网络游戏就是这样环境下成长的新生儿，国内网络游戏每年要大批量生产，但存活的基本没几个。不能否定，没有利益的事情没人干，但你还不能否定，有些事情即使没有利益，但还是有人干，哪怕知道自己并不能得到什么。国内的人，很少是第2种人，他们把游戏做为赚钱工具，垃圾游戏隔三差五的纷纷涌出。相比来讲，我只拿日本举例子，虽然小日本和咱们有愁，但我们不得不承认小日本在游戏这方面思想层次完完全全超越我们，他们有严格游戏教育背景，他们做一款游戏，要按照严格的流程，从设计到编程，以至最后的测试，都有着干一行敬一行的精神，否则《生化危机》这样游戏你是永远看不到的。
所以你要改变自己的思想，游戏是一种艺术品，你要有一种艺术境界来去欣赏她。

2 你有毅力爱她爱到底吗？

也许我上面的话，你还能接受，残酷的在下面，以我的经验告诉我，如果你编程和游戏理论起步是零，你要对游戏编程达到略有小成的水平最少要4到5年，我比较蠢，花了6年。这6年来，几乎每天平均学习4-5个小时左右，当然假期都要算上。头3年半基本学习计算机基础知识，包括数学，数据结构，计算机体系结构，人工智能，汇编，编译原理，操作系统，网络，软件工程，离散数学，算法分析。我们大学4年基本就学这东西，这些都是基础，游戏编程都需要，还有一个就高等物理我没有学，导致我现在对于一些物理微积分方程很难理解，当然这里并不一定是问题，只要你肯努力，没有学不会的。完全把这些学好，花4年时间真的不容易。我曾经抱怨自己没保研而痛苦的经历考研，现在我却认为是值得的，我很难有时间在集中精力的复习这些专业课了，尤其是数学。
在游戏编程中，上面的基本知识都可以用到，所以我说游戏编程很复杂一点不假。就拿游戏中最难的部分——一个好的游戏引擎来说（这里说的好引擎），世界上能把她做出来的人很少，中国更是寥寥无几。
上面只是理论基础，要走进游戏编程最基本的。过硬的编程技能更是需要的，其实这些理论学习可以和编程相结合，在编程中学习理论，为了学习理论而增长编程经验。
有了基础，你才能进一步学习游戏编程，2D游戏和3D游戏理论都要学，这又要花费很长时间，这个是我下面要详细说的。
看完我写的，你可能心惊胆寒，所以你要爱她，深深的爱她，否则你承受痛苦的时候享受不到暗含的乐趣。

3 爱她请从游戏开始。

很多人可能不解，游戏编程为什么要从游戏开始，玩游戏时，有很多潜移默化的东西影响着我们编写游戏程序，很多灵感确实从游戏中得来。一般的游戏编程高手，都是从小由于游戏对他们巨大吸引，从而走上游戏道路，虽然不是绝对，但按统计学角度讲可以说是一个事实。一个不爱玩游戏的人，爱上游戏编程的几率是很小的。其实很多人小的时候都爱玩游戏，他们都是从游戏厅张大，只有一少部分，走向了游戏开发这个行业，他们之间有着明显不同，走向游戏开发的人，是真的被游戏背后那种神秘东西所吸引，并想要揭开它，而另一些人，则是完全迎合了游戏开发的需要——玩的高兴。
我想说的是，一个游戏编程高手，必定是一个游戏玩家，他们都是从玩游戏而爱上游戏，从而走上游戏编程道路。这条路充满了荆棘，不是一般人能走到最后的。所以你一定要爱她！
当然任何事情都不绝对的，你可能就是那不爱游戏但爱游戏编程（或者和游戏性无关的那部分编程）小概率的人。

二。游戏编程，你真的了解她吗？

游戏编程，这个概念包含了很多深层次的东西。

1.广义上，我给的定义是，游戏引擎开发和游戏逻辑开发。

游戏逻辑开发是集中力量只开发游戏中剧情部分，你只需要做的是什么时候显示什么，什么时候放出什么声音，什么时候通过网络传输什么数据，什么时候这个物体或者人物做什么动作。至于底层怎么显示，声音如何处理，网络如何传输，物体动作怎么实现的，你不用关心，关心这些的是游戏引擎。所以说游戏引擎负责技术方面，而游戏逻辑负责游戏文化内涵。
成功的游戏是以好的游戏逻辑为基础的，而游戏引擎并不是成功游戏主要条件，但好的游戏配上好的游戏引擎，确实会给人一种震撼，相比同样的游戏逻辑，好的游戏引擎显示效果会给人一种全新视觉和听觉感受。
至于游戏逻辑我不想过多解释，但并不是说游戏逻辑简单，游戏逻辑也可以复杂的要命，这取决与游戏复杂程度和游戏引擎与这个游戏的关联程度。为了解释这句话，我不得不从游戏引擎解释开始。
早期的游戏是没有游戏引擎这个概念，都是一个游戏一套代码，随着游戏越来越多，大家发现开发有些游戏中，有很多可重用的代码，逐渐把这些重用代码封状起来，这就是早期的引擎。对于引擎没有明确的概念，只有好坏和适应程度之分，所谓的好坏，就是引擎支持功能和显示特性等是否strong,而适应程度是指一个引擎是否适合开发这个游戏，开发这个游戏是否要自己再编写一些额外的代码。
我举个例子
如果我用开发混斗罗的引擎（假如它有引擎）来开发RPG，和开发RPG游戏的“RPG游戏开发大师”相比，我们还要做很多工作，才能完成玩法功能一样的游戏。
所以说很难有明确的界限划分这一堆代码是否是游戏引擎，但游戏引擎的任务是不用质疑的，它的任务就是尽量不用负责底层处理，而专心到游戏逻辑上来。

2.从狭义上分，我只分解游戏引擎部分，基本包括(1)游戏图形引擎(2)声音引擎(3)网络引擎(4)脚本引擎(5)GUI(6)人工智能引擎(7)物理引擎。

(6)(7)两个不是必须的，而前5个是一个好的游戏引擎要基本具备的，其实每个游戏引擎中都具备物理引擎，只不过很多游戏对于物理要求不是很高，所以就集成到了图形引擎中或者游戏逻辑中。
图形引擎是引擎中最难的，它基本要处理游戏引擎中70-80%的工作量，它的主要任务是负责图形高效显示，包括速度和精度。后面我会集中并详细解释。至于声音和网络引擎大家通过字面就可以知道它干什么。本人对声音处理和网络传输知道甚少，说出来只能误人子弟。

至于脚本我还略有研究，我想解释下什么是脚本，游戏中为什么用脚本。脚本有时很难给出一个定义，但大家都知道那些是脚本语言，我给出的解释是用软件CPU(虚拟CPU)来运行的编程语言就是脚本语言，软件CPU和所说硬件CPU是对立的，也就是说脚本运行与否先是关联到这个虚拟CPU，在虚拟CPU上运行，然后再又映射到真正CPU，来真正运行。这个过程很抽象，我觉2个例子，第一个就是JAVA语言，它有一个虚拟机，这个虚拟机就是软件CPU。再举一个例子，我现在要编写这样一个指令、
PRINT S  这个指令表示打印S
S代表一个万能类型。
为了实现这个指令，你首先要有一个函数来负责处理打印
比如是这样的函数
void print(S)
{
cout<<S;
}
这里只是伪代码，只是表示这个意思。
你首先要找出PRINT这个单词，读入到一个buffer1，然后把参数读入buffer2
if(buffer1 == PRINT)
  print(buffer2);
这里段代码其实就是一个软件CPU，它负责虚拟运行PRINT S  这个指令。

那么游戏中为什么要用脚本呢！最简单解释就是灵活性好。拿一个RPG游戏例子来说，游戏中有大量物品，每个物品有大量的属性，如果我把这些属性值直接写到游戏中，每一个小小的改变就要编译整个游戏，花费很多时间，灵活性很差。
如果我把这些写到一个文件中，用脚本语言来编辑，只需要编译脚本文件就可以了，当然如果你脚本是解释型的语言，不用编译直接可以运行。
当然脚本还有很多好处，主要目的还是方便性和灵活性。
其实GUI(图形用户接口)是一个重要部分。3D游戏中，出现的是大量的3D模型，这些模型是先用文件的形式存放好的，而文件里面包括的是3D数据和这些数据的组织方式。
至于数据怎么组织是你引擎要规定好的，这样也方便读取，最后把3D数据加载到内存。现在问题是3D数据上，我们怎么能有效的得到这些3D模型的数据，手工写进文本里？我靠，那是奴隶社会，SB的做法。我想你不会这么做。人类很聪明，这就是为什么人把其他动物关进笼子里，而不是其他动物把人关进笼子里的原因。既然我们很聪明，就要想一个办法快速的定义3D数据，然后保存成文件。这样一个3D编辑器就产生了。3D编辑器就是类似于3DMAX那种，但引擎中的编辑器是有特殊目的的，使用者要按照引擎指定要求编辑3D数据，这样引擎高效的显示和处理数据比较容易，至于3D数据是怎么组织的，是一个设计上的问题，由你引擎来决定，设计好坏，决定你引擎加载数据是否容易，关系到最后渲染。所以一般好的游戏引擎都有自己GUI，但你也可以用3DMAX这样的软件，然后读3DMAX文件变成自己可以利用的数据形式。
说到这里，不知道上面的概念大家是否理解，我想如果你没接触过引擎，可能真的不理解。其实我很难用简短的语言把这么复杂的问题说清楚，如果有一天你把3D学的融会贯通，你发现我说的是对的。我不知道大家是否发现一个共性的问题，有时你读一本书，无论你怎么认真把它看完一遍，你都很难掌握里面的知识，当你再认真看第二遍的时候，你突然觉得这本书没有第一次看那么晦涩难懂。有些知识都是前后呼应的，它们之间相互联系，要想完整的理解它们缺一不可。游戏编程的知识也是这样。我前面介绍的如果你看懂了，那你perfect，如果你没有看懂，也不要灰心，这里介绍的只是一个大纲，让你对游戏编程有一个了解，最基础层面的了解。

三。游戏编程，你准备好了吗？

这个部分讲解如果你想开始游戏编程应该具备那些基础知识，这样你才能接下来游戏编程学习，当然下面的有些知识，我开始学习游戏编程时，也不是都具备，但这些知识都是很容易学的知识，如果你基础好，在游戏编程中随时学就可以，不耽误你学习游戏编程的进度。我在这段最后会指出那些是必须掌握的，因为这些知识如果你在游戏编程时学习再学，时间上真的不允许。

1。书，永远是你的好朋友！
书，是你了解她最直接途径，当然我说的书还包括所有游戏编程资料。书，有好有坏，想要深刻了解她，你必须挑选精妙的好书，而且还有循序渐进的，合理次序的去读它们。游戏编程书籍大量风起云涌的出现是在2000年以后，当然2000以前也有，只是很少一部分，从2000或者以前开始就研究3D游戏的中国大哥们，现在可以说是现在中国游戏行业的鼎梁支柱。现在出版有关游戏方面的书籍大约有200左右本，中国人自己原著的书几乎没有，大多数都是翻译国外的，就有几本翻译的质量很好（翻译大哥大姐确实很辛苦，我承认这点，但拜托你们翻译前要看懂再翻译，否则望文生义，不如让我们自己看英文原版）要么自己写的也是东挪西凑的，写出来估计是想骗钱，谁叫中国人这么老实，这么好欺负了。其中大部分书籍是3D游戏的，3D游戏确实要比2D游戏难一个数量级别，如果你足够聪明，其实这些书看个几十本，写出一个在中国可以立足的3D引擎足够了。但好象这样聪明的人真的很少，有黄金的这个地方大家都知道，可是前往这块宝地的道路太荆棘，很少有人走下来。
书，大家从出生时就接触，学会读书，这四个字，很少有人能领会，你看一本书，要么否定，要么肯定，如果你还是很迷糊，要么是书写的不好，要么就是你知识水平层次有限，要么就是你根本没学会读书。我在这里只说一句话“要读好书，思而不学则罔，学而不思则怠，温故而知新”，我想高手很容易体会这句话。
想要学好游戏编程，学会读书是你要掌握的，也是你获取知识最快的途径，开始时，建议还是读一些中文的游戏编程书，因为游戏编程中充斥大量术语和名词，没有任何游戏编程概念的人，直接看英文，即使你是老外，我估计你看一会就会爬在书上，眼皮一关，口水把它淹没了。
看书后，代码一定要仔细读，而且对于初学者一定要亲自去实现，这样你才能加深理解，有时看书看不懂，一看代码就全明白了。“纸上得来终觉浅，觉知此事必躬行”，我始终坚信这句话，只有你经历了，你才能感受，就象你没有失去过，就不会知道珍惜是什么东西。
我相信既然你都看到这里了，就应该知道我上面为什么给你打好的警钟。看完书，就要写代码，最好不要一味的效仿，要有你自己的独道之处，这样才说明你认真考虑了这个问题，你也真正了解了，这个问题是什么，应该怎么解决，怎么解决最有效果。
E文书，以后就要是你老婆（同性恋除外），天天都要见面，除非你离婚了，也就是游戏编程这个爱情你不想要了，你提前离开了这个努力走到最后才能见到美好果实的幸福家庭。中文翻译一般都很慢，中文翻译出来，国外这个技术基本过时了，而且有能力翻译的人本来就少，有时间干这事的说他有病，也不足为奇，因为翻译一本太浪费时间了。所以要适应去看E文，现在没钱，就看电子的，很多国外新书，没有电子的，但电子的够我们初学的人玩很长时间，等有钱了，就直接去买国外正中的洋版，然后弄到家中，天天啃，工作时也啃，人家都会说你很有激情的。看电子的如果闲麻烦，就打印下来，打印下来还是花不了几个钢币的，和买一本中文差不多（大家不要哭穷，一本好书100元我认为很值得，里面技术如果你掌握了，你想想，大把大把的票子就进你口袋里，很多人买来不看，天天还抱怨书贵。）
这几年来，我读过很多游戏编程方面的书，中文的基本都读过了，现在我一直在读E文书，有时到觉得看中文有些不适应，还有好多好书，我还没有读。读E文书时，如果没读懂，自己一定要去网上查查相关资料，然后集中精力把它弄懂，现在很少有看不懂的E文游戏编程书（知道我6级没过的，别用砖仍我），有些还是看不懂，确实自己水平有限，但不是因为英语问题，关于高深而复杂数学问题，即使翻译成中文，我也很难看明白。
我在后面会把所有好的游戏编程书籍都列出来，告诉大家那些可以买到，那些只有电子的。不好的书，我就不列出来了，只会浪费大家以后的时间。
2。游戏编程所需要的基础知识

我这里介绍下要做一个好的，称职的，游戏程序员所需要。学习就和盖楼一样，要想上层建筑牢固，你就要有坚实的基础，我这里介绍的基础是你从事游戏编程最基础，基础的不能再基础的东西。
2。1 数学
数学是游戏中支柱，没有了它，任何都不要谈，在你编写你游戏的时候，你就会知道，世界抽象成一堆数学是多么的神奇，突然你会觉得以前枯燥无味的数学现在是一顿大餐，但这个是霸王餐。国外人写关于引擎方面书的人，都可以说是数学高手，他们理论和实践都很厉害，让我崇拜的不得了。大学里是你学好数学的最好机会，一定要弄明白它的现实意义，任何理论都不是凭空出来的，它一定有现实基础，这个现实基础，就可以帮助你很好理解这个理论。
2。1。1高等数学——微积分理论
在游戏引擎中，很多游戏特效都是通过微积分方程来解得的，高度仿真是现在游戏的追求，真实感越强就需要越多的计算量。极限，一元微积分，多元微积分，级数，微分方程等等在游戏图形图象和物理上都有明显体现。有时一个硕士或者一个博士为了拟真一个效果要花费几个月或者几年的时间，做为一个游戏程序员，微积分到达什么层次我很难给出定义，但起码如果别人给出了原理我们能看明白，并把它实现，我觉得就很可贵了。
2。1。2线性代数和空间解析几何
在大学课本中，空间解析几何是放在高等数学书里面讲的，但游戏中，它和线性代数放到一起我认为更加合适。线性代数所有知识都要掌握，在游戏中它们比微积分体现的更淋漓尽致，理解上我个人认为相对微积分更容易。
空间解析几何主要讲向量，平面，线，体，这些东西并通过线形代数矩阵进行空间变换，最后达到游戏想要的目标。
2。1。3四元数
这个在大学里面不学数学的，估计很少有人接触，它也是来用来变换空间，理解起来不是那么容易，但最常用的就是用四元数来表示旋转。
我这里只是一概而过，上面任何知识在游戏中都有应用，但大学里的数学不是为了游戏而开设的，所以和游戏中用的数学在知识分列和讲解上还是有很大差异，尤其是线性代数和空间解析几何，不用担心，我在后面介绍给大家一些好的游戏书籍，对大家学习游戏编程和有帮助的。
2。2语言
编写游戏c和c++是你首选，相对来讲C++是你更应该掌握的。
2。2。1 其他语言为什么不是当今流行的编写游戏程序语言？
VB，JAVA，C#，等等其他语言，并不是说它们不能做游戏，它们能做，由于语言本身设计机理的限制，只能做一些对游戏速度要求低的游戏，对于运行速度要求高的游戏，它们被判成死刑。当然这个也取决于硬件的发展，以前8bit FC游戏都用C语言和汇编来写，现在由于硬件速度提高，用VB，JAVA，C#来写这些游戏运行也是可以的，例如现在兴起的WebGame(网页游戏)。但如果你真想做游戏的话，你一定想要了解现在最流行游戏编写，C和C++是你最好的选择，也是你走上真正的游戏编程道路的重要武器。
2。2。2 C和C++应该选择那一个？
C和C++，这里面我还要说一说，我个人更看好C++。大家都知道C是面向过程的，而C++是面向对象的，虽然C++的面向对象特性还不是很完善，但出于对大型软件设计上的考虑，因为游戏引擎是大的工程，框架设计远远要比编程重要，一般框架设计用面向对象方式更直接，所以C++比C更有优越性性，而且如果你合理用好C++，并不见得C++比C速度慢。有时一个软件架构和软件运行上问题，很难取舍，对于大应用程序来说，都是一点点牺牲速度来获得好的架构，是利大于弊的事情，这里确实体现软件工程的重要性质。
2。3。3 汇编，很重要吗？
汇编语言也是你要掌握的，你说你语言学的好，但却不会汇编，是一个天大的笑话。现在很少有汇编高手能写出比编译器优化出来的汇编代码运行效率要高，因为语言的不同，思考问题的方式就会有不同，就象最早纸带机上的原语言一样（可计算性与计算复杂性就讲这东西）。如果游戏都用汇编来写，写代码效率很低，所以我们都用高级语言来写，同时还要与底层有密切联系的，C和C++担任大部分工作量。对于游戏速度频颈问题，有时我们用C和C++即使优化很多，代码精简很多，算法也改良很多，但由于语言本身设计上问题，和高效汇编来编写还是有不同的，这时就要是汇编高手来做速度最快，内存和寄存器使用最少汇编程序。所以汇编还是很重要的。
2。3。4 其他CPU硬件指令
这里只是说 INTER 和 AMD CPU 都支持的指令集，也是最常用指令集。
MMX和SSE SSE2是游戏编程中最常用的指令集，这个指令集是 SIMD（single instruction multiple data），也就是单指令多数据流指令集，一个指令可以处理多个数据流运算。汇编CPU指令，一个指令只能执行一个数据流运算。
例如：
汇编中
  ADD EAX，EBX
  这是一个加法指令，EAX，EBX是寄存器，是32位的。这个指令就是 EAX = EAX + EBX。这个过程只有一个数据流相加。
  而SIMD思想是，如果现在有2个指令
  ADD EAX，EBX
  ADD ECX，EDX
  能不能让他们一起执行？所以SIMD 指令提供这样的功能，他用很大的寄存器，前一部分装EAX值，后一部分装ECX值，再用一个寄存器，前一部分装EBX，后一部分装EDX.
  SIMD 寄存器分成2部分[1部分][2部分]
  SIMD ADD 指令  积存器1  ，积存器2
  运算过程为寄存器1 [1部分] = 寄存器1  [1部分] + 寄存器2  [1部分] ；
   寄存器1 [2部分] = 寄存器1  [2部分] + 寄存器2  [2部分] ；
  这2个运行是在一个SIMD积寄存器用硬件来执行ADD 同时运行的。
  这里只是说了SIMD思想，现在简单介绍下 MMX，SSE，SSE2。

  MMX寄存器是32位的，所以它可以执行4个8bit数据同时运算，也可以执行2个16bit数据同时运算，具体要看使用哪个指令，在早期没有SSE指令时，就用MMX，但MMX有缺点，它和FPU（浮点运算单元，专门执行浮点数运算）共用同样寄存器，所以当你指令有中断，从浮点运算跳到MMX运算，要告诉CPU，从MMX跳到FPU 也要告诉CPU，这样数据要临时保存，降低了处理速度。早期2D游戏经常用这个。
  现在SSE，SSE2有自己单独的寄存器可以使用，而且它们是128位的，支持4个32位整数或者浮点数同时运算。
  这些指令都没有分支，所以使用时效率要我们掌握，因为执行都是并行的，一个指令完成多个计算，所以即使你编写SIMD代码很差，速度也会提高几倍，游戏中经常用SIMD处理颜色和数学运算问题。在游戏速度瓶颈地方用这样的代码，公德无量。

2。3。5  ASM SHADER语言和高级SHADER 语言
开始学游戏编程时，这个知识不一定要具备，因为你不了解3D流水线内部细节学起来还是比较困难，所当你做完“软引擎” 了解3D流水线，在学这个语言很容易，接下来的语言发挥，就靠你自己了。
早期的游戏，所有的图形图象处理基本都由CPU来完成，然后把处理完的数据传到显存，用显卡来显示。现在的设计理念尽量解放CPU，把与图形图象有关的运算用显卡来完成。但早期显卡只支持固定流水线，所谓的固定流水线就是所有3D数据处理过程都是事先用硬件实现好的，这个过程是一个大过程，里面封状了很多小过程细节，用户只需要输入数据，显卡负责输出数据，至于用户无法干预这个大过程，小过程更是接触不到。再说的通俗一点，一个空间3D三角形要想显示到计算机屏幕上，基本要经历2个大过程，顶点处理和象素处理，顶点处理封状了很多空间变换的小过程，象素处理包括象素混合小过程。这个过程是不可以访问的，我们只能通过显卡提供的接口来控制，而且改变方式很单一。（刚接触这些可能不明白，现在你知道的不用太详细，就知道大过程是不可以干预的就可以了，或者是只有很少一部分可以干预）为了让图形图象处理更加完善话，让人们可以参与到整个3D流水线中，实现更多丰富的效果，显卡开始出现GPU单元（图形处理单元），这时的3D流水线从固定流水编成了可编程流水线，有了早期的GPU 指令，大家都称为 SHADER指令，也就是ASM SHADER，和汇编一样，这些指令都是和GPU指令一一对应的，随着硬件更新，GPU越来越强大，支持指令越来越多，ASM SHADER 从1。0 到 1。4 ，到现在3。0版本。由于ASM SHADER 用起来不方便，就象我们用汇编写程序一样，所以又出现了高级SHADER语言，有DirectX3D下支持HLSL（high level shader language）和 OPGL下支持的GLSL（opengl shader language）这些语言都是面向过程。由于硬件设计限制，这些语言不能象C语言那样随意使用，SHADER语言有自己的使用规范，大家学习时一定要弄明白3D流水线内部实现过程，再使用SHADER简直很容易。
还有一个要说的是，GPU现在还不支持分支预测，但GPU编程语言现在已经提供了丰富的条件判断，条件判断还是会影响到速度的。

重点你要掌握的是，数学，c和c++，汇编，数据结构，基本掌握的是计算机体系结构，离散数学，编译原理，计算机网络，操作系统，软件工程，数据库，人工智能。可以说这些是计算机最基础的学科，你只有掌握了它们，无论你专研计算机哪个领域，你的基础都是足够的，游戏编程中这些学科都可以用到，我们不用每个学科都精通的要命，我们要精通的是游戏编程，也就是接触到和游戏相关的，我们有这些基础完全可以看懂，然后我们在用自己时间来去专研这些学科在游戏领域的应用。

四。游戏编程，她的大门已经为你打开。

1。颜色之迷

计算机怎么显示图形的，这个你必须要弄明白，计算机显示彩色图象是经历了一个什么样的发展过程。
1。1 象素和屏幕显示点
计算机显示一个图象是由象素组成，我们通常说的分辨率就是屏幕上显示多少个象素。如果一个屏幕最大可以支持1024*768那么它也可以支持800*600，当你屏幕分辨率是800*600时，一个象素占据了屏幕多个屏幕显示点，也就是说，只有当你分辨率调节到最大时，屏幕显示点和象素点才是一一对应的，至于一个象素占据多个屏幕显示点后颜色怎么显示这个是硬件的事，我也不是很了解。象素都是2进制存储，然后由硬件根据显存中当前象素值，根据颜色显示模式的设定，来显示指定颜色。
1。2 颜色组成和模式
计算机要显示颜色，每个象素都有自己的颜色，通常颜色有3种模式，一个是调色板模式，一个是16bit模式，一个是32bit模式,我这里说的通常，早期也有4bit模式,我要讲出里面的细节，让看的人真正理解，不是死记硬背，你就会发现实质上只有2种模式，一个是调色版模式和bit显示模式。
我先介绍位显示模式，从4bit开始，早期颜色显示很单调，硬件只支持16个颜色，当然这16个可以是黑白的，也可以是彩色的。总之硬件就支持16个颜色。所以用4bit表示4bit 2进制正好可以代表16个。
随着硬件发展支持的颜色越来越多，发展到16bit，16bit开始有了严格限制，颜色是有三种色彩基元组成，也就是红绿蓝，人送江湖称号RGB，16bit分成1555格式和565格式，1555就是1位给ALPHA（表示透明）分给RGB分别5bit，5bit可以表示色彩基元颜色是32种，RGB组合起来就是15bit，就是2的15次方，可以表示很多颜色了。而565格式没有ALPHA位置，直接分给RGB位数为565，也就是绿色多了一位，传说中，专家说人眼对绿色明感，所以给绿色多分了一位。
而32bit分给 ALPHA 和 RGB 分别是 8888，每个都是8bit。
其实标准的颜色都是每个分量都是8bit，每个色彩基元都是256种，而16bit模式不能显示出真实世界色彩。
调色板模式一般都是针对每个分量是8bit，也就是颜色组成是32位的。调色板模式有一个映射表数组，这个映射表数组每个元素都存放的是32位的颜色，而显存存放的是一个索引，但硬件读出显存当前象素值时，然后用这个值当作索引去映射表数组里面查对应的颜色，然后显示到屏幕上。
相比较而言，调色板模式是最早期的，例如早期FC 8bit机每个象素只占8bit，只能表示256种颜色，而我们彩电可以表示很多颜色，为了节省显存，增加处理速度，还显示出多种颜色，FC用调色板模式，而我们想换颜色时，其实只换调色板映射表数组某一个值就可以了，索引都不用变，毕竟索引是写在显存中的，一般改写显存还是速度很慢的。16bit模式也是在处理速度上，节省存储空间上得以应用。毕竟这些显示模式都是为了应付以前硬件速度太慢而设计的，现在一般都用32bit模式。而且无论颜色基元的数字越大表示这个基元颜色越浅。
还有一个要说的就是ALPHA，这个分量是表示透明度的，这个分量如果是8bit，那么它可以表示256种透明程度，255表示不透明，0表示完全透明。
现在大家知道你设置屏幕或者游戏时1024*768*32 什么意思了吧！每个象素占32bit，屏幕显示1024*768个象素。

1。3 颜色的运算
计算机支持颜色运算都是无符号颜色运算，颜色没有负数，而且颜色运算有CLAMP和MOD
如果每个颜色占8bit，颜色表示范围为0-255
这里CLAMP指的是
if(x<0) x=0;
if(x>255) x=255;
这里MOD指
if(x>255) x = x%255;
Color1(a1,r1,g1,b1) Color2(a2,r2,g2,b2)
颜色加减都是向量加减，每个分量做加减
1。3。1颜色加法
      Color3(a3,r3,g3,b3) = Color1(a1,r1,g1,b1) + Color2(a2,r2,g2,b2)
a3 = a1 + a2;
r3 = r1 + r2;
      g3 = g1 + g2;
b3 = b1 + b2;
颜色加法一般都用CLAMP
1。3。2颜色乘法
Color3(a3,r3,g3,b3) = Color1(a1,r1,g1,b1) * Color2(a2,r2,g2,b2)
a3 = a1 * a2;
r3 = r1 * r2;
      g3 = g1 * g2;
b3 = b1 * b2;
颜色乘法一般都用MOD
颜色加法和乘法在象素混合效果上经常用，有时为了到达一个效果，加法和减法混合用，至于什么时候用加法，什么时候用乘法，没有严格的规定，还是要看效果，一般对于全局光照模型颜色之间要用加法的，但其他光照模型可能不同，纹理混合或者纹理和颜色混合，加法和乘法都有各自用途。

2。Directx OpenGL到底用来干什么？

这里只说他们支持图形和图象部分，其他部分不说。
很多人都听过这2个名词，其实他们是一个函数库，这个函数库为我们做了一些最基本的和底层打交道的处理，其他它们还提供了一些常用的3D函数库，算是一个2次开发，其实2次开发一般和底层没有关系，所以在游戏引擎中很多都自己来做，微软做了很多2次开发，可以算是一个引擎。我前面说了，引擎没有明确概念，只有适应程度之分，用它这个提供的来做游戏，还是差很远，做小游戏当然没问题。
我主要说说和底层打交道那部分，DX和OPGL最大功劳在于充分调度和发挥了显卡性能，把显卡的特性用接口的形式提供出来，他们各自都有自己的管理层次，管理方法，管理管线，至于怎么管理，我也不是很清楚，但当你使用和显卡资源相关的API时，你要仔细看这个函数各个参数说明，它会根据你的指定，来管理显卡。但他的管理只是一部分，还有很大一部分要引擎里面自己处理。
如果你不想自己写驱动的话，那么你还想控制显卡，你就要用这些API，D3D（DX中主要处理3D的）和OPGL使用上还是有很大不同，所以学习他们也还要花费一些时间。我当初学习时，由于不了解3D渲染流程，学起来特别困难，很难看懂，我就放弃了他的学习，学习制作“软引擎”（用CPU来实现显卡提供的硬件功能），然后再学D3D，很容易的。有时后放弃是为了选择更好的，并不是真正的放弃。
至于学习D3D还是OPGL，我个人认为无所谓的，但好象OPGL越更新越混乱，没有DX那么清晰，我也是听别人说的，毕竟我不是很了解OPGL。

3。游戏编程中的常用术语

游戏编程充着大量常用术语，我不打算把它们都列出来，实在太多，我想对于初学者是来说，我希望，你在学习游戏编程时，自己多查下资料究竟这些术语都有什么含义，记住一定在学习游戏编程时去查，也就是说，针对问题去查，而不是在没有遇到任何问题时去查。其实我们的教育有个弊端，任何知识我们学了，不知道怎么用。其实很多知识都是我们遇到问题时再去查资料，去找解决方式，而不是在不知道这个解决方式用来解决什么的情况下吓学。
最好大家把这些术语的中文和英文名称看见都能知道是怎么回事，因为你到以后看英文书时，如果你知道这个术语的含义，看起来会很容易。

五游戏编程中的2D游戏，你首先要做到的。

通往神殿的第一个考验就是这个，不知道你是否能走下来，相信自己会成功，你的信念一定要不可动摇，当你走过这段路的时候，想想你现在所得到的，付出的其实不算什么。
很多人可能会问，我想做3D游戏，2D游戏学它干什么。其实3D游戏处理可以分成2个部分，一个是3D空间数据处理，经过纹理映射把象素写到屏幕缓冲，接下来其他特效处理都是归结到2D问题。
所以你想真正了解游戏图象处理过程，还是要学2D的。2D原理相对3D来说简单很多，学起来也不是很难。我建议去看《WINDOWS游戏编程大师技巧》里面的代码都读明白，它用C语言实现一个小的游戏引擎，我希望你用C++封状成类的形式，重新按照自己规划来实现，最后做出个游戏。用引擎做出的游戏和直接做游戏还是有很大区别的，这样你引擎也就符合引擎的概念，代码重用性更强。这本书用的DirectX中DDraw接口来实现的，你一定要了解你使用的工具，它能用来干什么，它不能用来干什么，这样你才能很好的游戏编程。如果你不了解C语言，怎么用C语言编程，都是一个道理的。我不想在过多详细介绍DDraw为我们提供了什么特性，你自己去看书。
2D游戏中，最常用的概念就是贴图，把一个图象贴到另一个上。2D游戏中一种处理模式是在各个图片上的处理，还有就是在象素上的处理，其实这些都可以归结到象素上的处理，象素处理，就是处理显存数据。
颜色模式，《WINDOWS游戏编程大师技巧》这本书讲的很详细。
2D动画系统，《WINDOWS游戏编程大师技巧》这本书没有详细介绍，但你看它的代码，代码写的很清楚而详细，你就知道的。
GDI 我不知道大家听说过没有，它是WINDOW自带的图形图象接口，我希望大家也能了解下，当时我是GDI和DDRAW一起学的，然后分别做了引擎，2个引擎接口也一样，游戏移植非常容易。

一个最重要的问题就是调试，8BIT模式下的游戏，用编译器带的单步调式是不可能的，我机器死机N回。我现在也没有发现好的办法，最好的办法就是自己做一个LOG日志系统，把所有调式信息都写到文件里，用任务管理器把当前程序关掉，然后看文件写的信息。
2D游戏制作细节我没有详细介绍，毕竟我不是在讲怎么制作2D游戏，我是讲你应该注意什么，怎么学，我想《WINDOWS游戏编程大师技巧》会给你想要的一切。当然我在学这本书前已经有了一些2D游戏基础，以前用VB做过游戏，用GDI也做过，所以学起来还算容易，如果你以前没有任何游戏编程基础就直接用DDraw，那么我希望你多下点工夫，把它制作游戏的流程都搞清楚，记住什么时候用自己的双手做出了自己2D游戏，你才算2D游戏编程过关了。这本书仔细看吧！直到把它所有的精髓都掌握。
还有一个要说的就是，图象处理常用算法，大家可以多看看图象处理的书，游戏中特效经常用到，其实如果你真想一心搞3D，2D上做一个坦克大战这样的游戏就可以了，很多2D处理详细东西，在学3D游戏时，都可以接触的。
六。游戏编程中的3D游戏，考验你耐力和勇气的时候到了！

前面你所遇到的一切都是小小测试，证明你有能力接受这个挑战，在3D游戏这个广阔无垠的天地里，它比2D游戏更有让你想象余地的空间，因为3D游戏不仅仅包括2D游戏所有，而且还包括很多其他东西。努力吧！朋友们，无论遇到什么挫折，都不要放弃，因为她最后会给你想要的。
我不知道其他人学习3D游戏是一个什么样的过程，这里我只介绍我自己的学习过程，因为我是从挫败中走过来的。
开始学3D，脑袋里一片模糊，只有一点点大学里学的计算机图形学相关的知识，我不得不说学校里讲的计算机图形学和游戏还是大相径庭的。
（这里允许我抱怨一下，国外很多大学都开设了3D游戏编程的课程，而且很专业，我看过老外的PPT。相对于国内，也有些，但不专业，我说游戏学院骗钱你不要打我，它确实能让你找到工作，但你做的永远是下手，学不到底层的东西。我看过游戏学院开设的课程，没有一个是有技术含量的，用“外包”形容在贴切不过。道理也很简单，中国现在牛人很少，我说搞引擎的高手全国有1000人都是保守的，真正能搞出名堂的，也不多于200人，这200人里面学习游戏编程经验10年就很多了，中国3D游戏起步很晚，相对国外，中国人爱跳槽的习惯，让任何公司都没有技术积累，发展更是困难，所以人才积累的少，而且这些人都很忙，在加上现在学校教育约束，即使他们想去高校教授游戏课程也是不可能，何况人家都不愿意去，这样中国积累的人才更少）

所以你要系统学习游戏中图形学理论。
这里我经历了游戏学习编程一次比较大的挫败，当时自己是初学者，问过很多人学3D，应该从什么入手。很多人都说从D3D开始入手，于是我做了。我不得不说的是，如果你不了解3D流水线过程，学D3D简直是看天书，当时我以为自己反复的看书，写程序，最后会理解的，浪费了我大量的时间，最后还是无法灵活掌握D3D，如果你无法掌握D3D，想做游戏可能真的很困难。我终于认识到，我选择的路是错误的，那些所谓的高手难道就学D3D学过来的？那么他们花费的时间是可想而知的。因为有些细节你无法掌握，你使用时就觉得匪夷所思。
《3D游戏编程大师技巧》这本书是每个学3D的人都应该看的，这本书把显卡硬件实现的功能都用软件来做，真正让你理解一个3D东西到最后的屏幕显示，是一个什么样的过程。作者实现了一个软引擎，软引擎就是所有的3D功能都是用代码自己写的，没有用什么显卡来做处理的引擎。这本书是一个经典巨著，如果你想学3D，即使死也要把这本书弄明白，这样不辜负作者写这本书留下的汗水，写一本书，尤其这么PERFECT，太不容易了，国内人翻译的也很出色，感谢他们。

《3D游戏编程大师技巧》继承了《WINDOWS游戏编程大师技巧》里面2D函数，然后3D功能以及流水线和引擎都是自己完成，这本书的代码量要有十几万，我当时用C++重新封装了《3D游戏编程大师技巧》代码，自己设计了一个面向对象固定流水线模式，代码量13W左右，这个过程很艰辛，这本书我看了2遍，最后一共零零散散花费了大约9。10个月的时间。你会感觉你立刻升级了，HP，MP，CP都增长了，当然也包括RP，哈哈！（不知道这些术语的，大家多玩玩RPG游戏吧！）
好东西去追求，不要怕浪费时间，浪费精力，你想想，你得到的最后会大于你的付出，这些都不算什么。很多人问我怎么学3D，我建议他们不能着急，要从学《3D游戏编程大师技巧》开始，大约要8，9个月时间，把每个细节都弄明白，闭上眼睛，怎么实现就很清楚，书上每一页写什么都很明确。他们都觉得浪费时间，那么这样是永远学不好的

1 3D数学是你要攻克的
虽然你数学学的好，但国内的教科书还是和游戏中用的有些不同，毕竟没有上过专门讲解游戏中数学知识的课程。这需要你系统学习游戏编程中数学，3*3矩阵为什么有的人用，而有的人用4*4矩阵，为什么有的用矩阵转置有的用矩阵的逆。《3D游戏编程大师技巧》这本书介绍的很详细，还有一本书就是《3D数学基础：图形与游戏开发》很不错（有中文的），先系统学习下，然后在学习游戏编程时，不懂的时候，再回头看看这些书，把所有的东西都彻底弄清。你如果数学基础好，学这些都很容易，以后游戏编程中最深奥的地方之一就是数学。

基本上我总结下，你要知道的是：
向量  4维和 3维向量有什么不同
矩阵  4*4 和 3*3 矩阵有什么不同
四元数
ELUER角
以后有机会深入研究碰撞中的各种算法，还会遇到很多关于数学的问题，上面只是渲染有关系。
2 3D流水线的实现过程
我无法用言语来表明这个过程的重要性，整个3D流水线是是3D游戏的脊柱，你的基础知识牢固与否，主要看你这里。3D流水线每一个细节我希望大家都要搞清楚，这个过程对初学者是要花费大量的时间专研与琢磨，D3D的固定流水线都是由硬件完成，如果你的硬件不支持，它会用软件模拟，好，关键就在这里，软件模拟是怎么回事，而《3D游戏编程大师技巧》的流水线是自己用C语言写的，也就是用软件完成，这样你能了解整个流水线的细节，同时你在学D3D时，对照着来学，你会发现，D3D学起来很容易。现在D3D和硬件都支持可编程流水线，而且DX10没有固定流水线，所有变换过程都用SHADER语言控制显卡完成，这个过程是3D流水线的缩影，所以3D流水线的重要性是是可想而知的。
我说了这么多，3D流水线对你是一个新鲜的名词，我也没有去解释它，我不想去解释，完全留给你自己去，我始终坚持着，我只告诉你去的路，路上有什么困难，应该怎么走，你自己去体会这条路上的酸甜苦辣。我希望大家多花些时间在这上面，真真正正的自己写代码实现一下，基础对你真的很重要，记住我说的话，很多人学习时，认为自己理解了，没有去实现，其实还是那句话“纸上得来终觉浅，绝知此事必躬行”，相信我，没错的。
      基本上我总结下，你要知道的是：
3D中的顶点结构，每个分量都用来干什么，三角形是基本渲染单元。
模型空间——》世界空间——》相机空间——》投影空间——》屏幕空间——》光栅化这个过程和运行原理
材质究竟是什么？
      常用的宏光照模型原理，光源类型
光源和材质和法向量关系
光照在哪个空间去执行（其实不是很严格）
纹理寻址，纹理映射方式，纹理混合，纹理过滤。
1D 2D 3D CUBE 纹理
Z 1/Z缓冲
2种相机模型
ALPHA 透明
关于光栅化三角形要特别注意，他最后混合纹理和光照颜色和ALPHA透明，还要判断深度缓冲，最后是插值填写每个象素。
3 D3D究竟要如何学习
《3D游戏编程大师技巧》和D3D流水线过程还是有些差别的，比如在投影矩阵上，其实它们都是大同小异，只不过表现形式不同，原理都一样。我希望大家自己可以找出来，深刻理解里面原理。
还有一个重要的东西，就是哪些是D3D开发游戏必须有的，哪些是D3D自己扩展的。必须有的，就是同硬件打交道的部分，而D3D中自己扩展了很多库函数，例如数学库，这个完全可以没有，我们自己来实现，还有D3D中的EFFECT接口，它自己定义的。X文件所有函数接口。也就是说，你要理解，哪些是游戏开发中必须有的，哪些是游戏开发中自己完全可以不接触底层来实现的。
游戏编程中有3个缓冲区，颜色缓冲，深度缓冲，模板缓冲，前2个《3D游戏编程大师技巧》中，都详细的介绍，而模板对初学者可能很晦涩，大家先弄明白模板的机制，然后多看些例子，我想你会深刻理解它的含义的。
D3D的学习，可以看D3D SDK的例子，也可以找一些书籍，很多的。

基本上我总结下，你要知道的是：
D3D提供基本常用底层接口，那些是是D3D为了编程必须提供的，那些是不用提供的，比如数学库我们完全可以自己写。
D3D顶点索引BUFFER
颜色缓冲，模版缓冲，深度缓冲以及对这些缓冲的操作
目标渲染对象、
D3D 中的3D流水线
单通道渲染，多通道渲染。
熟练操作上面的所有，这些都足够了，其他的都是D3D中多余的，如果你要自己做引擎，很多都要自己实现，当然初学者可以就用它扩展的函数库，也很方便的。

4 其他要知道的游戏知识
下面知识都属于很强的游戏技术范畴，他们只属于单单游戏中技术支持，引擎就是用合理的方式，把所有3D相关包括流水线和下面这些都整和到一起，但这种整和是有效的管理。
场景管理算法：BSP OCTREE QUADTREE PORTAL PVS
动画系统：骨骼动画，蒙皮骨骼动画，渐变动画，和这些动画的混合
阴影  ：阴影体投影阴影阴影影射
剔除算法：包围球 OBB AABB BHV算法
LOD系统       ：视点无关LOD 视点相关LOD
广告牌  ：跟踪相机方向和只围绕y轴旋转粒子系统
这些是比较常用的，常常碰到的，根据基本的颜色运算，空间运算还能衍生出很多游戏特效，等待你自己去看书，去解决。

七。3D引擎编程，令你的挑战达到了极限
就象我前面说的，引擎没有严格定义划分，但对于当代的引擎，似乎大家都趋向于越好的东西，越健壮的支持，才称上引擎。现在游戏玩家对画面拟真程度要求很高，这就要求引擎能更好的处理3D世界中大量数据，一个好的引擎，起码要做到以下几点（引用《3D.Game.Engine.Architecture.Engineering.RealTime.Applications.with.Wild.Magic》里面的话）
1。如何把3D世界中大量数据，让它实时快速处理。
2。引擎中的渲染器（用来管理数据，进行渲染处理的）接口应该怎么定义。
3。如何让使用引擎的人，能很容易的使用引擎。
4。当引擎中添加新特性时，如果让引擎改动最小。
我感觉这4句话，概括的很精辟，如果让我来概括，好象我现在还没这个能力。这是一个当代引擎的新的定义，虽然不是全面，但它一语道破天机，如果你的引擎能达到上面4点，我想它已经足够的优秀，同时说明你也很优秀了。下面我就分别解刨这4句话，让大家对引擎有一个深刻的了解。我只是分析，这4句话要求高手才可以完全去达到，我现在还不具备这个能力，所以只能帮大家分析。
1。如何把3D世界中大量数据，让它实时快速处理。

3D世界中充满了大量得数据，有效的处理只可以看见的，能感受到的就可以了。
3D引擎中，很多时候都在处理剪裁和剔除的问题，把不可见的或者和碰撞无关的数据用最快的方法弄掉，不让它进入显卡，一切还是停留在3D空间中。剪裁，剔除还有碰撞处理，永远是3D引擎中最常见的话题，现在有很多成型的方法，大家自己通过学习就可以了解的。
2。引擎中的渲染器（用来管理数据，进行渲染处理的）接口应该怎么定义。
即使你把3D数据给了显卡，还是不能达到最快显示，我们要把这些数据分类，重新组织，这里面还涉及到存储管理的问题。你的渲染器的接口要定义的和底层提供的DX或者OPGL相通，因为最后你要调用的是这2个库里面的函数。

3。如何让使用引擎的人，能很容易的使用引擎。
这是一个经验问题，一个软件设计给用户使用，怎么让用户很容易上手。但无论什么样的用户，你必须对3D有了解才可以使用，否则神仙也没法完成这个引擎。
4。当引擎中添加新特性时，如果让引擎改动最小。

经常说的一句话就是“计划没有变化快”，怎么能让引擎跟上时代的步伐，当硬件有革新，我们引擎就有革新，出现新的处理方法，引擎也要改进，用户需求改变，引擎接口也要改变，我们要求引擎的所有改动最小，这样才是一个完美的引擎。
引擎是软件设计+算法+编程的结合体，难点在软件设计上，一个好的引擎，代码几百万很正常，没有一个好的设计来规范它们，混乱是不可避免的。

对于一个引擎，从设计到编程都很重要，一个人完成一个好的引擎是不可能的，多人协作来完成引擎，在大家相互配合的同时，每个人对自己的要完成的任务必须精通，还要有人协调这些工作。
好的引擎，要有一个抽象层次，然后是渲染API层次，还要支持多操作系统平台，我在这里没有过多介绍各种技术细节，因为很多细节在书中都可以找到，加上你的聪明，很多技术算法可以自己创造的。
对于游戏中大量算法，引擎中到处都是，碰撞，场景管理，光照，纹理混合，动画系统，粒子系统，内存管理，资源管理等等大家要多实践，多思考，多看书，多看资料，把握每一个细节，把握每一个整体。看书时要带着问题去看，同时也要带出问题，因为没有一个方法是完美的，必定会有或多或少的缺陷。

现在开源的引擎确实不少，其实程序员都有一个共性，看别人代码有时不如自己写，确实这样，有时只看代码去体会别人的思想真的很难，但有时为了去学习也要硬着头皮去看的，跟踪代码。开始时，如果你不了解引擎究竟是什么，这时最好集中看一个开源引擎，一定要把它的工作原理都弄明白，这样你会得到很大的提升，你就会明白引擎是什么，为什么不用D3D直接编写游戏，还有一点就是，有机会一定要去实现，这样你的体会会更深。

八浅谈物理与人工智能

这2个都不是中国游戏中的优势，它们和图形一样，要求一定能力积累才可以胜任。如果我没有预测的话，未来中国游戏中大量的需求将来自物理和人工智能，传统的网络RPG会慢慢不能满足大家需要，而被时代所抛弃的。

这2方面的编程我只是略知一二，还算一个小白，在此简单谈谈。
10。1 物理
游戏中大部分物理模拟都集中在力学和运动学上，本来它们就是一个整体。因为最后效果是大家看到的，而看到的都是物体在屏幕上的移动，所以所有的计算最终都归结到物体移动上。
因为游戏毕竟是游戏，人也毕竟是人，没有必要模拟的那么精确，同时人也是感觉不出来的。
所以要想做好物理上的编程，必须对力学和运动学有系统的了解，高中学的力学部分还不是很足够，对于旋转部分，也就是处理力矩和转动惯量上，高中物理书都没有讲（我那时是没有讲，而且很多直线线形运动方程推倒其实是用微积分推倒的，高中书上都没有明确推倒）
物理上的模拟也没有逃脱物理计算基本规则，先是受力分析，然后计算合力，计算加速度，计算速度，最后计算位置，也可能涉及到动能和动量等知识，还有些流体力学等等吧。
物理其实处理的问题基本就是检测物体碰撞，碰撞后的反映，物体运动情况。
至于理论，大家弄本大学物理，力学部分就足够，如果数学好的话加上高中的物理知识，应该学起来不难的。
《游戏开发物理学》这本书很好，可惜绝版了，但有电子版的，也有中文版。
10。2 AI
相对物理的编程书籍来说，AI的书很多。
AI是研究生必须学的课程，包括传统的AI和计算智能。游戏中常用的传统AI包括自动机理论，A* 算法，回溯，图搜索，剪枝等等吧。计算智能包括的是：遗传算法，模糊计算，人工神经网络。
我答UBI笔试的时候，里面很多题都是A*算法，可见FPS游戏中大量存在的都是AI的路径搜索问题，让电脑更加智能。

AI的游戏编程书很多，我就看过几本。《WINDOWS游戏编程》中有一部分讲的AI，《游戏开发中人工智能》《游戏编程中的人工智能技术》这3本都有中文的，而且都有大量的实例，对于那些大量理论的书籍来说，看看它们还是很通俗的。还有很多好书，都是英文的。

本文链接

用Ogre固定渲染管线实现火炬之光X-RAY效果

2011-05-07T03:26:00Z

转载的，感谢原作者

http://blog.csdn.net/qq18052887/archive/2011/04/15/6326700.aspx

用Ogre固定渲染管线实现火炬之光X-RAY效果

游戏的遮挡半透,一般2种方法,一种是天龙的那种,让遮挡的建筑物半透明,一种是火炬之光的这种,X射线

那种好?其实达到效果都行,

火炬之光不能用第一种,因为他的模型都是很大很大的,建筑一透,全透了,很多地方可能还会穿帮,

我的游戏一直用的第一种,也没去研究Xray,但是有朋友问起这个问题,就花了2天时间详细研究了一下.

不研究不知道,一研究才发现,其实有很多细节要注意的呢,那我们开始分析了

1.火炬之光中人物不能自己挡自己.

解决方案:不写深度就完了,深度永远控制在遮挡物那里,

2.火炬之光中有的建筑可以透,有的却不能透,不是所有建筑都能透的哦

解决方案:分渲染队列,可以透的渲染队列为3，人物的渲染队列为4，不能透的建筑渲染队列为5

3.火炬之光中没用shader实现,而且角色材质里面只是一些简单的pass

解决方案:说明火炬之光是固定渲染管线实现的,而且不是在material中写的,而是代码中实现,操作整个渲染队列实现的

,其实这种操作整个渲染队列的方法很好,不用更改角色材质,就可以实现效果.那我也照做,

我的整个实现思路为,

1.监听整个角色的渲染队列,

2.角色队列渲染2次,第一次渲染被遮挡像素,第2次渲染未被遮挡像素

3.渲染被遮挡像素的时候,禁用渲染状态的改变(就是禁止角色的材质),用自己设置的渲染状态去渲染光照信息

场景混合采用add,因为火炬之光就是add,

网上有人用alpha混合去实现的...如果用光照亮度当alpha混合,那么固定渲染管线是实现不了的,因为要在片段程序里面才能把输出颜色加上alpha...而火炬之光也没有用shader...so,我们用固定渲染管线...

代码

由于公司的一些原因,代码只好取消了,前一周我是提供了代码的.见谅

第一步,初始化上面这个类:

view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
mSceneManager = mRoot->createSceneManager("OctreeSceneManager");  
  
// 2011.4.5 LuoYinan 实现X-Ray半透效果  
static XRayRenderQueueListener sXRayRenderQueueListener;  
mSceneManager->addRenderQueueListener(&sXRayRenderQueueListener);  

第二步:更改Ogre源码,因为Ogre有个bug,调用_suppressRenderStateChanges以后,不会去渲染不接受阴影的对象

找个这个函数renderBasicQueueGroupObjects.改成如下:

view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
//-----------------------------------------------------------------------  
void SceneManager::renderBasicQueueGroupObjects(RenderQueueGroup* pGroup,   
                                                QueuedRenderableCollection::OrganisationMode om)  
{  
    // Basic render loop  
    // Iterate through priorities  
    RenderQueueGroup::PriorityMapIterator groupIt = pGroup->getIterator();  
  
    while (groupIt.hasMoreElements())  
    {  
        RenderPriorityGroup* pPriorityGrp = groupIt.getNext();  
  
        // Sort the queue first  
        pPriorityGrp->sort(mCameraInProgress);  
  
        // Do solids  
        renderObjects(pPriorityGrp->getSolidsBasic(), om, true, true);  
        // 2011.4.5 modify by LuoYinan  
        renderObjects(pPriorityGrp->getSolidsNoShadowReceive(), om, true, true);  
        // Do unsorted transparents  
        renderObjects(pPriorityGrp->getTransparentsUnsorted(), om, true, true);  
        // Do transparents (always descending)  
        renderObjects(pPriorityGrp->getTransparents(),   
            QueuedRenderableCollection::OM_SORT_DESCENDING, true, true);  
  
  
    }// for each priority  
}  

另外,合成器的源码也要小改,合成器链有个队列监听,那个监听在某些时候会跳过我们的队列,导致合成器的问题,不能让他跳过队列所以

view plaincopy to clipboardprint?
·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150
void CompositorChain::RQListener::renderQueueStarted(uint8 id,   
    const String& invocation, bool& skipThisQueue)  
{  
    // Skip when not matching viewport  
    // shadows update is nested within main viewport update  
    if (mSceneManager->getCurrentViewport() != mViewport)  
        return;  
  
    flushUpTo(id);  
    /// If noone wants to render this queue, skip it  
    /// Don't skip the OVERLAY queue because that's handled seperately  
    if(!mOperation->renderQueues.test(id) && id!=RENDER_QUEUE_OVERLAY  
        && id != RENDER_QUEUE_4) // 2011.4.15 add by LuoYinan. don't skip XRay queue  
    {  
        skipThisQueue = true;  
    }  
}  

第三步:记得设置渲染队列

RENDER_QUEUE_3 -->要半透的建筑队列

RENDER_QUEUE_4 -->玩家队列

RENDER_QUEUE_MAIN -->不透的建筑队列

-------------------------------------------------------------------------------------------------

最后效果,颜色可能还要调试下

本文链接

character set,utf 8, unicode, ansi

2011-05-05T08:03:00Z

Character sets

Contributed by Ken Fowles, Personal Systems Division, Microsoft.

This page starts with a summary, then digs into ASCII, OEM, ANSI, DBCS, and Unicode character sets, and how character sets affect technology at Microsoft.

Summary

Character sets affect two fundamental parts of your code:

How you store or transmit data, your file format.
String processing, the logic with which you manipulate text.

Character sets do not solve:

Locale-awareness, formatting preferences.
Special input requirements, keyboard layouts, IMEs.
Text layout, fonts and other display issues.

In the dark ages, developers generally ignored character sets. Since one ANSI character set can handle Western European languages like English, French, German, Italian and Spanish, other languages were considered special cases or not handled at all.

Many, but not all of the world's major writing systems can be represented within 256 characters, using individual 8-bit character sets. It's important to note there isn't an 8-bit character set which can represent all of these languages at once, or even just the languages required by the European Union.

Languages which require more than 256 characters include: Chinese (Traditional and Simplified), Japanese, and Korean (Hangeul). It is a requirement, not an option, that any application which touches text in these languages needs to correctly handle DBCS or Unicode string processing and data. Unless you enjoy throwing away a lot of code and algorithms, it's best to implement this from day one in all your text handling code.

ASCII

ASCII is contained within 2 to the 7th power, or 128 characters. There's room in ASCII for upper and lowercase English, American English punctuation, base 10 numbers, a few control characters and not much else. Although very primitive, it's important to note ASCII is the one common denominator contained in all the other common character sets - so the only means of interchanging data across all major languages (without risk of character mapping loss) is to use ASCII (or have all sides understand Unicode). For example, the safest way to store filenames on a typical network today is using the ASCII subset of characters. If you manually log into CompuServe, they require a 7-bit instead of 8-bit modem protocol, since their servers were originally ASCII-based.

OEM 8-bit characters

Back in the DOS days, separate Original Equipment Manufacturer code pages were created so that text-mode PCs could display and print line-drawing characters. They're still used today for direct FAT access, and for accessing data files created by MS-DOS based applications. OEM code pages typically have a 3-digit label, such as CP 437 for American English.

The emphasis with OEM code pages was linedraw characters. It was a good idea at the time, since the standard video for the original IBM PC was a monochrome text card with 2k RAM, connected to an attractive green monitor. However the drawing characters took up a lot of space in the 256 character map, leaving very little room for international characters. Since each hardware OEM was free to set their own character standards, some situations continue today where characters can be scrambled or lost even within the same language, if two OEM code pages have different character code points. For example a few characters were mapped differently between Russian MS-DOS and Russian IBM PC-DOS, so data movement is unreliable, or software has to be written to map between each special case.

Users aren't going to suddently erase all their old data and reformat all their disks. The raw data and FAT filenames created with OEM code pages will be around for a long time.

Windows ANSI

Since Windows GDI overrides the need for text-based line draw characters, the old OEM line-draw characters could be freed up for something more useful, like international characters and publishing symbols. An assortment of 256-character Windows ANSI character sets cover all the 8-bit languages targeted by Windows.

You can think of Windows ANSI as a lower 128, and an upper 128. The lower 128 is identical to ASCII, and the upper 128 is different for each ANSI character set, and is where the various international characters are parked.

code page	1250	1251	1252	1253	1254	etc.,
upper 128	Eastern Europe	Cyrillic	West Euro ANSI	Greek	Turkish	etc.,
lower 128	ASCII	ASCII	ASCII	ASCII	ASCII	etc.,

The European Union includes more languages than Code Page 1252 can cover - specifically Greek is missing, and there's no way to fit it all into 256 characters. Switching entirely to Unicode would allow coverage of all EU languages (and a lot more) in one character set, but that conversion is not automatic, and requires every algorithm which touches text is inspected or rewritten. So an interim solution available, which allows the spanning of multiple ANSI code pages within one document - Multilingual Content I/O. Remember this is for multilingual document content, not user interface - two separate issues.

DBCS

DBCS stands for Double Byte Character Sets but are actually multi-byte encodings, a mix of 8-bit and 16-bit characters. Modern writing systems used in the Far East region typically require a minimum of 3k-15k characters.

There are several DBCS character sets supported by Far East editions of Microsoft Windows. Leadbytes signal that the following byte is a trailbyte of the 16-bit character unit, instead of the start of the next character. Each DBCS code page has a different leadbyte and trailbyte range. No leadbytes fall within the lower 127 (ASCII) range, but some trailbytes do.

Sample Shift-JIS String

4 Code Range

ASCII
1st lead byte range
Kana
2nd lead byte range

The main rules for DBCS-enabling are:

Always move entire characters, not bytes. Never let a 16-bit character get split up, don't allow an edit/insertion point in the middle of a 16-bit character. Check all your string algorithms for this.
Never code to specific leadbyte/trailbyte ranges - that will lock your code into one FE language. Instead, ask Windows for the answer using GetCPInfo (generic across all encodings) or IsDBCSLeadByte (DBCS systems)
p+ + and p- - will march your pointer right into the center of a DBCS character and break. Use CharPrev and Charnext instead. Charprev/next is the best way to go, since it behaves consistently across ANSI, DBCS and Unicode.

What is Unicode / ISO 10646 ?

Unicode is a 16-bit character set which contains all of the characters commonly used in information processing. Approximately 1/3 of the 64k possible code points are still unassigned, to allow room for adding additional characters in the future.

Unicode is not a technology in itself. Sometimes people misunderstand Unicode and expect it to 'solve' international engineering, which it doesn't. Unicode is an agreed upon way to store characters, a standard supported by members of the Unicode Consortium.

The fundamental idea behind Unicode is to be language-independent, which helps conserve space in the character map - no single character is assumed to identify a language in itself. Just like a character "a" can be a French, German or English "a" even if they have different meanings, a particular Han ideograph might map to a character used in Chinese, Japanese and Korean. Sometimes native speakers of these languages misunderstand Unicode as not "looking" correct in Japanese for example, but that's intentional - appearance should reside in the font as an artistic issue, not the code point as an engineering issue. Although it's technically possible to ship one font which covers all Unicode characters, it would have very limited commercial use, since end-users in Asia will expect fonts dedicated and designed to look correct in their language.

This language-independence also means Unicode does not imply any sort order. The older 8-bit and DBCS character sets usually contain a sort order, but this means they had to create a new character set to change the sort order, which makes a mess out of data interchange between languages. Instead, Unicode expects the host operating system to handle sorting, as the Win32 NLS APIs do.

Data interchange between languages

This is where Unicode has the clearest advantage compared to code pages. Unicode is essentially a superset of every Windows ANSI, Windows DBCS and DOS OEM character set. So for example an Unicode-based Internet browser could let its user simultaneously view Web pages which contained text in practically any language, as long as they have the appropriate fonts on their machine.

Unicode is even useful for products which don't rely on Unicode for string processing, since it makes a good common denominator for mapping characters between code pages. Instead of manually creating an almost infinite set of possible mapping tables between every code page, it's easier to map from one codepage to Unicode, and then back over to the other codepage. The Win32 SDK sample UCONVERT shows how to use the system's *.nls tables to accomplish part of this task.

Impact on your project

Unicode-enabling is not an automatic process - since it requires 16-bit characters, many of the same ANSI coding assumptions which will break on DBCS will also break on Unicode - for example your pointer math can't assume 8 bit characters, and you will need to test to verify correct string handling, in every place your code directly touches text. Fortunately there are some shortcuts.

Twelve steps to Unicode-enabling【熊猫注：这几条不错啊】

from Developing International Applications pages 109-111, Microsoft Press:

Modify your code to use generic data types.
Determine which variables declared as char or char* are text, and not pointers to buffers or binary byte arrays. Change these types to TCHAR and TCHAR*, as defined in the Win32 file windows.h, or to _TCHAR as defined in the VC++ file tchar.h. Replace LPSTR and LPCH with LPTSTR and LPTCH. Make sure to check all local variables and return types. Using generic data types is a good transition strategy because you can compile both ANSI and Unicode versions of your program without sacrificing the readability of the code. Don't use generic data types, however, for data that will always be Unicode or always ANSI. For example, one of the string parameters of MutliByteToWideChar and WideCharToMultiByte should always be in ANSI and the other should always be in Unicode.
Modify your code to use generic function prototypes.
For example, use the C run-time call _tclen instead of strlen, and use the Win32 API GetLocaleInfo instead of GetLocaleInfoA. If you are also porting from 16 bits to 32 bits, most Win32 generic function prototypes conveniently have the same name as the corresponding Windows 3.1 API calls (TextOut is one good example). Besides, the Win32 API is documented using generic types. If you plan to use Visual C++ 2.x or higher, become familiar with the available wide-character functions so that you'll know what kind of function calls you need to change. Always use generic data types when using generic function prototypes.
Surround any character or string literal with the TEXT macro.
The TEXT macro conditionally places an L in front of a character literal or a string literal. The C run-time equivalents are _T and _TEXT. Be careful with escape sequence specifying a 16-bit Unicode double-quote character, not as the beginning of a Unicode string. Visual C++ 2 treats anything within L" " quotes as a multibyte string and translates it to Unicode byte by byte, based on the current locale, using mbtowc. One possible way to create a string with Unicode hex values is to create a regular string and then coerce it to a Unicode string (while paying attention to byte order).
char foo[4] = 0x40,0x40,0x40,0x41;
wchar_t *wfoo = (wchar_t *)foo;
Create generic versions of your data structures.
Type definitions for string or character fields in structure should resolve correctly based on the UNICODE compile-time flag. If you write your own string-handling and character-handling functions, or functions that take strings as parameters, create Unicode versions of them and define generic prototypes for them.
Change your make process.
When you want to build a Unicode version of your application, both the Win32 compile-time flag -DUNICODE and the C run-time compile-time flag -D_UNICODE must be defined.
Adjust pointer arithmetic.
Subtracting char* values yields an answer in terms of bytes; subtracting wchar_t values yields an answer in terms of 16-bit chunks. When determining the number of bytes (for example, when allocating memory), multiply by sizeof(TCHAR). When determining the number of characters from the number of bytes, divide by sizeof(TCHAR). You can also create macros for these two operations, if you prefer. C makes sure that the + + and - - operators increment and decrement by the size of the data type.
Check for any code that assumes a character is always 1 byte long.
Code that assumes a character's value is always less than 256 (for example, code that uses a character value as an index into a table of size 256) must be changed. Remember that the ASCII subset of Unicode is fully compatible with 7-bit ASCII, but be smart about where you assume that character will be limited to ASCII. Make sure your definition of NULL is 16 bits long.
Add Unicode-specific code if necessary.
In particular, add code to map data "at the boundary" to and from Unicode using the Win32 functions WideCharToMultiByte and MutliByteToWideChar, or using the C run-time functions mbtowc, mbstowcs, wctomb, and wcstombs. Boundary refers to systems such as Windows 95, to old files, or to output calls, all of which might expect or provide non-Unicode encoded characters.
Add code to support special Unicode characters.
These include Unicode character in the compatibility zone, character in the private-use zone, combining characters, and character with directionality. Other special characters include the private-use-zone non-character U+FFFF, which can be used as a sentinel, and the byte order marks U+FEFF and U+FFFE, which can serve as flags that indicate a file is stored as Unicode. The byte order marks are used to indicate whether a text stream is little-Endian or big-Endian - that is, whether the high-order byte is stored first or last. In plaintext, the line separator U+2028 marks an unconditional end of line. Inserting a paragraph separator, U+2029, between paragraphs makes it easier to lay out text at different line widths.
Determine how using Unicode will affect file I/O.
If your application will exist in both Unicode and non-Unicode variations, you'll need to consider whether you want them to share a file format. Standardizing on an 8-bit character set data file will take away some of the benefits of having a Unicode application. Having different file formats and adding a conversion layer so each version can read the other's files is another alternative. Even if you choose a Unicode file format, you might have to support reading in old non-Unicode files or saving files in non-Unicode format for backward compatibility. Also, make sure to use the correct printf-style format specifiers for Visual C++, shown here:
   Specifier printf Expects wprintf expects
   %s SBCS or MBCS Unicode
   %S Unicode SBCS or MBCS
   %hs SBCS or MBCS SBCS or MBCS
   %ls Unicode Unicode
Double-check the way in which you retrieve command line arguments.
Use the function GetCommandLine rather than the lpCmdLine parameter (an ANSI string) that is passed to WinMain. WinMain cannot accept Unicode input because it is called before a window class is registered.
Debug your port by enabling your compiler's type-checking.
Do this (using W3 on Microsoft compilers) with and without the UNICODE flag defined. Some warnings that you might be able to ignore in the ANSI world will cause problems with Unicode. If your original code compiles cleanly with type-checking turned on, it will be easier to port. The warnings will help you make sure that you are not passing the wrong data type to code that expects wide-character data types. Use the Win32 NLSAPI or equivalent C run-time calls to get character typing and sorting information. Don't try to write your own logic - your application will end up carrying very large tables!

For samples on Unicode-enabled programming, UCONVERT shows character conversion using the system's *.nls tables, and GRIDFONT shows how font enumeration and display needs to keep track of character encoding.

本文链接

招聘UI帝，客户端逻辑，熟悉CEGUI Lua优先，薪水给力

2011-04-24T17:43:00Z

招聘UI帝，客户端逻辑，熟悉CEGUI Lua优先，薪水给力。

项目为MMORPG 2.5D，使用OGRE引擎，公司在上海长宁区，有意者发到 lai3d at 163.com

本文链接

NVIDIA Parallel Nsight试用

2011-04-24T17:26:00Z

IE9居然写不了blog！！！有木有！！！换Chrome！！！

言归正传，Parallel Nsight 1.51在我的台式机（双系统）Vista 32bits Ultimate上居然运行不了，后来就没弄了，这周末看到出了新的2.0版，试了下仍然不能运行，但Windows 7 64bits Ultimate可以运行，笔记本Vista 32bits Home Edition 上也可以运行。遂用笔记本做host machine，台式机做target machine,试了试remote debugging.

Host Machine | Vista 32bits Home Edition | Gefore 8600MGS

Target Machine | Windows 7 64bits Ultimate | Gefore 9800GTX

Target Machine：

Host Machine:

本文链接

What is a recommended tool for debugging shaders that I am writing for DirectX?

2011-04-23T16:07:00Z

微博字数限制，不爽，但是不限制的话就不是微博了，呵呵。

http://www.gamedev.net/topic/587926-directx-11-shader-debugging/

Q:What is a recommended tool for debugging shaders that I am writing for DirectX? There is two steps that I would like to debug a shader, compiling errors and values during run time.

Use the command line compiler fxc.exe which is included in the sdk to compile shaders. It works like a normal compiler and has lots of options.

PIX is a great debugging tool for figuring out errors in pipeline setup, textures, and other resources and can be used to debug shader issues, although you can't step through your shader line by line. PIX is also in the SDK.

NVIDIA has a tool for debugging shaders. However it requires two machines, one for rendering and one for debugging. You have to select the pixel or vertex that you want to debug for a draw call. It's pretty hardcore and probably only worth it for the most complex shader issues where other debugging attempts have failed.

AMD has GPUPerfStudio which you can use to debug the shader pipeline. It's sort of an alternate version of PIX, though it comes with counters so that you can work on optimization.

Microsoft: GPUView - performance analyzer. Shows how long API calls take and how long work packets take on the GPU. Really good for optimizing the entire program with ns resolution.

本文链接

在Vista/Win7中VS2008的破解补丁

2011-01-06T05:24:00Z

验证过了，下面的方法好用。人才啊！

http://www.chendw.cn:8080/view.aspx?id=238

【转】在Win7中VS2008的破解补丁

今天安装了VS2008，由于是90的评估版，按照原来在XP系统下，可以在反安装的时候，填写序列号来进行升级，但是在Windows7系统下，就没有那个输入框和升级按钮了。百度了一下，发现遇到这样的人还不算少，基本上都是说在安装前修改安装包里的一个文件，但是这样很麻烦，又要删除，又要重新安装，而且还要调出iso文件里的数据文件，真的是超麻烦，最后想了一下，于是用spy++看了一下，发现升级的输入框和按钮是隐藏到的，于是就写了这个工具将其显示出来，同时也帮助你把序列号填写好了，你只需要添加一下“升级”按钮即可完成！请看下面裁图。

补丁下载： UpgradeVs2008.rar

2010-2-2:

更新了可以支持英文版的VS2008。

备注：由于有很多网友下载了后使用时，不出现“升级”按钮和输入序列号的框框，这里给一个建议，就是以administrators（超级管理员）进入去使用即可，因为非管理员，系统限制了修改和获取系统句柄等权限。所以这个软件就会修改不到（获取不取）VS2008的维护界面里的控件。

原理：通过找到VS的维护页，然后再找子控件，找到需要的子控件并将其显示、激活、并把可以使用的序列号填入来达到目的。

本文链接