PocketPC の gapi

◎ WindowsCE のソフト開発

WindowsCE の開発には、eMbedded Visual Tools を使います。 このツールは無料で手に入れることができます。

もともと WindowsCE のアプリケーション開発には VisualStudio が使われていました。 このソフトは PC の Windows 用アプリ開発に広く使われているもので、 これに各種 CPU 用のコンパイラや WindowsCE ライブラリなど、 WindowsCE SDK をアドオンで組み込んで、Windows95/NT/2000 以外のプラットフォームに対する開発を行います。

VisualStudio は、 シリアルやネットワークでつないだリモートマシンをターゲットにして、 プログラムの実行やデバッグを行うことができます。 PC のソフト開発においても、DirectX を使ったフルスクリーン アプリケーションを作る場合などリモートでバッグのお世話になることがあります。

WindowsCE 組み込み機器の開発も全く同様であり、 PDA (に限らず) リモート接続によって、VisualStudio 上から クロスコンパイルにプログラムの実行、 デバッグ等の開発を行うことができるわけです。

ただし VisualStudio そのものは決して安価なものではありません。 これだけ機能豊富であれば当然かもしれませんが、 VisualC++ 6.0 の Professional 版だけでも 8万円くらいします。

その VisualStudio と機能も使い勝手もほとんど一緒であるにもかかわらず、 WindowsCE 専用の開発ツール eMbedded Visual Tools は、無料で手に入れることができてしまうわけです。

◎ eMbedded Visual Tools

Microsoft eMbedded Visual Tools 3.0 は、 こちら から申し込むことができます。 これは CD-ROM による郵送で、送料と手数料分の 1700円がかかります。

こちら では直接ダウンロードできますが 304M もあるので、 よほど恵まれた環境でないと現実的ではありません。 英語版ですがメニューやメッセージが英語なだけであり、 開発そのものは差がありません。 筆者は Download で(!)手に入れました。

eMbedded Visual C++ の使い方は、VisualC++ と全く同じです。 ターゲットを指定して、リモートデバッグを行う方法も一緒です。

もちろん、これらの開発ツールは Windows 専用です。

◎ gapi

gapi は、PocketPC 用のゲーム API です。 PocketPC 専用(おそらく)で、直接 VRAM にアクセスできること、 そしてボタンなどキー入力情報をリアルタイムに取得することができます。

DirectX と違い、 直接プライマリサーフェースへの lock と unlock のみサポートされていて、 バックサーフェースや Blt といったサービスは一切提供されていません。 DirectX でも Draw を使ったアプリケーションの場合は、 結局バックスクリーンを lock したあと、全部自前で CPU 描画するケースが ほとんどでした。 それを考えると、gapi で提供される機能は必要最小限ながら 「これさえできればあとは自前で何とでもなる」レベルです。

iPAQ はもともと CPU である StrongARM が高速ですが、 それと同じくらいこの gapi も高速です。 iPAQ の VRAM は Landscape で横画面並びで、GXBeginDraw() で アドレスを受け取ることができます。 液晶画面自体は 4096 色(12bit) ですが、VRAM 上は 16bit です。 VRAM アクセスは GXBeginDraw() ではじまり GXEndDraw() で 終了しなければなりません。 ところが iPAQ の場合、この Begin と End はさほど重要ではなく、 対応がいい加減でも動作してしまい、VRAM がロックされません。 Begin と End の呼び出しオーバーヘッドもほとんどありません。

E700 の CPU は MIPS の 4000系で、64bit CPU です。 決して遅い CPU ではありません。 ただし、E700 の gapi は iPAQ に比べると低速です。 液晶の色数は異なるものの、 VRAM ピクセルフォーマットは iPAQ と同様 16bit であり、 色数と速度は直接関係無いようです。

GXBeginDraw() でアドレスを受け取ることができますが、 Begin と End 呼び出し自体にかなりのオーバーヘッドがかかり、 非常に重い処理になっています。 ロックは完全にかかり、対応が間違っていたり割り込まれたりすると VRAM アクセスはできません。 Begin と End のアクセスを行うと、 VRAM アクセスしていないはずの gapi 以外の描画エリア(GDI描画部分)も クリアされてしまいます。

上記の挙動から想像できるのは、 E700 の gapi プレーンは raw な VRAM ではなく仮想的なものであり、 GXEndDraw() のタイミングで 一度全スクリーン転送が発生しているのではないかということです。 GXOpenDisplay() 時にイメージ領域が作られているのかもしれません。

◎ CASSIOPEIA E700 用の flatlib

PocketPC 版 GA 3D Engine である flatlib を E700 にも移植してみました。 結論を言えば CPU の違いはどうでも良くて、問題になるのは gapi の方です。 iPAQ の VRAM 構造が Zaurus と完全に同一であったのに対して E700 は異なります。 90度回転するためにはバックバッファをピクセル単位で Vertical 転送しなければなりません。 互換性を保つために連続アドレスに対する 32bit 転送ができず、 不連続アドレスに対して 16bit 転送しています。 この段階で無駄が生じ、速度が落ちているのは事実でしょう。

また GXBeginDraw() と GXEndDraw() 呼び出しが非常に遅いので、 描画更新をまとめてできるだけ一度の Begin, End で済むように書き換えます。 これで E700 上で動くようになりました。 ただし GDI で描画している部分(fps等) が Begin, End で消えてしまうので、 fps は表示しないように変更しました。

iPAQ に比べると遅くなった E700 版の動作ですが、 これだけプログラムに無駄があるにもかかわらず、 それでもまだまだ MI Zaurus よりは 十分高速です。 現在 ChiRaKS で 60fps 前後出ているものの、 チューニングの余地はまだまだ残っています。

また E700 の画面はバックライト式の 65536色(RGB565) TFT 液晶です。 iPAQ では階調の表現が 4096色に制限されてしまいます。 E700 はハイカラーのままそのまま表示されるので、光源のグラデーションが MI Zaurus 同様かなりきれいに再現されます。

E700 版開発で一番苦労させられたのは LAN 接続できないことでしょう。 シリアルケーブルも持っていないので、コンパイルするたびにいちいち MMC (マルチメディアカード、フラッシュメモリ) による 抜き差しでプログラムの動作確認を行っていました。 さらに E700 の SD カードスロットにはごむのふたがついているので、 これがますます抜き差しを妨害してデバッグしづらくしてくれます・・。 E700 をお貸ししていただいた石田様に感謝します。