ハンドル欲しいMobile系、Direct3DやShaderなどについて書いています。00:14前回迷路を作成するシェーダーを作りました。今度は自分で探索させてみました。迷路を作り、その後色のついたピクセルが勝手に歩き回ります。キャプチャだけだと良くわからないので、これも実際に走らせてぜひ動いているところをご覧ください。動いているところだったら、何をやっているのか一目瞭然だと思います。初期データが入ってます。拡大しないとわからないですが暇な時にじっくり見るのにお勧めです。基本的にすべての探索点は同じアルゴリズムで動いています。どれも右側の壁伝いに歩いてすべての通路を歩きつくそうとします。お互いにも衝突するので、狭い路地から出られなくなったりショートカットして違う分岐に進んだりと結構ランダムに散らばってくれるようです。壁伝いに動くため、壁を見失うとその場でくるくる回ってしまいます。誰かが助けに来てくれるまでそのままです。点から生み出されます。四角形を1つ描いているだけになっています。迷路のデータを元画像としてレンダリングすると次のシーンが出来上がるわけです。内部的なピクセルの意味は次の通り。探索点の色フレームバッファに転送する際に内部ワーク状態を消すようにしたので、ちらつきも無く見やすくなっています。その代わり判定している様子など内部状態は見えなくなりました。使っている乱数は1つだけ。探索点の生成と探索点自身の色決定です。移動時の判定順は次の通り。右も前も埋まっているなら左に向きを変える(未確定)単なる画像処理なので探索点はいくつでも構わないし、何千個あっても、数万個あっても処理速度はほぼ一定です。動的分岐とリソースアクセス遅延によるばらつきが出る可能性がありますが、ほぼ完全に面積だけで速度が決定します。複数同時に動く可能性があるので、衝突判定はかなり厳密です。1つ前のシーンだけなので、同じ空白を複数のピクセルが同時に移動可能と判断してしまう可能性があるからです。3フレームも費やしています。迷路生成よりも判定が長いのは、確定判定が追加されたからです。違い足跡を正確に消す必要があります。右を向いた瞬間もと来た場所が空きになるので、さらに右手に回れると判断してしまう(戻ってしまう)ことも防いでいます。これらの判定のおかげでピクセルが同時にいっぺんに移動しても問題なく処理可能となりました。すり抜けも起こらないでしょう。同じものですが、乱数計算に偏りのバグがあったので一部修正しました。ダウンロードはこちらです。・wheelhandle_ss04t.zipソースだけでなく実行ファイルも入っています。