首页 > 未分类 > 资源的后台加载
2019
11-29

资源的后台加载

现代的游戏大多资源量都比较大,无法做到游戏启动之初就加载了全部资源,所以资源动态加载必然要做。下面说一说一些不同的资源动态加载方案。

第一种方式,分贞加载。所谓分贞加载顾名思义就是把游戏资源的加载分解到不同贞去做,这样可以降低某一贞突然加载大量资源导致的帧率急剧下降。这种分贞可以是以资源为单位,也可以加载步骤为单位。比方说第一步进行磁盘IO,第二步进行一些资源使用前的准备工作(如提交显卡等),这些步骤也可以分别放在不同贞中进行。为了使贞率更加平稳,可以限定每贞加载的量,或者时间阈值。比方说目前渲染以贞的时间是10ms,目标帧率是30贞,这样还有20ms左右的空闲时间,这时可以在加载的时候累计耗时,如果超过20ms则停止当前贞的加载,剩下的放到下一贞进行,直到加载完为止。这种方式的好处就在于控制比较简单,容易,当然他的问题也比较明显,就是资源将会一个个加载,在游戏时看到的东西一个个的出。

第二种方式,后台加载。所谓后台加载就是在后台线程中进行资源的加载,它不影响主线程。从资源的整个加载过程来看主要有两个比较耗时的地方,首先是磁盘IO,再有就是申请显卡资源并提交数据。这两个耗时的地方又以磁盘IO耗时最多,同时磁盘IO本身就是设备阻塞的,cpu时间很低,因此资源的磁盘IO一定是要放在多线程中的。而对于显卡资源申请,提交数据等,获多或少会涉及加锁的问题。我不太推荐这一块也放入多线程中,原因很简单,经过测试磁盘IO后台加载已经可以解决掉80%以上的加载效率,显卡资源的申请和提交即使能够提高渲染效率也不多,但是他会提高程序设计上的复杂性,简单的事情简单的设计将会被更多的加锁,解锁操作打乱,不值得。

下面我具体说一下我的后台加载方案。

在引擎里面(也可以在引擎外)有一个后台IO池,之所以是IO线程池是因为磁盘IO会在设备级阻塞,对cpu几乎没有消耗,也就是说它是一个运算量比较低需求。而使用IO线程池可以同时加载多个又不会造成cpu资源占用过多。而到底多少个合适取决于加载的资源量和细碎程度,他是可以外部配置的。与此同时磁盘IO可以做得很独立很模块化,和引擎其他模块交互到最少,这样极大的减少了加锁减锁的操作,设计上也会比较简单。

另外只有那些逻辑无关的东西才会被后台加载,比如场景中的树木,石头,箱子等。因为他们加载后就只有显示了,也不需要立即。而逻辑相关的东西比如某个npc,如果使用后台加载则需要额外设计,因为他们往往是加载之后就要有某些响应,比如播放某个动画,使用后台加载则会导致逻辑复杂,带来的麻烦多于好处,而且隐含大量的潜在Bug。

综上所述,场景里面的静态模型特校等使用后台io进行资源加载,加载后直接显示即可,npc这样的逻辑的东西需要把他们分一分类,那些是最常用的那些不是,最常用的则在游戏启动的时候就把资源加载好,而不常用的npc可以使用分贞进行加载。

 

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/Leo1981816/archive/2010/09/08/5869960.aspx

最后编辑:
作者:搬运工
这个作者貌似有点懒,什么都没有留下。