Geekmind

只是一个类似概念证明的工具，无法称之为产品。但效率上确实做到了interactive。720P，直接光照+AO+不太复杂的BRDF，采样方面不清楚，6个SPE下可以达到5帧/秒。

截图（1080P缩小）：

今天心情好，多写几篇。

访谈在这里：http://www.gamasutra.com/php-bin/news_index.php?story=20974

解读在这里：

前期工作，主要是技术验证：Dave communicates through prototypes. He needs to get his brain fluff distilled into technical demonstrations.

给发行商的demo，未必一定要好看，但必须好玩。事实证明LBP的玩法的确是有趣的。Evans showed some videos of the very first demo pitch to Sony -- primitive compared to the final game, but featuring recognizable highlights. Small touches of animation -- the way the character's head bobbles, for example -- and the realtime physics system belie Little Big Planet's humble beginnings. The combination of simple physics and platforming are completely consistent with the shipped product.

玩家玩游戏好玩才是首要的。开发游戏和正确的人合作才是首要的。The four founders of Media Molecule strongly believed that great games do not require huge teams to be competitive... In Evans' opinion, the quality of the outcome can be traced directly to the quality of the individuals comprising the team -- so finding good people is key.

优秀的团队，不代表不需要管理和激发。"Content is important," Evans said. "These first renders taught our team that communication of process was absolutely essential."

带有UGC特性的游戏，通常会遭遇这样那样的疑问，有些甚至是创作者自己的。这时候你需要一个清醒的认识。Even within Media Molecule's own team, there was initially an uncertainty about what, exactly, they were developing on the spectrum between "game" and "creation tool."

嗯，我相信如果Evans会作为GDC09的speaker，那场session一定又是许多人跪坐着。。。

由于实在忍受不了vi，又没有信心搞定长久弃用的emacs，还是决定使用Code::Blocks。。。既然有了vnc，C::B用起来已经算不错了。特别感动的还有intellisense，好开心...

只是CB要使用自己的Makefile，以及第三方编译器/debugger，过程就显得巨痛苦。。。结论是放弃在CB IDE中进行build，还是使用命令行make，弃用所有CB的编译设置。但debugger可以集成进IDE，不过就是找debugger位置、改设置、重启CB、再改target name、再重启这样而已……后来又发现IDE中进行debug，用键盘快速step over的话会在编辑器中的文件里加上一个乱字符…………= =!

不过C::B，我很知足啦～

今天也在PS3 fedora 7上跑起vnc server了，具体步骤如下：

1、起服务

# vncserver

2、一步步跟着提示设置密码

3、Windows客户端下载realVNC即可，连上192.168.1.xxx:1，表示连上你linux VNC的第一个屏幕。

4、噢。。。raw X Window。。。不要紧：

cd ~my_username/.vnc

vi xstartup

头上有两行

#unset SESSION_MANAGER

#exec /etc/X11/xinit/xinitrc 

把注释去掉，用killall -HUP Xvnc杀掉服务进程，重启搞定。

换了蓝牙模块后板砖变Wii！

痛苦的是后来PDA又板砖了……

没有瞎升级，没有XXOO，放在丈母娘家很长时间，昨天开机时发现一直是红灯，开不了机了。。。隐约觉得有张盘在里面，不知道是不是哪位小朋友把dvd扔了进去。。。

总之，电源问题还是主机问题，都还没定论，下周拿回家彻底清查！

 这两天没有条件写代码，只能看点闲书，不料除了获得了丰富的历史人文知识之外，还发现了科学技术的一些共通性。

说起来非常早期的火铳，通过火药爆炸来弹射铅石。但早期火铳装填火药和弹射物的过程又特别耗时，加上战场形势瞬息万变，骑兵快速冲击下使得火铳神机无法发挥应有的战力。于是明朝沐英和后来的普鲁士腓特列二世，分别发明了一种战术：三线战法。即火铳队分三排，一排率先射击，随后立即退到后列装填弹药，由第二排火铳继续射击，之后也退下，然后第三排上……循环往复，以此解决装填弹药的时间差问题。

搞图形的、搞多核的你，难道对这个战法会不熟悉么？这就素那double/triple buffer啊！！！

目前在gameplay中应用物理特性的游戏还很少，一方面是技术原因，很多实时模拟的方法存在稳定性和震荡的问题，造成的众多bug使得设计师不愿意在使用物理特性驱动gameplay；另一方面也是技术和应用分离的原因，很多设计师没有花很多时间考虑物理特性和gameplay之间的关系，或者很多程序员也根本不了解目前物理特性可以实现的效果、可以辅助gameplay的地方。退一步来讲，即使程序员们了解，他们和设计师之间也未必有良好的沟通交流。

对此我有以下一些建议，设计和程序都可以看看。

这里有一个网站，专门对拥有物理特性（或主推物理特性）的游戏发表试玩评论：

http://www.fun-motion.com/ 对物理特性不了解的设计师和程序员可以从中发现不少优秀的游戏idea。其中我最看好的是Armadillo Run。

目前物理特性应用最普遍的刚体物理模拟，已经有不少优秀的开源项目可以参考、甚至使用。Bullet和ODE都是可以考虑的选择。也有很多游戏应用了刚体物理特性（虽然很少是影响gameplay的），如half-life 2。

还有一类是柔体模拟，这方面应用还很少，而且即使有应用也是基于简单的质点－弹簧模型。我相信乐克乐克是使用了这一类的模型。除此之外，PS Network上的鸭子游戏，虽然我没机会玩过，但从各方面收集的信息看来，应该也是应用了一定的柔体模拟。这方面我认为绝对缺乏深度的gameplay挖掘，值得关注。

再有是衣物（布料）模拟。这方面大多数游戏是将其作为eye candy来对待的，很多日本3D格斗游戏都是这种应用的代表作。技术方面我不太了解，但我想对于avatar，衣物模拟也有必要进行研究和挖掘。

最后是流体模拟。流体很多人会想到液体，其实很多气体和烟雾都是流体模拟的范畴。其中又分为基于grid的和基于粒子的做法，但无论哪种做法，目前将其应用到gameplay的游戏也还是很少。这方面我觉得至少是2D的流体模拟，或者以2D流体模拟伪装进行3D流体模拟，已经在技术上非常可行了。再一此提到鸭子游戏，是我所知不多的，把流体模拟作为主要gameplay的一款游戏。

以上说了这么几种技术，都是我认为目前gameplay还很缺乏的应用。而且相信会在今后多核的趋势下，越来越适合实时游戏应用。

流体计算的主要问题就是解NS方程，至于怎么解就是各家之长了。Alias的大牛Stam在上世纪末提出了的稳定解算流体的做法，10年之后来瞅瞅……

把流体解算过程看作一个积分过程，但积分一不小心就会整成不稳定的，原因很多，如步长大于某种方法的稳定步长啦，没把质量守恒、能量守恒考虑进去啦，等等。

Stam用了个隐式积分的方法解决稳定积分的问题，以前是直接显式积分（加dt），现在是倒退回dt的时间，拿t-dt时刻的量，但这额外需要计算一个线性方程组。由于这个线性系统非常稀疏，可以使用Gauss-Seidel迭代法解这个系统（试下来性能令人满意）。

好，稳定的积分方法解决了，现在看质量守恒。通常根据NS方程几个项（平流、扩散、外力作用）积分下来，通常不会是质量守恒的。如果把符合质量守恒的状态可视化成所有一个平面的点集，那么每次积分的结果都可能把一个点（状态）带离这个平面，也就是破坏了质量守恒的条件。那么我们要在积分末尾进行一个projection的动作，把状态投影到这个平面上，也算满足了质量守恒的先决条件。可能这个投影的动作不那么科学，但至少满足了“稳定”的需求。投影的依据是Helmholtz-Hodge分解法，这个方法指出：任何向量场（我们所积的速度场）都可以唯一分解为一个收敛的向量场（即不发散）和一个标量的梯度场。
w = u + del(q) ==> u = w - del(q)
（del是del operator，向量微分算子，是一个记号，和向量一起使用才有微分的意义）
那么我们只要取这个收敛的向量场作为速度场即可，这个操作就是投影。至于求这个q，又需要解一个线性系统，
del(w) = del^2(q)
这是个泊松方程，也存在一些数值方法可以解它。总之得出q后也得到了最后的投影操作，也完成了整个解算的过程。

下面是在PS3上试验的结果，二维、用CPU更新的纹理，还没捣腾出截屏功能，凑合看……

托几个大黑客的福，firmware 2.0及以下的PS3可以使用“部分”GPU（Nvidia RSX）的功能。最近花不少时间在这上面，也让自己对GPU底层和工具链有个大概了解。

在PS3里，在最底层有个提供硬件功能接口的操作系统，姑且称之为Level 1。其上的任何操作系统都使用需要通过Level 1的API和硬件接口进行交互，姑且称之为Level 2。以这个概念，目前PS3上运行的默认操作系统（GameOS）和其他第三方可提供的操作系统（OtherOS）都是Level 2 OS。SONY出于很复杂的目的，在一定程度上开发了第三方操作系统的可能性，称之为OpenPlatform。具体来说它是安排了一个自己的职员，专门为PS3维护linux内核。由于内核必须是开放的，尽管其中只有很少对于Level 1 OS的系统调用且没有注释，还是给了黑客们机会，这里有一个收集并描述Level 1 API的wiki：http://wiki.ps2dev.org/ps3:hypervisor

一切的hacking都从这些API开始。通过摸索、试验、逆向工程分析dump，并利用nouveau开源驱动项目，最终黑客们找到了一些解决办法来驾驭GPU。

Nvidia系列GPU都有一个FIFO的环形队列（command buffer）供存放GPU指令。这块存在于系统内存的区域大约是64KB（还是2MB记不清？）。有一个类似于程序指针PC的指针（寄存器），指向FIFO。而另一个指针（寄存器）则标注着目前GPU的队列尾。一旦这两个指针不匹配，前者就会一个个将队列中的指令DMA到GPU，直到和后者重合。所以我们要做的就是把正确的指令填入这个FIFO，以期待最后GPU会把我们的指令一一执行。

由于实现一套driver和图形API的代价太大，几乎很难以个人力量完成。所以没有driver，没有图形API，没有任何资源管理，所有的一切都只有FIFO和指令。这有点类似官方SDK中的libgcm库，可以绕过PSGL的下层，对command buffer进行一些操作，如传入预编译的指令队列等。

其实最令人感到不适的还不是图形API的缺失。由于硬件指令是不公开的，所以这里需要通过nouveau的项目资源，以及一些dump来分析NV40系列的指令。有些可以正常使用，另一些则不然（如vp中的ADD和fp中的MOVR，总是无法正确输出float4的色彩）。还没完，即使完全掌握了这些硬件指令，没有一个assembler或高级语言编译器的话，写shader会变得无比痛苦。所以目前的工具链是这样的：在PC上写完Cg，使用Cg编译器输出vp20和fp30的汇编代码。在PS3 Linux上已经有写好的assembler，可以将汇编代码翻译成硬件指令。所以写一个shader会在两个平台上来回切换，忙的不亦乐乎。

我想以后的工作可以包括一些简单的资源管理和队列管理的工作，包括显存分配、资源缓存和换出，这样一个简单的"driver"可以大大增强目前的创造能力，以及今后对于Cell的开发的可视化能力。

最后放一张screenshot，利用SDL可以近乎完美使用SIXAXIS进行操纵。