我一直在爲最後幾天的工作方法,以保存時將我的xna遊戲的144百萬磁貼表示壓縮爲非常小的尺寸。設法解決這個問題後,我現在發現自己難以應付如何從文件中將它們從大塊中分離出來。請求方向加載我的文件塊(只需要建議)
在我有的文件中。
- 一個整數(它被壓縮到使用7BitEncodedInt方法字節)
- 字節
壓縮整數表示的片的數目和隨後的字節確定什麼類型的磚。這一切都很好,並且運作得非常好。最重要的是,它將文件大小平均縮小到只有50mb。
問題是我正在讀回整個文件。 從文件我得到這個。
- 每一瓦片的索引值(只是一個基本迭代作爲我搶瓦片)
- 類型每一瓦片爲字節值
- 表示用於該圖塊的紋理的一個字節值(這是很難解釋,但它的必要基於每個瓷磚)
所有這一切的最終結果是,我設法保存文件,只使用約50MB。但是通過重新裝載整個東西,擴展到了將近1.5G的內存。我無法承擔犧牲任何瓦信息。所以我需要一種只根據玩家位置加載地圖部分的方法。目標是在100-200mb範圍內
我一直在尋找內存映射文件,使用quadtrees,幾乎所有我能找到的用於加載文件的塊。雖然這些選項似乎都很不錯,但我不確定哪個是最好的,或者如果考慮到情況,可能會有另一個更好的選項。所有這些問題的另一個問題是,這些解決方案似乎都很涉及(尤其是因爲這是我第一次使用它們),雖然我並不反對把自己投入一些冗長的編碼,但我想知道它會做我所做的需要它之前。
我的問題是,鑑於我在處理文件時需要如何處理文件,並且需要根據播放器位置來完成這一事實,那麼最好的方法是什麼?我只是在這裏尋找一些方向。代碼總是受歡迎但不是必需的。
在我頭頂,jst看看你是否可以優化你存儲在文件中的數據和你想傳輸的數據。把它分成幾塊,只發送需要的東西。對於網絡傳輸,發送已更改並主要保存在本地計算機本身。對不起,如果這不是你要找的答案。 – Zenwalker 2011-06-15 04:56:05