我嘗試使用zlib打包和壓縮遊戲客戶端資源數據。如果我壓縮數據，它將減少磁盤I/O的大小，但會增加解壓縮時的CPU使用率。打包並壓縮資源數據
問題1
如果用於渲染的資源被壓縮，處理（渲染和解壓）使用的CPU，所以我覺得這似乎是相當緩慢的，是不是？
如果沒有壓縮，則磁盤I/O沒有改變，並且不會發生額外的CPU使用。如果只讀取文件的一部分，則可以通過使用CreateFileMapping（），MapViewOfFile（）函數來減少DISK I/O。
問題2
在資源，如非壓縮圖像的情況下（例如TGA，不是PNG）當我們讀取整個文件（圖像文件前），我們無法獲得adventage的CreateFileMapping（），MapViewOfFile（），所以我認爲壓縮資源更好，你怎麼看？
問題3
你怎麼看待包裝的時候壓縮的資源數據是什麼？
遊戲資源不僅可以縮小尺寸，還可以通過將許多小文件合併爲一個來減少搜索次數，這比磁盤上的大小要重要得多。傳統硬盤上的一次不必要的查找花費與讀取千兆字節數據相同的時間。即使您的「壓縮」只包含連接小文件，您已經獲得了性能。
作爲一個小小的好處，資源包裝在一個檔案中會讓他們不敢從計算機高端的人身上遮住他們，阻止他們修改遊戲資產（儘管承認這不是一個很大的障礙！）。
Q1：根據您使用的壓縮算法，您可以輕鬆獲得1 GB/s以上的解壓縮（使用快速CPU接近2 GB/s）。即使在固態下（通常更少），順序磁盤I/O仍然大約爲300-400 MB/s。隨機存取磁盤I/O速度較慢5-20倍，具體取決於磁盤和訪問模式。
另一方面，如果您選擇一種較慢的算法，那麼您可以以每秒幾十千字節的速度獲得解壓縮速度，這比僅從磁盤載入更多數據要糟糕得多。祕訣在於選擇一種算法壓縮比較合理（不完美，合理），並且運行速度很好。壓縮速度通常並不重要，因爲這是一次離線完成的。候選算法例如LZF，Snappy或LZ4。
無論內容是否被壓縮，通常都可以使用文件映射。此外，相反，檔案圖僅爲而非僅佔很小部分的優勢。讀取量越大，它的優勢就越大（使用傳統讀取時，實際上非常小的視圖可能會更快）。
Q2：未壓縮的圖像通常不會在遊戲中出現。大多數情況下，您希望使用DXT壓縮，而不是減少磁盤I/O，但要減少內存和PCIe帶寬要求以及GPU內存消耗。 DXT是一種非常差的壓縮，但它可以在硬件中工作，並具有完全可預測的壓縮比。您可以使用傳統的通用壓縮機（具有不同的速率，取決於您使用的壓縮機，還有一些爲此目的而特別優化的壓縮機）再次壓縮DXT壓縮紋理。
Q3：對於任何非平凡的遊戲，包裝資源絕對可取。