Monthly Archives: 9月 2010

2010-09-22

Pobs(Android上のゲーム)

最近Pobsをプレイしています。六角マス盤上の陣取りゲーム。

できるのは自分の駒を隣接マスへ複製する(増やす)か二つ先へ(一つ飛ばしで)ジャンプするかの二つだけ。もし移動先(または複製先)の隣に敵の駒があれば、その駒はこちらの色に変わります。このような操作を一手ずつ交互に行っていき、最後に駒が多い方が勝ち。

基本は一手でできるだけ多くの駒を取れるような操作をすること。相手の駒で埋まっているところに一つだけ穴が開いている場合、そこへ飛び込めれば最大六つの駒を自分の色にできます。

ただ、そのような「穴」に飛び込む場合、隣接複製では入れないので一つ飛ばしのジャンプを使うことになるのですが、そうすると当然駒が元々いた場所には穴ができてしまいます。着手後、もし敵がその穴に移動できる場合、こちらは(奪った六つの内)最低 三つ 二つの駒を失う可能性ができるわけです。

だから常に出入りで考える必要があります。自分がこう動かしたらN個取れるけど相手にM個とられる手が生じてしまうからN-M個の価値。自分がこう動かしたら一個も取れないけど相手がM個取る手を防げるからM個の価値。というような。

このような感覚は囲碁にとても近いと思いますが、囲碁よりも一手の選択肢が少ないので考えやすくなっています。

2010-09-21

Emacsの環境整備

結局未だにMeadow3のままでEmacs23.2に移行していませんが、移行しやすくするために環境を整備しました。

.emacsの類は ~/emacs/config/ に置き、従来site-lispに置いていたものは ~/emacs/lisp/ へ置くようにし、~/emacsをgitで共有するようにしました。.elcはMeadow3とNTEmacs23.2の間で互換性があるのか分からなかったので共有せず、チェックアウト先個別で(byte-recompile-directory "~/emacs/lisp/" 0)するようにしました。

.emacs-meadow.elの設定の内、プラットフォームに依存していないものはできるだけ.emacs-common.elへ移したり。apelやflim、semi、wlはMeadow3のインストーラで入れていたのですが、それも~/emacs/lispへ手動で入れ直したり。

2010-09-16

ピクセルシェーダからレンダーターゲットを参照する(Direct3D9)

最近ピクセルシェーダをいじっているのですが、GPU方面はどうにも分からないことが多くて困っています。

ピクセルシェーダからレンダーターゲットのピクセルを参照したくなるのですが、そういうことってやっても良いのでしょうか。試しにD3DUSAGE_RENDERTARGETなテクスチャを作ってレンダーターゲットとサンプラーの両方にセットしてピクセルシェーダから読み書きしてみたのですが、手元のGeForceでは一応ちゃんと動いているみたいです。ただ、読み込む位置を間違えると書き換え後の値を参照したり・しなかったり不定になります。ピクセルの処理順はGPUの都合で決まっているのでしょうからこれは当然でしょう。ピクセルシェーダにおいて結果が書き込まれるだろう位置から読み込む場合は常に問題なく書き換え前の値を読み込めました。描画対象範囲外であるピクセルを読み込む場合も問題ありませんでした。

問題はこのような処理をするコードに移植性があるのかということです。上のように動作しない環境があるのならば、描画範囲矩形を算出して、その部分をいったん作業用テクスチャへコピーするような実装が必要になります。……望み薄いんだろうなぁ。

2010-09-15

冷たい風

朝、外の空気が冷たいのに気がつく。緩やかな風が肌をすり抜けると冷気がとても心地よい。

もう九月も半ば。あと少しで十月。

このまま寒くなると布団や衣類が心配だなぁ、と憂鬱になる。

風邪などをひかないように注意。

2010-09-14

乗算済みアルファ

画像の合成処理において、乗算済みアルファ(premultiplied alpha)はとても有用な考え方です。単純な例では Fa*Fc+(1-Fa)*Bc が Fm+(1-Fa)*Bc で計算でき、乗算が一つ減ります(FはForegroundのF、BはBackgroundのB、aはAlpha、cはColor、mはMultiplied colorの意)。しかしこの式の場合は乗算済みアルファを使わなくても Bc+(Fc-Bc)*Fa と変形できるので、それほどメリットにはならないかもしれません。有用なのは共にアルファ(不透明度)を含む二つのピクセル同士を合成または補間するような場合です。このようなときの合成処理は不透明度付きピクセルのブレンドモード付き合成方法に書きましたが、不透明度を含むピクセル同士を合成してストレートアルファで結果を得ようとすると、どうしても最後に不透明度でカラー値を割る必要が出てきます。ピクセルごとに除算を行うのは処理速度上大変不利なので、できれば回避したいところです。乗算済みアルファでの合成結果は「カラー値×不透明度」が得られればよいので、最後に不透明度で割る必要がありません。また、不透明度を含めた双線形補間サンプリングにおいても乗算済みアルファは同様に力を発揮します。

このように色々とメリットのある乗算済みアルファですが、残念ながら私は普段使っていません。理由は二つ。一つはただでさえテンプレートで組み合わせ爆発気味の既存の合成処理ライブラリにもう一つピクセルフォーマットを追加してメンテナンスしきる自信がないこと。もう一つはピクセルごとに除算してもぎりぎり許容範囲内の速度が出てしまう昨今のPC事情。つまり、労多くして功少なしな感じがして、とてもやる気が起きないといったところでしょうか。

しかし時々猛烈に乗算済みアルファが使いたくなるときがあるのです。う゛ー。