畢業(yè)論文---- 基于j2me的手機游戲開發(fā)

1、<p>　　本 科 生 畢 業(yè) 論 文（設計）</p><p>　　題目 基于J2ME的手機游戲開發(fā)關鍵技術研究與應用 </p><p><b>　　摘要</b></p><p>　　無線通訊領域的飛速發(fā)展，使得移動電話在人們的生活中占有越來越重要的地位。由于其便攜性和普及性的特點，手機上的應用程序尤其是娛樂程序也逐漸成為市

2、場的新熱點。</p><p>　　J2ME平臺作為Java體系的一個分支，廣泛應用于消費和嵌入式設備中，它主要針對資源受限制的設備做Java開發(fā)。J2ME通過虛擬機、配置和簡表實現(xiàn)跨平臺性，虛擬機建立在本地操作系統(tǒng)之上，配置層建立在虛擬機基礎上并定義了虛擬機和java語言的特性，簡表層為具體的設備類型定義了特定的要求。</p><p>　　本文首先介紹J2ME平臺的相關概念與規(guī)范，分析國內(nèi)

3、外的應用趨勢與關鍵技術。然后結合一款網(wǎng)絡游戲的開發(fā)，詳細分析在J2ME平臺上如何在游戲中進行動畫效果顯示、圖片變色處理、網(wǎng)絡通訊。</p><p>　　關鍵字：J2ME，移動信息設備概要描述，手機網(wǎng)絡游戲</p><p><b>　　Abstract</b></p><p>　　This is an age of wireless commun

4、ication and mobile phone has already become an indispensable part of our daily life. As a result, entertainment applications on mobile phones are popping up like flowers after a spring rain.</p><p>　　Running

5、 on JVM and targeting at resource limited devices, J2ME wins its great popularity as the best platform for mobile applications in industry for its platform independence and great flexibility. </p><p>　　via t

6、he case study of a mobile phone Internet game application, the paper studies in detail several key issues in the game design including cartoon design and painting, graphic processing and rendering, network communications

7、 etc. Optimization issues are also discussed in detail.</p><p>　　Keywords: J2ME, MIDP, mobile phone Internet application</p><p><b>　　目錄</b></p><p><b>　　第一章緒論1<

8、;/b></p><p>　　1.1 J2ME的背景與應用現(xiàn)狀1</p><p>　　1.2 手機游戲的發(fā)展現(xiàn)狀2</p><p>　　1.3 研究目的與內(nèi)容3</p><p>　　第二章J2ME架構與技術特點4</p><p>　　2.1 J2ME架構4</p><p>　　

9、2.2 J2ME組件4</p><p>　　2.3 移動設備上游戲的限制5</p><p>　　2.3.1 內(nèi)存5</p><p>　　2.3.2 手機的界面6</p><p>　　2.3.3 缺少庫文件支持6</p><p>　　第三章一款基于J2ME的游戲--《天下2》的設計7</p>

10、<p>　　3.1 《天下2》簡介7</p><p>　　3.2 《天下2》系統(tǒng)架構設計8</p><p>　　3.3關鍵技術研究10</p><p>　　3.3.1 動畫渲染技術10</p><p>　　3.3.2 網(wǎng)絡通訊11</p><p>　　3.3.3 用戶與界面的交互11</p&

11、gt;<p>　　第四章圖像和動畫渲染的處理12</p><p>　　4.1 MIDP 2.0下的一般處理方式12</p><p>　　4.1.1 GameCanvas12</p><p>　　4.1.2 Layer12</p><p>　　4.1.3 LayerManager13</p><p&

12、gt;　　4.1.4 Sprite13</p><p>　　4.1.5 TiledLayer13</p><p>　　4.2 《天下2》對圖像顯示部分的改進14</p><p>　　4.2.1 《天下2》圖像顯示模塊的結構14</p><p>　　4.2.2 圖像變色的設計18</p><p>　　4.3 J

13、2ME平臺下圖像顯示技術的探討21</p><p>　　第五章網(wǎng)絡通訊設計23</p><p>　　5.1 J2ME平臺網(wǎng)絡通訊23</p><p>　　5.2 網(wǎng)絡游戲中數(shù)據(jù)包設計23</p><p>　　5.3 《天下2》網(wǎng)絡數(shù)據(jù)包的設計24</p><p>　　5.3.1 數(shù)據(jù)包通用規(guī)則24<

14、/p><p>　　5.3.2 數(shù)據(jù)包頭定義26</p><p>　　第六章界面和用戶交互的研究與設計28</p><p>　　6.1 移動平臺上的界面交互28</p><p>　　6.2 《天下2》界面控件的設計29</p><p>　　6.3 網(wǎng)絡通訊與界面控件的結合：商人NPC的設計31</p>

15、<p>　　6.3.1 NPC部分的系統(tǒng)結構31</p><p>　　6.3.2 商人NPC的界面控件32</p><p>　　6.3.3 商人NPC專用的數(shù)據(jù)包32</p><p>　　6.3.4 商人NPC的流程34</p><p>　　第七章J2ME程序優(yōu)化的研究37</p><p>　

16、　7.1 內(nèi)存優(yōu)化37</p><p>　　7.2 程序執(zhí)行速度優(yōu)化38</p><p>　　7.3 使用工具優(yōu)化38</p><p>　　第八章總結與展望40</p><p>　　附錄A：Java下RGB空間和HLS空間的相互轉(zhuǎn)換41</p><p><b>　　參考文獻44</b>

17、;</p><p><b>　　致謝45</b></p><p><b>　　緒論</b></p><p>　　1.1 J2ME的背景與應用現(xiàn)狀</p><p>　　自Java問世以來，Sun Microsystems已成功地將Java平臺技術推廣到臺式機及服務器。隨著移動電話和個人數(shù)字助理（PD

18、A）的日益普及和性能的不斷提高，將Java技術應用于移動設備這個發(fā)展方向，將在未來得到更高的重視。</p><p>　　J2ME（Java 2 Micro Edition）是為小型設備設計的Java平臺。它包含專門設計的輕量級虛擬機，一個最小化的核心庫和標準Java庫的輕量級替代物。J2ME是無線PDA和高性能的移動電話的理想移動客戶機平臺。</p><p>　　Sun Microsyst

19、ems 將 J2ME 定義為“一種以廣泛的消費性產(chǎn)品為目標的高度優(yōu)化的 Java 運行時環(huán)境，包括尋呼機、移動電話、可視電話、數(shù)字機頂盒和汽車導航系統(tǒng)?！?自從 1999 年Developer Conference 上聲明之后，J2ME 為小型設備帶來了 Java 語言的跨平臺功能，允許移動無線設備共享應用程序。[1][4]</p><p>　　在另一方面，隨著移動通信技術的高速發(fā)展，移動設備的性能日益提高，同時

20、用戶對于移動設備上應用程序的需求也越來越多。但是，移動設備制造商本身的軟件開發(fā)能力和資源都有限，無法充分滿足用戶的需要。同時，由于以前主要移動設備上的程序主要用C語言開發(fā)，并采用專用的操作系統(tǒng)，其他眾多軟件開發(fā)商也無法為其開發(fā)新的應用程序。這種兩難的局面嚴重的限制了移動設備上新應用的推廣于普及。</p><p>　　Java技術的開放性、安全性和龐大的社會已有資源，以及其跨平臺性，即“編寫一次，到處運行”的特點，

21、使Java技術成為智能手機軟件平臺的事實標準。采用Java技術后，編寫應用程序和提供服務的人就不必關心接受其服務的手機采用的是什么操作系統(tǒng)和芯片，只要按照Java的要求寫出的程序就可以運行；同樣，生產(chǎn)手機的廠商也不必顧慮將來誰來提供增值服務?？梢钥闯觯捎肑ava技術，可以建立完整、高效的無線數(shù)據(jù)增值服務產(chǎn)業(yè)鏈，從而為用戶提供靈活、個性化、內(nèi)容方式多樣的服務。</p><p>　　如今支持Java已經(jīng)成了主流手機

22、的標準，支持下載新的Java應用也是手機的一個重要賣點。到2005年6月，全世界已經(jīng)有大約1億部Java手機在使用，除中國大陸外共有53個移動運營商正式推出了基于Java技術的無線數(shù)據(jù)增值服務。</p><p>　　在國內(nèi)，中國移動通信集團已經(jīng)建立了無線Java增值服務體系，并推出了“百寶箱”等服務品牌，包括游戲百寶箱、娛樂百寶箱、商務百寶箱、生活百寶箱等，已經(jīng)于2003年7月10日開始正式商用。</p&g

23、t;<p>　　中國聯(lián)通公司也正在其CDMA 1X網(wǎng)絡上建立無線Java增值服務體系，目前系統(tǒng)正在建設過程中，并且2003年9月26日中國聯(lián)通、北京振戎融通公司和Sun公司在人民大會堂宣布聯(lián)合發(fā)起成立“UniJa技術聯(lián)盟”，三方將在聯(lián)通CDMA 1X網(wǎng)絡上的Java增值服務方面全面合作。</p><p>　　1.2 手機游戲的發(fā)展現(xiàn)狀</p><p>　　所謂“手機游戲”，就

24、是依托移動通信網(wǎng)絡運行在手機終端上的游戲。從誕生到現(xiàn)在，手機游戲經(jīng)歷了從最初的簡單文字類游戲、簡單的圖形界面游戲到可下載的單機版游戲再到大型手機網(wǎng)絡游戲的發(fā)展歷程，手機游戲的業(yè)務形態(tài)日益成熟，展示出廣闊的市場前景。有關機構預測，在未來5年里，手機游戲?qū)⒃跉W洲形成30億歐元的大市場。另據(jù)IDC預測，到2006年，手機游戲業(yè)務的軟件、硬件及服務所帶來的收入將達到40億美元。近兩年來，手機游戲業(yè)務在日韓等國已經(jīng)顯示出勃勃生機，成為一個潛力巨大

25、的文化產(chǎn)業(yè)。以日本NTT DoCoMo目前的經(jīng)營狀況為例，移動游戲已經(jīng)成為該公司的重要收入來源。日本最大的游戲網(wǎng)站BanDai擁有200多萬用戶，每個用戶每月平均花2.75美元在i-mode手機上玩游戲，這為DoCoMo和BanDai帶來約550萬美元的收入。</p><p>　　與日、韓等國相比，中國的手機游戲市場起步比較晚，但中國有一個巨大的手機用戶群，手機游戲擁有廣闊的市場前景。目前，在中國有8000多萬電

26、腦網(wǎng)絡用戶，而中國的手機用戶卻已經(jīng)超過3億。與PC游戲不同，手機游戲擺脫了線纜的束縛，具有隨時、隨地、隨身的特點，更適合人們在移動中休閑和娛樂。顯然，手機游戲產(chǎn)業(yè)一旦啟動，其能量將不亞于目前的電腦網(wǎng)絡游戲。數(shù)據(jù)顯示，2004年中國手機游戲市場規(guī)模超過8億元人民幣，預計在2005年手機游戲產(chǎn)業(yè)市場規(guī)模將達到14.41億元人民幣。雖然目前手機游戲用戶數(shù)只占3億用戶的很小一部分，但隨著手機游戲產(chǎn)業(yè)發(fā)展環(huán)境的日益成熟，其發(fā)展速度將一日千里。&l

27、t;/p><p>　　其中的手機網(wǎng)絡游戲，是手機游戲產(chǎn)業(yè)未來發(fā)展的重要趨勢和遠景。區(qū)別于傳統(tǒng)手機游戲，手機網(wǎng)絡游戲應該具有什么網(wǎng)絡游戲和手機單機游戲的雙重特點。手機游戲主要作用應該是一種大眾化的移動數(shù)據(jù)增值服務，而良好的游戲的便捷性和操作性是影響游戲可玩度的主要標準之一。手機游戲在操縱性能上受到一定的制約。往往是通過類比化的按鍵和簡便易懂的游戲手段快速的完成實時的操作過程。而另外一個方面網(wǎng)絡游戲必須有非常有效的信息交

28、互平臺，傳統(tǒng)的PC或者TV網(wǎng)絡游戲的平臺并不適應于硬件條件簡單的手機使用。手機網(wǎng)絡游戲的信息交互平臺相對簡單，但必須滿足用戶的最基本交流需要。</p><p>　　1.3 研究目的與內(nèi)容</p><p>　　基于移動設備的應用軟件，從以前的只提供基本的語音，通訊錄和SMS功能，到后來提供WAP（Wireless Application Protocol）等基本的附加應用，再到目前逐漸豐富的

29、各種應用。J2ME平臺的出現(xiàn)，為第三方軟件開發(fā)商為移動設備開發(fā)應用軟件帶來了極大的便利，開發(fā)商可以方便的將應用軟件移植到移動設備上。豐富的Java資源和Java開發(fā)人員，可以大大的縮短開發(fā)周期。同時也可以為移動應用提供在線升級和動態(tài)下載的服務。</p><p>　　本次研究的目的主要在于分析基于J2ME平臺進行手機游戲開發(fā)所用到的核心技術，如繪圖、圖形與動畫顯示，響應用戶輸入，網(wǎng)絡通訊。并且還要針對J2ME平臺本

30、身的缺點，以及具體的應用，提出自己的改進方法和解決方案。</p><p>　　J2ME架構與技術特點</p><p>　　2.1 J2ME架構</p><p>　　圖1-1：J2ME體系結構</p><p>　　僅僅將J2ME從J2SE中區(qū)分開來并不能解決所有的兼容性問題。圖1-1顯示了J2ME平臺的多層結構。由于有多種多樣的移動設備，它們?yōu)?/p>

31、了不同的目的設計為了現(xiàn)實中平衡移植性和性能與可比性，J2ME包含了幾個稱為配置（Configuration）、簡檔（Profile）、可選包（Optional Packages）的組件。[12]每一種配置和簡檔的有效配合針對的是一種特定的設備。配置提供了最基本和一般性的語言功能。簡檔在配置之上，它支持了更高級的API，如圖形界面（GUI）、永久性存儲、安全和網(wǎng)絡連接?？蛇x包可以與標準簡檔綁定以滿足特定程序的需要。</p>

32、<p>　　2.2 J2ME組件</p><p>　　在配置這一層，J2ME中最重要的兩個配置是CDC和CLDC</p><p>　　連接受限設備配置（Connected Limited Device Configuration，CLDC[7]）是用于最小的無線設備的。它們有160K及160K以上的內(nèi)存，低速的16/32位處理器。CLDC具有有限的算術、字符串和IO功能，并缺少像

33、JNI（Java Native Interfae，Java本地接口）和自定義類加載這樣的功能。CLDC虛擬機（稱為KVM）只支持J2SE核心庫的一小部分。</p><p>　　連接設備配置（Connected Device Configuration，CDC）用于具有至少2M內(nèi)存和32位處理器的高級無線設備。與CLDC不同，CDC支持JVM的全部功能，因此可以利用大部分J2SE的庫。</p><

34、;p>　　從上述的標準中可以看出CLDC 主要指那些資源非常受限的設備比如手機、PDA、雙工尋呼機等。而CDC 主要指處理能力相對較強的設備，比如機頂盒、汽車導航系統(tǒng)等。</p><p>　　在簡檔這一層，最重要和最成功的J2ME簡檔是移動信息設備簡檔（Mobile Information Device Profile，MIDP），它基于CLDC。MIDP針對的是最小設備，如手機。目前大部分的主流手機都已經(jīng)

35、支持MIDP。MIDP為移動應用提供的核心應用包括用戶界面、網(wǎng)絡連接、本地數(shù)據(jù)存儲及應用生命周期管理等，統(tǒng)稱為標準Java運行環(huán)境和Java API等。</p><p>　　MIDP規(guī)范是由Java Community Program定義的，它是一個專門用于為移動信息設備動態(tài)地、安全地提供圖像性能要求高、需要網(wǎng)絡支持的應用平臺。[9]</p><p>　　在MIDP中定義了一種新的應用程序

36、模型MIDlet，它是被Application Management Software（AMS）管理的。AMS 負責MIDlet 的安裝、下載、運行和刪除等操作。在被AMS 管理的同時，MIDlet 可以和應用管理軟件通信通知應用管理軟件自己狀態(tài)的變化，通常是通過方法notifyDestroyed()和notifyPaused()實現(xiàn)的。[10]</p><p>　　2.3 移動設備上游戲的限制</p>

37、;<p>　　在開發(fā)J2ME移動游戲過程中，開發(fā)人員面對的最大的困難和障礙是，本來在PC機和控制臺上習以為常的應用在移動設備上卻遇到各種限制，包括內(nèi)存的、屏幕尺寸的、甚至色彩的限制。 </p><p>　　由于游戲中的用戶輸入、圖形圖像、動畫、聲音和振動的高交互性，這種限制在移動游戲中表現(xiàn)得比移動應用程序更加明顯。此外，不僅要注意不同制造商之間產(chǎn)品的不同，也要了解同一個制造商的不同移動設備模型的差別

38、。不同手機的模式在內(nèi)存、色彩、屏幕尺寸和用戶界面等各個方面都有很多不同。[11]</p><p><b>　　2.3.1 內(nèi)存</b></p><p>　　一般情況下，內(nèi)存被認為是內(nèi)存區(qū)域中的堆棧，在游戲執(zhí)行的時候儲存信息，在游戲終止后被釋放。顯而易見，手機上可以使用的內(nèi)存總量要比PC機上少的多，因此在開發(fā)游戲的時候，要先查看所針對機型的內(nèi)存容量，注意自己程序內(nèi)存使用

39、情況，已防止需要的內(nèi)存空間超過可以分配的大小。</p><p>　　另外的存儲空間包括RMS(Record Management System)。它可以用來存儲玩家的最高分數(shù)或者上次保存的設置?？晒┦褂玫腞MS大小也是要注意的。</p><p>　　PC機上的硬盤和內(nèi)存在使用一段時間后就會出現(xiàn)碎片，在手機的存儲空間上也會出現(xiàn)這種情況。例如需要寫一個大的對象到內(nèi)存中，但是卻找不到足夠的一整塊

40、連續(xù)的空間，于是系統(tǒng)就將它分成幾塊分別存儲在內(nèi)存的各個空閑空間中。這不但會導致存儲空間訪問時間的增加，當內(nèi)存中大的對象被清除后會留下很多內(nèi)存空洞，從而導致新的對象被存儲時也會遍布內(nèi)存各處。</p><p>　　2.3.2 手機的界面</p><p>　　最近幾年，各個手機制造商開始放棄傳統(tǒng)的手機界面，進而追求更為個性化的按鍵和控制，這歸結于制造商對更加友好的用戶界面的孜孜不倦的追求。雖然一

41、些制造商已經(jīng)意識到?jīng)]有絕對最好的用戶界面，只有對某些有特殊需求的特定的群體比較好的用戶界面，這主要取決于用戶除了使用手機打電話外還做什么，比如聽音樂、玩游戲、或這記錄商業(yè)事件。當然，新界面的設計也擴展了手機市場的邊界和吸引力。這意味著又增加了開發(fā)者需要考慮的一個因素，比如，把數(shù)字鍵“5”設定為開火，但是也許在某些手機上這個鍵不是很方便就可以按到的。</p><p>　　2.3.3 缺少庫文件支持</p>

42、;<p>　　由于J2ME是J2SE的子集，所以它并沒有包含所有的包和類。也就是說要么不使用這些類，要么自己擴展所需要的類。例如，J2ME中不支持浮點數(shù)(float)，故不能進行小數(shù)運算，也不能使用sin、cos和tan運算，但是在游戲開發(fā)中，小數(shù)是經(jīng)常要用到的。然而，可以用定點數(shù)學運算的方式來代替小數(shù)運算。比方說，如果想精確到小數(shù)點后三位，可以用1000來表示1.000。在變換的過程中要不斷的乘以或者除以10，以得到正確

43、的結果。至于角度可以用0、30、60、90、120、150、180、210、240、270、300、330、360這種對應角度值的整數(shù)值來代替，事實上由于移動設備的屏幕往往都很小，所以太精確的計算也是沒有意義的。</p><p>　　一款基于J2ME的游戲--《天下2》的設計</p><p>　　3.1 《天下2》簡介</p><p>　　《天下2》是一款RPG性質(zhì)

44、的手機網(wǎng)絡游戲，可以實現(xiàn)線上線下兩部分功能，線上部分完成所有的交互性事件如交易、PK、聊天、組隊、攻城。線下部分可以當成一個單機版的RPG游戲來玩如練功、任務。離線時，系統(tǒng)還有呼喚功能，即通過系統(tǒng)將離線的玩家呼喚上來完成游戲過程。</p><p>　　突破WAP游戲的靜態(tài)畫面顯示和文字界面的操作復雜，和單機版的有窮性，具備無窮任務和新地圖，具備pc機上的打斗升級，打造裝備，在線交易，比武，賭博，聊天等多種網(wǎng)游元素

45、。</p><p>　　圖3-1：游戲的功能劃分</p><p>　　圖3-1顯示了這款游戲需要實現(xiàn)的功能。整個游戲種的世界包括以下幾部分：</p><p>　　地圖：游戲世界的場景。</p><p>　　時間：游戲世界的時間，目前不設置專門的游戲時間，而采用現(xiàn)實時間。</p><p>　　角色：關于游戲角色的種類，每

46、個角色的背景、屬性、屬性發(fā)展空間和規(guī)則。</p><p>　　物品：包括道具、武器、裝備等。</p><p>　　NPC：提供一些系統(tǒng)功能的虛擬角色，有商人、鐵匠（武器和裝備的升級功能）、任務NPC，幫派大使、傳送商人。</p><p>　　社會：用戶之間形成關系的功能，包括幫派、組隊等。</p><p>　　戰(zhàn)斗：用戶和其他用戶、NPC發(fā)送

47、的戰(zhàn)斗活動，包括：練功、任務、攻城、PK等。</p><p>　　任務：用戶實現(xiàn)一系列目標后，可以得到一個任務結果，結果包括財富值、道具等兩類。</p><p>　　交易：用戶和用戶之間發(fā)生的關于物品的交流活動，包括買、賣、送。</p><p>　　交流：用戶之間交流的功能，包括聊天、BBS。</p><p>　　用戶：用戶進入游戲的入口功能

48、。包括：注冊、登陸、登出。</p><p>　　主菜單：系統(tǒng)級的菜單，程序啟動的入口。</p><p>　　3.2 《天下2》系統(tǒng)架構設計</p><p>　　圖3-2：《天下2》程序架構</p><p>　　《天下2》的系統(tǒng)整體結構如圖3-2所示。從圖中可以看到，除主程序外，還包括了音樂播放模塊、網(wǎng)絡通訊模塊、界面顯示模塊。在界面顯示模塊種

49、，又包含圖像顯示和界面控件2個子模塊。</p><p>　　主程序為整個游戲的入口。它是一個繼承自javax.microedition.midlet.MIDlet的一個類TXMain。這也是J2ME程序的統(tǒng)一規(guī)范。按照規(guī)范程序的運行從startApp()函數(shù)開始。在這里要做好所有程序運行的準備工作，包括聲音播放器的初始化，本地數(shù)據(jù)的讀取，網(wǎng)絡連接的初始化，全部要在這個部分完成。一旦某一部分初始化時發(fā)生錯誤，程序?qū)?/p>

50、不能運行。如初始化過程正常結束，將通過調(diào)用界面顯示模塊，進入程序的開始界面。</p><p>　　界面顯示模塊實現(xiàn)了整個程序核心功能。游戲中的場景由一個虛的基類TXScene來定義。TXScene包含了一個TXView對象view，這個類繼承自javax.microedition.lcdui.game.GameCanvas。由它負責響應用戶的按鍵輸入，并處理最終的畫圖操作。這個類中最重要的部分，是對游戲循環(huán)的定義

51、</p><p>　　private class GameCycle extends TimerTask {</p><p>　　public void run() {</p><p>　　if (socket != null)</p><p>　　socket.netCommand();</p><p>　　// 處

52、理網(wǎng)絡數(shù)據(jù)，處于連接狀態(tài)時讀取數(shù)據(jù)，并通知socket繼續(xù)監(jiān)聽</p><p>　　function();// 各個scene自己的功能函數(shù)處理集合</p><p>　　if (!stopped) {</p><p>　　synchronized (graphics) {</p><p>　　draw();// 畫背景</p&g

53、t;<p>　　view.flushGraphics();</p><p><b>　　}</b></p><p><b>　　}</b></p><p><b>　　}</b></p><p><b>　　}</b></p>

54、<p>　　從上面的代碼段可以看出，每次游戲循環(huán)，首先檢查網(wǎng)絡鏈接狀態(tài)，如果有數(shù)據(jù)需要讀取，則先接受網(wǎng)絡的數(shù)據(jù)包。待網(wǎng)絡數(shù)據(jù)包處理完畢之后，進入各種Scene自己的邏輯處理部分。每種場景在將圖像畫到屏幕上之前，很可能需要進行一些自己的邏輯處理。在基類中，這僅僅是個抽象函數(shù)，而每種場景都會根據(jù)自己的需要進行不同的實現(xiàn)。在處理完邏輯之后，將進行真正的畫圖操作。繪圖函數(shù)draw()也由各個子類各自實現(xiàn)。因為用戶的按鍵輸入，游戲本身的

55、邏輯處理，接受到網(wǎng)絡數(shù)據(jù)包都可能需要刷新界面，所以很多時候會發(fā)生多個線程同時調(diào)用graphics的draw函數(shù)的情況，因此為確保線程安全，將draw函數(shù)放到synchronized塊當中。</p><p>　　從這段代碼中還能看到，GameCycle類繼承自TimerTask。通過一個Time就可以按照一定的時間間隔來運行。</p><p>　　圖3-3：游戲中的場景</p>

56、<p>　　游戲中一共出現(xiàn)3種場景，開始界面和主菜單（TXStart）、正常普通場景（TXWorld）、玩家PK場景（TXPK）。這3種場景都繼承自TXScene。TXStart需要處理的元素包括開場動畫、主菜單，以及由用戶選擇主菜單后顯示相應的界面，包括注冊界面，登陸界面，游戲設置等。游戲場景TXWorld是游戲中大多數(shù)時候使用的場景。在這個場景里，玩家進行移動、戰(zhàn)斗、交易、對話等各種游戲中可能出現(xiàn)活動。最主要的游戲邏輯也

57、需要在這里實現(xiàn)。這個場景里要通過圖像顯示子模塊來顯示地圖上的人物、建筑物、地圖，還需要通過界面控件子模塊來顯示各種在游戲中定義的控件，包括對話框，輸入筐，消息提示筐等，從而和用戶進行有效的交流。</p><p>　　在游戲過程中，隨時都可能向服務器端發(fā)送數(shù)據(jù)包，或者從服務器接受數(shù)據(jù)包。在游戲中，由一個專門的TXSocket類來負責網(wǎng)絡聯(lián)接的操作。它在一個單獨的線程中執(zhí)行，維護一個javax.microeditio

58、n.io.SocketConnection的對象，來接受數(shù)據(jù)和發(fā)送數(shù)據(jù)。</p><p>　　作為游戲，音樂也是必不可少的。《天下2》這個部分完全采用J2ME平臺的標準接口實現(xiàn)。通過一個javax.microedition.media.Player對象來播放實現(xiàn)存儲好的mid文件，對音量的控制也是通過標準的平臺接口javax.microedition.media.control.VolumeControl來實現(xiàn)。

59、</p><p><b>　　3.3關鍵技術研究</b></p><p>　　3.3.1 動畫渲染技術</p><p>　　MIDP 2.0的一個重要更新就是提供了GAME API。它的目的就是給游戲開發(fā)人員提供統(tǒng)一個接口，用來顯示游戲中的圖像和動畫效果。通過Sprit和TiledLayer類可以方便的構建出游戲的背景和位于背景上的各種元素，一

60、些常用操作如位移和碰撞檢測也都做了封裝。這很好的替代了原來手機廠商各自提供的API。</p><p>　　但在游戲?qū)嶋H開發(fā)中發(fā)現(xiàn)，這組API對圖片變色的處理不夠理想，內(nèi)存消耗和處理速度都不夠理想，因此需要針對這一點做出適當?shù)母倪M。為了能夠以較小的代價實現(xiàn)圖片的變色顯示功能，需要對PNG格式文件進行重新編碼，建立自己的調(diào)色板，再對調(diào)色板進行操作。</p><p>　　本文將在第四章深入的探討

61、《天下2》中所使用的動畫渲染技術。</p><p>　　3.3.2 網(wǎng)絡通訊</p><p>　　在與服務器通訊的時候，J2ME平臺上可以選擇HTTP和Socket方式。在游戲中更多采用的是Socket方式，因為這樣可以自己定義多種類型的數(shù)據(jù)包，也能合理的利用帶寬。使用平臺提供的接口，建立Socket連接和發(fā)送、接收消息都比較方便，但難點在于數(shù)據(jù)包格式的設計。作為一款復雜的網(wǎng)絡游戲，與服務

62、器的交互非常頻繁，數(shù)據(jù)包的種類也就相當繁雜，只有合理數(shù)據(jù)包設計才能保證數(shù)據(jù)處理的效率。</p><p>　　本文將在第五章詳細的闡述《天下2》中所使用的網(wǎng)絡通訊技術。</p><p>　　3.3.3 用戶與界面的交互</p><p>　　CLDC并沒有任何的GUI功能，而在MIDP中定義了一套精簡的圖形界面API。但是到了游戲中，為了維護界面的統(tǒng)一性，不可能使用標準

63、的界面控件來用于用戶的交互。在游戲中需要通過javax.microedition.lcdui.Canvas和Graphics類來檢測用戶輸入以及進行界面的顯示。在此基礎上，針對游戲交互的特點，通過一些圖片資源，定義出一整套的游戲界面控件，這樣才能既給用戶提供方便的操作，又能即時展示游戲的信息。</p><p>　　本文將在第六章對《天下2》中的用戶界面設計以及與用戶的交互做深入的分析。</p>&l

64、t;p>　　圖像和動畫渲染的處理</p><p>　　4.1 MIDP 2.0下的一般處理方式</p><p>　　MIDP 2.0相對于1.0來說，最大的變化就是新添加了用于支持游戲的API，它們被放在javax.microedition.lcdui.game包中。游戲API包提供了一系列針對無線設備的游戲開發(fā)類。由于無線設備僅有有限的計算能力，因此許多API的目的在于提高Java

65、游戲的性能，并且把原來很多需要手動編寫的代碼如屏幕雙緩沖、圖像剪裁等都交給API 間接調(diào)用本地代碼來實現(xiàn)。各廠家有相當大的自由來優(yōu)化它們。[2][3]</p><p>　　游戲API使用了MIDP的低級圖形類接口（Graphics，Image，等等）。整個game包僅有5個Class：</p><p>　　4.1.1 GameCanvas</p><p>　　這個類

66、是LCDUI的Canvas 類的子類，為游戲提供了基本的“屏幕”功能。除了從Canvas繼承下來的方法外，這個類還提供了游戲?qū)Ｓ玫墓δ?，如查詢當前游戲鍵狀態(tài)的能力，同步圖像輸出；這些功能簡化了游戲開發(fā)并提高了性能。</p><p>　　GameCanvas類提供了基本的游戲用戶接口。除了從Canvas繼承下來的特性（命令，輸入事件等）以外，它還提供了專門針對游戲的功能，比如后備屏幕緩沖和鍵盤狀態(tài)查詢的能力。每個G

67、ameCanvas實例都會有一個為之創(chuàng)建的專用的緩沖區(qū)。因為每個GameCanvas實例都會有一個唯一的緩沖區(qū)。可以從GameCanvas實例獲得其對應的Graphics對象，而且，只有對Graphics對象操作，才會修改緩沖區(qū)的內(nèi)容。外部資源如其他的MIDlet或者系統(tǒng)級的通知都不會導致緩沖區(qū)內(nèi)容被修改。[8]</p><p>　　4.1.2 Layer</p><p>　　Layer

68、類代表游戲中的一個可視化元素，例如Sprite 或TiledLayer 是它的子類；這個抽象類搭好了層(Layer)的基本框架并提供了一些基本的屬性，如位置，大小，可視與否。出于優(yōu)化的考慮，不允許直接產(chǎn)生Layer 的子類（不能包外繼承）。</p><p>　　4.1.3 LayerManager</p><p>　　對于有著許多Layer的游戲而言，LayerManager通過實現(xiàn)分層次

69、的自動渲染，從而簡化了游戲開發(fā)。它允許開發(fā)者設置一個可視窗口(View Window)，表示用戶在游戲中可見的窗口；LayerManager自動渲染游戲中的Layer，從而實現(xiàn)期望的視圖效果。</p><p>　　LayerManager管理一系列的Layer。LayerManager簡化了渲染每個Layer的過程，每個添加的Layer都將在正確的區(qū)域并以正確的順序被渲染。</p><p>

70、;　　LayerManager維護一個順序列表，以便管理如何追加、插入和刪除Layer。一個Layer的索引號關聯(lián)了它的Z軸位置(z-order)；索引號為0的Layer最接近用戶，索引號越大的Layer離用戶越遠。索引號永遠是連續(xù)的，即，如果一個Layer被刪除，后面的Layer的索引號都將調(diào)整使得索引號保持連續(xù)。[2]</p><p>　　4.1.4 Sprite</p><p>　　

71、Sprite又稱“精靈”，也是一種Layer，可以顯示一幀或多幀的連續(xù)圖像。但所有的幀都是相同大小的，并且由一個Image對象提供。Sprite通過循環(huán)顯示每一幀，可以實現(xiàn)任意順序的動畫；Sprite類還提供了許多變換（翻轉(zhuǎn)和旋轉(zhuǎn)）模式和碰撞檢測方法，能大大簡化游戲邏輯的實現(xiàn)。</p><p>　　Sprite是一個基本的可視元素，可以用存儲在圖像中的一幀或多幀來渲染它；輪流顯示不同的幀可以令Sprite實現(xiàn)動畫

72、。翻轉(zhuǎn)和旋轉(zhuǎn)等幾種變換方式也能應用于Sprite使之外觀改變。作為Layer子類，Sprite的位置可以改變，并且還能設置其可視與否。[5]</p><p>　　4.1.5 TiledLayer</p><p>　　TiledLayer又稱“磚塊”，這個類允許開發(fā)者在不必使用非常大的Image對象的情況下創(chuàng)建一個大的圖像內(nèi)容。TiledLayer有許多單元格構成，每個單元格能顯示由一個單一

73、Image對象提供的一組貼圖中的某一個貼圖。單元格也能被動畫貼圖填充，動畫貼圖的內(nèi)容能非常迅速地變化；這個功能對于動畫顯示非常大的一組單元格非常有用，例如一個充滿水的動態(tài)區(qū)域。</p><p>　　TiledLayer由一系列單元格組成，單元格可被一組貼圖填充。這個類允許不必使用特別大的圖像來創(chuàng)建大的虛擬層。這個技術在2D游戲中被廣泛用于創(chuàng)建特別大的可卷動的背景。[6]</p><p>　

74、　在游戲中，某些方法如果改變了Layer，LayerManager，Sprite 和TiledLayer 對象的狀態(tài)，通常并不能立刻顯示出視覺變化。因為這些狀態(tài)僅僅存儲在對象里，只有當隨后調(diào)用我們自己的paint()方法時才會更新顯示。這種模式非常適合游戲程序，因為在一個游戲循環(huán)中，一些對象的狀態(tài)會更新，在每個循環(huán)的最后，整個屏幕才會被重繪?；谳喸円彩乾F(xiàn)在視頻游戲的基本結構。</p><p>　　由上面的這5個

75、類就能夠?qū)崿F(xiàn)基本的圖像和動畫的顯示功能。由Sprite類來創(chuàng)建動畫元素，它可以顯示PNG格式文件的某一部分，作為動畫的某一幀。可以方便的對它進行幀的切換，屏幕上位置的變化。以此來顯示游戲中人物、怪物等可移動的部分。用TiledLayer來創(chuàng)建游戲的背景。它能夠?qū)⑵聊环指畛傻却蟮娜舾刹糠?，每一部分都可以用PNG文件的一部分來填充。這就可以方便的畫出游戲需要的背景圖片。還可以根據(jù)某一塊部分時候填充了圖片，來和Sprite類進行碰撞檢測。Sp

76、rite類和TiledLayer類都是Layer類的子類，而LayerManager可以管理這些Layer。它能夠添加和移除一個Layer，也可以對這些Layer進行排序，從而在重畫的時候達到需要的疊加效果。這樣，對于一些小游戲來說，完全可以滿足要求，并且能夠提供相當強的兼容性和可移植性。</p><p>　　4.2 《天下2》對圖像顯示部分的改進</p><p>　　如前所述，MIDP

77、2.0中新增了專門的game包，里面包含了很多用于顯示圖像和動畫的類。但是《天下2》的實際使用中，遇到了很多方面的問題。最明顯的問題是，作為專門處理動畫的Sprite類中每一幀都必須是等寬等高的，但實際使用中，圖片每一幀的分割都是等高但并不等寬的。另一方面，Sprite類只提供了nextFrame和prevFrame這組函數(shù)來控制各個幀的切換，而事實上經(jīng)常需要直接定位到圖片中的某一幀，頻繁的調(diào)用這組函數(shù)顯然也是不合理的。此外，Sprit

78、e類是由圖片構造出來的，而一旦新建出來一個對象，那么其中圖片將是不可變的。因此，在處理比較復雜的動畫時候，將反復的創(chuàng)建和銷毀許多對象，這無論對于程序運行效率還是代碼的重用性都有很大的影響。由此可見，完全采用MIDP 2.0中的動畫實現(xiàn)方法是無法滿足顯示復雜動畫要求的。參考MIDP 2.0中圖像和動畫部分的實現(xiàn)方式，設計一套適合游戲的圖像和動畫顯示系統(tǒng)是必須的。</p><p>　　4.2.1 《天下2》圖像顯示模

79、塊的結構</p><p>　　在《天下2》中，屏幕上的人物，物品等都需要由文件讀取，每個圖片文件都包含有多幀，每幀的寬度也不盡相同。因此必須將圖片資源統(tǒng)一管理起來，進行相關資源的加載與釋放操作，以及記錄每張圖片各幀的偏移量。此外還需要根據(jù)動畫數(shù)據(jù)，組合各個圖片，拼成用于屏幕顯示的動畫幀。圖形顯示模塊的系統(tǒng)結構圖4-1所示。這個子模塊中出現(xiàn)的類包括ResorceManger負責管理圖片資源，TX2Image是最終顯

80、示的基本單位，TX2Fixity代表地圖上不可移動的物體，TX2Sprite代表地圖上可移動的物體，TX2Monster和TX2Hero分別是它的不同實現(xiàn)的子類。</p><p>　　圖4-1：圖像顯示子模塊結構圖</p><p>　　4.2.1.1 ResourceManager</p><p>　　ResourceManager負責維護與該模塊相關的圖片文件?？?/p>

81、以根據(jù)不同需要對圖片進行加載和釋放操作。例如，在城鎮(zhèn)中會顯示建筑物、玩家角色、NPC；到了野外，就需要怪物和野外地形。因此為了有效的利用有限的內(nèi)存，就必須針對不同的情況，加載資源，并在場景切換的時候及時的釋放資源。類里面的為一個javax.microedition.lcdui.Image對象的數(shù)組，用于向屏幕上繪制。同時，還需要保存圖片每幀的下標，已備畫圖時使用。</p><p>　　另一方面，對于怪物和玩家角色

82、（英雄），要將各個幀組合成動畫，需要讀取事先存儲好的數(shù)據(jù)。對于J2ME平臺來說，這部分數(shù)據(jù)量較大，以某個類的靜態(tài)變量形式存儲會大量增加目標代碼的大小，因此考慮已二進制形式存儲到文件中，在游戲開始時，讀取到ResourceManager的一些靜態(tài)變量當中，后來創(chuàng)建的怪物和英雄都只保留一個指向ResourceManager中某個靜態(tài)變量的引用。這樣處理，雖然總的內(nèi)存占用并未減少，但有效的精簡了編譯后目標代碼。</p><

83、p>　　4.2.1.2 TX2Image</p><p>　　TX2Image是游戲中圖形顯示的基本單位。游戲的部分元素由TX2Image直接顯示。例如道具欄中的各種道具，這些不需要顯示在游戲的地圖上，顯示在屏幕上后也不會再移動，直到當前控件關閉。因此該類需要保存的信息包括繪制的位置，該幀的寬度與高度，以及在ResourceManager中對應資源索引和幀索引。圖4-2中各種物品，均是TX2Image的對象

84、。</p><p>　　圖4-2：TX2Image應用實例</p><p>　　TX2Image的最終繪制，通過調(diào)用javax.microedition.lcdui包下Graphics類的drawRegion()函數(shù)實現(xiàn)。</p><p>　　經(jīng)過實際測試可知，在一般該函數(shù)的運行效率較高，畫圖效果比較理想。但在游戲中，為了節(jié)省存儲空間，經(jīng)常會把向左和向右的2幀只存儲

85、向左的一幀，向右的那一幀通過將向左的幀翻轉(zhuǎn)后繪制出來。但經(jīng)測試發(fā)現(xiàn)drawRegion函數(shù)的翻轉(zhuǎn)性能比較差，同樣的一張圖片，在WTK 2.2的模擬器中比不翻轉(zhuǎn)的情況要慢10倍左右。因此考慮采用其他方式解決翻轉(zhuǎn)問題。由于所要處理的翻轉(zhuǎn)只有左右對翻這一種情況，所以可以將圖片分割為一個象素寬的多個部分，每個部分按照相反的順序畫出來。這樣雖然drawRegion函數(shù)被調(diào)用了許多次，但總耗時卻顯著下降了。該過程的代碼如下：</p>

86、<p>　　for (int j = 0; j < width; ++j)</p><p>　　g.drawRegion(rm.images[pictype], rm.offsets[pictype][picindex] + width - j - 1, 0,1, height, 0, destx + j, desty, 20);</p><p>　　因為drawRegio

87、n函數(shù)是通過native方法實現(xiàn)的，所以無法看到其源代碼。但根據(jù)測試結果推測，drawRegion是通過將圖片該區(qū)域的RGB值取出來存到數(shù)組當中，再根據(jù)需要的變換類型進行，對數(shù)組進行運算，再將運算后的數(shù)組繪制出來。因此，整個運算過程耗時比較長。</p><p>　　4.2.1.3 TX2Fixity</p><p>　　TX2Fixity類用于表示地圖上無法移動的物體，如建筑物，NPC等。

88、它們在地圖上的絕對坐標是固定的。但玩家移動時，屏幕的顯示區(qū)域也會相對地圖做響應的移動，因此，這些對象也需要隨時的根據(jù)當前屏幕的位置，計算出自己在屏幕上的坐標，所以要提供一個移動的函數(shù)offset(int dx, int dy)，用于改變自己在屏幕上的位置。這類對象可能由一個TX2Image組成，也可能由多個部分組合而成。但是這類對象的組合都相對簡單，不需要專門存儲各個部分組合方式的數(shù)據(jù)。圖4-3中的建筑物和NPC均是TX2Fixity的

89、對象：</p><p>　　圖4-3：TX2Fixity應用實例</p><p>　　4.2.1.4 TX2Sprite</p><p>　　TX2Sprite類是TX2Fixity類的一個子類，也是一個抽象類。它代表了地圖上可以移動的物體。這里的移動并不是簡單的位移，而是要帶有一定的動畫效果。動畫中各個幀的組合方式在這個類里并沒有規(guī)定，要在子類實現(xiàn)。這個類中最重要

90、的是一個抽象函數(shù)setAct()，外界可以通過調(diào)用它來指定TX2Sprite需要顯示的動畫效果。類中還需要有保存動畫信息的數(shù)據(jù)，這樣在通過setAct(int act, int dir)指定動作的時候才能夠根據(jù)存儲好的數(shù)據(jù)組合動畫。兩個參數(shù)分別指定動作類型（移動、攻擊、受傷）和方向（上、下、左、右）。動畫的每一幀一般都由多個部分組成，data中存儲了動畫所需的各個幀，因此在每次重畫的時候需要根據(jù)當前幀的數(shù)據(jù)，來設定images中每個元素

91、的值。</p><p>　　4.2.1.5 TX2Hero和TX2Monster</p><p>　　TX2Hero和TX2Monster都是TX2Sprite的子類。它們的不同之處在于動畫的來源不同。TX2Monster類的動作都是存儲好數(shù)據(jù)中的連續(xù)幀，例如第1，2，3幀代表背向移動，4，5，6幀代表正面移動等。這樣的規(guī)則是確定好的，所以TX2Monster在外界調(diào)用setAct()的時

92、候，可以根據(jù)指定的動作，直接找到開始幀和結束幀（maxacition字段）。</p><p>　　TX2Hero的動作要復雜些，而且?guī)瑪?shù)很多，又沒有很強的規(guī)律。所以需要事先儲存好一個動作表。例如，背向移動、正向移動、側(cè)向移動以次為{4, 3, 5, 3}, {1, 0, 2, 0}, {7, 6, 8, 6}。這樣在指定動作的時候，先要去動作表中讀取所有的動作信息，再根據(jù)這些信息進行畫圖操作。也就是需要一個sho

93、rt的數(shù)組來存儲這些信息。</p><p>　　這兩個類的畫出動畫效果都需要在類中設置一個變量來標志當前畫到了哪一幀。這樣，再每次重畫的時候，可以改變它的值，指向下一幀，這樣就畫出了動畫效果。</p><p>　　圖4-4中的玩家角色和敵人分別是TX2Hero和TX2Monster：</p><p>　　圖4-4：TX2Hero和TX2Monster應用實例<

94、/p><p>　　4.2.2 圖像變色的設計</p><p>　　在J2ME平臺上一般通過javax.microedition.lcdui.Graphics類的drawRegion函數(shù)來實現(xiàn)。這個函數(shù)可以繪制一個PNG圖片的某一部分。它的效率和穩(wěn)定性也都很令人滿意，但這個操作是不支持變色處理的，如果想用這種方法實現(xiàn)讓圖片變色，除非準備多張圖片，這顯然是不可接受的。</p><

95、;p>　　Image類中提供了getRGB()方法，Graphics也有drawRGB()方法，這樣可以將圖片中的一部分RGB數(shù)據(jù)取出來，針對顏色變換的規(guī)則改變RGB數(shù)據(jù)的值，在通過drawRGB()畫到屏幕上。這樣可以通過調(diào)用平臺提供的接口實現(xiàn)，但是這樣做內(nèi)存占用會很大，每次畫圖都要進行一次getRGB()和drawRGB()，顯然也會大大的降低畫圖的效率，增加畫圖的延遲時間。在《天下2》的設計中，采用了另外一種實現(xiàn)方法。<

96、;/p><p>　　4.2.2.1對PNG文件重新編碼</p><p>　　實現(xiàn)圖片變色的第一步，是對PNG文件進行重新編碼，為后期在的渲染做好準備。在Windows下通過VC提供的GDI＋庫，可以取出每個點的RGB數(shù)據(jù)。對PNG文件的每個象素點進行一次掃描，對其的RGB值進行一次統(tǒng)計。得出共使用了多少種顏色，這就可以生成一個調(diào)色板。在將RGB數(shù)據(jù)替換成調(diào)色版的索引值，最后使用LZSS算法對其

97、進行一次壓縮，這樣就完成了編碼工作。</p><p>　　LZSS算法的是一種基于字典壓縮的滑動窗口壓縮算法，其基本原理是以前面出現(xiàn)的串作為字典，然后對后面出現(xiàn)的相同串用編碼代替，而達到壓縮的目的，如下是一段要壓縮的文本：</p><p>　　---------------------------------------------</p><p><b>

98、;　　|</b></p><p>　　for(i=0;i<MAX-1;i++)</p><p>　　for(j=i+1;j<MAX;j++)</p><p><b>　　|</b></p><p>　　---------------------------------------------<

99、;/p><p>　　+--------- 滑動窗口 -------------+-向前緩沖-+ </p><p>　　LZSS把要壓縮的內(nèi)容讀到一個滑動窗口和向前緩沖區(qū)中，然后把向前緩沖區(qū)中的內(nèi)容與滑動窗口中的內(nèi)容進行比較發(fā)現(xiàn)“<MAX”與窗口中的第9個字符開始的四個字符，這樣“<MAX”就編碼為“9,3”，而LZSS用12位作索引4位作長度，所以總共用16位就可表示“<M

100、AX”，但是，如果找不到匹配的詞組或只匹配一個字符時就直接用原字符，不過在壓縮碼中要有標志來區(qū)分這種區(qū)別，所以每8個壓縮碼就用一個字符8位來表示是否壓縮。</p><p>　　LZSS算法在壓縮過程中是比較復雜的，它需要用一個二叉樹來加快查找操作，但其解壓過程十分快。因為解壓時它不需要另外建立詞典，已經(jīng)解壓的文本就是詞典，而且解壓時不用查找，而是直接定位，所以LZSS的解壓速度和直接拷貝的速度幾乎相同。</

101、p><p>　　圖4-5：PNG文件重新編碼后的文件結構</p><p>　　圖4-5顯示了重新編碼后的文件格式（括號中為占用的字節(jié)數(shù)）。文件開始首先是圖片寬度和長度值，之后是調(diào)色板的長度值，假定寬度為w，高度為h，調(diào)色板長度為L。調(diào)色板數(shù)據(jù)為一個int的數(shù)組，數(shù)組長度為L。后面為圖片象素數(shù)據(jù)，是一個byte的數(shù)組，保存調(diào)色板的索引值，長度為h*w。這樣編碼后的文件保證了文件大小和PNG大體相

102、當。</p><p>　　4.2.2.2 渲染時的處理</p><p>　　在使用的時候，首先按照這種格式將文件數(shù)據(jù)讀取出來。保存到ResourceManager當中，另外還要定義一個類TX2PNGImage，繼承自TX2Image。不同的是，增加了一個自身的調(diào)色板，在創(chuàng)建的時候，將ResourceManager中與之相對應的圖片的調(diào)色板拷貝過來，在需要變色的時候，只要改變自身調(diào)色板中的值

103、即可。這樣可以針對需要對進行變色處理，而不會對ResourceManager中的原始數(shù)據(jù)產(chǎn)生影響，同時也不用遍歷整個象素的數(shù)組，大大加快了變色的速度。在畫圖的時候，需要申請一塊int的數(shù)組，根據(jù)索引值找到自己調(diào)色板中的顏色數(shù)據(jù)，填充到數(shù)組里面。通過調(diào)用Graphics的drawRGB()函數(shù)，畫到屏幕上。</p><p>　　游戲中需要處理的變色包括兩種：顏色的替換和色相的變換。</p><p

104、><b>　　圖4-6：顏色替換</b></p><p>　　顏色的替換就是要把調(diào)色板中某幾個顏色替換成另外的顏色。圖4-6中兩個框起來的人物，它們都是來自同一個圖片文件的同一幀。但是經(jīng)過了顏色的替換，衣服的顏色就由紅色變成了粉紅色。這時就需要遍歷TX2PNGImage的調(diào)色板，在找到相應的顏色后將顏色值替換掉即可。</p><p><b>　　圖4-

105、7：色相變換</b></p><p>　　色相變化首先要將RGB數(shù)值轉(zhuǎn)換成HLS數(shù)值。HLS代表色相、亮度和飽和度。色相的變化也就是改變H的值，然后再轉(zhuǎn)換成回RGB值。圖4-7中兩個人盔甲，由金黃色調(diào)變成了藍色色調(diào)。根據(jù)類似這樣的顏色變化要求，要遍歷所有的調(diào)色板的值，將其替換成更改后的值。</p><p>　　相對于后面象素數(shù)據(jù)來說，調(diào)色板的數(shù)據(jù)量要小的多。因此相對于每次get

106、RGB( )，再操作RGB數(shù)組中的數(shù)據(jù)來說，這樣程序的執(zhí)行效率要高的多。每次重畫的時候，雖然最終也是調(diào)用drawRGB()來實現(xiàn)的畫圖功能，但每次操作的都是一個byte型的數(shù)組，相對于每次都要通過getRGB()來操作int型的數(shù)組，內(nèi)存的峰值需求要小的多。因為在移動設備上內(nèi)存是相當緊張的資源，這樣可以有效的避免因內(nèi)存不足引起的程序崩潰。</p><p>　　4.3 J2ME平臺下圖像顯示技術的探討</p&

107、gt;<p>　　在游戲程序設計中，圖像顯示的效果往往是最受關注的方面。如本章的第一節(jié)所述，Sun也一直致力于制定J2ME平臺用于游戲的圖像顯示的標準。MIDP 2.0中加入的Game API有效的改變了MIDP 1.0時代各自廠商使用自己API的局面。從平臺發(fā)展的角度看，這也是必然趨勢。</p><p>　　但我們也看到，目前發(fā)布的MIDP 2.0中這些API還只是制定了一些最基本的規(guī)范，很多高級

108、的動畫效果都沒有實現(xiàn)。就像前文提到的圖片變色技術，盡管按照這種方式，以比較小的代價實現(xiàn)了動畫中的圖片變色的需求。但從程序設計流程可以看到，這個方案也有它自身的缺陷。首先，對PNG進行重編碼，并存儲編碼后的信息這個步驟就沒有很強的通用性。如果目標圖片較大，這樣的編碼很可能增大圖片文件的大小。其次，按照前面描述的渲染時處理方法，每次重畫都要新建一塊RGB的數(shù)組。這個過程本身就要求有比較多的空余內(nèi)存，對程序的運行速度也有一定的影響。雖然測試發(fā)