VirtualPC で Windows7 βを動かす

結論から言うと、全く書くことがないくらい、あっさりとインストールできました。（ただし、32bits版です。）

さらに、操作メニューにある、「バーチャルマシン追加機能のインストール／更新」もばっちり動きます。

これで、右ALTキーを押す必要もありませんし、なにより、ウィンドウを任意のサイズに引き伸ばしたりすることもできます。縦長のWindowsってのもいいですね。

使っているウィルスソフトも動いたし、何にも問題はありませんでした。すること無いので、付属のゲームでも動かしてみたりして。

あと、Aeroは動きません。エクスペリエンスインデックスの評価時に、
「仮想マシン内では評価を実行できません。」
とわざわざ教えてくれます。

グラフィックス以外の数値を見たかったのですが、まあ、しょうがない。

Android Dev Phone 1 でセンサー入力

android ではセンサー入力が一般化されています。G1では、主に、角度（方位）、加速度センサーの入力です。

Javaからの使い方ですが、implements SensorListener　をつけたクラスに、

public void onSensorChanged(int sensor, float[] values) {
}

こういうコールバックを準備しておきます。

あとは、
SensorManager mSensorManager;
mSensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);

とサービスを取得して、アプリが動作する際には、

mSensorManager.registerListener( _view,　// SensorListener　をつけたクラス
SensorManager.SENSOR_ALL,　　 // センサーの種類に応じて
SensorManager.SENSOR_DELAY_GAME);　　// 目的に応じて

を呼びます。

必要ないときは、

mSensorManager.unregisterListener( _view );

でリリースしておくようです。

G1 で動いているセンサーの値は、

SENSOR_ORIENTATION
SENSOR_ACCELEROMETER
SENSOR_MAGNETIC_FIELD

の3種類のようです。android としては、これ以外にも、温度やライトのセンサーなども定義されています。

ついでに、定義されている定数がいろいろ。GRAVITY_DEATH_STAR_I　って何？

float GRAVITY_DEATH_STAR_I 3.5303614E-7
float GRAVITY_EARTH 9.80665
float GRAVITY_JUPITER 23.12
float GRAVITY_MARS 3.71
float GRAVITY_MERCURY 3.7
float GRAVITY_MOON 1.6
float GRAVITY_NEPTUNE 11.0
float GRAVITY_PLUTO 0.6
float GRAVITY_SATURN 8.96
float GRAVITY_SUN 　　 275.0
float GRAVITY_THE_ISLAND 4.815162
float GRAVITY_URANUS 8.69
float GRAVITY_VENUS 8.87
float LIGHT_CLOUDY 100.0
float LIGHT_FULLMOON 0.25
float LIGHT_NO_MOON 0.0010
float LIGHT_OVERCAST 10000.0
float LIGHT_SHADE 20000.0
float LIGHT_SUNLIGHT 110000.0
float LIGHT_SUNLIGHT_MAX 120000.0
float LIGHT_SUNRISE 400.0
float MAGNETIC_FIELD_EARTH_MAX 60.0
float MAGNETIC_FIELD_EARTH_MIN 30.0


あと、このセンサーは何でしょうか。

public static final int SENSOR_TRICORDER
A constant describing a Tricorder When this sensor is available and enabled, the device can be used as a fully functional Tricorder. All values are returned in SI units.

Android Dev Phone 1 でタッチパネル＆トラックボール入力

投稿を分けますが、G1で入力インターフェースを色々試しています。

ＵＩのサンプルプログラムは、ApiDemos に入っているので、そちらを参考にしています。現在、主に、OpenGLESのプログラムをCで書いていますが、UIはJAVAのクラスが充実していますので、JAVA側で取得して、Nativeに渡すようにしています。

まず、タッチパネルですが、特に問題なく動きました。

まず、View のクラスに

@Override
public boolean onTouchEvent( MotionEvent event) {
return true;
}

をつければいいです。また、トラックボール入力は、

@Override
public boolean onTrackballEvent( MotionEvent event) {
return true;
}

これでよいはずです。

あと、これだけで動かなくて困ったときは、
setClickable(true);
setFocusable(true);
を呼んでおきましょう。重要なおまじないです。

ただし、このタッチパネル＆トラックボール入力は、かなり重たいように感じています。タッチしているときのGLのパフォーマンスを見ていると、フレームレートが半分になったりして、どこかでスレッドの処理が固まっている感じもします。他のセンサー入力も同様のコールバックですが、そんなことにはなりません。まあ、そんなに激しくタッチするアプリも少ないと思うので今のところ困ってる人はいないのかもしれませんが。

さらに、タッチパネルやトラックボールを動かしていると、入力をアプリで使っていなくても、処理が重たい気がします。常時、バックグラウンドでドライバが動いているためでしょうか。

Android Dev Phone 1 で GL_OES_matrix_palette

matrix_palette 関連は　OpenGLES1.1　の仕様だと思っていましたが、1.1 でも拡張機能に入れられてしまったようです。どこかのチップメーカがサポートを嫌がったのでしょうか。android のヘッダにもAPIが見当たりません。

でも、ドライバは、GL_OES_matrix_palette　をサポートしているとでてたので、ハードをたたくドライバ　libhgl.so を使って、拡張APIのシンボルをロードしてみました。

////////////////////////////////////////////////////////////////////
// Load OES symbol
////////////////////////////////////////////////////////////////////
#include
struct dso_symbol
{
char *symbol;
void *api;
};
static struct dso_symbol symbol_table[] =
{
{ "glCurrentPaletteMatrixOES", NULL },
{ "glLoadPaletteFromModelViewMatrixOES", NULL },
{ "glMatrixIndexPointerOES", NULL },
{ "glWeightPointerOES", NULL },
};
void LoadDsoSymbol()
{
int i;
int symbol_num = sizeof(symbol_table)/sizeof(symbol_table[0]);

void *dso = dlopen( "/system/lib/libhgl.so", RTLD_NOW | RTLD_LOCAL );
if( dso )
{
LOGI( "SUCCESS : Load libhgl.so" );
for( i = 0 ; i < symbol_num ; ++i )
{
symbol_table[i].api = dlsym( dso, symbol_table[i].symbol );
if( symbol_table[i].api )
{
LOGI( "SUCCESS : Load %s", symbol_table[i].symbol );
}
else
{
LOGI( "ERROR : Load %s", symbol_table[i].symbol );
}
}
dlclose( dso );
}
else
{
LOGI( "ERROR : Load libhgl.so" );
}

}

その結果、、、、

I/Game1 ( 1302): SUCCESS : Load libhgl.so
I/Game1 ( 1302): SUCCESS : Load glCurrentPaletteMatrixOES
I/Game1 ( 1302): SUCCESS : Load glLoadPaletteFromModelViewMatrixOES
I/Game1 ( 1302): SUCCESS : Load glMatrixIndexPointerOES
I/Game1 ( 1302): SUCCESS : Load glWeightPointerOES

やっぱりシンボルはロードできました。動かしてないけど、たぶん動くでしょう。

android dev phone1 で OpenGLES の速度評価 （２）

今日も速度評価しました。

テクスチャ張ったり、ライティング（平行光源１つ）してみたり、頂点カラー入力してみたり。

昨日もチラッと書きましたら、テクスチャ張ったり、頂点カラー入れたりすると、２０％、３０％と、速度が落ちていきます。これは妥当なところでしょう。しかし、ライティングを行うと、２分の１～３分の１に速度が落ちるのです。

これは、ちょっと速度が落ちすぎです。原因を探ろうと色々やってみた結果、どうも、buffer object　と関係がありそうです。

OpenGLES には、buffer object と呼ぶ、GPU側で管理される頂点メモリがあります（　DirectXでいう　VertexBuffer　）。これを使用するとメモリの転送が減り、ディスプレイリストの構築も軽くなるため、大幅な速度向上が見込めるものであり、G1のアクセラレータも対応しています。（OpenGLES1.0の仕様には入っていませんので拡張APIとして実装されています。）

ただし、buffer objectを使うということは、座標変換やライティング計算をジオメトリエンジンがすべて処理できなければいけません。ですが、携帯向けのプアなハードでは処理できないものもあり、一部をCPUで処理しなければいけなかったりします。例えば、スポットライトの減衰計算が仕様を満たせないとか、ライトの個数が４個以上はCPUで処理するとか、ハードにバグがあった場合とか、、、

今回、速度測定をしてみて、buffer object を使うことで大幅に早くなることは確認できたのですが、ライティングを行うとあまり変わりませんでした。平行光源１個だけだというのに。現状のドライバは、CPUで何らかの処理をしているのでしょうか。光源処理がすべてCPUなのでしょうか。

残念ながら、1M polygon / sec を超えるのは、テクスチャ＆頂点カラーを使ってもよいが、read-only buffer object を使った場合だけのようです。光源処理をした場合は、buffer object を使ったメリットがなくなってしまい、最大でも、400k　が限界でしょうか。

話は変わるけど、G1　の OpenGLES って、MatrixPalette　は実装されているのに、VertexBlend　が見当たらないなあ。確かサポートしていたはずだけど。さらに、1.1 の仕様書からも削除されてる気がする。動かそうと思ってたけど、まあいいか。他にも試したいことは色々あるけど、速度評価はそろそろ終了。

android dev phone1 で OpenGLES の速度評価 （１）

ちまちまと、android dev phone1 でOpenGLESのプログラムを書いています。

いまさら、固定小数のコードを書くことになろうとは思いませんでしたが、数年前にも携帯向けのOpenGLESで固定小数のコードを書いていました。（もちろん、浮動小数でも、どちらでも動かせるように。）もう５年以上前でしょうか。やっと一般の人でも携帯電話で３ＤＣＧが動かせる時代になりました。

もともと参考にしたアプリも速度評価用アプリだったので、だいたいの数値はわかっていましたが、自分で書いてみたアプリでもだいたい同じ値が出ました。

球をストリップで描画するコードを作り、分割数を調整して、１００フレーム平均の速度を出力しました。まだ、ちょっと試しただけですが、

・頂点バッファの頂点数　＝　２０３０１　（２０１ｘ１０１）
・２００頂点　x ２００ストリップ　＝　４００００ポリゴン（頂点）

で描画して、およそ 30fps くらいでした。1.2M　Polygon/秒　くらいです。

半分の２００００ポリゴンにしても、55 fps 出てました。（何も描画しない状態で、最大60fpsです。）

もちろん、頂点座標(x,y,z）のみ、ライティングなし、テクスチャなしの単色塗りつぶしのみです。極小ポリゴンではなく、球が画面の半分くらいの面積を占めても、速度は落ちません。（追記：よく考えると、数万ポリゴンの球ということは、１ポリゴン単位では極小ポリゴンといったほうが正しいですね。）

参考元のアプリでの計測結果で見てみると、最大、1.33M Polygon/秒　くらいだと思われます。このアプリでは、テクスチャを張っても、１M　以上の速度を保っているようですが、ライティングさせると、3分の1 くらいに落ちるようです。

バッファオブジェクトを使っていることもあり、固定小数でも浮動少数でも、大きな速度差は見えません。あと、ストリップハードウェアのようで、ストリップをつかわないと速度は3分の1に落ちるようです。

まあ、Ｇ１はiPhone には負けているでしょうが、趣味で動かすには十分な速度ではないでしょうか。もうしばらく遊んでみます。

android market

いくつかアプリをダウンロードしてみました。

Qualcomm の　３ＤＣＧデモ　「 NeoCore　」は数少ない３Ｄアプリです。
http://jp.youtube.com/watch?v=RqKCam7wgws

背景が真っ黒なのがちょっと気になります。ちなみに、ＢＧＭをＯＮにするとフレームレートが２割程度落ちます。

そういえば、Qualcomm 作ということですが、これって東京タワーですよね。MADE IN JAPAN でしょうか。