我一朋友全手工做的，是不是很厉害，她的东西都买到香港，马拉西亚了，看的我好喜欢

据说买的很抢手呢，现在要买要排期定做呢，哎~，看来要灿烂的发紫了

祝她一切顺利，我可是她启蒙恩师呢，哈哈（看见不要打我啊，呵呵）

这是她的taobao店铺，喜欢的朋友，可以去看看哦，http://shop34405019.taobao.com/

这篇文章的主要内容是Dx10的一个例子，ParticlesGS Sample，Siney最近在研究dx10，说起来，已经“研究”好久了，但一直没有系统的写点例子，了解整个dx10的架构，所以写一篇dx10的文章，1）是总结学习，2）是整理下思路，根据自己的理解把相关的内容讲述清楚。

dx10与dx9相比，有很多变化，其中之一就是渲染管线的变化，如图：

可以看到，主要是加入了Stream Output和Geometry-Shader阶段，而ParticlesGS Sample正好演示这两个阶段的用处和功能，这个例子演示了如何实现一个基于gs的粒子系统，该粒子系统是模拟焰火，由于焰火需要爆炸出新例子的特性，使用gs可以动态构建新primitive的特性，可以很方便的模拟这个系统，在初始阶段，我只要在IA阶段传入一个luancher粒子，他的作用就是定时的产生新的shell例子，然后shell粒子经过一段时间后，爆炸出n多ember粒子，ember粒子再经过一段时间后就消亡了，往复这个过程，我们就可以看见一个焰火的模拟例子系统。

以luancher产生shell粒子为例，可以看到gs如下：

[maxvertexcount(128)]

void GSAdvanceParticlesMain(point VSParticleIn input[1], inout PointStream<VSParticleIn> ParticleOutputStream)
{
    if( input[0].Type == PT_LAUNCHER )
        GSLauncherHandler( input[0], ParticleOutputStream );
    else if ( input[0].Type == PT_SHELL )
        GSShellHandler( input[0], ParticleOutputStream );
    else if ( input[0].Type == PT_EMBER1 ||
              input[0].Type == PT_EMBER3 )
        GSEmber1Handler( input[0], ParticleOutputStream );
    else if( input[0].Type == PT_EMBER2 )
        GSEmber2Handler( input[0], ParticleOutputStream );
}

void GSLauncherHandler( VSParticleIn input, inout PointStream<VSParticleIn> ParticleOutputStream )
{
    if(input.Timer <= 0)
    {
        float3 vRandom = normalize( RandomDir( input.Type ) );
        //time to emit a new SHELL
        VSParticleIn output;
        output.pos = input.pos + input.vel*g_fElapsedTime;
        output.vel = input.vel + vRandom*8.0;
        output.Timer = P_SHELLLIFE + vRandom.y*0.5;
        output.Type = PT_SHELL;
        ParticleOutputStream.Append( output );
        //reset our timer
        input.Timer = g_fSecondsPerFirework + vRandom.x*0.4;
    }
    else
    {
        input.Timer -= g_fElapsedTime;
    }
    //emit ourselves to keep us alive
    ParticleOutputStream.Append( input );
}

除去vs和ps没有的语法外，上述gs还是蛮好理解的，简单来说，就是在定时器结束的时候，new一个新的shell例子，并Append到ParticleOutputStream，注意这里的primitive为point，而不是triangle，所以在后面渲染的时候，我们还需要在gs中，展开为triangle以渲染一个billboard。还需要注意的是，我们需要重置luancher例子的计时器，并也把他Append到ParticleOutputStream，没有了这个发动机，下次就不会产生shell例子了。

上述gs代码需要stream output，如下：

// Point to the correct output buffer
pBuffers[0] = g_pParticleStreamTo;
pd3dDevice->SOSetTargets( 1, pBuffers, offset );

[maxvertexcount(128)]的语意是告诉gpu，这段gs代码最多会产生128个顶点，当然也可能没有这么多，比如产生shell例子就仅需要[maxvertexcount(1)]，而128这个数值是针对shell产生ember粒子。能够动态产生point的粒子了，我们还需要渲染这些粒子，我们都知道粒子的渲染一般是billboard，而仅仅是一个point是不能构成billboard，所以我们还需要一段gs，展开point成为2个triangle，如下gs：

[maxvertexcount(4)]
void GSScenemain(point VSParticleDrawOut input[1], inout TriangleStream<PSSceneIn> SpriteStream)
{
    PSSceneIn output;
    //
    // Emit two new triangles
    //
    for(int i=0; i<4; i++)
    {
        float3 position = g_positions[i]*input[0].radius;
        position = mul( position, (float3x3)g_mInvView ) + input[0].pos;
        output.pos = mul( float4(position,1.0), g_mWorldViewProj );
        output.color = input[0].color;
        output.tex = g_texcoords[i];
        SpriteStream.Append(output);
    }
    SpriteStream.RestartStrip();
}

这段gs，产生4个vertex，其实就是strip的4边形，最后需要RestartStrip()，告诉gpu一段strip完成，这样就会产生独立的4边形，否则可能会导致后续的vertex也进入strip，从而渲染错误。

在开始渲染之前，我们需要关闭stream output，否则后续的gs代码又会stream output，如下：

// Get back to normal
pBuffers[0] = NULL;
pd3dDevice->SOSetTargets( 1, pBuffers, offset );

这样后续的gs阶段后，会进入ps阶段。

最后我们还需要注意，由于在gs中我们可能增加vertex，也可能不增加，但对于外部的draw函数来说，并不知道实际的顶点数量，或者primitive数量，这使得我们不能直接调用传统的Draw函数，为此dx10为我们提供了DrawAuto函数，他会根据gpu实际产生的primitive数量来渲染，不需要任何参数。

用gs实现粒子系统确实很方便，也很高效，与传统的基于dx9的粒子系统，我们避免了频繁的lock & unlock，形体计算等cpu密集的操作，而是完全交给gpu去计算、更新，能够更好的并行cpu和gpu，最大发挥gpu的威力。

在游戏中如果可以嵌入Flash，则可以使用Flash的便利功能为游戏提供UI系统，内嵌小游戏，内嵌视频播放等等，当然对于这个想法，市面上也有现成的第三方套件实现类似功能，例如ScaleForms（http://www.scaleform.com/），但其售价昂贵，而且是针对每个游戏title授权，技术支持也单独收费。

为此Siney通过OLE/COM封装Adobe Flash控件的方法，实现了一套类似与ScaleForms的产品，命名为Sflash，与ScaleForms相比，Sflash最大的优势在于，兼容性。ScaleForms为了能跨平台，自己实现了Flash的功能，包括文件读取，解码，硬件加速渲染，但这造成了其兼容性不好，特别ActionScript3脚本制作的Flash文件完全不支持，同时也不支持主流的Flash视频播放。而Sflash则完全没有这方面问题，因为Sflash完全封装了Flash的功能，使他能够在游戏环境下运行，与游戏引擎产生交互，只要Flash支持的，Sflash都能完美的在游戏引擎里支持。

一些关于Sflash的可能应用：

内嵌休闲小游戏

目前mmorpg游戏包含的范围越来越广，大有将所有游戏类型纳入其中的意味，这导致很多mmorpg游戏在游戏系统内制作各种吸引玩家的小游戏，传统的方法是程序员需要花大量时间在这种锦上添花的下游戏上，而真正的mmorpg系统则因为时间关系有所削弱。而引入Flash，则将mmorpg游戏的制作同小游戏的制作区分开来，mmorpg程序员专注于游戏引擎、系统的制作，而小游戏则交给相应的Flash制作人员，将Flash游戏作为美术资源与mmorpg整合，目前越来越多的外国游戏厂商采用ScaleForms，为其游戏产品提供更多丰富的游戏特性。

内嵌视频播放

在我们的游戏《天下贰》中，很多玩家喜欢拍摄游戏电影，然后发到youku，土豆这样的网络上展示给其他玩家观看，而这些视频通常都是flv（Flash电影）如果我们游戏内做一个类似电影院的场景，可以把那些优秀的游戏电影集中在电影院内播放展示，必定能提高游戏玩家的荣誉感和成就感，这就是Sflash的另外一种可能应用，因为Sflash的实现可以不必像传统Flash播放器那样只能在窗口内平面显示，而可以通过3d 贴图的方法，贴到游戏中任意的模型上，就像场景内被摆放了一个大萤幕，玩家可以3d透视的观看视频，这无疑会提高游戏产品的玩家友好度。

目前正式奥运时期，如果能在游戏内播放奥运赛事，吼吼~~~

过场动画

某些游戏可能需求简单的过场演示动画，就是一些简单的图片、文字和特效，用于介绍游戏故事情节等。

关于Sflash的技术特性：

Sflash是引擎无关的，可以不加修改（或者少量修改）应用现有游戏引擎内，包括2D游戏，Sflash可以完全兼容Flash播放，能够完全兼容用户交互（包括本身Flash的鼠标、键盘操作），采用transparent的flash渲染技术，能够不需要HWND，能够实现半透明。

关于ScaleForms和Sflash的优缺点对比，如表：

关于技术实现

最后来说说如何使用OLE技术封装Flash控件，说出来其实很简单，就是从Flash接口QueryIViewObject接口，其提供的Draw函数，可以把OLE对象绘制到一个指定的HDC上，然后根据这个HDC创建贴图在贴到游戏引擎内即可，这里唯一需要注意的是，Flash的消息处理，即用于交互的实现，这里我们还是Query IOleInPlaceObjectWindowless接口，其提供过的OnWindowMessage函数可以通知Flash处理windows消息，即可以完成Flash与用户交互。

当然， IOleInPlaceObjectWindowless接口依赖IOleClientSite等OLE容器，所以还需要简单实现一个OLE容器类，或者直接使用ATL/MFC提供的现成类。

截图：

在3d透视情况下播放Flash视频。

测试程序这里下载。（可能需要dx9）

很多人发邮件说Game Analyzer不能运行，缺少detourd.dll文件，经过检查这是一时疏忽导致的bug，现在已经上传的最新修正版，欢迎大家下载使用。

ps：貌似在vista下不能使用，具体原因还不清楚。

下载地址：http://www.sineysoft.com/down/ga.rar

关于ga的介绍：http://www.sineysoft.com/blog/post/ga_help.html

今天看到前同事出去开公司搞了一个桌面3D宠物，感觉有点意思，以前就想过桌面版的任天狗online，没有想到已经有人搞起来了，“不是我不明白，是世界变化快”啊，所谓3D渲染的桌面宠物，就是类似office助手那种桌面动画（桌面精灵），其实它也是一个窗口，不同的是，是一个shape会改变的不规则窗口，office助手是2D图形，如果换成3D渲染一只宠物，我就称其“3D渲染的桌面宠物”。

先说说2D桌面精灵的实现，在2k的系统以后，有一个非常好用的函数，就是UpdateLayeredWindow，只要每次传递给他一个内容不同的dc，该函数就会根据dc的bitmap和key color，把桌面的shape修改为dc的样子，所以对于2D的桌面精灵就是定时修改dc的内容，然后调用UpdateLayeredWindow就可以了。与简单的2D桌面精灵不同的是，3D渲染对shape的变化率要求比较高（取决于fps），而得到3D渲染的rt则受到硬件特性的限制，我们都知道直接lock back buffer或者rt都是很慢，更不用提将rt变化为dc，所以要解决3D渲染转换可以使用的dc，首先要解决的就是速度问题。

解决速度问题，我想到了2种方法，第一就是完全软件渲染，摒弃对硬件的依赖，因为一般桌面精灵（即使是3D）对渲染质量不会太高，完全软件渲染的速度是完全可以接受的，无非是变换和光栅化，网络上也有一些纯软件实现的3D framework；第二种方法就是想办法优化从硬件中访问rt的速度，这也是我努力的方向，毕竟能用现成的技术直接渲染桌面精灵是再好不过了，经过不断尝试，总算解决了问题，步骤如下：

1）创建rt，渲染所有图形到rt；

2）创建offscreen surface，把rt的内容通过GetRenderTargetData函数导入到surface；

3.1) 如果需要同桌面alpha混合，lock surface，创建32bit bitmap，select到mem dc；

3.2) 如果不需要alpha混合（可能会有锯齿，或者不会半透明），直接surface->getdc；

4) 使用上述dc调用UpdateLayeredWindow函数，收工。

这种方法在我的8800和7600的卡上，通过测试，其关键的时间消耗可能在步骤2）上，之前我直接lock rt，发现很慢，每次lock获取dc需要200ms，而通过一个offscreen surface转换则几乎没有时间消耗，当然GetRenderTargetData函数的效率我没有办法预估在不同card上的表现，如果在某些卡上效率不理想，则只有考虑方法1）了。

这是运行的效果图，由于没有模型动画，用了一个简单旋转三角形表示，原理一样。

点击这里下载例子，修改.jpg为.exe。

最近在搞视频播放这玩意，因为《天下贰》有需要播放片头动画，就是我们在游戏中常见的过场电影，首先想到肯定是bink video，很多游戏都用它，虽然我到现在还没有搞清楚其优势同目前主流的rmvb、wmv等体现在那里，但看到其高昂的价格，又不提供试用，我望而却步了，辗转在wmv和开源的xvid、ogm之间选择，最后经过比较和测试选择了xvid，其中一个最大的原因就是使用xvid代码很简单，就1个函数，3种用法，分别是create，delete和解码一帧，解出来的帧可以制定为很多格式，比如rgba32，rgba16，yuv等，内部已经统统帮你处理好，返回一个处理好的buffer，对于3d游戏，我们直接使用rgba32或者rgb24，创建对应贴图，lock填充，然后绘制出来就ok了。为了重用，引擎内部设计了一种MovieTexture，这样甚至可以把视频当作贴图贴到任何多边形上，而不一定用于传统的视频播放，想想我们场景如果放了一个电视：）。

xvid本身只对视频编码，所以xvid提供的库也没有音频的部分，如果需要播放带音频的文件，就需要考虑视频、音频同步的问题，xvid经过编码后一般是avi文件，而avi文件可以附带音频编码，而音频编码也不在乎采用的格式，比如mp3，ogg都可以，我采用的同步方案就是时间轴同步，视频和音频采用同一时间轴，当发生视频不同步的时候，音频等待视频，因为视频编码有关键桢和非关键桢，不能直接skip到某帧，否则可能出现马赛克。如果skip到关键桢，则需要分析avi文件idx0 chunk数据，传入对应stream buffer即可。

Here are few screenshots of the realtime raytracer we developed at VRcontext (www.vrcontext.com), and that has been presented during the Intel Research Days last week. It's a realtime raytracer designed for massive models. The images are from two different models, one is an oil platform made of a bit more than 100 million triangles, and the other one is a chip manufacturing factory of 200 million triangles (you need few gigabytes of memory to keep these in memory), there is no instantiation or level of details, it's all there each frame. On our local 16 core machine it runs at 20 to 30 fps under the following conditions: 640x480 with 4 times supersampling (x4AA), dynamic shadows from a directional light and on the fly real ambient occlusion (not backed, neither fake SSAO). We observed perfect scalability (x15.9 speed up compared to monocore). The demo machine was 24 cores, so we believe the performance was around 37 fps. Without ambient occlusion you can navigate at full framerate (>70 fps). As explained, it runs only on the CPU(s), the GPU is not used at all (not even for image postprocessing).
This type of models are quite unfriendly regarding geometry and topology (like very long and thin triangles mixed with regular ones, clashes and so on) so the kdtree builder has hard work here.
Images are pure white because we didn't have any material information, we basically had a polysoup to work with.

原帖地址：http://www.gamedev.net/community/forums/topic.asp?topic_id=497681