GoFoot Enginee目前进展
2008-09-20 14:57
232 查看
最近在引擎底层方面做了不少工作包括顶点缓存,纹理管理,多流管理等,在参考了大量directx sdk以及ogre的代码以后得出以下几个结论。
1。不要去写自己的纹理管理器而应该用dx自带的manage类型的纹理,除了那些需要创建在default_pool的纹理外
2。同样不要写自己的顶点缓存管理器而应该用manage类型除了那些一定需要创建在default_pool的顶点外
3。对于在default_pool的资源管理也应该使用尽量简单的调度策略,由于大多数纹理顶点都属于静态资源所以用manage类型是最好的选择,自己做管理不但要考虑各种调度策略还要综合考虑顶点格式纹理格式的影响非常麻烦,而且可能随着dx10的普遍而被淘汰,dx9文档上写了如果混用default_pool和managed类型资源会使得dx的内置管理器confused从而会有效率上的损失。
4。多流对于速度提高非常显著基本将一个流增加到5个流以后对于画一个256X256的地形速度可以提高一倍
今天开始重构GFNode和子类GFSceneNode以及GFScenemangaer类准备加入4元数支持的旋转,目前只是简单的通过矩证完成的。
说起前缀名GF,那是GoFoot的缩写,想当初这是自己和好朋友开发的第一个虚拟社区网站,哈哈一直想不出什么好的名字命名就暂时用这个了o(∩_∩)o
最近不少人对自己开发这个引擎表示怀疑和不屑,也得到不少死党的支持比如偶的好同事BoBoQian还有可爱滴Young弟弟,其实就目前计划我只希望能够做一个能够十分容易就产出一个游戏的编辑器,其实做了也是自己玩哈哈 。至于以后能否应用到商业领域就只能随缘了。
1。不要去写自己的纹理管理器而应该用dx自带的manage类型的纹理,除了那些需要创建在default_pool的纹理外
2。同样不要写自己的顶点缓存管理器而应该用manage类型除了那些一定需要创建在default_pool的顶点外
3。对于在default_pool的资源管理也应该使用尽量简单的调度策略,由于大多数纹理顶点都属于静态资源所以用manage类型是最好的选择,自己做管理不但要考虑各种调度策略还要综合考虑顶点格式纹理格式的影响非常麻烦,而且可能随着dx10的普遍而被淘汰,dx9文档上写了如果混用default_pool和managed类型资源会使得dx的内置管理器confused从而会有效率上的损失。
4。多流对于速度提高非常显著基本将一个流增加到5个流以后对于画一个256X256的地形速度可以提高一倍
今天开始重构GFNode和子类GFSceneNode以及GFScenemangaer类准备加入4元数支持的旋转,目前只是简单的通过矩证完成的。
说起前缀名GF,那是GoFoot的缩写,想当初这是自己和好朋友开发的第一个虚拟社区网站,哈哈一直想不出什么好的名字命名就暂时用这个了o(∩_∩)o
最近不少人对自己开发这个引擎表示怀疑和不屑,也得到不少死党的支持比如偶的好同事BoBoQian还有可爱滴Young弟弟,其实就目前计划我只希望能够做一个能够十分容易就产出一个游戏的编辑器,其实做了也是自己玩哈哈 。至于以后能否应用到商业领域就只能随缘了。
相关文章推荐
- 到目前为止的进展情况(v.1.0.0.4)
- Atitit 人工智能目前的进展与未来 包含的技术 v3
- go 工具链目前[不支持编译 windows 下的动态链接库][1],不过[支持静态链接库][2]
- 目前工作进展
- 新书目前的出版进展
- 关于目前素数的进展记录
- 工作业务时间学点java,目前有点进展
- 我的3D Engine ( ALGA )目前进展情况
- 中科院自动化所介绍深度强化学习进展:从AlphaGo到AlphaGo Zero
- (一)VR播放器项目介绍和到目前为止的工作进展
- 目前进展中存在的问题,绝对不能当成惯性来执行。
- 我的3D Engine ( ALGA )目前进展情况
- Atitit 人工智能目前的进展与未来 包含的技术 v2 r99.docx
- UIScrollView 弹性 消失的问题,目前无解
- go语言init和main函数
- 目前使用的stm32的开发环境及其工具
- Go学习笔记-Go语言数组array和切片slice
- iphone视图屏幕元素-像素大小 目前iphone,ipod touch 屏幕:320*480
- Go语言的beego框架中的orm中的Read函数使用
- 文本分类专题(ultimate 版)绝对是目前最全的C++版开源文本分类代码和最令人耳目一新的实验解释