x86のAndroidエミュレータでlibGDXを走らせてみた

Androidでのテストは「Nexus 7」の実機で行っているので，仮想環境は今のところ不要．
とはいえ，前のマシンで話にならなかったのがどの程度改善したかなと思い，仮想環境での動作を試してみました．

Atom仮想マシンを使ってAndoidを起動．ホーム画面やブラウザは結構スムーズに動く！

これはちょっと期待できるかもと思い，制作中のプロジェクトをx86向けにビルド．
libpdのpd-for-androidはx86向けのコンパイルオプションが最初から入っているので何も考えなくてOK．
libGDXは現在の安定板ではx86非対応ですが，タイミングの良いことに開発中のnightly buildがサポートを始めているので，ライブラリを最新のものに差し替え．ビットマップフォント表示の関数でバグが出ましたが，そこだけコメントアウトしてあっさり起動しました．

描画はせいぜい30fps．マシンパワーにはまだ余裕があるのでAVD側で間引いている気がします．音も一緒に間引かれたような感じで潰れた音になってますが，一応は止まらずに動いてます．取り急ぎのテストということで．

How to embed pd-for-android in your libGDX project

libGDX supports cross-platform game development.
It is very convenient in the case of using your PC as a test environment of a mobile game application.

When you set up cross-platform project using gdx-setup-ui.jar,
following project folders will be made.

• my-gdx-project : core project, includes main sources, common libraries and interfaces
• your sources are connected to libGDX
• my-gdx-project-android : Android project, includes only Android specific implementations and native libraries
• libGDX is connected to Android: OpenGL ES, touch input, etc
• my-gdx-project-desktop : Desktop project, includes only Win/Mac specific implementations and native libraries 
• libGDX is connected to Win/Mac: DirectX, OpenGL, mouse input, etc

libpd is a library to embed the Data-Flow programming language Pd(Pure Data) in our application programs. Additionally, in Android systems, libpd supports OpenSL ES audio API expected to reduce audio latency after Jelly Bean.

libpd needs platform-specific implementations. So if you want to use libpd in the cross-platform projects, it would be better to trace the same way as above libGDX connection.

libpdでパッチ開いて鳴ったわー

鳴ったぜ．

libpdのJNI側のソースコードやAudio glueとサンプルプログラムを見比べてたら形が見えてきた．

やっぱり3Dは避けて通れなかった

映像的な面でのモチベーションとして，色々なデザインモチーフやVFX的効果を取り入れて動きを出し，画面いっぱいを使って楽しさを演出したいというイメージをもって進めています．

プログラマブルシェーダ使いたさ故にイキナリOpenGL ES 2.0で作り始めてるのは，そんな自分の中のイメージを楽に具現化できる機能というか可能性を感じるからで，全くGPUプログラミングの経験がない自分でも楽に試作を重ねられるGLSL Sandboxは大いに活用させてもらってます．

演算負荷を意識しはじめる

背景のエフェクトは解像度や各種演算精度をダイエットして負荷を節約することとしても、肝心のゲーム部分でも光の散乱や逆光とかパーティクルといったエフェクトを多用するイメージでいるため、なにやら早くもハードウェアリソースを最大限活用する必要がありそう。

CPUさんにはlibpdの動作のほうをがんばってもらう必要があるので、グラフィックについてはGPU/ソフトウェア処理を問わず、しっかり60fps出るように速度をチューニングできる余裕（＝自分の知識、理解）を作っておきたい。

そうなってくると、動作テストのリファレンススペックのようなものを想定しておかないといけない気がします。

libGDXでOpenGL ES 2.0でシェーダ動いた

やればやるほど出口の見えなかったOpenGLでのグラフィック実装ですが，
libGDXを使いはじめてようやく軌道に乗ってきました．

libGDXはJavaベースでOpenGL ESを使ったゲームを作るライブラリですが，
マルチプラットフォームで開発できるので，PC上でもOpenGL ES 2.0で
テストができて超ラクチン．今までテスト環境に困ってたのは何だったんだ．

libGDXは，工程はラップせずに手段をラップする感じのフレームワーク．
ですので自由度がかなり高いと思われる一方，私のような初心者が触るには
敷居のほうも正直高い．
日本語のドキュメントはあんまりないので，主に海外のサイトを見て回って
使い方を覚える感じです．

OpenGLの使い方と並行して，キャラクターの書き込みプロセスや
状態遷移に関するメッセージの渡し方を考えてると，
何気にそれっぽくオブジェクト指向で書けてる気がしてきました，

で，とりあえずグラフィック面では「ここまで出来れば一段落」と思っていた
フラグメントシェーダの実装を形にするところまで辿り着きました．

先日の記事でGLSL Sandboxに投稿したエフェクト．

OpenGLESGLSLSGLEELSEG

いまAndroid上でOpenGL ES 1.0を使ってグラフィックの試作をしているのですが，何をするにも実機に流し込んで動作させてやる必要があって少し面倒．

ちょっとした描画やエフェクトのテスト程度のものは，開発環境(Mac OS XのDesktop画面)上で適当にできたりすると楽だなーと思いはじめました．

一般的なデスクトップPC環境で「JavaでOpenGLをやろう」と言いはじめる際にそれっぽくまとまってそうなのは，JOGLというOpen GLのラッパー．
JOGLは，2009年に開発が終了したver.1.1.1と現行バージョンの2.0が存在しますが，なんか2.0がうまく動かなかったのでとりあえず1.1.1のほうを使いはじめました．

OpenGL ESを触りはじめたり

今まで統合開発環境なんて触れた事があるのは 組み込み屋が使うCode Composer StudioやらHEW程度しかないわけですが，
当然Eclipseはもっともっともっとリッチな環境ということで，
Javaと並行してお勉強を進めながらも 色々とカルチャーショックを受けているところです．

実機デバッグも端末側ではなくあくまで開発環境側の目線から整理されてるあたりも， JTAGとは何だったのかと空を見つめながら思いたくなるところであります… 

その実機デバッグですが，ブレークポイントでうまく止まってくれませんでした．
以下の設定が必要なようです．
 ・AndroidManifest.xmlの"Debuggable"を"true"にする．
・プロジェクトのActivityのonCreateメソッドでwaitForDebugger();を呼ぶ．

protected void onCreate(Bundle savedInstanceState){
 android.os.Debug.waitForDebugger();
 super.onCreate(savedInstanceState);
}

Pdほど頻繁に記事を更新できるようなネタが上がらないと思いますが，
ぼちぼち進めていこうと思います．
libpdの実装に入るまでが第一関門ってとこですかね．

AVDのconfig.ini

AVD上でメニューキーを押してApps一覧を開くと
「Unfortunately, Launcher has stopped.」
とかいって落ちる件．

特に，仮想のDeviceとしてNexus 7を選択した時に起きるという報告がよくされている模様．

Deviceは特定機種を仕様を想定した各種設定値のプリセットにすぎないので，
この問題はNexus 7固有のものってわけじゃないはず．

解決策としては，AVDのconfig.iniをテキストエディタで開いて
設定値を手でいじるというのが出回ってます．
config.iniの場所は以下．
~/.android/avd/{avd_name}/config.ini
というかAVDのイメージとかスナップショットとかもこのドットディレクトリの中に入ってるんですが．
重いバイナリをローカルにしれっと隠さないでくれよなー頼むよー（懇願）

で，以下の2項目を更新します．

Android仮想デバイスが重すぎて仰天

iOS SDKを入れてみて触ったiPhone Simulatorは
サクサクで快適なテスト環境だったんですが，
Android SDKのAndroid Virtual Deviceに同じものを期待していたら
どっこいはるかに重くて戦慄…
はっきりいって使い物にならんですな．

この規格外な遅さのストレス，なんか昔にあったような…と思ったら，
G4でVirtual PCを動かした時の，あのとてつもない苛立ち。あれだ．


そんなこんなで，みなさん速い仮想マシンを使おうと苦心されているようです。
一番メジャーなのは，ARMではなくx86の仮想マシンを立てて
x86ハードウェアでサポートされてる仮想化支援機能を効かせるという手法のようです．

Get started

最近、実現してみたいゲームを脳内で温めてるんですが，
たたき台でも自分で組み立てられないと，人を巻き込むこともできないなーという所で
しぶしぶ（？）手を動かし始めることにします．

タッチスクリーンタイプのデバイス上で組むことを想定しているんですが，
人を巻き込みたいという前提があると，実機のデバッグ環境がいちいち年会費制になるiOSは
なにかと不便だなあという印象を持ちました．
というわけで，まずはプラットホームとしてAndroidを選んでみたのですが，
当然Androidでのアプリケーション開発を勉強しなければならないわけで…