近況？
最近ぴろさんの日記が更新されまくりじゃないですか。気づいてなかった……。標準のlibcを入れ換えずに、soft-float環境にchrootするってのは考え付きませんでした。mplayerも動いてるみたいだし、すばらし〜。
snes9xのほうはまだ動いてませんが、ぼちぼちと。C-ABIにはgcc-2と3で互換性があることに注目して、snes9xのコア部分はgcc-3でコンパイルしてライブラリにし、それをGUI部からリンクするようにしてます(1週間前くらいに思いついた)。libqtcを使うことも考えましたが、あれをそのまま使ってGUIを作るのは辛すぎる……。
VBAもいつか着手予定。ARMエミュレータの実装が汎用C/x86/ppc版しか無いんですが、ここにARM版を追加すればそれなりに速くなりそう。ARMエミュレータをARMで実装するわけだから、基本的にインラインアセンブラで単純に命令を埋め込んでいくだけで簡単なはず。でも、グラフィックエミュレーションが負荷の大部分を占めていそうだから、実用的な速度になるかはわからん。
mplayerフロントエンドも進めないと……。やりたいことが多すぎて大変です。
mplayerのrotateフィルタは凄く遅いです。リファレンス実装なんじゃないかと思うぐらい最適化されていないコードのうえに(まぁPCでは使わないフィルタですから)、バッファが一段増えてます。個人的にはpre-rotate推奨なんですが、どうもpre-rotateしない使い方が多数のようなので、vo(w100やpxafb)側でrotateするようにしようと思ってます。
やっぱり液晶自体が480x640で作られているんですね。液晶側で640x480に出来ないかと思いましたが、それも無理なようで……。640x480ならとても楽な手段でかなりの高速化が出来るんだけどなぁ(ソフトの内部バッファからフレームバッファへのコピーを無くして、内部バッファ自体をフレームバッファにできる)。ソフトの内部処理自体をローテートに対応させるという最終手段を講じればそれと同じくらい速くなりますが、いかんせん仕事コストが……。そのコストを支払ってまで高速化する価値のあるソフトって個人的には無いしなぁ。うむむ。
VBAの高速化パッチを書かれている方がいますね。MMXが使われている部分はおいておくとしても、地道に演算数を減らす作業がされていて、かなりいい感じ。VBAに手を付けるときには取り込ませていただくとします。
