noslopforever ［天堂里的死神］

花了三天时间，加上了动态的卸载，发文祝贺！

noslopforever（天堂里的死神） — Wed, 24 Jun 2009 15:32:00 +0800

上周六看了看相关代码，周一编码，周二解决了几个致挂的BUG，终于把急需的动态卸载加上了，扩展一下Unreal，貌似也没预想中那么痛苦。
编码极少，这点得感谢同事Aman Jiang那富有远见的Streaming，省了大事了。
具体能带来多少好处，今天去测试一下，不过运行时确实比之前卡一些了 ^_^。如果能把显卡报错给彻底消除掉，卡那么一点或许也不是大事。
有些人还嫌这地图小，有些人又觉得地图太大，众口难调。反正别人都很难指望，老老实实的把Unreal这个本来没为MMO考虑太多的工具改成个为MMO考虑的工具才是王道。
好像也没啥好办法，地图越做越大，Unreal的Level Streaming又有先天不足，所以还是从根本上解决问题吧！
另外还有点很感谢Aman Jiang，他一直在对我说的这些话是绝对正确的——任何事情，不能凭空臆想，而要相信数据——数据是绝对不会骗人的。数据一打出来，纹理500M，1D纹理176M，静态模型才40M，板上钉钉的数据，马上就知道优化的方向了。

WPF

noslopforever（天堂里的死神） — Mon, 22 Jun 2009 05:31:00 +0800

最近从同事那里借了本WPF的书，看了看WPF，挺简单的，确实很简单，概念很简单，实现很简单，没有什么再简单了。这就是伟大——将复杂的事情用简单的体系去描述。做游戏开发的人或多或少可能都有点对商业软件不太重视，其实，商业软件中有很多思路是很值得我们借鉴的。软件为什么要发展？实现新的功能？——但那个是要取决于硬件的。软件的发展，我认为，第一的要务，是要帮助人类完成他们希望完成的事情。对于游戏开发而言，就是能够尽可能让一切简化，简化到让更多的人可以参与的地步。把软件做的复杂，谁都会，难的是把一个原本复杂的事情做的简单。从语言的发展历史，我们或许也能看得出来。C语言的普及程度很低，因为它的思路与人类思考问题的方式差的比较远。C++和JAVA相对就好一些——它们用对象和对象之间的关系来描述整个世界。当对象过多的时候，我们发现COM接口可以将模块的复杂度完美地秒杀到一个COM组件内，并由COM继续发展而产生了现如今.NET的态势。而当把API、平台调用等等复杂度全部压下去后，就会是很多动态语言胜任的领域和场合了，他们更适合于用

焦油坑……

noslopforever（天堂里的死神） — Tue, 16 Jun 2009 07:35:00 +0800

记得Blooks人月神话里有一个很形象的比喻——焦油坑。
又回想起了这个比喻，陷入泥潭中的史前生物——无论多么强大——无一例外地，越挣扎，陷入的越深。
乐观主义的认知总是会觉得事情是可以避免的，然而不幸的是，从Blooks 70年代写下这些文字的时候，我们直到今天，也没有从根本上避免项目陷入焦油坑。
我们试图用很多假设，但却一次次的碰壁，到最后，又一次次陷入恶性循环，难道人类是不长记性的么？
人的记性还不错，记自己的东西放到哪里，记谁动了我的奶酪……
其实，或许人们也能记住焦油坑，只不过谁都想捏它一把，以为自己能彻底解决这个问题。
但无数次失败，成功总是那么艰难……
因为，项目开发，并不是技术的技术，而是人的技术。问题并不发生在技术上，而是发生在人上。
最后期限，死了都要改，永无止境的修正……这些挖坑的工具，每个项目都不缺，也缺不了。
因此，完美总是这么困难……

累了……

noslopforever（天堂里的死神） — Mon, 15 Jun 2009 06:26:00 +0800

昨天初步测试了一下现在这个版本静态模型动态加载部分的效率，马马虎虎吧，省了70%的读取时间。剩下几个BUG，跟动态加载没什么关系了，是umbra的BUG，下周继续修理。此外还有个重挂接的效率问题，不过那个简直是没难度。

测完了，感觉很累，没觉得这么累过，今天睡了一整天觉，睡得现在超级精神。

真的很想感谢一下Unreal，无论如何，能坚持到今天，是因为Unreal，又爱又恨的Unreal。

无论如何，看来，我还要跟它携手走段日子吧……

我不是个喜欢说别人好或者不好的人，上过马哲的应该都或多或少有些迂腐的辩证，好或者不好，无非也就是人心一动。

只不过是人生中的一个过客，何必呢？

尊重它，面对它，解决它，工作无非就是就这样吧。

越来越觉得六年前，王前辈说的对了，你是因为爱好程序而进入这个行业，而不是爱好游戏本身。

很多人，变得陌生，很多人，让人讨厌，很多人，让人喜

6-6又歇菜了，赋闲在家，顺便写一下最近的进展和问题。

noslopforever（天堂里的死神） — Sun, 07 Jun 2009 01:03:00 +0800

周三觉得发热，周四就躺着动不了，生病的感觉真难受，躺在那里就像在倒数计时，听着血液在耳边流过的声音，想喝口水，一看——还没烧……顿时就万念俱灰。去见医生，抽血，拍片，又开了一大坨药，天！周五又睡了一天，今天好歹能起床了，盯着电脑屏幕两眼发黑，脑子一片空白，不知道该干什么……要做的事情太多，哪个放前面做？
体质真的不如以前了，所以是不是该把锻炼身体列为第一要务呢？

有人说我生病是自找的，也是，没办法……在前一个公司时，听一位原来做对外游戏外包的前辈说过，欧美的公司，在他们的工作时间中，是包括对员工的培训和学习时间的。想来，在游戏这一行当做了也有5、6年头了，也只有在上一个公司，可以在工作的闲暇之余有时间去学习自己想学习的东西——尽管无人交流。
累了，觉得，躺了两天，本来该精神的，却突然觉得虚脱了一般。上网翻翻帖子，看到有些“业内人”说“业内”的种种问题，突然又有“权威业内人”跳出来说我们XX公司很好很好。突然不知道为什么，想起了之前老朋友的一句话：“中国有游戏开发行业么？”
乱所以才有无数的机会，才会让无数的人愿意投身

U3Terrain的一个BUG及修正

noslopforever（天堂里的死神） — Tue, 26 May 2009 16:07:00 +0800

不知道有人遇到了没。U3的Terrain系统，在层数高于5层后，一定会出现一个BUG——6层时，当你开始对第1、2层的过渡进行涂抹时，就一定会发现，整个地形以统一的Alpha给第2层和第1层来了个过渡，无论你怎么刷，这个Alpha都不会变。
跟踪资源，发现两张Weight Map都在，第一张描述了2-3、3-4、4-5、5-6四层，第二张描述了1-2。资源这里没问题，跟踪游戏流程，数据直到提交到渲染线程之前，都是对的，Alpha Map的生成完全没有问题。
那么问题在哪里呢？
用PIX跟踪，发现是6层后，因为U3使用了两张Weight Map权重图，来描述各层混合，问题就发生在这里：用于描述第1、2层之间Alpha的图，也就是第二张Weight Map不翼而飞！只留下了一个白白的纹理。在U3中，当纹理资源不存在时，会自动给入一张白色纹理，以提醒用户注意修正。
根据这个信息，重新跟踪流程，发现数据层的Weight Map是存下来的，两张，数据都对，提交到渲染线程后，渲染的Shader Compiler做了一件事，根据当前用到了哪张，而提

GamerClass Shading系统设计【四】需求-扩展性

noslopforever（天堂里的死神） — Tue, 26 May 2009 15:57:00 +0800

1，引擎升级或者Fix BUG后，制作者的代码是否需要修改？需要多大程度的修改？这个看起来简单，事实上并不容易，因为新的接口很有可能极大修改原有流程，比如DX8和DX10的流程，差得很远。 2，引擎升级后，旧功能会在多大程度上可以继续使用？是完全不能使用？是能使用但效果或者性能变差？还是能使用但不能修改（最常见是因为旧的流程被抛弃，实际上硬编码了旧接口的实现）？还是能使用且能修改以加入新功能？

VS一个好用的功能

noslopforever（天堂里的死神） — Wed, 20 May 2009 07:07:00 +0800

就是这个：Property Manager。

GC在制作过程中，制作了20个例子和测试工程，之后可能会更多。
由于我们把示例工程与工具集工程独立了，如果每个示例工程都要重新配置一遍Include的话，那将会是一件很可怕的事情。
我们在调整工程设置时，应该能经常见到有这样的设置：

这是什么意思呢？查MSDN，发现这个就是一种类似继承和重载的概念。
假设一个属性表D继承自B，那么最终的设置就是：
整个VS默认的设置 -> 根据B改变的部分修改 -> 根据D改变的部分修改 -> 根据工程本身的配置修改。
于是，我们就打开了Property Manager，通过新建按钮建立了一个新的Property，设置如下：
是不是很熟悉？没错，工程设置。其实工程设置应该也是一种特殊的属性，工程里有的，这里全都有。

这样子，所有同类工程只需要配置一遍即可，不需要再每个工程改设置了。
Have fun！

GamerClass Shading系统设计【三】需求-实用性

noslopforever（天堂里的死神） — Mon, 18 May 2009 09:42:00 +0800

Gamer Class遇到的问题，最大的方面就体现在易用性上，因为用户对于编辑器的需求非常重要。而在上层编辑器层次，不能有太多的概念，否则会冲淡编辑器本身的概念，而且还会引入很多由于顺序而导致的不确定性，增加处理的成本。Gamer Class希望，在制作的过程中，随时可以添加新的渲染物体和渲染模式，添加的过程可以足够简单。最好是继承出一个类，随便改改，然后就一切正常。什么Shader，什么算法，都滚一边去，剩下的最好只是纯粹的概念：勾上了动态光的选项，就要计算动态光，勾上了Light Map的选项，则就要计算Light Map。

Template + Type List导致C4002的问题

noslopforever（天堂里的死神） — Thu, 14 May 2009 16:29:00 +0800

昨天，为GC的添加了类似于U3的Policy的东西。
我一直很不爽U3的Policy体系，添加一个渲染模块太困难了，同时要修改N个地方，任何一个地方不修改都会导致问题。
GC的Policy使用了Typelist，其中Vertex Assignment使用了如下的Template + Typelist

/*!
*/
class _NullTypeListNode
{
};
template
class TVertexAssignNode
{
};
template
class TGCVertexAssignGroup
{
};

#define TGC_VERTEX_ASSIGN_GROUP1(T1) TGCVe