壁

適当に壁画像増やした。
各種壁と壁エフェクトを描画すればいいんだけど、
壁が
■■■
■■■
■■■
みたいに周りも同種の壁が存在する場合は、
壁エフェクトを描画してもしょうがないので、
壁エフェクトなしで描画可能なようにプログラムに修正を加えた。
画像は壁エフェクトつきの壁と、そうでない壁の2種類が入り乱れた状態。
　
　方向性が決まってないから、いまひとつ身が入らないゲーム製作。
さらっと無かったことに！

IndexBuffer(2)

　２と書いておきながら別にIndexBufferは関係ないが、
まあそれはさておき。

　宣言どおりDrawPrimitiveUpで一括レンダリングできるクラスを作成して、
実際に実行してみた。速度差はほとんど無し。
若干IndexBufferのほうが早い気がするような、別にそうでもないようなって感じ。
　IndexBufferの場合は頂点は4つでよかったが、
今回はそういうわけにはいかず、
D3DPT_TRIANGLELISTを使い、頂点6個で四角形ポリゴンを表示する。
　バッファはvectorで管理。頂点の追加もpush_backで簡単。
レンダリングしたらバッファをclearする感じ。

　とりあえずバッファ関係は大体やったかな？
バッファを使うと手軽さが激減するし、プログラムの構造も考え直す必要があるしで、
なかなか前に進めないけど、特にバグが出てるとかでもないから精神的には楽だね！

IndexBuffer

　DrawPrimitive系はあんまり呼ばないほうがいいという話なので、
VertexBufferとIndexBufferを使い、できるだけ1回でレンダリングできるように変更してみた。
仕様としては、
VertexBufferに頂点登録→最後にDrawIndexedPrimitiveで描画、
という流れ。
　テクスチャやレンダリングステートが変わる部分ではどうしようもないので、
そこを区切りにレンダリング、それからバッファをクリアして、新たに登録＆描画。
　VertexBufferで確保するメモリ量は頂点128個分、
途中で足りなくなったら、とりあえずいったんレンダリングし、
その後バッファをクリアしてから頂点を登録する動作に戻る。
　四角形ポリゴン以外レンダリングする気がないので、
インデックスはバッファを作成したついでにLockして書き込んでおき、2度と変更しない。

　で、結果なんだけど、
壁は一気に全部描画しても頂点は128以下なので1回でレンダリングできて問題なし。
壁のエフェクトも同様。
　ところが、128以上あるオブジェクトだと、バッファが埋まるたびにレンダリングするもんだから、
オブジェクトの表示がすごいチカチカする。
自分のアプリケーションでは垂直同期をまたないので、
バッファのLock、Unlockをするたびに画面になんかでちゃってるのではないかと思う。
　もう一度組みなおしてみたところ、この現象に遭遇しなくなった。
組み方が悪かったらしい。
1000回ほどのDrawPrimitiveを1回のDrawIndexedPrimitiveにすると、
確かに速度がアップした。200回ならともかく1000回ぐらいにもなると差が出るようで。

　よく理屈はわからんが、ともかくチカチカして使い物にならないので、
VertexBufferとIndexBufferを使うのをやめた。
　何も開発に進展がないけど、まあ少し詳しくなったからいいか。
　それ以前にバッファってどれくらいまで確保していいのかがわからん。
インデックスの番号は65535までふれるけど、今回は767しか使っていない。
もっと使ってもいいのかしら。
　
　あれこれしらべてたら「まじあん」の人は普通にDrawPrimitiveUpを使ってるみたいなんで、
明日はこの方向でいってみようとおもう。
（追記）問題は解決したが、物は試しにインデックスを使用しない方法も試してみよう！

デュアルディスプレイ

　家のデスクトップがゴミ同然の扱いを受けていたので、

とりあえずディスプレイだけでも利用してみた。

デュアルディスプレイ！

　画面広くなって、やめられなくなるという話。

たしかにVCを最大表示しつつも、ブラウザも最大表示できちゃうのは、

かなり使い勝手がいい。

ニコニコしながらプログラミング！

　とりあえず使ってみた感じ、マウスカーソルがどこにあるかがよくわからんくなる。

それから古いディスプレイだからかCRTだからかは知らないが、

やたらチカチカして大変目によろしくない。

　しばらくこのまま使用し続けてみようとは思うが、はたして。

　

　あと、知らなかったけどこの状態でゲームなんかをフルスクリーンにすると、

プライマリのモニタに表示されるのね。

だからどうというでもないけど、特にプログラムで対応する必要が無いのはわかった。

壁の設置

　前回同様、適当に壁を設置。配置はランダム。
下の画像のように、素で壁を置くとやたらと浮いて見えるので、
適当に加算合成で壁にエフェクトをかけた。



　CAVEがよくやる手法で、
虫姫さまふたりの1面岩や島なんかも同じようなエフェクトがかかっている。
見てのとおり、加算合成のエフェクトを設置するだけで、やたらなじむ。
なぜ発光しているのかは俺にもわからん。不思議パワーでうおっまぶしっ。

　壁画像は32*32を2倍に拡大して表示している。
64*64の画像を等倍でレンダリングすると、
参照するピクセルが増えるからか処理が重くなる。
それに、ドットが荒いほうが岩っぽくみえる不思議。
　この画像は背景同様に雲画像生成ツールで作成。
いろんなところに使い回しがきくのでたいへん重宝する。
　エフェクト部分は、ライトセーバーのエフェクトと同じ方法で作成している。
ガウスぼかしで10pxほどぼかしたものを加算合成すると、こんな感じに。

　Youtubeにライトセーバーの描き方なる動画があり、参考になった。
ほかにもMaｃのアイコンの描き方とか、
いろいろ参考になる動画が結構あるので要チェックだと思う。
　
　レンダリングにDrawPrimitiveUPを使用しているんだけど、
これをVertexBufferを使用することで、
呼び出し回数を200回ぐらいからDrawPrimitive1回になるよう修正してみたが、
特に速度は変わらなかった。
根本的な実装方法が悪いのか200回ぐらいじゃ差が出ないものなのかは不明。
　
　後からいろいろ既存のゲームを調べてみると、
壁とかが背景から浮いてても、敵や自機なんかも背景から浮くので
結果として問題ないようだ。

背景4重スクロール

http://cid-8cd7cf5ea9fbca55.skydrive.live.com/self.aspx/Public/program/test080920.zip
　いまひとつ進行速度が遅い。
適当に背景付けてみた。
800*600で4重にレンダリングしたら処理が間に合わない。

　背景に使用したグラフィックは
フラクタル雲画像生成ツール(Windows95/98/Me / 画像＆サウンド)http://www.vector.co.jp/soft/win95/art/se082007.html?site=n
を使用。512*512を出力して、800*600に拡大した。
DirectXでのラップテクスチャアドレッシングモードなんたるもののおかげでループも簡単。

　余りを出すのにをmath.hを使用せずに自力で計算してたんだけど、
最適化したら計算結果が変わってしまう症状にあった。
なのでしかたなくfmodを使用するようにした。
Releaseビルドするとなんかおかしな動作しだして、原因を突き止めるのにえらく時間がかかったわ。
Mathクラスなるラッパーを通しているので、修正は一行ですんだ。
ラッパーまじ便利。

　困ったことに２Dは表示できるけど、３Dが表示できなくなった。
いろいろいじくりすぎて元に戻せないというか、仕様変更したから正しいパラメータがわからない。
もう３Dはあきらめるか。自機とかべつに回転しなくても良いよね

　（追記）実にくだらないことに、
背景をレンダリングしたときにZバッファを塗りつぶしてるのが原因だったようだ。
1時間半ぐらい調べ回ったが、まったくの無意味！

171号

http://cid-8cd7cf5ea9fbca55.skydrive.live.com/self.aspx/Public/music/no%20name171.ogg

　171号です。
某なんとか動画で作業用BGMを適当に聞いてたときにピンときてまねしたもの。
まねしたつもりがまったく原型が残ってない。
一応ケルトだったんだけど、そんな技量はなく。

　もはや更新のねたにしか過ぎない。
反省はしている。

PackFileEditor

　以前にパックファイルを作成するモジュールとツールを作ったのだけど、
仕様が気になって新たに作り直してた。

　以前のパックファイルの使用では、

• ファイル名の長さ
• ファイル名
• ファイルサイズ
• ファイルデータ

の4つをひとまとまりのデータとして、前から順番に記録していく方法だった。

　利点は、

1. ファイルデータへのアドレスを省略できる
2. 追加が簡単。後ろに追記すればいい。

という2点。

　欠点は、読み込みのときはファイル全体をなめなければならず、効率が悪い点であった。 もうひとついえば、データへのアドレスなんて4Byte*nなんで、とくに重たいわけでもない。

　そこで、よくあるパックファイルの形式にしてみた。
まずファイル情報のデータ郡があり、それからファイルのデータが書き込まれている形式で、

• ファイル数
• ｛ファイル名の長さ、ファイル名、ファイルサイズ、ファイルデータへのアドレス｝*n
• ファイルのデータ * n

といった感じ。
　で、利点が、読み込み時はとりあえずファイル先端のほうだけ読めば良いので、読み込みは効率的。

　そんなわけで、画像を見てのとおり一通りの機能を実装したツールを作ったはいいんだけど、この形式の欠点をまったく考慮してなかった。
　というのも、ファイルのデータが設置される場所がファイル情報数に依存ため、最終的に書き込むまでファイルデータ等をまるまるメモリに保存していないといけない。効率云々の問題ではなくなったしまった。
　たかだか数MB程度の消費といえばそれまでだけど、これは許せんッ！
ってことでせっかく作ったツールもおじゃんである。
読み込みが遅いよりもメモリを食うほうが嫌だというのは、時代遅れだろうか。

　冷静に考えれば、新たに作った方式のほうがまとめて書き込みする分、数倍は高速なはず。しかしこの気持ち悪さは異常！　たえられない！

170号

http://cid-8cd7cf5ea9fbca55.skydrive.live.com/self.aspx/Public/music/no%20name170.ogg

　曲を作らざるを得ない状況から約1年たったがあまり進歩がない。
絵とか曲とかセンスがいる分野はマジ苦手だわ。
そんなんいったらプログラムもセンスいるけど、
まあ今の時代書けば動くし、コンパイラがなんとかしてくれる。

　例によって、ピストンコラージュで作成。
こんな音でも10和音。
SoundEngineFreeで加工後、oggDropXPdで変換

　ありゃ、170号ってことは二日に1曲は作ってる計算になるのか。
なんとも成長の遅い……。

マウス壊れた

またか！
明日にでも買いに