今天在做项目之余抽出点时间来看Ogre,可谓且喜且忧
看过之后一扫当初对Ogre的恐惧感,让我比较惊异的是这种代码结构让我感觉异常舒服。彻底见识了与国外编程水平的差距。
Ogre的代码优雅至极,清晰的思路与结构让我折服,看demo的过程其实是另外一种修炼。
这个工程依赖于ogre提供的两个实例基类,一个是ExampleApplication和 ExampleFrameListener
里面其实就是对应用实例的2次封装,SkyBox继承自ExampleApplication同时响应了帧监听
这个监听就是观察着模式的原型
然而,创建场景的过程全部由ExampleApplication一手包办了。
这个监听过程做得很巧妙,不过创建个人项目我还是想把其再次封装下至少当出现渲染崩溃的时候抓下到底哪里出了问题。
while( !mQueuedEnd )
{
//Pump messages in all registered RenderWindow windows
WindowEventUtilities::messagePump();/// 以往看到的代码都是将window的解析和执行过程做到一起,这里写得相当优雅
if (!renderOneFrame()) /// 如此每次循环调用监听表,监视事件改变
break;
}
bool Root::renderOneFrame(void)
{
if(!_fireFrameStarted())
return false;
if (!_updateAllRenderTargets())
return false;
return _fireFrameEnded();
}
这个代码中真正起作用的
void createScene(void)
{
mSceneMgr->setSkyBox(true, "Examples/SpaceSkyBox", 50 );
}
/// 代码就几句话,结构非常清晰
class SkyBoxFrameListener : public ExampleFrameListener
{
SkyBoxFrameListener(RenderWindow* win, Camera* cam) : ExampleFrameListener( win, cam )
bool frameRenderingQueued( const FrameEvent& evt );/// 帧监听响应函数
}
class SkyBoxApplication : public ExampleApplication
{
public:
SkyBoxApplication() {}
virtual void createFrameListener(void) /// 创建监听器
{
mFrameListener= new SkyBoxFrameListener(mWindow, mCamera);
mRoot->addFrameListener(mFrameListener);/// 添加到监控列表
}
void createScene(void);/// 创建场景内容 ExampleApplication 中存在的虚拟基类
}
如此代码下面包含的设计模式有2虚基类里面涵盖单件模式,创立Mipmap纹理映射等级 TextureManager::getSingleton().setDefaultNumMipmaps(5);
纯虚函数 virtual void createScene(void) = 0; 创建场景由子类实现从而实例化抽象类
用观察着模式 FrameListener 来控制场景管理器控制frameRenderingQueued里面客户的动作事件捕捉
灯光,实体等通过基类的SceneManager* mSceneMgr指针去完成
调试信息,提供了非常明确的接口
显示数据:最大fps,最小fps,平均fps,三角形数量等等
plugins.cfg 罗列所需插件列表
Ogre.cfg 存放窗口的详细信息
resources.cfg 存放全部的资源配置路径
目前来看代码结构极其清晰,产生第一个Ogre项目变得得新应手起来,我激活了学习Ogre的兴趣,虽然当下仅是个开始。
SkyBox可谓‘麻雀虽小,五脏俱全’ 一扫当初“学习慌”的心态
简单牢骚几句
Ogre的代码风格和CEGUI很相似,两者阅读的方式差不多。不过Ogre代码量大一些,需要的实践次数要远比cegui大得多。就扩展而言,cegui的扩展主要偏向于应用控件属性扩展,也就是针对当下的需求‘重新组装’控件结构的过程;Ogre如果想扩展的话,需要的准备工作就比cegui多一些了,比如如果想达到更炫的粒子效果,必须做更深一层的扩展开发。
相似之处:设计模式上普遍采用单件和工厂,监听者模式仅见于Ogre Demo,这个也可以理解,cegui主要是应用于界面开发,而ogre作为一个引擎一部分,所需要的操作更多一些,毕竟是开源引擎,弱点都存在,就是工具稀缺,大部分都得自己动手写。
不同之处:cegui学习主要是应用窗口属性扩展也仅限于属性扩展,至于布局方面,cegui框架提供的looknfeel外观设计模式可以帮我们完成很多东西,Ogre作为一个渲染引擎,cegui完全可以说是渲染原件的一部分;ogre偏向于整个游戏的成型过程,需要扩展的方面非常多,比如地形,编辑器,网络等等都需要自己手动开发。另外,cegui并不适合开发编辑器,毕竟专属于游戏界面引擎,也需在Wx或者Qt作为一个图形开发工具2次包装ogre来完成制作