大型3d游戏资源加载三步曲(硬盘->内存->显存)

做过游戏的人都知道游戏的资源非常庞大，需要有一个好的后台预加载机制。现在一般都是再开一个I/O线程，主线程有I/O需求的话，将信息推入队列，I/O辅助线程从队列读出需求，从磁盘加载I/O,加载好后设置好对应状态.

但是随着游戏越来越大，单纯的这阶段处理好已经不能够满足要求，从内存到显存的这一个阶段占据的比重也越来越大，这里是再次总结强调一次.

以下举例如果设计到平台，以windows为例

1) I/O: Memory-mapped I/O技术．Memory-mapped I/O跟一般的I/O不同，有它的好处也有它的坏处，好处在：

Memory-mapped I/Ｏ不需要将资源加载到大家共用的虚拟内存文件中（pagefile.sys)．而是直接把数据所在的硬盘空间映射到进程的虚拟地址空间. 这将急剧加速磁盘文件的加载数据（windows加载exe/dll就是把exe/dll直接映射进来的,记住，这在加载的第一次很块，也就那一次）．

Memory->mapped使用的时候要注意不要超出进程的虚拟内存空间．　另外也页面对齐，这个在msdn上有说明.

Memory-Mapped 也有一些缺点，这个是os设计实现的．　一般的虚拟内存是Page Directory--> PageTables-->Physical Pages,而Memory-Mapped有四层，PageTables-->PageTables-->(mapped机制专有)-->Physical Pages.多了一层，就多了一些中断.所以会更慢一点，但对于上层应用来说，基本可以忽略.所以这个技术可以用.

2) 随着游戏的资源越来越多，也随着显存越来越多，管理的必要性逐渐体现出来．很显然，这个也是很耗时的，所以也要放一个辅助线程.