【正文】 } public void keyPressed。 //自定義的健值常量進(jìn)行移位 每個自定義的健值常量用每個 int 中的 0~21bit 表示 public final static int C_KEY_NUM0 = (10)。 如代碼 414： 代碼 414 傳入鍵值 這樣我們就可以處理 游戲中 一直按 鍵和按下鍵。 //釋放 LOGO 對象 if (isKeyPressed()) { //按數(shù)字鍵 8 向上移動 } static boolean unWalkableTiles(int ri, int le) { //地圖中不可能通過的 tile} 中山大學(xué)南方學(xué)院 2020屆本科生畢業(yè)設(shè)計 29 代碼 412 存儲鍵值 然后我們在 K 類里，將 Constance 里的鍵值轉(zhuǎn)換為自定義鍵。 如代碼 412： public static boolean unwalkable(int ri, int le, int x, int y) {//下一步將走的長度是否整除地圖塊 if (!(ri, le + i)) {//判斷在下一步長度中是否存在不可通過的地圖塊 } } public void heroAction() { if (isKeyHeld()) { //是否一直按數(shù)字鍵 6 向右走 (1)。比如在 Game_Canvas 類里 ，如代碼 411： 代碼 411 設(shè)置線程 這里我做了用自定義鍵值來存設(shè)備的鍵。 如代碼 49 所示： 代碼 49 判斷是否可以通過 在 Game_Canvas 類中的 heroAction()方法 中判斷 是否可以通過，如果下一步是可以通過的，坐標(biāo)才允許改變。 我們在 Game_Canvas 類中用 boolean public class Game_Action{ loadAnimation(String Dpng, String Dani){ //讀入動畫流，讀出數(shù)據(jù) } } public boolean currentAnimation(byte Num){ //用來控制當(dāng)前動畫 } public static boolean colliding(int aX, int aY, int aW, int aH, int bX,int bY, int bW, int bH) {//結(jié)果取反 } void GameLoop() { if (colliding(npcaX 4, npcaY + 20, , )) { //是否主角和NPC 碰撞 } } 中山大學(xué)南方學(xué)院 2020屆本科生畢業(yè)設(shè)計 28 unWalkableTiles(int ri, int le)來存儲地圖中不 可通過的地圖塊索引 。此方法是 用極限思想來判斷的，把兩個矩形不碰撞的結(jié)果取反。 效果如圖 49，代碼 46： 圖 49 與 NPC 碰撞效果 代碼 46 判斷是否與 NPC 碰撞 矩形碰撞是計算矩形大小 。 比如說，主角與 NPC 碰撞后對話，與任務(wù)觸發(fā)點碰撞?？梢詺w納為兩類判斷，矩形碰撞和主角與地圖碰撞。//緩沖中的地圖 X位置更新。 如代碼 45 所示： public static void updatamap() { //根據(jù)主角的移動來更新地圖 if (viewX + bufferX + bufferW) {//向右更新 } } public void drawMap(Graphics gr) { //畫地圖，平滑移動 int mX = mapX + bufferW / tileW。然后在 Game_Action 類中，將 *.ani 以流的形式讀入，再讀取出來，再繪制。 圖 48 主角攻擊效果 Game_Action 類封裝了所有動畫的繪制。 G 類 中的 paint()調(diào)用 World 類里的 drawMap()來實現(xiàn)地圖的繪制 。 i bufferH / tileH。 如代碼 43： public void init(){DataInputStream data = new DataInputStream(.getClass(). getResourceAsStream(/hedy/))。如代碼 42： 代碼 42 更新地圖 然后是 World 中的 updatamap()方法 。 首先 World 類中的 Init()讀入 HotEdit 制作出來的 *.map 二進(jìn)制文件，然后再根據(jù) *.map 中數(shù)據(jù)的順序依次讀出來。 45 度角 ARPG 游戲 的 實現(xiàn) 地圖 模塊 的實現(xiàn) 游戲中的效果的最直接表現(xiàn)就 是地圖，由了地圖，游戲的效果就出來了一半了。 （ 3） 圖片分拆。假如有多張規(guī)格一樣的圖片，可以把它做成一張長條圖片。再使用 PngMate 壓縮圖片。所以防止內(nèi)存溢出最直接的辦法就是從圖片入手 : （ 1） 圖片壓縮。 2. 程序用到的基本類型的優(yōu)化 對于程序中用到的基本類型來說，盡量減小類型所占用的內(nèi)存，比如說 中山大學(xué)南方學(xué)院 2020屆本科生畢業(yè)設(shè)計 25 能用 byte 的就不用 int,能用 char 的地方，就不要用 int。實際上垃圾回收器并非是實時的。內(nèi)存優(yōu)化主要包括：代碼優(yōu)化和圖片優(yōu)化。從而節(jié)約系統(tǒng)的開銷。 JAVA 允許在代碼的任何地方定義和初始化對象。因為管理一個對象緩沖池的“開銷”要比平繁地生成和回收對象的“開銷”小得多。 4. 避免生成不常使用或聲明周期短的對象或變量。對于 StringBuffer 類來講，默認(rèn)的分配空間大小是 16 個字符。 3. 生成對象時，要分配給它合理的時間和大小。 2. 不要對已生成的對象作過多的改變。 對象的生成和大小調(diào)整 充分利用 J2ME 提供的庫函數(shù)優(yōu)化程序，對 J2ME 程序的性能是非常重要的，關(guān)鍵點如下： 1. 盡可能地使用靜態(tài)變量。 3. 啟動的時間，程序啟動需要多少時間。所以程序的性能，主要包括： 1. 運算的性能，那一個算法的執(zhí)行性能最好。因此，與其努力提高所有代碼的效率，不如找出代碼中 的瓶頸部分，使之更高效，這樣會得到更高的效益。 優(yōu)化程序設(shè)計 J2ME 程序的優(yōu)化，一般來說與大多數(shù) JAVA 程序的優(yōu)化方式是相同的，但是由于支持 J2ME 的設(shè)備的限制，需要做出特別的優(yōu)化。 這就是卡馬克算法的主要思想，這樣可以很大節(jié)約內(nèi)存開銷，繪制時間也充裕。 圖 45 卡馬克算法原理圖 中山大學(xué)南方學(xué)院 2020屆本科生畢業(yè)設(shè)計 23 圖 46 卡馬克算法原理圖 圖 47 卡馬克算法原理圖 在初始化之后，我們的 buffer 雖然只顯示了屏幕大小，但是實際上是比屏幕大的，沒有顯示出來的部分就是我們移動后將要顯示的部分。那這個就是我們這種算法的思想。其實從上面我們可以看出，當(dāng)我們的地圖從 1 移動到2 的情況時，我們的屏幕顯示的地圖是 B~F 這一段，可是我們預(yù)留下的 A 部分卻沒有用了，所以我們現(xiàn)在要把這個部分利用起來。就是說不論怎樣更新，我們能看見的地方最多就比我們的屏幕大一個 Tile 的寬度！反 過來說，就是我們只需要比屏幕大一個 Tile 的圖片就能在上面展示我們所有的地圖場景了。 這樣，也就是使我們改進(jìn)了我們的方法，就是把顯示的區(qū)域直接畫到屏幕上。但是仔細(xì)觀察上面這副圖。其實在我們在向右運動的時候，實際上我們是在讓 buffer_x 向左。下面主要介紹其原理。根據(jù)中山大學(xué)南方學(xué)院 2020屆本科生畢業(yè)設(shè)計 21 這些弊端，本游戲決定用卡馬克的地圖算法。移動地圖的時候，就會進(jìn)行重繪制地圖，因為繪制地圖量比較大，我們不可能重繪整張地圖，畫圖片是很耗時的操作，能盡量的少那就盡量的少?？R克在 1979 年的時候提出的，其核心思想是把地圖卷動過程中移出屏幕（不需要顯示的部分）所占的區(qū)域，繪制上新的需 要圖塊，從而實現(xiàn)降低內(nèi)存，提高效率的目的，卡馬克算法的提出不單只影響了游戲開發(fā)的進(jìn)度，而且大大地提高了游戲的質(zhì)量 [8]?，F(xiàn)在大多數(shù)手機(jī)都支持雙緩沖。繪制動畫時經(jīng)常需要不斷地更新畫面，而更新畫面的操作就是先將屏幕以 fillRect()的方式清除，再將下一張圖片畫在屏幕上，然而 反復(fù)的清除及重繪會造成屏幕的閃爍現(xiàn)象（ flicker） ，因此使用雙重緩沖的好處就是在背景進(jìn)行這個清除及重繪的操作，再將完成的繪圖拷貝到屏幕上，由于用戶看不到清除的操作，因此就不會出現(xiàn)閃爍的現(xiàn)象了。 Image 類提供了一個建立背景的靜態(tài)方法 createImage(int width, int height)，再利用 getGraphics()方法取得屬于這個背景的 Graphics 對象，所進(jìn)行的繪圖操作都會作用在背景上，等到全部的繪圖操作完成后，再調(diào)用 drawImage()方法將背景的數(shù)據(jù)復(fù)制到實際顯示的屏幕上。 在沒有 前，進(jìn)行游戲繪圖一般需要手動編程使用雙緩沖。程序只能在 paint()函數(shù)中使用 Graphics 繪制，GameCanvas 可調(diào)用 getGraphics()函數(shù)直接繪制在緩沖區(qū)上，可以在任何時間請求傳輸?shù)角芭_。 Graphics 可以提供簡單的二位的二維幾何繪圖功 能，它與 J2SE 中的 類非常相似。應(yīng)當(dāng)將鍵代碼轉(zhuǎn)換為游戲鍵的代碼，以便硬件開發(fā)商能定義他們自己的游戲鍵布局。 Canvas 提供了鍵盤事件、指點桿事件（如果設(shè)備支持），并定義了允許將鍵盤按鍵映射為游戲控制鍵的函數(shù)。為了能有程序開發(fā)人員控制接口的外觀和行為，需要使用大量的初級用戶接口類，尤其在游戲程序中，幾乎完全依賴的就是 Canvas 抽象類進(jìn)行繪圖。低級事件處理方法未聲明為抽象方法，其默認(rèn)實現(xiàn)為空，也就是說可以什么都不作。應(yīng)用程序如果要使用，必須擴(kuò)展 Canvas類。 Canvas 類是實現(xiàn)低級 API 的 Displayable 類的子類，它提供了繪制方 法以及應(yīng)用程序所忽略的一些低級事件處理方法。低級 API 包括兩個部分一個是 Canvas（畫布）類，在 Canvas 類上，可以進(jìn)行圖形操作，同時它也是低級事件的接受者；另一個是 Graphics 類，它可以用來提供文本和圖像，并且能夠?qū)崿F(xiàn)繪制和填充圖形?！暗图? API”卻為應(yīng)用程序提供了這方面充分的控制權(quán)，并且應(yīng)用程序還可以訪問低級事件。“高級 API”強(qiáng)調(diào)可移植性，它使用高度抽象的方法從而將開發(fā)者的實現(xiàn)細(xì)節(jié)都掩蓋了。此類派生自 Canvas，此類還處理資源的載入，屏幕的繪制等工作。 游戲的架構(gòu) 消減狀態(tài) (Destroyed) 停止?fàn)顟B(tài) (Paused) 運行狀態(tài) (Active) StartApp() DestroyApp() 呼叫 MIDlet 的構(gòu)造函數(shù) DestroyApp() PauseApp() 圖 41 MIDlet 的流程 中山大學(xué)南方學(xué)院 2020屆本科生畢業(yè)設(shè)計 19 游戲的架構(gòu)如下圖 42 所示： 圖 42 游戲 架構(gòu)圖 邏輯主要在 GameCanvas 類中實現(xiàn)。 GMIDlet 類繼承自 Midlet， G類繼承自 Canvas。如：主角的HP，敵人的 HP，物品的掉落，與 NPC 對話，任務(wù)等屏幕上相關(guān)信息的繪制等。在主程序運行的線程中，游戲中所有的對象都應(yīng)該運行在同一個線程下。運行程序后允許用戶選擇執(zhí)行選項菜單，在開始游戲后將先從外部文件載入地圖文件，對背景的所有物體進(jìn)行繪圖。如果 unconditional 為 false 的時候， MIDlet 可以在接到通知后拋出MIDletStateChangeException 而保持在當(dāng)前狀態(tài)，如果設(shè)置為 true 的話，則必須立即進(jìn)入 destroyed 狀態(tài)。值得一提的是 destroyApp(boolean unconditional)方法，事實上，當(dāng) destroyApp()方法被調(diào)用的時候， AMS 通知 MIDlet進(jìn)入 destroyed 狀態(tài)。在啟動一個 MIDlet 的時候，應(yīng)用管理軟件會首先創(chuàng)建一個 MIDlet 實例并使得他處于 pause 狀態(tài)，當(dāng)startApp()方法被調(diào)用的時候 MIDlet 進(jìn)入 active 狀態(tài)，也就是所說的運行狀態(tài)。在 MIDP 規(guī)范中定義了 MIDlet 的中山大學(xué)南方學(xué)院 2020屆本科生畢業(yè)設(shè)計 18 生命周期，以及可 以存在的三種狀態(tài)，包括 Paused、Active 以及Destroyed，每一個 MIDlet在任何時刻只可能 處于其中的一個狀態(tài)。 MIDlet 及相關(guān)