游戏性能优化特殊案例
2011-11-30 13:51
253 查看
声明:
一不小心使用了QQ的图标,希望不会惹到什么麻烦!
当然,绝不会使用qq图标作为具有商业用途的素材图片,这里仅用于讨论学术!!
在纠结一个问题,某之游戏应该采用怎样一个方案才能进一步提升效率
关卡文件是我自定义的xml文件,之前我想过将该文件持久化以提升效率(读取的时候直接将文件内容读成对象)
不过鉴于objective-c持久化的自动程度完全不能与java相比,于是我便放弃了,其实也提升不了多少效率
我也意识到这是我的一个缺陷,这本是微不足道的,但是我却吹毛求疵,不可谓不能称之捡了芝麻丢了西瓜
但是,人总是有一个目标,比如说,我就喜欢追求完美,虽然不能做到极致,但我一直向着这么目标而努力,不断的项目标靠近
这不,我又发现了一个可以挖掘的点,如下:
游戏地图背景是一张很大的图片,这张图片是我依据自制的地图编辑器描点而成
编辑完毕之后,会生成一个xml文件,这个文件保存了所有的描点数据
然后我再在游戏里面通过一个特定的关卡解析模块来完成对xml文件的解读
读取完毕之后,能够使用这些数据来生成游戏中的地图背景图片,以及相应的box2d body,游戏效果如下
岩石的纹理表示了静止不可动的山体,是具有box2d 静态物体碰撞骨骼的
看到岩石外围那一圈黑边了吗?这圈黑边耗费了我很多的精力
这些复杂的多边形本来是由简单的凸多边形拼接合成的
如果不处理而希望整个复杂多变形外围添加上一圈黑边的话,这是不可能的!
因为由简单凸多边形组成的复杂多变性内部会出现黑线,这样严重影响到了游戏ui的美观
但是如果去掉了复杂多变形的外部黑边,游戏的界面效果也会大打折扣(锯齿效果严重,切割间隙不突出)~
源自冰块可被切割的特性以及抗锯齿的表现不力,就因为抗锯齿这块我不知道如何处理,导致只能舍弃3代的市场
所以说,我既想保留外部黑边又想去除内部黑线,这是一个让我非常蛋疼的问题
想了好几天,得出一套方案,能够大部分的解决内部黑线的问题,但是还是有不完美的地方,偶尔内部黑线还是会冒出来~
说到这里,还没有走入正题,这是我的老毛病了,不过我打紧,我主要还是写给我自己看~
山体图片是由xml数据+CCRenderTexture即时渲染出来的,消除内部黑线这个方法个人认为效率还是比较低的
我并不想玩家每次在进行游戏的开始,都要做一个这样的耗费
所以我想,由于每个关卡刚开始的时候画面都是 一致的,我何不将山体纹理导出为图片保存起来呢?
倒时候直接拿来使用就是了,这不很方便么?
天从人愿,我找到了解决方案,CCRenderTexture本身就提供一个这样的方法谓之saveBuffer
说实话我开心了两天,因为我确实能将即时渲染出来的山体纹理保存成图片了,这样无疑降低了cpu的负荷
但是,经过我的仔细观察和深入思考,发现有不妥的地方:
1。生成出来的山体图片必须是png格式的,但是png格式的图片和jpg格式的图片体积相差太大了!!
换句话说,我如果用增大游戏体积的方法来降低游戏对cpu的耗费,如果游戏关卡为40关,
那么40张山体png图片的大小合计下来就是12M
(每张300kB肯定是少算了的,因为我有意将最大地图的分辨率提升到1920*1280,也就retina所支持的极限)
12M,整整12M,可有可无的12M!!! 据我的伙计说,app的大小一旦超过20MB,就无法实现无线下载安装
当然我也仅仅只是听说,不过本着宁可信其有的心态,这不是一件好事情!!
况且山体图片如此做了之后,我肯定会尝试将 每关1-6张的冰块图片亦如法炮制
有言opengl从硬盘里读取一张大图片的效率要比读取多张小图片的效率高很多
因此,我又要将1-6张小图片拼凑到一张大图片上面(Zwoptex,CCSpriteBatchNode,你懂的),这些都是要手工来完成的
这样就太麻烦了,而且又要再一次增大游戏安装包的体积,实乃得不偿失!!
不过提升性能的方案还是存在的,可以修改描点工具,在生成关卡文件的过程中就完成消除内部黑边的步骤
这样在游戏过程中就可以将这一步给节省掉了,ok,这就是我接下来要完成的工作了!!
一不小心使用了QQ的图标,希望不会惹到什么麻烦!
当然,绝不会使用qq图标作为具有商业用途的素材图片,这里仅用于讨论学术!!
在纠结一个问题,某之游戏应该采用怎样一个方案才能进一步提升效率
关卡文件是我自定义的xml文件,之前我想过将该文件持久化以提升效率(读取的时候直接将文件内容读成对象)
不过鉴于objective-c持久化的自动程度完全不能与java相比,于是我便放弃了,其实也提升不了多少效率
我也意识到这是我的一个缺陷,这本是微不足道的,但是我却吹毛求疵,不可谓不能称之捡了芝麻丢了西瓜
但是,人总是有一个目标,比如说,我就喜欢追求完美,虽然不能做到极致,但我一直向着这么目标而努力,不断的项目标靠近
这不,我又发现了一个可以挖掘的点,如下:
游戏地图背景是一张很大的图片,这张图片是我依据自制的地图编辑器描点而成
编辑完毕之后,会生成一个xml文件,这个文件保存了所有的描点数据
然后我再在游戏里面通过一个特定的关卡解析模块来完成对xml文件的解读
读取完毕之后,能够使用这些数据来生成游戏中的地图背景图片,以及相应的box2d body,游戏效果如下
岩石的纹理表示了静止不可动的山体,是具有box2d 静态物体碰撞骨骼的
看到岩石外围那一圈黑边了吗?这圈黑边耗费了我很多的精力
这些复杂的多边形本来是由简单的凸多边形拼接合成的
如果不处理而希望整个复杂多变形外围添加上一圈黑边的话,这是不可能的!
因为由简单凸多边形组成的复杂多变性内部会出现黑线,这样严重影响到了游戏ui的美观
但是如果去掉了复杂多变形的外部黑边,游戏的界面效果也会大打折扣(锯齿效果严重,切割间隙不突出)~
源自冰块可被切割的特性以及抗锯齿的表现不力,就因为抗锯齿这块我不知道如何处理,导致只能舍弃3代的市场
所以说,我既想保留外部黑边又想去除内部黑线,这是一个让我非常蛋疼的问题
想了好几天,得出一套方案,能够大部分的解决内部黑线的问题,但是还是有不完美的地方,偶尔内部黑线还是会冒出来~
说到这里,还没有走入正题,这是我的老毛病了,不过我打紧,我主要还是写给我自己看~
山体图片是由xml数据+CCRenderTexture即时渲染出来的,消除内部黑线这个方法个人认为效率还是比较低的
我并不想玩家每次在进行游戏的开始,都要做一个这样的耗费
所以我想,由于每个关卡刚开始的时候画面都是 一致的,我何不将山体纹理导出为图片保存起来呢?
倒时候直接拿来使用就是了,这不很方便么?
天从人愿,我找到了解决方案,CCRenderTexture本身就提供一个这样的方法谓之saveBuffer
说实话我开心了两天,因为我确实能将即时渲染出来的山体纹理保存成图片了,这样无疑降低了cpu的负荷
但是,经过我的仔细观察和深入思考,发现有不妥的地方:
1。生成出来的山体图片必须是png格式的,但是png格式的图片和jpg格式的图片体积相差太大了!!
换句话说,我如果用增大游戏体积的方法来降低游戏对cpu的耗费,如果游戏关卡为40关,
那么40张山体png图片的大小合计下来就是12M
(每张300kB肯定是少算了的,因为我有意将最大地图的分辨率提升到1920*1280,也就retina所支持的极限)
12M,整整12M,可有可无的12M!!! 据我的伙计说,app的大小一旦超过20MB,就无法实现无线下载安装
当然我也仅仅只是听说,不过本着宁可信其有的心态,这不是一件好事情!!
况且山体图片如此做了之后,我肯定会尝试将 每关1-6张的冰块图片亦如法炮制
有言opengl从硬盘里读取一张大图片的效率要比读取多张小图片的效率高很多
因此,我又要将1-6张小图片拼凑到一张大图片上面(Zwoptex,CCSpriteBatchNode,你懂的),这些都是要手工来完成的
这样就太麻烦了,而且又要再一次增大游戏安装包的体积,实乃得不偿失!!
不过提升性能的方案还是存在的,可以修改描点工具,在生成关卡文件的过程中就完成消除内部黑边的步骤
这样在游戏过程中就可以将这一步给节省掉了,ok,这就是我接下来要完成的工作了!!
相关文章推荐
- 游戏性能优化特殊案例
- 案例研究:使用英特尔GPA优化《剑侠情缘三》游戏的性能
- 优化hbase的查询提升读写速率优化案例及性能提升的几种方法
- SQL Server性能优化案例报告
- 总结使用Unity 3D优化游戏运行性能的经验
- unity游戏性能优化之简单内存优化
- 【Android游戏开发十五】关于Android 游戏开发中 OnTouchEvent() 触屏事件的性能优化笔记!
- Android性能优化案例研究
- 基于Web应用的性能分析及优化案例
- 嵌套For循环性能优化案例
- 大数据应用之HBase数据插入性能优化之多线程并行插入测试案例
- 嵌套For循环性能优化案例
- 游戏开发性能优化经验总结
- 【Android游戏开发十五】关于Android 游戏开发中 OnTouchEvent() 触屏事件的性能优化笔记!
- oracle :性能优化的一个案例
- 清算/报表/日终跑批程序之性能优化案例(一) 推荐
- 总结使用Unity 3D优化游戏运行性能的经验
- AMD OpenCL大学课程(12) 性能优化案例NBody
- C++游戏服务器的性能优化
- 总结使用Unity 3D优化游戏运行性能的经验