コメを噛め

コメを噛め

rerofumi の電子工作メモ

Archive for the ‘GP2X’ Category


hatena bookmark

そういえばアナウンスするのを忘れていたけれども、GP2X Wiz のページを作っていた。
PSPやGP2Xでおなじみの TCGS−CAR をイニシャルタイトルとして置いてある。
ひとまず開発環境が整って、無事動かせるようになったという事ですな。
以前言っていたタイマー問題なども調べたので GP2X Wiz の雑多な情報を書いておくことにしよう。

■ タイマー問題
GP2X とか通常のシステムでは 1ms の単位で取れていたタイマーが Wiz では 10ms でしか取れない。何とかならんかと調べていたけれども、どうやら Wiz のカーネルでは clock() 関数が(数字の精度はともかく)10ms単位のカウンタで更新されているということらしい。なのでこれを見ている多くのタイマー系が全部 10ms 単位になってしまうという結果。
何で10ms じゃダメなのかというと、60fps という数字は約 16ms だから。
タイマーを使ってゲームを定速で動かすのはきついのでどうするかというと、ハードウェアレジスタにアクセスして V-Sync を取ることにした。
このへんレジスタへのアクセス方法(/dev/mem を mmap() してアドレスを直接読み書きする)は mame4all あたりのソースコードを参考にするのが良い。
mame4all は SDL とかを使用しておらず、キー入力と画面描画は直接ハードにアクセスして行っているから。(サウンドはカーネルドライバをつかっている)

■ インターレース問題
Wiz をちょいと弄るとわかるのだけれども、ELディスプレイがちょいと変わったインタレースで描かれている。この辺ディスプレイをインタレースにして半分ずつ描くというのは携帯の安いディスプレイでは珍しくはなく、PSPも3000番台になってLCDが綺麗になったら実はインタレースだということが見えるようになってしまいコームノイズがやり玉に挙げられている。
Wiz の EL も 60Hz で半分ずつ描かれているようなのだが、その Even と Odd が対角線で分かれている。つまり、画面を三角形2つに分割してその2つを交互に描いている。
これがどういうことかというと60FPSでゲームを動かすと斜めに絵がずれる。画面半分の三角形は今のフレームだが、もう半分は前のフレームが表示されているのだから。
じゃあ画面上部からの描画ラスタというタイミングはないかというとこれもちゃんとある。
なので画面swapを VBlank で行わないとラスタとインタレースの両方でフレームギャップを生じてしまうというとほほさ。
Wiz の次ロットから LCD になるという噂もあるけれども、それはこの奇妙なインタレースを改善するためなのかもしれない。

■ タッチパネル
GP2X-F200 ではタッチパネルが付いていたものの、デバイスファイルを直接読みとる方式だったと思う。
Wizではカーネルのマウスドライバとして扱われているらしく、SDLのマウスで読めるらしい。

■ ボリューム
相変わらずただのボタンで、音量はアプリが自前で音量をコントロールするソフトウェアボリューム。

■ OpenGL
lib だけ提供されて開発が GL Quake のソースしか手がかりがないという状態が長らく続いていた OpenGL だが、このへんのデベロップリーダーである Pickle 氏による開発パッケージがようやく提供開始となった。
wizGLES, nanoGL というインタフェースでアクセスするのだが、今はSDL1.3 への OpenGLES 組み込み対応が進められている。
しかし、Wiz に入っているSDLは 1.2 なのでそのあたりが将来的に提供されてもライブラリインストールをユーザーに強いることになるかもしれない。

■ カーネルソース問題
ここに来てゆるゆるといろんな開発が立ち上がっているけれども、GPH から提供されているものは何もない。SDK もなければドキュメントもカーネルソースもない。
この辺にコミュニティのいらだちが募ってきておりどうなっとんじゃという声も高くなっている。
そんななかついにカーネルソースがアップされる。おおとうとう、と思ったがどうやらこれは協力デベロッパーがGPHに業を煮やして独断でアップしたものらしい。
そんなこんなで、勝手にやるぜとコミュニティ手動でがんがん進んでいる状況なのだけれども、あまりやりすぎるとファームウェアのライブラリと剥離が進むかもしれない。

■ 良いところ
なんのかんので SDL レベルで開発はできるし、2Dのピクセルフィルレートはかなり早い部類にいるので、320×240 という画面サイズに目をつぶれば 2Dスプライトゲームが作り易いターミナルかもしれない。
フラッシュプレイヤーがあるので、Flashでカジュアルゲームを作ってねというのがGPHの思惑だったっぽいが、皆そのへんに興味はないあたり。


hatena bookmark

結局 GP2X wiz の方はまだなんにも触っていない状態。
なんでかというと、クロスコンパイル環境がまだ手元で確立していないからなんですな。
ここしばらくはずーっとクロスコンパイラのビルドに挑戦しまくっていたり、その他のライブラリ群のビルドに挑んでくじけていたりの繰り返し。まあ、Open2Xの成果を使えば良い話なんだけれども、cygwin上でのtoolchainが不完全だったり、自分で環境を作るのが色々修行になったりするのでやめられないとかそんなあたりで。

そうこうしているうちに MacOSX 向けの toolchain がリリースされてきた。ふむ、MacOSX 上で GP2x wiz の開発をするほうが手っ取り早いかもしれないなあ。
んがふと気がついてみると、手元のMacBook(白、けいおんモデルと同じ奴)に SDL が入っていない事に気がつく。昔の環境には入れていたけれども、こいつになってからはまだ一度もいれていなかったっけ?
そんなわけで SDL, SDL_image, SDL_mixer をインストールすることにしたのだけれども、周辺ライブラリもたくさんあって地味にめんどい。

ところで、最近は toolchain の提供はバイナリよりもインストールスクリプトによる方が主流っぽい。オープンソースなんでバイナリのみの配布だと波風たつのかね?
CrossTool や ct-ng なんかもこの類だねえ。これらは自動ビルドスクリプトではあるけれども、スクリプトを読むことで環境構築手順がわかる教材でもあったりする。
Open2X もそういったスクリプトを用意しているのだけれども、いまいち使い勝手が悪かったりターゲットが linux だけだったり。
うむ、自分で作るか。
どうせ、ちまちまインストールしていく途中で configure につけるスイッチをメモしたりするんだから、それをスクリプトにメモしていくと思えば同じことだろう。

で、そのスクリプトに ruby で書かれた make 代替コマンドである rake を採用する。
前々から使えるようになりたかったんだよね、rake。
shスクリプトとmakefileでなんでもできるというのは嘘じゃないけれども、いまいち自分で書こうとは思わない。どうせ書くなら楽しいコーディングしたいじゃない。
rake だと ruby そのままに make みたいな依存関係記述ができるので、今回の用途にはぴったりじゃないかと。

てなわけで今回作成したのがこちら

Download: fumi2_sdl_build-0.0.1.tar.gz (4kb, tar+gz形式)

SDL のインストールだけでなく rake に興味ある人もどぞ。
ターゲットは MacOSX/Cygwin/Linux の 3種類。一応手元で動作確認済み。
まーご利用に際しては as is ということで。


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未満で時間を計測できる手法を見つけなくては。