noslopforever ［天堂里的死神］

我浴血奋战，只为了神圣永久不变的传言

用户操作

[留言] [发消息] [加为好友]

订阅我的博客

[编辑]noslopforever的公告

<img src="http://p.blog.csdn.net/images/p_blog_csdn_net/noslopforever/294924/o_zcover.jpg" width="144" height="192"/> -欢迎大家来到我的空间。这里关注游戏相关学科的问题。 -自我介绍：男，26岁，程序员，喜欢战争、历史和哲学题材游戏。作为一位普通的初学者，希望众位前辈们能多多包涵和帮助。 -欢迎大家拍砖。本Blog原创的文章，如要转载，请注明出处和姓名。本Blog放置的代码，大部分是伪码，不保证能够运行。 <a href="http://blog.csdn.net/noslopforever/archive/2007/05/16/1610969.aspx">*留言本1：没有CSDN帐号的网友留言请点击此链接</a> <a href="http://hi.csdn.net/noslopforever">*留言本2：CSDN网友请在个人空间留言 ^_^</a> 上善若水，水利万物而不争。处众人之所恶，故几于道。 ——《道德经》 -最近在做：GC、FF、Remoting -有些栏目的文章是不放在主页显示的，如果有感兴趣的可以到相应栏目查询。杂项和Just As Gamer栏目的，仅作为个人喜好，恕不回复。

[编辑]文章分类

[编辑]！飞龙在天！

cproom前辈的Blog

eXtreme 3D —— Dreams的Blog (RSS)

flymemory的Blog

johnson的Blog——我的老师和第一个上司 ^_^

nhsoft——野猪大大的Blog

Nightmare of Design/Dev (RSS)

[编辑]！虎狼成群！

[编辑]推荐网页

[编辑]喜欢的站点

存档

开始写BLOG

2007年06月14日

置顶的参考和资源目录（07-7-24更新：GC）

基本上，本文所列举的都是最近学习或参考的来自于网络的共享文章和资源。只是链接，并不表示赞同，也并不表示反对。如果对您的权益构成了损害，请与我联系，我将在第一时间将其从本文条目中删去。阅读全文>

发表于 @ 2007年06月14日　12:58:00 | 评论( loading... ) | 编辑| 举报| 收藏

2007年06月11日

置顶原创文章目录和近期计划（09-9-21更新）

早就说要写计划的，2009年2月，终于开始写了。不管怎么样，记录一下自己曾经走过的路，顺便也算是种监督，还是不错的。此外，抽取本Blog主要的原创技术文章的链接在这里，以避免找起来麻烦。此处所有收录的文章均为原创，因此如要转载请注明出处。非技术文章将不会纳入此分类，若感兴趣可到相应栏目查阅。感谢您的关注和支持！欢迎一切形式的版砖手雷扔炸弹，谢谢您！阅读全文>

发表于 @ 2007年06月11日　13:37:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年11月21日

《杀戮地带2》中的延迟渲染

这篇文章对延迟渲染的描述还是挺有参考意义的，其实早就说要翻译了，主要也是帮助自己加深一下印象，但是一直就抽不出时间来，今天家里有事不得不在家休息，于是也就趁机翻译了一下。翻译： http://download.csdn.net/source/1684527 原文： http://www.dimension3.sk/mambo/View-document-details/Deferred-Rendering-In-Killzone.php 翻译完了，发现另外一篇更好的文章，也贴出来。 http://www.pcinlife.com/article/graphics/2009-05-05/1241494639d816.html http://www.pcinlife.com/article/graphics/2009-05-18/1242638159d820.html Have Fun！阅读全文>

发表于 @ 2009年09月21日　19:49:00 | 评论( loading... ) | 编辑| 举报| 收藏

自动序列化，学习和实践

GC本次重构中，唯一不需要大动的或许就是自动序列化了，这个思想算是从U3借鉴过来的。 U3里给我最大的感觉，就是序列化这里几乎不需要太动脑筋，只要是uc系的Object，基本上都已经处理好了自动序列化，版本更新时，数千个类却不需要合并一行序列化相关的代码。 Every Thing Is Automatic。如果游戏能这么做出来该多好！当然也有人说U3这个系统设计的很烂，费效率，耽误时间，难查错，等等等等。这里面有些是自动序列化必然会存在的问题，也有些是U3本身的假设导致的，从系统论的观点而言，一个组件的错误有可能不是因为组件本身，而是因为它所在的环境，这些废话就不细细展开了。对于GC而言，资源系统是独立于整个渲染构架的，因此资源的存储也是由这些外部系统来处理的。而外部系统的重构、重写、改变也可能是最多的——因为他们跟需求最相关，最直接相关。面对着未知次数的重写，也就大胆试了试自动序列化——我可不想焦头烂额的时候还去处理序列化这种劳动密集型的问题。自动序列化的基本思路是：利用语言系统提供的反射机制（C/C++靠宏和Template自己写，.NET靠.NET本身提供的反射）阅读全文>

发表于 @ 2009年09月21日　17:07:00 | 评论( loading... ) | 编辑| 举报| 收藏

星际2的DS和Shadow学习笔记。

最近，随着外包告一段落，开始整理和重构GC了，顺手整理一下GC的MRT。之前没有认真读完的星际2的白皮书，这次至少是把MRT部分和Shadow部分读了一下。先说MRT吧：星际2的MRT大约如下配置：具体就不解释了，看样子，为了保证精度，每个MRT应该都是64-bit的，0、2、3三个MRT保存表面颜色信息，1用来保存对于DS而言最重要的Normal Depth，还不错。关于MRT，其用途可能比看起来的要大得多。其实很多效果都可以通过MRT来实现，例如Killzone2就把SH球谐光照编码到Lighting Accumulation域里，这个Lighting Accumulation在我感觉可能很像Emissive，稍有不同吧——很可能最后用的是与Albedo的乘法？也就是公式是： Albedo * LightingAccumulation + Albedo * dot(N,L) + Specular* dot(N,H) Lighting Accumulation主要是用来存储静态光照图、Decal和球谐光照。SC这里面没有Lighting Accumula阅读全文>

发表于 @ 2009年09月21日　15:46:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年09月06日

该整理一下了……

不需要理由，不需要借口，梦就在前方，需要的是永不停息的脚步。阅读全文>

发表于 @ 2009年09月06日　23:56:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年08月05日

永恒不变

项目的消息发布了，在本次CJ。
没有过多的感觉，因为没有心思去感觉。
动态加载的优化、天气系统、材质优化、64位平台支持、编辑器新功能、BUG修正……
看起来很多吧？一点都不多，来了两位强大的同事来分担工作，其实我的工作已经很简单了。
累是一种什么东西？我不知道，我曾经累过，但是当把关于它的思考放下去后，发现已经不那么累了。
还是感觉，人如果思绪过多、杂念过多，就会很累，而我还是很轻松，不明白很多人怎么就那么累。
这世界上有很多事情是一直在变的，人无法把握，因此觉得自己渺小，因此而受挫。
但这世界上总是有很多事情是不变的。
就正如引擎的版本更迭一样，很多事情，真的是恒久不变的。
程序不像美术，不像策划，程序是一种只要坚持了正确的做法，就会产生收益的学科。不需要讨价还价，不需要揣度用户，体系和构架的稳定性、扩展性，只要能达到一个层次，那么在这个层次的需求就都能够包容。
所以，做程序，一直都不会累。
游戏系统的需求并不是无限延展的，而是收敛的。因为游戏比起那些大规模，超阅读全文>

发表于 @ 2009年08月05日　07:39:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年07月24日

灰暗的感觉……（早一篇，未实时发表）

一年一度的CJ又开始了，看了看新闻，心中总觉得很悲凉。我们看到外国的游戏大展，虽然也会去关注女人，但是总归更多的目光是放在《战神3》《FF13》这样的神作上。可是当看到CJ之后，从一片浮华的背后，却觉得游戏越搞越糟，女人越穿越少。虚伪，虚假，很少能看到真实的东西，越来越空虚的感觉，伴随着月光挥洒到心的深处，让它凝结，不再跳动。当这个世界已经沦陷的时候，或者伴随着旧世界而死去，或者拥抱着新世界而苟活，难道没有别的路可以选择？五年前，我们的开发环境，与五年后的今天，有什么本质的变化？五年前，我们的开发心态，与五年后的今天，有什么本质的变化？五年前，我看到的是阴暗的世界，五年后，我看到的依旧是虚伪、狡诈。做事首先要学会做人，这是中国传统处世哲学的一个重要命题。但一个做事的人，如果把心思都花到做人上，那么他能做好什么事情？于是，中国的技术，就如同中国的官场一样，政治关系成为了一切的道德准绳。技术始终是处于压榨之下，直到榨空的那天。阅读全文>

发表于 @ 2009年07月24日　22:52:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年06月24日

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

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

发表于 @ 2009年06月24日　07:32:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年06月21日

WPF

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

发表于 @ 2009年06月21日　21:31:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年06月15日

焦油坑……

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

发表于 @ 2009年06月15日　23:35:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年06月14日

累了……

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

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

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

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

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

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

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

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

很多人，变得陌生，很多人，让人讨厌，很多人，让人喜阅读全文>

发表于 @ 2009年06月14日　22:26:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年06月06日

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

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

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

发表于 @ 2009年06月06日　17:03:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月26日

U3Terrain的一个BUG及修正

不知道有人遇到了没。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做了一件事，根据当前用到了哪张，而提阅读全文>

发表于 @ 2009年05月26日　08:07:00 | 评论( loading... ) | 编辑| 举报| 收藏

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

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

发表于 @ 2009年05月26日　07:57:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月19日

VS一个好用的功能

就是这个：Property Manager。

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

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

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

发表于 @ 2009年05月19日　23:07:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月18日

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

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

发表于 @ 2009年05月18日　01:42:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月14日

Template + Type List导致C4002的问题

昨天，为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阅读全文>

发表于 @ 2009年05月14日　08:29:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月11日

GamerClass Shading系统设计【二】普遍性与特殊性

在进行Shading系统的设计之前，可能先需要明白大体的需求以及自己手中拥有哪些资源。在这个系统中，主要包括如下的组成部分： 1，模型数据。用于描述模型的空间位置，外型。模型的处理可能也许要用到Shader，主要是Vertex Shader和Geometry Shader。比如Skin、水面波动、地表波动、粒子系统之类的。 2，材质。用于描述表面的受光特性，表面的属性，包括半透明、线框、是否进行Alpha Test等等。这个视需求而定，可能比较简单，也可能比较复杂。但无论如何，它都可能涵盖整个Shader的三个阶段（VS、GS、PS）。 3，光照处理。例如：延期着色系统和前向着色系统。对于同样的材质，不同着色系统的输出不同。光照可能会走顶点光照，也可能走像素光照，不过对于Deferred Shading这种本身并不处理顶点光照的着色系统而言，可以把顶点光照认为是一种特殊的Emissive材质，这样就只需要处理像素光照了。在上面的列举中，我们很容易发现，当前系统面临的普遍性和特殊性。普遍性就是，所有的问题都可以归结为数据（Mesh顶点和Shader参数）阅读全文>

发表于 @ 2009年05月11日　23:28:00 | 评论( loading... ) | 编辑| 举报| 收藏

GamerClass Shading系统设计【一】Preview

在进行外包实现的过程中，由于需求的变化，受光是一个经常变化的选项。在真实感光影上，我们就已经有诸多选择，即便是最终决定了使用Deferred Shading进行全场景动态光影之后，针对是否使用静态光照图仍然有一些讨论——毕竟，目前来说，动态的优势在于交互，但是静态的优势在于真实。 GC初始的设计，是一切围绕着材质转，材质决定其渲染模式，Shading Environment决定材质的渲染。Render System这个Singleton，拿到材质之后，根据当前的渲染环境，决定对其的渲染……阅读全文>

发表于 @ 2009年05月11日　08:31:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年05月05日

4月份荒废了

真是一个悲惨的月份，不知道为什么，4月份的产出比较少了。项目在4月底和5月底各有一个版本，这两个版本都很重要。天天在公司忙得半死，回来的效率也无法保证了。不过……说不定只是借口，呵呵。4月份，跟朋友一起为GC添加了骨骼系统，以应付外包的需求。本来是，因为之前只是停留在理论上知道的阶段，自己没有做过，所以一直不敢迈进来。好在现在有点雏形，虽然还有别的错误，不过相信BUG是能解决的吧。5月份，希望能为GC添加完毕骨骼、类似Vertex Factory的图元构造系统、阴影和地形，加油了呢。之前有人问过GC到底之后准备怎么样的问题——因为这个东西多少带有点理想主义，不可能会真的有人拿它来做游戏，只不过是一种学习和自我提高的手段。自己写引擎，有时候，并不是为了真的要拿这引擎怎么样，更重要的是，这种行为本身是一种态度，究根问底的态度。如果所有的一切都只是理论上，那么最终实践的时候，真知还是要去探寻的。理论的道路，你可以站在巨人的肩膀上，可是实践的道路——除非整个系统有大变革——只能靠人两只脚走出来。或者说，说的直接阅读全文>

发表于 @ 2009年05月05日　23:08:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年04月12日

诡异的日子

本周的最后一天，在结束了一上午的工作，准备下午再搞它一下的时候。美术提了一个需求：不慎调错了地形的两层，土和草地，土在上，草地在下，而且就这样已经刷了一周了，希望我们能把它们给换过来，换成土在下，草地在上。看到界面上有“保留Alpha”的选项，直接就很放心的选上，然后点换层，结果……层是换过来了，可是……所有的草地全都没了，只剩下了土地。OMG……阅读全文>

发表于 @ 2009年04月12日　22:34:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年03月14日

Deferred Lighting翻译后记【三】——从DS到技术

Deferred Shading，是以一种相对简单但有效的结构，以丧失一定的复杂度为代价，换取在高效率实现逐像素光照下，最好的效果。可能很多人，对于新技术的看法往往是一个新技术，是很复杂的，是需要花很多脑子去学习的。我觉得，对于过去而言，这是很有道理的，因为在低端机器上，很多无用功其实是浪费到了优化上。BSP、ROAM……诸如此类的技术，都是换取效率而必须付出的代价。但在已经不用过多的优化，就可以达到这些数年前技术效果的层次上，新的技术则将眼光瞄准了更远更高的方向都是抄，早一天，晚一天，不重要，重要的无非就是谁抄的好。都是卖，口碑好，口碑差，不重要，重要的是只要有人买就好。看清自己的问题，永远比看清别人的问题更重要，明白自己的需求，永远比明白别人的需求更关键！阅读全文>

发表于 @ 2009年03月14日　22:48:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年03月10日

Gamer Class的Deferred Shading截图

截图。阅读全文>

发表于 @ 2009年03月10日　21:38:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年03月09日

Deferred Shading翻译后记【二】

本周四，跟同事们讨论的时候，大概说了一下Deferred Shading的一些基本细节，以及与我们项目的关系。我对Unreal3没有全面支持Deferred Shading至今耿耿于怀，甚至有时候让一部分同事产生了对Unreal3的不信任感。其实，我最想表达的，是这个Blog一贯以来的主题：没有最好的技术，没有最坏的技术，没有有用的技术，没有没用的技术，没有正确的技术，没有错误的技术——技术就是技术，决定技术优劣的，并非技术本身，而是使用技术的人。阅读全文>

发表于 @ 2009年03月09日　02:03:00 | 评论( loading... ) | 编辑| 举报| 收藏

2009年03月08日

Deferred Shading翻译（Shawn Hargreaves 2004 GDC的经典文章）

唉，吭哧吭哧半天，终于翻译完了，郁闷，要是两年前，十几篇这样的文章都搞定了，最近的状态需要振作了！
不多说了，比较大，找不到地方放，放到了CSDN的下载里。
http://download.csdn.net/source/1084504

原文可见：
http://www.talula.demon.co.uk/
里的
http://www.talula.demon.co.uk/DeferredShading.pdf

经典文章，不翻译应该也不难懂，主要是给自己加点压力，迫使自己好好看完。
接下来就是Killzone2、GDC08和Nvidia的6800 Leagues的那篇了。争取下周搞定。

计划虽然是无法完美完成的，但如果不去努力的话，那就一点都完成不了了……阅读全文>

发表于 @ 2009年03月08日　23:46:00 | 评论( loading... ) | 编辑| 举报| 收藏

第1页，共5页