ああああああああ、ああああああああああああああ、あああああああ。

あああああああ！あああああああ、ああああああ。

あああああああああああああああああああああああああああああああああああ

あああ、ああああ。ああああああ、ああああああああ？あああああああああ。あああああああ、あ、あ、あ、あああああああああああああああああああああ！！

ああああああ、あああああああ

あああ、ぁぁああああぁぁぁ、あぁぁぁぁああ。あああ、ぁぁぁああああああああ。

あああ、ああああ。↓あああ、あああ！ああ、ああ！！

ああああああああああ。ああああああああああ

Kirikiri based games update screen slowly

僕も日常的にWineを使っている立場ではあるし、ちょっとした動作確認ではWine上で吉里吉里を動かしてはいるけど、まだこれ僕の方でもどういう状況でトロくなるのかわかってないんだよねー

トロくなる状況は確認してますが、タイミングや条件が不明。トランジションはするする動くときもあるけど、トランジション終了直後の画面更新が、描画が目で追えるほどにトロかったりする。

Pandora

うーむ、手軽に開発ができる…かなぁ。

Pandoraにも搭載されている?TIのOMAP3によるデモシーン

OpenGL ES 2.0 とな！

メモリ128MBはちときついっす。X起動してからの仮想端末でのfreeの実行に何秒かかってんのよwあれ、でもX起動してもSwap used が 0 だなあ。

平気で200MBぐらいコンパイラが使うからなぁ。あーこれで512MBぐらい積んでてくれればもっといいのだが……。

ソフトウェアレンダリングでもQuake IIが60fpsでてるとか。搭載されている3Dハードウェア使わずに。

Engadget 日本版の記事

値段は手頃なので欲しい。ううむ。

Ubuntu Hardy (2.6.24) では SoundBlaster X-fi がうまく使えなかったので、Roland UA-5 を接続して USB オーディオでサウンドを再生しているんですが……。

しかしサウンドの初めや、再生している途中に「ブツッ」といった感じでサウンドが途切れるというか、ノイズがはいってしまいます。

うーん、どこをいじれば改善するのやら……。plusaudio や Rythmbox の優先度をいじっても改善しないとなるとカーネルモジュール内のどこかかな。USBオーディオへの同期転送が時々追いつけないとかそういう奴でしょうかね。

http://d.hatena.ne.jp/unagi127g/20080811

あーと、なんでTJS2がレジスタマシンかというと、最初はネイティブコードへのJITterをつける予定だったので、あー、こっちの方がJITterの実装が楽そう、と思ってのことだったと思います。結局JITterはつけずにバイトコードインタプリタを積んだだけでしたが。なので元々あれはネイティブコードを吐く前の「中間形式」でした。ソースコード名に「Intermediate」という単語が混じってるのがあるのはそれの名残りです。

ちなみに他にレジスタマシンなのはParrot VMとか。LLVMは中間形式(SSA形式ですが)を実行するバイトコードインタプリタがレジスタマシンですね。

TJS2のVMのモデルとしては、ローカル変数も、計算中の一時変数もすべてレジスタとして扱うモデルです。すべてがレジスタに置かれるため、スタックや主記憶領域のようなものはありません。

こういうモデルでのレジスタマシンのメリットは、比較的命令コード数が少なくなるということでしょうか。

たとえばローカル変数同士の計算で a = b*c + d*e; とあった場合、レジスタマシンスタックマシンでは

load b
load c
mul
load d
load e
mul
add
storep a

みたいな感じの命令列になると思うのですが、TJS2だと基本的に2アドレス命令形式なので

cp  tmp1, b     // tmp1=b
mul tmp1, c     // tmp1*=c
cp  tmp2, d     // tmp2=d
mul tmp2, e     // tmp2*=e
add tmp1, tmp2  // tmp1+=tmp2
cp  a,    tmp1  // a=tmp1

みたいになります (TJS2はコンパイラはおバカなのであんまり命令コード数減ってないですけど)。実際のバイトコードインタプリタの実効効率がこれで上がるかどうかは実のところ比較したことがないのでわかりません。オペランドの分だけ命令に必要なバイト数が長くなってメモリアクセスが増えるしメモリアクセスの局所性もおそらく減るから、もしかしたら結局はトントンじゃないのーみたいな気はしてます。

Risseもレジスタマシンですが、この場合は内部でSSA形式で簡単な最適化を行ってます。SSA形式はそもそもそれがレジスタマシンに近い表現なので、それをそのままVM命令にしちゃったのが今のRisseのVMという感じになります。

Risseは今のところ3アドレス命令形式なので、上記のような計算だったら、

mul tmp, b, c  // tmp = b*c
mul b, d, e    // b = d*e
add c, tmp, b  // c = tmp+b

みたいな命令が出力されます (最終的な答えは c に入る; b と c に対応するレジスタは以降参照されていないことが分かっているので再利用されている)。

RisseはまだVMの最適化には手をつけていないし、そもそも今のRisseのVMは仮の実装なので、これから先どのような構成になるのかは後で考えたいと思います。最近JavaScriptインタプリタ方面で実行速度戦争がおきてるようなので適当にテクニックを盗みつつ……。

ちょっとまえにPNG画像を減色する必要があって適当な減色ソフトを探していたのですが、pngnqというソフトが目に止まりました。

減色には、よく使われているメディアン・カット法ではなくて、ニューラルネットワークを利用した方法でパレットを決めるんだとか。元となっているアルゴリズムのページ NeuQuant: Fast High-Quality Image Quantizationのテストイメージをみると確かにいいかんじ。

このpngnq、先日よく見るとアルファチャンネルつきインデックスカラーにちゃんと対応してるんですね、これ。こっちのメリットは大きいかも。

トキワ荘からの日記移植。

Blenderには流体シミュレーションがついています。

この流体シミュレーションは格子ボルツマン法(Lattice Boltzmann Method; LBM) といって、セルオートマトンの一種です。

http://graphics.ethz.ch/~thuereyn/ntoken3/ ここの方が開発したものらしいです。

LBMは空間を格子に区切って演算を行うのでメモリを食いますが、液体の量が増えても演算速度が(あまり)落ちないというメリットがあります。32bit windows版だとあんまり大きな空間のシミュレーションはできなかったのですが、最近環境をガラリと全部Linux 64bitにしたんで、メモリたくさん食っても大丈夫な演算ができるようになりましたー。

一方、もう一つの主要な流体シミュレーション法であるパーティクル法では、液体をパーティクルの集まりとして近似してパーティクル同士のモーメントだとか衝突だとかを計算するもので、液体の量に応じて演算負荷がかかります。こちらは物理演算アクセラレータなどで高速な演算ができるようにしたものなどがあるようです。

どっちがいいかは用途によるんだろうなぁ。とりあえずBlenderではLBMだということです。

で、お遊び。

http://kikyou.info/misc/miku.avi

どろどろどろどろどろどろ……

モデルデータはまささんからお借りしました。ご快諾ありがとうございます！