ちょっと関西地方へ遊びに行ってきました。京都なんて生まれて始めていきましたよ。貸し自転車を借りてブラブラしたり。
ちょっと関西地方へ遊びに行ってきました。京都なんて生まれて始めていきましたよ。貸し自転車を借りてブラブラしたり。
最初聞いたときにはそれほどでもなかったのだけど、何度も聞いているうちに洗脳されて、つい最近CDを入手して今聞いているところ。個人的には、挿入歌>=OP>ED、かなと。
今期の歌はどれも無理。好きになれそうにない。
今はAndroid上でエイジオブコンクエストをプレイしてます。適度に単純化されていて気軽にプレイできるのがうれしい。結構いろいろなプラットフォームで出ているみたい(www.ageofconquest.com/)。
とりあえず、やろうと思った些細なことはやり切りますかね。やり切っても別にどうと言うこともないかもしれないけど。
最近Pobsをプレイしています。六角マス盤上の陣取りゲーム。
できるのは自分の駒を隣接マスへ複製する(増やす)か二つ先へ(一つ飛ばしで)ジャンプするかの二つだけ。もし移動先(または複製先)の隣に敵の駒があれば、その駒はこちらの色に変わります。このような操作を一手ずつ交互に行っていき、最後に駒が多い方が勝ち。
基本は一手でできるだけ多くの駒を取れるような操作をすること。相手の駒で埋まっているところに一つだけ穴が開いている場合、そこへ飛び込めれば最大六つの駒を自分の色にできます。
ただ、そのような「穴」に飛び込む場合、隣接複製では入れないので一つ飛ばしのジャンプを使うことになるのですが、そうすると当然駒が元々いた場所には穴ができてしまいます。着手後、もし敵がその穴に移動できる場合、こちらは(奪った六つの内)最低 三つ 二つの駒を失う可能性ができるわけです。
だから常に出入りで考える必要があります。自分がこう動かしたらN個取れるけど相手にM個とられる手が生じてしまうからN-M個の価値。自分がこう動かしたら一個も取れないけど相手がM個取る手を防げるからM個の価値。というような。
このような感覚は囲碁にとても近いと思いますが、囲碁よりも一手の選択肢が少ないので考えやすくなっています。
trampのsshやscpの接続って他のOSでもこんなに遅いのかなぁ。ftpだとそんなに遅くないんだけど。
結局未だに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へ手動で入れ直したり。
ジュエルペットてぃんくる☆のDVDってこんなに安いんだ！？ 知らなかった。1～2話くらいは割と良かった記憶があるからポチっておくか。……といういい加減な買い方が出来るくらいの値段。
今期一番はやはり「屍鬼」かなと思う。
最近ピクセルシェーダをいじっているのですが、GPU方面はどうにも分からないことが多くて困っています。
ピクセルシェーダからレンダーターゲットのピクセルを参照したくなるのですが、そういうことってやっても良いのでしょうか。試しにD3DUSAGE_RENDERTARGETなテクスチャを作ってレンダーターゲットとサンプラーの両方にセットしてピクセルシェーダから読み書きしてみたのですが、手元のGeForceでは一応ちゃんと動いているみたいです。ただ、読み込む位置を間違えると書き換え後の値を参照したり・しなかったり不定になります。ピクセルの処理順はGPUの都合で決まっているのでしょうからこれは当然でしょう。ピクセルシェーダにおいて結果が書き込まれるだろう位置から読み込む場合は常に問題なく書き換え前の値を読み込めました。描画対象範囲外であるピクセルを読み込む場合も問題ありませんでした。
問題はこのような処理をするコードに移植性があるのかということです。上のように動作しない環境があるのならば、描画範囲矩形を算出して、その部分をいったん作業用テクスチャへコピーするような実装が必要になります。……望み薄いんだろうなぁ。