real-time 3d terrain engines using C++ and DX9 翻譯 3

 cGameHost包含的一個關鍵管理對象就是資源管理員（resource manager）.我們的程式使用他自己的管理系統來管理我們將要建立的裝置。這個資源管理系統的根，cResourcePoolManager類，是建立在一個我們引擎中提供的支援類的集合的基礎上的。在我們討論資來源物件本身，我們花一點時間來瞭解這個我們將要使用的資源集區和將會使用的資源管理計劃。

 

建立資料池

       一個高效記憶體管理的關鍵就是限制分配的總數。完成這個最簡單的方法就是將相似的物體組合起來成為一個大的記憶體配置。我們把這個叫做記憶體池（date pools），使用他們作為複合物體的容器。其中包含的物體被認為是池的成員，並且通過使用控制代碼被提供給要求者。成員可以被客戶請求和釋放，同時以固定的增量來擴張資料池以滿足更多成員空間的需要。

       這是一個代碼會變得複雜的地方。我們想要這些池是型別安全的，所以他們被建成模板類（template calsses）——實用一個特殊的資料類型來代表池的成員。然後，依然需要使用一個普通的介面所有這些池間的通訊。當我們隨後建立維互紋理，頂點，動畫的資料池的資源管理員的時候，在不同的池間通過一個普通的介面實現通訊對於建立和銷毀這些資源就非常重要了。因此，即使資料池他們自己是獨立的模板類的執行個體，他們也必須繼承自一個可以用來建立和釋放成員的外部管理類的普通介面。

       雖然有充足的理由來簡單的分配一個大的數組並且通過他們的數組索引引用他們，但是這個方法非常的不靈活。數組的大小必須事Crowdsourced Security Testing道，並且數組不能超過預先分配的大小，因此限制了能夠在遊戲中使用的對象的數量。固定數組提供了最佳化的記憶體使用量，同時卻犧牲了能夠容納的對象的數量。當我們明確的知道我們遊戲中要使用的物體的數量並且確實可以被預先分配記憶體的時候，這是一個好主意，但對於我們開發迴圈，我們需要更多一些的靈活性。

       程式中管理資料池的解決方案，cDatePool模板類，不是真的包含一個成員對象的大小。事實上，它包含了一個成員對象的鏈表（linked list），叫做cPoolGroups。每個組包含一個固定數量的成員對象，能夠根據需要從資料池中增加和刪除。這是一個在高效記憶體使用量和固定對象數目的折中方案。當資料池根據需要增長，它只能按照預訂的塊（chunk）增長，每次分配一塊新的成員對象。

       這個設計最有價值的地方就是他可以被轉化成常規數組而不會影響遊戲的其他方面。在資料池建立對象樹的同時嵌套的為每個成員建立了一個獨立的縮影。如果資料池維護的對象數退化為常規數組，這個索引值依然不會變。4.1並列的展示了這兩個資料結構，並且比較的展示了他們索引方法的相似性。資料池的這個屬性使用資料池的靈活性來工作，儘管是少一些效率的方式，我們隨後可以用一個高效的，常規的數組一次分配所有的需要的記憶體來代替。對遊戲來說，資料池中的對象作為控制代碼使用的索引值不會改變。

 

使用cDatePool類的樹狀儲存方式或者是常規數組方式意味著一塊記憶體塊將被重複使用。當資料池中的成員被釋放，這些儲存空間變為可用的以被接下來的請求使用。因此，我們需要追蹤哪些成員是可用的，這樣當請求空間的時候可以被快速的在池中找到可用的縫隙。在cPoolGroup中，我們維護一個開放成員的列表。它只是一個對應於組中成員數目的簡單的WORD值數組。數組中的每個值表示它對應的池成員是否可用。

每個正在被使用的成員在數組中使用一個常量（INVALID_INDEX）表示它是停用。那些可用的成員形成一個索引值的鏈表。每個成員包含表中下一個可用成員的索引。我們的cDatePool類儲存第一個可用執行個體的索引值，最後一個可用執行個體的包含它自己的索引值來表示這條鏈的結束。我們可以通過簡單的返回第一個可用的索引並且將我們的內部控制代碼移動到下一個可用索引（如果有的話）來返回一個可用的成員給調用者。當調用者把成員釋放回資料池，我們簡單的將我們的控制代碼直接指向返回的成員，這個控制代碼先前是指向先前可用成員鏈表的頭部。

查看原始碼將更容易理解這個過程。完整的資料池對象的原始碼可以在配套CD的source_code\core\date_pool.h中找到。這些對象的函數要全部在書中列出實在是很棘手的事情，但是負責從資料池中添加和移除成員的函數可以在清單4.2中找到。這些例子展示了定位可用cPoolGroup，從中釋放一個可用索引，建立一個包含索引值的cPoolHandle對象給調用者的基本操作。釋放扯遠，成員將在池中背定位並且放在可用成員鏈表的前端節點中。