OSXでdevkitARM（を触る前に）
OSXでdevkitARMを使ってみた。
言わずとしれたGBAの開発環境。
GBAでどれくらいSTLが動くんだろう？
というのが発端。
コンパイル自体はフツーにコンパイルできてROMファイルもできたので、
あまり困らなさそうな印象。
馴染みがない人を振り切った書き方になる予感。
GBAはARM7 16.78Mhzなのでそれなりに早い。
問題はサウンドを実行するための専用のプロセッサがないので、
良質なサウンドを鳴らそうとするとCPUパワーを食われるため、
どうしても劣化させなければならない点。
（市販ソフトの音が割れたりモノラルなのは大抵これのせい）
RAMはCPU内部RAM（高速）が32KBで、
CPU外部RAM（低速）が256KBと、
結構貧弱で、
きちんと使いこなそうとするとリンカスクリプトでちゃんとマップしないとだけど、
普通に使う分には問題なさそうなサイズ。
問題は動作確認のエミュレータのデバッグ性能が、
Windows版最高なので、これがないときついかも。
リアルタイムにBGのキャラクタ*1やスクリーン*2、
パレット*3の状態を見られるのはかなり大きいのです。
で、画像はとりあえずprintfをつくって動かしてみたところ。
hoge[%d]でただひたすら書いてるだけー。
もちろん、ASCIIフォントだけBG0のキャラクタ領域に転送して、あとはスクリーンで指し示すだけの代物。
諸処をSTLのlistで書いてみたんだけど、
あんがい動くなぁ、という印象。
実機じゃないので、パフォーマンスに関しては微妙かもですが。
（実機だとVBlank前のパレットの０に色を埋め込むとラインバッファの描画中に色が変わってくれて、
負荷が見やすいです。BG消さないと見えないけど。）
諸処のサイトを見ると、リソースを全部cppとかにしてリンクさせているのだけど、
普通にバイナリにして指定番地にバインドする方が良いとおもふ。
リソースのリンクに時間がかかるようになるのと、
マスクROMでもないので、ダイレクトに埋め込んで良しの筈。
Cで書くと面倒だけどPythonで書くと楽です。
PILとかで読み込めばGIFでもBMPでも簡単にバイナリに！
hoge++;
printfDebugConsole("hoge[%d]?n",hoge);
putsDebugConsole("python?n");
putsDebugConsole("php?nruby?nperl?nc++");
表示部はとかしてるだけです。
