转自原文
http://www.cnblogs.com/lookof/archive/2010/03/06/1679633.html 这个问题我也遇到过,确定DX版本和VC版本对应就OK
Ogre3D官方于上个月末放出了1.7的稳定版本。据称该版本与旧版1.6x比起来,改动幅度较大。因此作为一名Ogre使用用户,“与时俱进”既是我的责任,又是变被动为主动的上乘战略。于是,学习新的Ogre系统成为我计划中的一部分。
与以往不同,新Ogre的编译策略完全采用了CMake安装方式。为此,你首先要下载CMake工具才能安装Ogre。不过,官方在wiki中对如何安装新Ogre进行了详尽的说明,包括在哪里下载CMake以及如何使用它,都有step-by-step的指导。因此只要按照说明来,你“应该”可以顺利地看到通过CMake释放出的Ogre.sln。
之所以说“应该”,是因为种种原因,还是有相当大的几率会遇到“挫折”。遇挫的可能性取决于与新Ogre有关联的周边配置。拿本人案例来说,就是要看你的DX SDK版本以及VC版本是否一致了。
具体我的悲惨编译经历如下:
. 在公司机子上下载Ogre1.7并按指导进行安装,选择VC2003编译器编译,一切顺利,没有见到任何阻碍。很快就看到了Ogre.sln;编译Ogre.sln,全部顺利生成成功。心想新Ogre的用户体验不错嘛,没想到这么顺。注意,此机子的DX9 SDK版本是2009(March)的。
. 回家后重新下载Ogre1.7并安装,打算给本本也升级至新版。本本的DX9 SDK版本还停留在05年的古董级。就这样,开始,同样的步骤(依然选择了VC2003编译器)——然后,所以但是卡壳了。CMake在处理RenderSystem_Direct3D9时出现问题,具体出错信息想不起来了,抱歉。但稍稍分析一下即知,是找不到DxErr.h这个文件。经过google知道这是一个DX9 SDK新版本里的文件。于是,卸载旧的版本,选择最新的DX9 SDK (2010 February版本,新鲜出炉的呀)安装。
. 接着重新一开始的步骤——然后,终于见到Ogre.sln了,很好很强大。然后继续Ogre.sln的编译。经过近一个小时的编译——全部生成——除了一个RenderSystem_Direct3D9的工程!我艹,又是它。分析得知,DxErr.h虽然有,但它里面用到的__in却是一个无法识别的符号。继续google,得知__in是存在于VC2005中的一个系统变量。换句话说,如果要使用DX9 SDK(2010 Feb)版,就要用VC2005来编译工程了。
. 重新卸载了DX9 SDK(2010 Feb)版,下载了DX9 SDK(2009 March)版来装。然后,再次开始编译旅程——终于全部搞定!
从这里可以看到这个编译过程实际上对 Ogre – DX9 – VC 这条链上的版本有相对严格的要求。Ogre – DX9的环节可能会出错,同样DX9 - VC的环节也可能会出错。
Done~
ps: 顺便一提,在参观Ogre1.7的地形Sample时,点击Start后会发现程序陷入“死掉”状态,突然就那么不反应了。开始我以为又是什么bug所致,追踪源码后发现,原来是初次运行时Ogre要计算一张1024*1024的光照贴图(见OgreTeerain.CalcLightmap.for.for),此时用时较长,并没有真正死掉,只要耐心等一段时间,就会顺利打开这个Smaple,而且这张lightmap是生成一次,终生受用的。以后只要还是相同的地形,再次打开时直接载入,不必再等那么长的时间了。
另外,发现Ogre还没有提供对1.7系统的学习指导wiki,我想只有靠自己去摸索了。最好的方法应该就是认真参观各Sample大神了吧。
posted on 2010-06-08 10:12
风轻云淡 阅读(1037)
评论(2) 编辑 收藏 引用 所属分类:
OGRE