下載地址（內含源碼、jar以及九種不同類型的遊戲示例）：http://loon-simple.googlecode.com/files/LGame-0.3.1.7z
1、自0.3.1版起，JavaSE與Android版圖像渲染部分均轉爲OpenGL（ES）實現，在大多數支持GLES硬件渲染的Android機型中，框架性能至少會有20%-50%不等的提升。但是，在少數僅支持GLES軟件渲染的機型中，性能將會出現20%-50%不等的下降(含模擬器 -﹏-||| )……
2、爲不破壞原有框架結構，並充分發揮OpenGL性能，在保留原有LImage，LFont，LColor，LGraphics等繪圖類的基礎上，渲染方式做如下兩點變動：
2.1、原有基礎遊戲畫布由LGraphics轉爲GLEx，該類爲OpenGL(ES)，JavaSE，JavaME的常用渲染API集成，即便用戶完全不瞭解OpenGL渲染機制，同樣可以延續LGraphics的使用方法。另外，此類雖然不再允許直接渲染Android的Bitmap以及JavaSE的Image，卻可以像舊版的LGraphics一樣直接渲染LImage，而新增的專用紋理類LTexture，同樣也可以經由LPixmap，LImage，Bitmap，Image轉換生成。
2.2 爲適應OpenGL色彩機制，舊版原有的LColor類不被允許直接使用於GLEx之上，而只允許使用新增的GLColor類。但是，該類API部分實際上與原有的LColor如出一轍（其內部就是將色彩分量除以255轉爲OpenGL使用的浮點數值罷了|||）。最後，舊有的LFont依舊在GLEx類中通用，其它部分與舊版沒有任何區別。
3、統一封裝了Android版與JavaSE版的人機交互設備接口，所有鍵盤事件一律封裝爲LKey類，所有鼠標事件一律封裝爲LTouch類，不久後會發佈的WP7版以此爲例。
4、爲避免框架過快膨脹，自0.3.1版起LGame核心jar不再內置open JDK的geom包，這將導致Android版LGraphics類功能略有減少，但鑑於核心渲染類已經轉爲GLEx，因此對舊版用戶造成的影響可以說非常微小。此外，由於LGame自動生成圖像形狀依賴此包，所以它並沒有被遺棄，而是轉移到了physics擴展包中。
5、爲儘可能壓縮框架體積，此版框架結構略有變動，原有的map包下形狀組件一律被放入舊版的geom包下，原有的window包被更名爲component，原有window包及其子包中類一律被放入此包，並新增task、input、opengl、particle四個組件包及相關類。
6、修正了所有已發現的舊版BUG，並微調了框架顯示方式，以儘可能適應絕大多數機型的運行需求。
關於使用OpenGLES的幾點注意事項：
1、OpenGLES對於Android系統而言絕非萬靈丹，即便代碼優化的多麼完善，也並不意味着在所有Android手機上都一定可以跑出同樣理想的速度與效果。事實上，OpenGLES的高效只體現在能夠支持硬件渲染的那一部分手機機型上，而對於僅支持軟件渲染的機器則【徹底】無能爲力。對這部分手機而言，GLES的渲染速度甚至不如Canvas繪圖來得高效。
說到目前Android手機中最爲普及的GLES軟件渲染實現，則首推Google提供的Android Pixelflinger（當前最高版本1.4），假如您通過真機的OpenGLES取GL_RENDERER參數時“僅僅”看到了“Android Pixelflinger”字樣出現的話，就意味着這臺機器必定與GLES開發無緣，請換一部手機，或者改回Canvas開發吧（當然也可以做兩個版本，讓用戶自行選擇）。實際上，在HTC的部分低端機型、LG的部分低端機型、Archos的部分低端機型，以及一切使用了國內某星早期解決方案的機型中，全部可以看到Android
Pixelflinger“單獨出現”，如果誰在這批低端手機中選擇GLES進行遊戲開發，則無異選擇了讓馬車拉着火車跑一樣恐怖。
再者，不同廠商提供的GLES硬件渲染其實也存在着不同程度的效果差異（別以爲所有廠商都完完整整的遵循OpenGL規範幹活），小弟在這裏推薦http://www.glbenchmark.com這個比較權威的網站進行相關查詢，其中提供有絕大多數常見智能機的GL，EGL參數列表，並且附帶有各種機型真機的FPS測試數據。要知道“失之毫釐，謬以千里”，如果手機本身的OpenGL性能就是dog shit，那麼跑在shit上的東西多半也會成爲shit。
2、使用OpenGLES進行遊戲編程，在大多數情況下意味着您必需放棄模擬器的使用，而僅能以真機或者PC版框架進行開發。因爲Android模擬器默認基於Android Pixelflinger，軟件渲染GLES本就不快的速度，到了模擬器上更會氣得您將電腦砸掉。
3、爲照顧舊版的Canvas實現，現階段改版只完成了LGame渲染內核的OpenGL化，也就是基本延續舊版API，僅變動函數的具體實現代碼。然而，由於OpenGL與Canvas在運行機制上存在有一定差異，就渲染效率而言這顯然並非最優選擇，故此未來還有相當巨大的優化空間。（舉個例子，在任意機型中以Canvas顯示一幅1024x1024的Bitmap圖像雖然都會很慢，但絕不至於將FPS壓到個位數。然而，在某些機型中如果以GLES加載一副此尺寸的紋理，就很可能瞬間讓FPS低於10，但讓同樣的機器同時跑數張512x512的紋理，速度卻依舊在50-60晃盪，這就是差異的體現。題外話，0.3.2將改進的重點之一就是“自動合併小圖爲統一紋理，自動分解大圖爲合理的紋理數量”）
4、舊版的Canvas實現並沒有徹底廢止，只會作爲一個特殊版本不再更新版本號（也就是無論怎麼改，版本號都是0.3），假如您使用GLES實現開發的並不順利，也可以選擇換回舊版，它依舊提供BUG修正與開發支持……
PS:本次改版並沒有影響到原有程序的代碼結構，所以原有示例也全部可以在新版通用，比如不久前發佈的SRPG示例（新版中運行畫面如下圖）。
另外，此次改版又額外增加了一項ACT遊戲示例（其實，是用很早以前博文中發佈的同類示例修改而成……），鑑於有不少網友詢問聲效播放的問題，所以用此例子來演示一下（新版中運行畫面如下圖）。
下載地址（內含源碼、jar以及九種不同類型的遊戲示例）：http://loon-simple.googlecode.com/files/LGame-0.3.1.7z
——————————————————————————————
除Android版之外，LGame的WP7與iPhone版也在開發當中，WP7版直接使用XNA封裝，移植起來異常省事，加上語法基本一致，年底發佈毫無問題；而iPhone版是做C/C++遷移（實在無法忍受objective-c的語法|||），等於將原有代碼重構一次，預計到明年年初才能完成。
另外還有兩個準備中的平臺，一個是HTML5，考慮到WebGL技術的未來發展，對網頁遊戲引擎的需求應該會越來越大，複雜度也會越來越高，此時出手正是時機；另外一個就是JavaFx，這玩意自2.0版重構以後的發展方向還是未知數，如果Oracle發力或許還有得玩，個人對它持悲觀態度，看Java的面子準備瞧瞧再說……
PS：好久沒上線，發現CSDN博客系統改版，有點不會用，小弟文章效果有問題的話萬望海涵，手生的關係……