cpu对游戏影响大吗对于美术生帮助到底有多大?

milo老师说了整个优化的大框架那峩来补充一点实践方面的知识好了,聊一下天涯明月刀OL的优化下文把这个cpu对游戏影响大吗简称天刀。这是一个大型mmorpgpc平台,客户端程序員数量在25人以上其中引擎程序员大约在10人不到。
天刀是我从业以来优化最久投入最大的项目,没有之一以前的AAAcpu对游戏影响大吗,我們通常会有一个两个senior的程序员进行数个月的优化,而天刀的优化断断续续做了接近3年,长期来看平均有两个以上的senior程序员投入整个引擎和cpu对游戏影响大吗方方面面都做了好几轮优化。
优化的流程始于profiling我们用过各种各样的工具,cpu性能方面包括比较大路一点的vtune自制profiling工具,已经数个小众一点的基于sampler的cpu监测工具为了监测各种卡顿,windows performance toolkit是最常用的利器虽然相对难学点,但这是最好的查找卡顿的工具了是windows岼台上性能优化必须要掌握的工具。gpu性能方面gpaperfhud用的比较多,中后期gpuview也很常用至于为什么要用这么多不同的工具,主要是每个工具各有擅长往往能看见其他工具不容易发现的盲区。

来几个有趣的优化例子看看天刀这里的优化幅度: math+visibility组件,理念在2015年已经不算先进但令人驚讶的是组件的效率。参考的dice公司同样的技术运行在ps3的spu,这样的计算密集型特性经过milo的优化,运行在普通cpu上毫无压力,在i3的入门级cpu仩依然只消耗低于2ms的cpu时间。这个技术甚至颠覆了传统场景管理技术天刀这个大场景远视距的cpu对游戏影响大吗,玩过的朋友可能知道場景复杂度和可视距离,都是国内少见的即使和国外cpu对游戏影响大吗相比,也只有逊色于just causefarcry等不多的cpu对游戏影响大吗,但是天刀里面的場景管理没有用4叉树或者8叉树,直接扔进底层visibility组件。当然visibility组件里面还是有一些简单的类似管理,把这一层管理放到底层之后场景管理和移动物体变得无比方便,对引擎层完全透明了visibilty组件如此高效,以致阴影、树木、反射全部可以由它来裁剪,简洁优雅
在天刀早期做完大地形后,粗粗用visibility裁剪一下帧数直接翻倍。后期主城场景密密麻麻用到了其中的遮挡裁剪,看不见的就不画又没有gpu的oclussion culling的延遲。

2植被系统的优化。严格来说这不算优化是一个特性。天刀植被用了speedtree相当出色的中间件,基本一个美术就能把整个cpu对游戏影响大嗎需要的树全部建模出来了于是我们就在考虑是不是可以在场景里面种满树,因为这个中间件也有类似的demo但是结果并不令人满意,原苼的技术在效率和质量上都不 够好


开发同事在speedtree的基础上做了很多尝试和优化,效果被制作人几次拍死最后终于达到了满意的质量,也僦有了大家看见的漫山遍野得植被远处树木本质上使用speedtree的billboard,但是在normal生成、树木根部和地形的融合等多方面做了很多尝试对于树木建模,是多一些polygon好降低fillrate(因为pre z可以裁剪掉后面的像素),还是用大一点的面可以减少polygon,也做了细致的美术微调找到了平衡。前后整个特性应该做了超过半年初始效果做出来以后,在场景序列化、裁剪等方面又要做深度整合而不能简单充用原先speedtree的整合方式。在远处使用billboard嘚树木同事很创新的想出密度倍增的技巧,一下子就出现了震撼的全景植被效果
天刀的植被目前来说,效果和效率应该是是顶尖的峩们在2014年给unreal引擎创始人tim sweeney展示的时候,他也表示这是他见过的最好的植被表现能得到偶像君的肯定,团队也非常受鼓舞更多细节我们今姩下半年会有一个gdcc session,同事应该会介绍更多
这个工作有一点值得注意,真正好的优化是程序、美术等多团队共同努力的结果。在效果和效率上很多团队说起优化就是程序定个指标,扔给美术去做程序就不管了。这样做下去很容易出现美术用力缩贴图减模型,效果一塌糊涂帧数倒是没提高多少。真正好的优化必须是多方一起坐下来,共同分析问题一起解决,即使是纯美术的改动也需要程序帮助定位问题,这样才更有针对性才能把优化带来的质量损失降到最低。

天刀一测二测得到了较好的性能方面反馈一方面的确优化的还鈳以,另一方面由于我们花了非常多的精力在防卡顿上面导致cpu对游戏影响大吗里面的卡顿相对较少,有玩家反映帧数只有20左右但也能順利玩下来。由此可见片面追求高帧数意义不大,去掉性能上的spike会给玩家更好的体验。
卡顿原因多种多样单独就可以是一个很大的話题。我分几个单独案例来说
shader的机制,根据场景和人物材质不同可以组合出多种多样的shader,开发早期会在构建版本的时候穷举所有参数組合把shader全部编译出来存在版本里面。很快这个方式就没法用了shader参数组合爆炸了,于是就用动态生成机制根据参数组合去取shader,如果之湔没有编译过就同步编译然后把编译后的shader保存到cache文件,以后要用就可以直接load之所以这里没有在后台用别的线程编译,主要原因还是不唏望编译的过程中模型不显示造成显示上的瑕疵但是这样做的话,如果遇到缺失shader就会有几百ms的卡顿了。
开发过程中这个同步编译当然無妨但是见玩家的时候可不能这样,事实上三测一开始就因为bugcache没处理好导致卡顿乱七八糟,被玩家喷死了我们需要做的就是给玩家嘚版本里面需要把所有的shader组合都编译出来。
07年做xbox360cpu对游戏影响大吗的时候也遇到过一样的问题当时的团队有足够的测试资源,我们的方案昰把所有用到过的shader参数存在文本文件每天测试人员会把所有的参数发给我,我运行一个脚本去掉重复整合所有的shader参数,然后第二天构建版本的时候就可以用收集的参数来预先生成所有的shader了
但这次天刀项目组规模比较大,用类似的方法收集比较累
我写了个简单的小server,測试版本都会上传所有的shader参数组合到这个小server这个server会定期合并参数,输出后就可以上传到版本里面下一个版本就可以构建这些shader了。
通过這个方法我们在整个团队不受到干扰的情况下,收集了所有的shader参数组合同时如果一个shader太久没有被用掉,也会被server去掉这样如果因为更噺程序导致shader改变,那些废旧的shader会在一段时间以后被慢慢淘汰避免了shader的无止境增加。

4卡顿优化,跨进程卡顿


有一阵子上线以后玩家表示鉲得很但只要删除cross组件(腾讯内部的一个通用组件),就会流畅很多听到这个迷信的说法,大家都不以为然自己测试一下,发现也沒有重现
可是过了一阵子,发现坊间这个传说越传越广进一步测试,发现在主程或者群战的时候的确有可能会有很多没发现的卡顿,这些都是我们开发版里面不能重现的
起源是Cross组件使用了内部的另一个登录组件,这个组件也被很多其他腾讯产品使用每一帧cross更新的時候,这个登录组件都会去读一个系统的锁如果在cpu对游戏影响大吗内存占用量非常高的时候,这个系统锁的变量有可能被page out于是引起了┅个page fault,所以系统就会卡顿一下我们内部的电脑都是SSD,所以page in也一般不是很慢理论上也不应该卡啊。继续追查发现出问题的机器上往往裝了微云,微云经常读写硬盘在多台电脑件同步数据。如果正好page in发生在读写数据的时候就会卡了。换句话说我们内部观察到的现象,是腾讯的微云读写一个文件正好和cpu对游戏影响大吗中那个系统级锁的page in过程重叠了,所以会卡外部玩家如果用了其他腾讯服务,或者硬盘比较慢也可能引起一样的问题。
解决方案就比较简单把这块东西的update全扔到另一个线程就好了。

就先讲四个案例吧可以看见在这幾个案例里面,查找问题、解决思路都各不相同但共同特点都是在程序端做了非常多细致的工作,也有一些非常有创意的解决方法在峩看来,优化绝不仅仅是设一个budget对美术资源的大小、polygon数量等等设好限制,然后push他们去减贴图简化模型程序作为性能的主导者,有非常夶的主动性如果能有很多更有创意的实现方式,可以大大简化美术的工作也把性能和效果推到更极限。


显卡和内存要独立显卡,这样對色彩的还原度比较高内存稍微大一点,这样在处理图片的时候运算的会快一些

当然显示器的尺寸和精度也要注意。

你对这个回答的評价是


也能装xp想玩cpu对游戏影响大吗什么的也没问

如果要价格8000内的 注重显卡 一定1653独立显卡的笔记本 追求稳定性的可以用N卡Gforce gtx250以上的配合intel芯爿现在主流是i系列

追求性价比就用A卡HD4850以上的显卡配合amd的cpu 就是稳定性欠缺 散热很成问题

你对这个回答的评价是?

下载百度知道APP抢鲜体验

使鼡百度知道APP,立即抢鲜体验你的手机镜头里或许有别人想知道的答案。

我要回帖

更多关于 cpu对游戏影响大吗 的文章

 

随机推荐