编写Max导出插件目前有两种选择，一种是使用max脚本，另一种就是使用max SDK了。使用Max SDK又分为使用Max标准API和IGame接口。我使用IGame接口编写Max导出插件。IGame接口就是在Max标准API的基础上有针对性地对游戏导出进行了封装，将通常繁琐的操作调用简化成一个函数，与此同时还可以通过IGame接口获得标准API的数据结构从而使用标准API进行一些复杂的操作。要想

<br />听起来挺悬的，好家伙写了一个iPhone的模拟器，模拟了一个Mac OS系统，呵呵，其实不是，我可没那么牛比。<br />其实写的就是一个专门应对iPhone游戏开发的win平台模拟器，与GameFramework配合，从而极大的提高了哪些熟悉win开发但不熟悉iPhone开发者的开发效率。毕竟我也是Windows开发出身，用vs最熟也最顺手。<br /> <br />这个模拟器主要功能就是与GameFramework进行配合，提供了诸如点选，滑动，震动，设置模拟器朝向等功能，更重要的是与Gam

<br />不光还是游戏引擎，任何一个项目都有必要做好内存管理，至少可以监控内存使用量和内存泄露。而对于游戏引擎而言更是如此，在游戏引擎里面动态分配释放内存的地方不在少数，做好内存管理对于提高引擎运行效率是十分必要的。<br /> <br />内存管理就是做两件事，负责内存的分配和释放，再有就是对内存的分配释放进行监控，据此来解决内存泄露和掌握内存使用情况。<br /> <br />先说说内存分配释放，这也是内存管理最重要的部分。一般来说内存管理只管理小内存的分配释放，大内存则无需管理制作监控即可。过多的小

<br />渲染是3D引擎不可缺少的模块，这两天在思考如何把这个部分设计好。<br /> <br />首先明确需求，最起码的因该是把图形API进行抽象风装，这样引擎只调用经过抽象的渲染接口，这样便于扩展到其他图形API上，简单来说就是把GL/GLES/D3D的通用的API抽象出来到CRenderBase上，再由此派生CRenderGL,CRenderGLES,CRenderD3D等分别实现，完成底层渲染API的分离。这是最起码要做到的，接下来就是一些具体的渲染工作到底是放在CRender里面还是放在具体到C

<br />这几天在做特效系统的优化，稍有些心得，分享一下。<br /> <br />首先要讨论的是优化层次，然后再说说优化策略。<br /> <br />游戏这个东西是程序美术策划共同努力工作的结果，所以优化再更宏观的角度来看不只是程序的问题。在具体工作中经常会出现，美术作了一个特别牛鼻的特效，效果及其绚丽，但是他却消耗了大量的资源，导致游戏性能低下。这是很常见的问题，因为美术他不管程序怎么处理，他只追求效果，而且美术的特点是很感性，对于一些具体技术细节不是那么靠就，比如说粒子发射量，很多情况下用不着那么

<br />很早以前研究过crysis的引擎，最近和同事讨论起来这个东西，现在简单总结一下。<br /> <br />这里关注的是crysis的场景管理和光影。<br /> <br />crysis的场景管理是通过把玩他的编辑器猜测的，不一定完全正确，还有部分是我自己的设想。<br />crysis的场景管理是全实时的不需要什么预计算，以他的室内场景为例，他是通过放置VisArea和Portal以及Furtums的Portal剪切筛选来实现的。可以通过编辑器编辑VisArea，这个VisArea就是一个几何

<br />现代的游戏大多资源量都比较大，无法做到游戏启动之初就加载了全部资源，所以资源动态加载必然要做。下面说一说一些不同的资源动态加载方案。<br /> <br />第一种方式，分贞加载。所谓分贞加载顾名思义就是把游戏资源的加载分解到不同贞去做，这样可以降低某一贞突然加载大量资源导致的帧率急剧下降。这种分贞可以是以资源为单位，也可以加载步骤为单位。比方说第一步进行磁盘IO，第二步进行一些资源使用前的准备工作（如提交显卡等），这些步骤也可以分别放在不同贞中进行。为了使贞率更加平稳，可以限定每贞加载的量，或

<br />好久没有更新过博克了,春节的最后一天更新一下,写一下关于游戏中关于光影效果的方法,以及我的实现.<br /> <br />去年有个机会和call duty3的程序总监聊天（此人是一个华人，当时已经回国在腾讯做互动娱乐部门副总，想找我过去），他提到次时代游戏和前一代游戏的最大区别之一就是游戏的光影效果，可见游戏中光影效果是如此的重要。<br /> <br />关于游戏中的光照，就目前来看大致两种方式，一种是Unreal的与渲染光照贴图+ShadowMap，另一种则是Crysis的完全实时光影。效果

<br />废话不多说.<br /> <br />先从显卡渲染都需要哪些东西说起。<br />显卡要完成渲染本质上就是要回答两个问题，即画什么和如何画。<br /> <br />对于画什么这个问题，是由场景管理器来决定，这也是场景管理最本质的工作。<br />场景管理器最重要的工作就是根据当前相机位置及朝向，使用各种算法（BSP,四叉树,八叉树或者其他）来快速筛选出场景可渲染的几何体，这就是画什么。<br /> <br />对于如何画这个问题，是由材质来解决，在材质中保存了渲染管线参数，Shader等信息，

翻看自己的博客，都还是4，5年前写的东西了。而近几年随着移动互联网的兴起，整个行业也发生了翻天覆地的变化。具体到我们游戏开发人员，更具体来说引擎开发人员来说更是天壤之别。我个人算是一个有过多年（7，8年了吧）经验的引擎开发人员了，一直做引擎开发相关的工作，甚至独立开发了一整套引擎和所有工具。之所以说是”抉择“，这个问题只是针对我这种情况而言，毕竟积累了那么多年的东西，而且有些地方还存在

<br />场景编辑器，又是场景编辑器，大概一年前我曾写过一个基于BSP的场景编辑器，配合当时的引擎。经过这将近一年的时间我对场景编辑器和bsp，portal，pvs又有了更加透彻的了解。<br /> <br />可能有的朋友已经用过Unreal，worldcalf(cs的编辑器)等。我总结一下这些编辑器。<br /> <br />首先是单位，他们的1米使用的是64各单位。我开始很奇怪为什么用这么不零不整的单位，为什么不用100代表1米，或者1代表一米，这样不是更加自然。但是深入研究发现这样做是有历史原因的

<br />这几天抽时间完成了特效编辑器，正如我之前讨论过的特效系统。不多说了，上两个图<br /> <br /> 

最近这几天在搞一个GameFramework，其实就是在引擎基础上增加一个游戏框架，对游戏进行抽象，对引擎使用的一些封装。在进行具体设计的时候很多细节问题是值得思考的。总结如下     总的来说我所设计的游戏框架从功能上来讲就是两件事，一个是游戏的状态管理（什么菜单状态，游戏状态等等），在一个就是AI管理，又有一个有效的机制来负责对所有AI进行更新和维护还有交互。     对于一个

近几个星期以来一直在搞粒子系统，下面简要总结一下。粒子系统从其本质来说就是一些点被发射出来，并在其生命周期内受到一些影响。这些点的信息也无非就是位置，方向，颜色等等，根据需要也可以扩充其他。而渲染的时候则根据粒子的信息，再结合具体的渲染类型（比如billboard）进行渲染。从上面可以看出粒子系统分为4各部分1. 粒子，这里只要把他理解成一些关心的变量集合，比如位置，方向，颜色，纹理偏移，生命时间

工作这么多年，也开发过几个引擎，去年还独立开发一个基于iPhone平台的3D FPS游戏引擎（包括引擎和所有编辑器）。最近在研究Unreal 3和Crysis的引擎，有了些新的想法，于是想全新开发一个新的引擎 ZeusEngine。在写这片博客的时候这个引擎已经开发一段时间。下面列出这个引擎将要支持的特性。首先这个引擎是一个同时支持PC和iPhone平台的引擎，使用统一架构（事实上没有写任何区分平

作为一个引擎程序员，在我以往经历的项目中经常会遇到这样的问题，这个功能是不是该市现在引擎中，似乎放在逻辑中（或者客户端）也可以。每当举棋不定的时候我都会想引擎到底该做什么！？我这里我说说我的想法。很久以前并没有什么引擎，所有东西都是写在一起的，当开发新的游戏时基本上都是从头开始，这样就有大量重复的工作。后来一些聪明的程序员将那些可以在各个游戏中使用的代码独立出来，并作成一个库，这样便有了引擎。其实

  

<br />周末在家尝试着使用sse对引擎进行优化。<br /> <br />关于如何使用sse这里并不多说，有很多资料，这里提一下，使用sse无非就是直接使用汇编或是使用函数指令，如果是诸如解码器核心之类的推荐使用汇编直接进行优化，毕竟可以将核心全部用汇编实现，其他情况下使用sse函数指令即可。<br /> <br />接下来说一下sse在3D引擎中的优化。可优化的地方很多，但总的来说绝大部分优化都集中在了数学运算，3D游戏的数学运算基本上都是向量运算非常适合进行sse优化，一般情况下把数学模块优化好也基

昨天参加了公司组织的nvdia的培训，讲了一些关于D3D的优化和可能的瓶颈所在，具体的条目就不说了，这里说一些关于资源的Lock和Unlock，以及我在GL下的测试。老师讲到向Draw*这类函数是将其指令放入指令队列，带填满后或者强制刷新时交给显卡去画，也就是说它并不是即时的，而像对资源的Lock和Unlock确是即时的操作，而且cpu和gpu是并行计算的，当lock的资源正是当前gpu正在使用的资源会导致lock堵塞直到gpu使用完后才返回，也就是说不当的使用lock会造成cpu等待gpu的情形。当然D3

以前一直没有接触过粒子系统，上一个引擎由于试运行在iPhone上，也没有专门的实现这一模块。最近由于工作关系不得不进行研究并写一个编辑器。 通过这一段时间对各种粒子系统，特效系统的研究我也有了进一步的了解，在51期间自己写了一个十分简单的粒子系统框架，给大家共享（见后面的连接），并打算进一步集成到目前正在独立开发的ZeusEngine中。 看到粒子系统作的各种效果感觉很神秘也很强大

这两天有机会重新翻翻之前看过的3D数学方面的书籍，下面简单介绍一下3D数学要点和我的学习轨迹。 和很多人一样在刚刚开始接触3D方面的东西时并不是直接看3D数学，毕竟也不是计算机专业出身，没学过计算机图形学。最开始仅仅是找一些关于OpenGL的书籍来看，这些书大多数都是手册性质的（包括什么红宝书之类的），然后照猫画虎照葫芦画瓢照着例子把代码桥进取，这样经过短暂的联系基本上了解了OpenGL，