程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> J2ME >> 秉承Java思路 開發易於移植的J2ME游戲

秉承Java思路 開發易於移植的J2ME游戲

編輯:J2ME
 1. 屏幕尺寸不同

  這兒談的主要問題,是自適應控件。所謂控件,就是菜單、文本框、列表框、進度條等等。這些控件的大小必須可以根據屏幕大小自適應的調整。按照第一篇說的方法,將屏幕大小作為變量參與到控件尺寸的計算即可得到正確的尺寸(自適應後的)。其次就是得到正確尺寸後怎麼把它畫出來。

  這要看你的GUI是怎麼畫得了,如果是用線畫的,那就很簡單;如果使用了圖片,那麼就可能要更換圖片了。我的控件使用了圖片平鋪和畫線結合,所以可以很容易的改變尺寸。如果控件變大了,則繪制時增加平鋪的次數即可。

  順便說一下,這些控件我只用了一個類表示,使用參數化的方法區分使用,畢竟咱要盡量少用類吧。

  2. 支持的API不同

  如果你的游戲只限於使用Midp1.0,那麼移植的時候就不用考慮什麼了。實際上由於我們經常要使用圖片翻轉、象素繪制、全屏等,往往要用到廠商API或Midp2.0。顯然移植的時候要考慮到這些API的差異。

  我的辦法是將這些api封裝一層,比如我需要使用創建透明子圖的API,於是封裝了一個函數createSubImg。這是Nokia版本:

public static Image createSubImg(Image img,int []imgRect){
Image subImg = DirectUtils.createImage(imgRect[2],imgRect[3],0);
subImg.getGraphics().drawImage(img,-imgRect[0],-imgRect[1],20);
return subImg;
}

  這是Midp2.0版本:

public static Image createSubImg(Image img,int []imgRect){
return Image.createImage(img,imgRect[0],imgRect[1],imgRect[2],imgRect[3],0);
}

  對於不同機型,該函數的實現不同,但功能相同,因此使用這個函數的代碼在移植時無需修改。當然這樣做增加了一些間接性,有可能降低性能。

  3. 按鍵代碼不同我們知道MIDP提供了Game Action,和按鍵代碼無關,但這不夠用啊,我們完全可以定義自己的Game Action,但首先讓我們定義自己的虛擬按鍵碼吧。我使用位記錄每個鍵的狀態,每個位代表一個按鍵,一個int有32個位所以足夠了。當keyPressed發生時,我記下哪些鍵被按下;同樣當keyReleased時,將那些被松開的鍵使用的位清0。某個鍵,也就是這個鍵盤狀態整數裡的某個位,就是我定義的一個虛擬鍵。當然它的值總是2的n次方了,和key code完全不搭邊,所以需要我們用一個映射函數將key code映射到這些虛擬鍵。這個函數就是移植的關鍵,每個機型都要改寫這個映射函數,在裡面填入正確的key code。你可以在虛擬鍵的基礎上再定義Game Action,支持在游戲中設置按鍵,這樣就更靈活了。(4) 封裝庫如果想不更改一行代碼就從MotorolaV600移植到Nokia N-Gage,那麼為他們封裝不同的庫吧。我就這樣在1分鐘內完成了移植。我的庫包含了一個游戲框架類(內含游戲循環和渲染函數,鍵盤處理,以及若干跨機型的工具函數),一個圖形組管理類(管理圖片的載入切割旋轉繪制和動畫等,有點像GameAPI中的Sprite)和一個控件類(包含了所有我需要的控件)。這3個類封裝了不同機型的所有差異,我需要為每種機型改寫這三個類,當然大部分代碼是相同的了。此外我還寫了一個工具支持圖形組管理類,所見即所得的編輯動畫和管理圖片,當然這也對移植有幫助。總結:以上幾條,總得講來,無非是拆合而以。主要是要將差異性獨立出來,便於更改。但是移植總得來講還是比較郁悶,主要原因是各種機型有各自的bug,這就需要特殊處理啦。各位寫代碼時一定要想好移植的問題啊!

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved