コメを噛め

コメを噛め

rerofumi の電子工作メモ

hatena bookmark

GP2X wiz が届いたものの、その後開発マシンのOS入れ替えで開発環境構築し直しにより触れなくなっていたしだい。
GP2X wiz の Toolchain 構築で七転八倒してちょいあきらめた状態(後述)でとりあえず気になっていた Wiz の速度テスト。

スプライトサンプルアプリを動くようビルドして色々とチェックその結果わかったことは……。

私のコードはGP2XとWiz上でもっとも高速に動くよう、16bit depth のフレームバッファモードで動かしているとこはちょいと注意してね。PCの方で32bitで動作させると、倍の負荷がかかったりするから。

wiz_sprite_test

でまあ、このスプライトサンプルアプリではスプライトの数を増やしてどれくらい時間がかかるかをみることができるのです。これでSDLとfbdevの速度をなんとなく見る。
元々の GP2X-200 とかでは、fbdev から液晶に表示させるまでの負荷が異様に重くそれだけで 13~14ms かかっているというのが最大のネック。なので、2Dスプライトでも 60fps で動かすのはほとんど無理。
でも、ピクセルフィルレートは 327680pixel/16ms とそんなに悪いわけでもなく、320x240pixel なら 4画面分とそこそこだった。
なので GP2X-200 では 30fps 以下が基本。
Wiz では、fbdev の処理が 5~6ms と結構高速になっているため色々と軽く見える様だ。
ピクセルフィルレート換算だと 491520pixel/10ms とかなり早くなっている。16ms換算で、786432pixel なので倍を超えている。
その他色々な要素を総合して、CPUクロックが 266MHz から 533MHz にあがった分の数値そのまま高速化されていると考えて良いようだ。画面周りは改善されているので fbdev はそれ以上に早くなった様に見え、それがアプリのスムーズ化に現れている。

んが一つ大きな問題を見つけた。
ファーストインプレッションで「なんか動作が遅い」と言ってた理由がわかった。私がGP2Xの頃使っていた SDL を static で利用していると SDL_tick() の単位が 1ms ではなく 10ms になっているようだ。ハードやカーネルが変わりタイマーの単位が変更となったようだ。なので60fpsを数えるために16msを計測しようとしても、10ms単位なので20msしかわからないということらしい。増えた4msの分だけ遅くなっていたというわけ。
Wiz 内にあるシェアドライブラリではどうかはまだ試せていない。

利用するタイマーを変えるか、シェアドライブラリを試してみるかしないとならないかもなー。
なんとかして、10ms未満で時間を計測できる手法を見つけなくては。

Leave a Reply