J2ME遊戲中的圖片處理

標籤：使用   檔案   資料   width   問題   代碼   

圖片資源乃是遊戲的外衣，直接影響一個遊戲是否看上去很美。在J2ME遊戲開發中，由於受到容量和記憶體的兩重限制，圖片使用受到極大的限制。在這種環境中，處理好圖片的使用問題就顯得更加重要。
 本文從容量和記憶體兩個方面談談J2ME遊戲圖片處理的基本方法。

一 減少圖片容量

方法1：將多張png圖片整合到一張圖片上。
 這是最基本也是最有效減少png圖片容量的辦法了。比如你有10張png圖片，每張10×15，現在你可以把它整合到一張100×15或者10×150或者X×X的圖片上去。這張大png圖片的容量比10張png圖片的總容量小很多。這是因為省去了9張圖片的檔案頭，檔案結束資料區塊等等，而且合并了調色盤（如果10張圖片的調色盤恰好相同，則省去了9張圖片的調色盤所佔的容量！這是個不小的數字）

方法2：減少圖片的顏色數
 減少顏色也算是一個方法？我想說的是什麼時候減，誰去減。如果遊戲完成後發現容量超出，此時在用最佳化工具減少顏色，雖然能降低圖片容量，但圖片效果可能就不讓你滿意了。所以，在美工作圖時就要確定使用的顏色數，手機遊戲使用的是象素圖，即一個象素一個象素點出來的映像，所以預先規定調色盤顏色數量是可以辦到的。不過，最終使用最佳化工具也是有用的，有時候相差一兩種顏色，但效果差別並不大，容量卻可以變小一些。呵呵，減少顏色確實可以算是一種方法。

方法3：儘可能使用旋轉和翻轉
 這點不用解釋了 

方法4：使用換調色盤技術和自訂圖片格式
 如果前兩種方法還不能滿足你對容量的要求，而你的遊戲中恰好使用了很多僅顏色不同的怪物，那麼可以試試換調色盤技術。J2ME規範中規定手機至少可以支援png格式的圖片，每張png都帶有調色盤資料，如果兩張圖片除了顏色不同而其他（包括顏色數）完全相同，則只要儲存一張圖片和其他圖片的調色盤，這相對於儲存多張圖片來說節省了不少容量。不過這個方法挺麻煩，你得瞭解png檔案格式，然後做一個工具提取出調色盤資料和調色盤資料區塊在png檔案中的位移。記憶體中儲存映像仍使用Image,如果要換調色盤，則將png檔案讀入到一個位元組數組中，根據調色盤資料區塊在png中的位移，用新的調色盤代替原來的調色盤資料，然後用這個位元組數組建立出換色後的Image。也許你覺得儲存一張png和n份調色盤資料的方法有點浪費。至少多儲存了1份調色盤資料啊！如果直接將映像資料提取出來，在加上n份調色盤資料，豈不是更節省容量。但是使用上面的方法，我們還可以用drawImage渲染。如果這樣自訂了圖片格式，那隻有自己寫個渲染函數了，這倒還可以，只不過put pixel的速度在某些機器上非常慢。或者自己構造png格式資料,再使用Image.如果你真得決定這麼做，我還有個小建議，不要對映像資料進行壓縮，zip壓縮大多數時候比你寫得壓縮演算法好(參見J2ME Game開發筆記－壓縮還是不壓縮)。論壇上有位朋友提過使用bmp格式代替png格式，jar中圖片容量更小，也是一個道理。

二 減少圖片所佔記憶體

1 圖片所佔記憶體的計算
 png圖片所佔用的記憶體並不對應於圖片容量。圖片佔用的記憶體的計算為：width*height*bpp。bpp即為系統內建的顏色位元。以Nokia 6600為例，象素格式為565共16位。所以一張100*100的圖片佔用100*100*(16/8)=20000位元組，約為19.5k的記憶體。象素格式是固定的無法改變，所以只有減少圖片的寬和高才能降低其消耗的記憶體。

2 減少Image對象數量可節約大量記憶體
 減少Image對象數量不等於減少圖片數量。我的意思是說，將一張整合圖儲存在一個Image對象中，通過setClip的方法從這個Iamge對象中選取你需要的映像渲染。不過這個方法犧牲了一點速度，每幀都從整合圖Image中減切映像的速度比無減切的渲染慢。但對於數目不多的渲染，比如精靈，使用這個方法沒問題。這個方法還有一個問題就是不能釋放整合圖中不需要的圖片，這就要看你整合的程度了。從圖片容量和記憶體管理的角度綜合考慮，我一般使用二次整合的方法。比如有n個精靈,先將各精靈所有的圖片整合到一張整合圖中，得到n張整合圖，然後將這n張整合圖再次整合到一張更大的整合圖中。這樣在jar中只存在一張整合圖。使用時，先將大整合圖分割載入到n個Image對象中即可。這樣各個精靈的圖片可以單獨管理了。

3 使用旋轉和翻轉
 只儲存一個原始的Image,需要時再旋轉或翻轉

後記:
 本文僅僅從圖片方面談談容量和記憶體，所談的幾點均是普遍的方法，內行人一眼就能看明白，對於新手可以參考一下。減少J2ME遊戲容量和記憶體也確實是一個值得探討的問題，圖片方面僅是其一。想要有較好的效果必須從資原始碼等多方面入手,而這之中必須處理好容量,速度,記憶體,記憶體峰值,等待時間等等的關係.最後的方案往往是各方面因素相互平衡的結果.