忙碌的小猪崽

 

近日很多朋友咨询Overlay中文显示问题，回答的多了想索性再写个文档算了，放在网上共享，于是就有了本篇。

       在Ogre1.2.5版本中，通过与Ogre官方论坛的开发者讨论实现了Overlay的中文显示，当初的实现非常的怪异，具体的实现可以参见Ogre官方论坛。

随着Ogre的更新，现在Ogre已经发布了1.4.7，1.4系列版本有一个重要的改进，就是加入了UTFString，这为Ogre中文显示予以很大的帮助。为了便于演示，我直接使用Ogre自带的Overlay，也就是大家熟悉的DebugOverlay，测试工程我选择Demo_ParticleFX，选择其他的也没有关系。现在编译它，运行后得到下图：

图的最左下角显示的就是英文DebugOverlay，接下来我们的任务就是把它编程中文的，^_^。

Overlay中文化操作步骤如下

1.      打开OgreSDK\media\packs\ OgreCore.zip。

2.      打开C:\WINDOWS\Fonts，把simhei.ttf添加到OgreCore.zip，（什么，没有simhei.ttf这个文件，那就还其他的中文ttf字体吧）。

3.      打开OgreCore.zip中的Ogre.fontdef，里面有BlueHighway这个字体定义块，在他的下面添加我们的SimHei，code_points里面的一大堆数字看不明白没关系，随后文章会解释。

SimHei

{

       type             truetype

       source         simhei.ttf

       size              16

       resolution   96

       code_points 33-166 24403-24403 21069-21069 24103-24103 36895-36895 29575-29575 24179-24179 22343-22343 26368-26368 39640-39640 20302-20302 19977-19977 35282-35282 24418-24418 25968-25968 37327-37327 25209-25209 27425-27425

}

4.      打开OgreCore.zip中的OgreDebugPanel.overlay，把BlueHighway全部替换成SimHei，我们要使用中文字体了，嘿嘿。

5.      修改完成后，确保所做的修改已经保存到OgreCore.zip。

6.      进入Ogre解决方案，打开文件ExampleFrameListener.h，把54-59行的代码替换如下：

              static String currFps = "Current FPS: ";

              static String avgFps = "Average FPS: ";

              static String bestFps = "Best FPS: ";

              static String worstFps = "Worst FPS: ";

              static String tris = "Triangle Count: ";

       static String batches = "Batch Count: ";

 

              static DisplayString currFps = L"当前帧速率: ";

              static DisplayString avgFps = L"平均帧速率: ";

              static DisplayString bestFps = L"最高帧速率: ";

              static DisplayString worstFps = L"最低帧速率: ";

              static DisplayString tris = L"三角形数量: ";

              static DisplayString batches = L"批次: ";

7.      最后重新编译工程，下面是我运行的截图，是不是已经显示中文了，^_^。

现在再来看看SimHei中的code_points是如何生成的，这个可以参考我上次写的这篇文章http://www.cnblogs.com/gogoplayer/archive/2008/05/09/1189795.html，至此，实现Overlay中文显示。

转载请注明出处：

作者：gogoplayer

E-mail : gogoplayer@163.com

QQ : 78939328

http://www.gogoplayer.com.cn

今天在做Ogre中文显示时，遇到了Ogre字体code_points生成问题，下面来看一下我使用的黑体定义。

SimHei

{

       type             truetype

       source         simhei.ttf

       size              16

       resolution  96

       code_points 33-166 24403-24403 21069-21069 24103-24103 36895-36895 29575-29575 24179-24179 22343-22343 26368-26368 39640-39640 20302-20302 19977-19977 35282-35282 24418-24418 25968-25968 37327-37327 25209-25209 27425-27425

}

字体code_points就是你要使用的Unicode字符编码，例如‘当’这个字的编码用16进制表示是5F53，转换成10进制就是24403，在Ogre字体定义中使用的是10进制，根据Ogre字体定义文档的描述，这个‘当’字需要在文件中描述成这样24403-24403，你可以到http://www.chi2ko.com/tool/CJK.htm查看每个字符对应的编码。

为了自动生成Ogre字体code_points，网上转了一圈没有找到合适的软件，那就自己动手吧，软件界面如下：

    软件中分隔线以上是单字符转换，对应上述网站的编码查找功能；分隔线以下是字符串转换，可以用他来生成Ogre字体需要的code_points格式。

    点击这里下载，注：软件需要.Net2.0 Framework。

 

转载请注明出处：

作者：gogoplayer

E-mail : gogoplayer@163.com

QQ : 78939328

http://www.gogoplayer.com.cn/

 

 

       QuickGUI是Ogre引擎下的一种用户界面，如果你使用的Ogre，而Ogre自带的Overlay无法满足你的需求时，你可以考虑QuickGUI，相对于CEGUI，他小巧，并且完全基于Ogre设计，这点比CEGUI要好，但是没有CEGUI支持那么多的控件，不过对于一般的用户，QuickGUI提供的控件还是够用的，下面是QuickGUI目前支持的控件『V0.97版本』。

 

目前QuickGUI编辑器还没有开始做，主要是想使用C＃来做UI，C＋＋只负责解析，这样的话会比较容易，虽然C＃UI那部分要重写读取和保存模块，比直接用C＋＋多了一个步骤，但是C＃开发UI的简便还是让我选择了这样做。

       了解了这些，就可以知道，现在一定先做C＋＋的XML解析部分，现在让我们把目光集中在QuickGUI XML的文件格式上。

       xml解析使用了tinyXML库，目前只支持Sheet和Window，以后会逐渐增加对其他控件的支持，其它的控件格式是类似的，XML文件描述很简单，下面放上一张截图：

 

最后再简单说一下QuickGUI的事件绑定和注入：

QuickGUI支持事件绑定，用法和CEGUI类似：     

 

 

QuickGUI可以和OIS共用，支持注入：

 

 

QuickGUI官方论坛

QuickGUI下载地址

从文件中读取并解析代码

Shawn Hargreaves Blog的blog对我很有帮助，翻译高手的文章，诚惶诚恐，一定做到认真仔细，保持原汁原味，基于外语和水平的限制，难免会有纰漏，到时还望各位指正。

 

Lsge ---2D引擎介绍

       Lsge全称为Light Shadow Game Engine，和Ogre有点像，因为这个2D引擎使用了很多Ogre的代码，因此得名。

引擎使用VS2005构建，支持Unicode，工程附带三个演示，可以帮助开发人员迅速了解，Lsge最大的特点是使用简单，内置了很多兼而易用的功能。

       Lsge是我大一、大二时的作品，设计的初衷是为了能快速写出小游戏，使开发者把注意力放在创造上，这个引擎的渲染效率不高，但是没有关系，引擎目标是小游戏，简单的演示，不是大规模游戏，在我设计期间，网络给了我所需要的大多数资料，让我有机会接触到Ogre，zlib，audiere，ois等巨人，有了他们的帮助，才有这个引擎的发展，引擎有完整的注释，文档比较完善。

       很早就想开放Lsge，回报网络，只有开放才能避免固步自封，我始终认为我所了解的只是沧海一粟。在Lsge完成的很长一段时间里，我差点忘了他的存在，前几天我想起了他，认为我改写点东西，整理出来，让他不只是在我的硬盘中，这对一些开发者可能有帮助，发表出来，将让他重获新生，最后，再次感谢Ogre，zlib，audiere，ois等巨人，感谢网络，没有你们就没有Lsge。

        附上一张引擎演示图（^_^）：

 

附加说明：

选项配置：Lsge自带所需要的库，需要注意的是Lsge所需要的DX库需要特殊配置。


 

项目属性配置：

需要把调试->工作目录设为../Bin/$(ConfigurationName)

VS2005版本较多，主要分为sp1和非sp1版本，配置比较麻烦，经常会出现应用程序没有初始化之类的错误，这些可以通过安装正确地库一一排除。

Lsge下载：
blog不支持大文件，还要分割成五份，麻烦啊。
Lsge第一部分
Lsge第二部分
Lsge第三部分
Lsge第四部分
Lsge第五部分

1：XNA2.0做UI，场景编辑工具，粒子编辑工具的3D人才
2：场景布局策划，使用工具
3：网络开发，服务器构架
4：音频传输，网络大规模音频传输

以上四个各招一人，招贤纳士啦

公司：杭州汉宜信息技术有限公司
工作地点：杭州滨江区恒生大楼301，303
电话：0571－28937318
QQ:78939328

CEGUI支持中文字体是不用说了，需要中文显示时所需的配置可以参见网络上其他相关文章，这里说得是字符串转换问题，应为CEGUI有自己的字符串类（CEGUI::String），显示时需要把char*转换为CEGUI::String，下面这个小算法可以实现这个功能，具体就不多说了，各位复制粘贴即可，^_^。

 

研究HLSL也有些日子了，其中犯了很多错误，现将沿途所遇略作纪录，以次时刻提醒自己不要重蹈覆辙。

1.         Effect文件(.fx)是标准格式，要妥善利用其接口与应用程序通讯，理解语意（Semantic）和注释（Annoation）是关键。

2.         HLSL指令集要倒背如流，切不可做出重写标准库的蠢事，当初我就写了一个distance函数来求距离，熟不知标准库里早有这个函数，仔细一研究，标准库里不仅支持三维向量，其它的诸如二维也以考虑在内，汗^_^，完整的指令集可以参见DX帮助文件，路径为DirectX Graphics->HLSL->Reference->Intrinsic Functions。

3.         不仅指令既要倒背如流，还要注意指令的限制，尤其是Shader Model（SM），像ddx，ddy这样的指令是不能用在Shader Model 1 中的，这个我感觉是比较令人沮丧的事情，程序员的代码和逻辑都正确，却限制于硬件配置的问题，还好现在硬件发展迅速，SM3.0甚至SM4.0的显卡都已经进入主流市场，这些限制会逐渐消失的。具体的限制可以查看DirectX Graphics->HLSL->Reference-> Shader Models。

4.         编译Effect的时候能用低配置的Profile就用低的，举例来说能用vs_1_1的就不要用vs_2_0，ps也是一样的道理，Profile选的越低，你的Effect兼容性就越好，如果不分清楚直接就用最高Profile，到了客户那因为显卡配置不够报错的概率就大了，至少我现在还没听说某款PC游戏只能在SM4.0下才能用，游戏机，测试程序自然不算了，以后没准等SM5.0都普及的时候，我这话也自然过时了^_^。

5.         在VS中计算屏幕坐标时要把坐标先转换成齐次坐标

a)         这样写是有问题的，mul(input.Position, WorldViewTransform);

b)         要改成mul(float4(input.Position,1), WorldViewTransform);

6.         文件最后一行要在最后加一个空格或一个空行，要不有时会有error X3000: syntax error: unexpected end of file，这样的错误信息，这种错误信息有时莫明其妙发生，例如在加了一条注释后，总之是在编写Effect的时候要格外小心谨慎。

7.         前几天还遇到了这样的错误，在ps中写了个if语句返回某种颜色，不料产生错误，错误信息如下error X3500: asymetric returns from if statements not yet implemented。现在把Effect文件内容张帖出来，为了搞清楚问题本质，我把不相关代码全部删除了，只留下必要地解释性代码。一开始没注意看错误信息，以为是那里写错了，就几十行代码折腾半天不见好转，后来仔细看错误信息后才恍然大悟，原来是Effect编译器不支持这种if用法，虽然HLSL支持以c的语法来写shader，但毕竟和c还是有区别的，编译下面的代码就会得到上述错误信息，只要在第二个return前加else，使其成为一个if－else结构，编译自然通过。由此可见，写shader时c的观念在某些情况下要转变过来，如果一味以c的直观印象去评测，极有可能出现问题。

 

以上几点皆为个人经验小节，以后遇到再做补充，某些可能还有问题，不足之处请指出共勉。文章中提到的Effect文件可以在这里下载。/Files/gogoplayer/HLSL/Test.rar

 

最近在使用.X文件时遇到了很多问题，主要集中在用panda插件导出的模型总是出现模型朝向不正确，模型比例出错等问题。

       引起这些问题的原因很多，先说说坐标系，XNA采用右手坐标系，3dsmax也采用右手坐标系，这是一样的，但是不要忘了，当我们使用DXSDK自带的模型查看器观察模型的时候，D3D用的可是左手坐标系，而panda作为.X文件导出器，自然对D3D的坐标系格外照顾，这样看起来问题有一些复杂，好在我们不需要纠缠这些，只要对上述坐标系有个数就可以了。

       因为XNA和3dsmax的坐标系相同，都是右手坐标系，这样就好办了。不过要是你认为只需要把坐标系一一对应再导出就可以了，那你就错了，仔细看看3dsmax的坐标系，你会发现他的Z是朝上的，美工建模时采用的都是这种坐标系，也就是说和我们平时常用的以Y为上向量不符，晕了吧，不要着急，下面就将关键的，嘿嘿。

1.      通过Alt加鼠标拖动3dsmax世界系，使得X轴指向左边，Y正对着你，Z朝上。

       上图中左下角就是3dsmax世界坐标系，中间有个模型，这个模型的红绿蓝三轴分别对应了XNA中的世界X，Y，Z轴，即这个模型导出后加载到XNA显示的就是XNA的世界坐标系。明白了吧，这样我们只要让美工按照这个3dsmax坐标系建模就可以了，下面说panda导出参数的设置。

2.      主要修改两处

a)     确认3DS Max Objects页中的Use local object space没有被钩选

b)         确认X File Settings页中的Left Handed Axis被钩选

经过这样的处理就大功告成了，你可能会迷惑，命名XNA是右手坐标系，为什么要选择左手坐标系导出呢？其实道理很简单，为了兼容性，.X不是微软为了XNA而设计的，他出现的比XNA早的多，都可以当XNA的爷爷了，.X本来是针对D3D开发的，而D3D默认的是左手坐标系，因此.X文件也采用左手坐标系，这时你可能又要问，那为什么左手坐标系导出的.X文件可以在XNA正确使用呢，解铃还需系铃人，答案在微软的素材导入器中，XNA默认提供的.X导入器会在那个阶段自动把左手坐标系转换成XNA支持的右手坐标系，这样不就皆大欢喜了，^_^。打开微软自带的.X模型浏览器，看起来应该是这样的：

把模型加入到XNA中去看看吧，你会有新的收获。