PlaySoundは簡単だが、速度面で不十分だった。
衝突時に別スレッドを立てて再生してみたんだが。
音の再生で固まる、そんな事よりボール移動スレの
理想FPSなSleep入れろよという突っ込みは無しで。
oggの方はpngのライブラリと一部のifdefによる
関数定義が競合しまくってるので後回し。
oggの使い方自体は理解が進んできた。
DirectSoundを利用すべきかなぁ。


余談－－－
先日のDIBSection問題は解決できてないものの、
DIBSectionを一々作成せずにメモリにおいてある
情報から別に用意したDIBに直接描き込む方法で
無理矢理解決する方法が上手く行った。
要約すると、GetBitsで取ってきたビット列を
マスクとシフト演算でもって各RGB色相に強制挿入。
描画時は結果をStretchDIBitsなり何なり。
実は置き換える場所が最小で済むので一番高速
とは思うんだが、しかし上記別枠で解決策は模索中。
気になるんじゃ、要はhbitmapを再利用できれば…
後、mciとかネットワーク通信とかちょこっと触る。
先はまだまだ長そうね。


同日　16:36
WAVEデータの作成と再生
http://www13.plala.or.jp/kymats/study/MULTIMEDIA/waveOut_create.html
いい参考ページ発見。
波形描画も後編に載ってるので、こいつで勉強。

ちょっと話が逸れるが、先程の話。
DirectSoundの利点なんだが、メモリに保持して
高速再生できる点に尽きるのかしら。
COMインターフェースで取得してダブルバッファ
で再生できるのも勿論イイ機能だとは思うんだが。


同日　23:52
wave把握。
① WAVEFORMATEX用意後、
waveOutOpenでハンドル入手。
② LPBYTEなりshort*なりで波形を生成。
③ WAVEHDRを用意して、waveOutPrepareHeader
関数にハンドルとヘッダを引数に取り準備。
④ waveOutWriteで実際に再生。

終了時はwaveOutResetでハンドルを初期位置に戻し
waveOutUnprepareHeaderでヘッダを解放して
waveOutCloseでハンドルを閉じる、と。


4月3日　1:50
っちゅうわけで波形描画まで進めた。

矩形波をlpWaveに入れて左クリックで再生。
ファイルからの読み込みも読んだ。
CreateFileからパス指定したファイル全体を
Readして、ファイルのヘッダ情報から順番に取得。
肝心のデータは、準備関数に必要となるWAVEHDR
つまりWAVEヘッダのlpDataに読み込ませて、
同様の処理を行えばいいだけ。
これでお手軽ぅにメモリから音再生できるわけね。

解析必死;
久々だわ・・・足を取られるの。


原因発覚。
DIBを上手く使いこなさないとアカン。

まぁ、Sleep無しで回転させてたら容量なんて
すぐにナクナルヨネ、という点と、DIBSectionの仕様。
いくらhbitmap解放しても消えない謎。
これは本当に聖域なのかもしれんね。
にしても、hnumが1407になるまで回せるのはイミフ。

Ｌｅｓｓｏｎ　１．超高速描画の謎【前編】
http://www.sun-inet.or.jp/~yaneurao/intensive/diw1.html
やねうらお先生の文章にもちょいとかかってくる。
ちくしょうめ。

入力反映するとデバッグツールっぽくなるｗ

右クリックでのモーダルダイアログから、
ブロックサイズを入力して反映ボタンを押すと
プロシージャが押したボタンに沿って動作。
反映はブロック情報を開放し、再取得してから、
親のhWndにInvalidate送って強制WM_PAINT。
ゼロ処理行ってないのは手抜き（藁
この調子で他もぼちぼちと進めていこう。
次に問題になりそうなのはブロック破壊時の
消去処理関連かな、フェードを実装したい所。
ついでに、この状態でちゃんとブロック崩しが
機能するかもテストしておこう。
13:00か・・・外に出なあかんな。


同日　23:32
反射で手こずった、形にはなったのでよし。

改めて不透明度の採用を考えよう


4月1日　0:18
アルファブレンドの確認でとりあえず単純描画。
引数にアルファ値を取れる関数を用意したので、
これを動的にフェードさせるには、別スレッドで
フェードアウト回しつつ、描画を続けるのが最適
と思っているが如何に。



同日　3:05
スレッドを別々にすると描画同期上逆に問題が出たｗ
結局解決策は、構造体に現在のアルファ値と
消去描画が終了したかのフラグを追加して管理する
事で実現、これが上手く行った。
勉強になったからヨシとする。

綺麗にフェード致しました。

次はoggとかの音関連かなぁ。
BGMも衝突音も無いと寂しいし。

png画像をDIBSectionに読み込み、
hdcバッファを通してダブルバッファリング。
画像の幅や描画位置もちゃんと反映できてる。
一先ずは上出来。

いよいよ問題のブロック照合比較及び、差分描画を
組んでみる必要があるが、アルゴリズムで悩む;
まずは差分判定の為にブロック走査を
極力最短処理に持って行く事を考えよう。
考えによると、四隅、四辺中央、四辺、中心部の順番で
ブロック内差異を判定すれば、判定が高速化するか？
差異が無い場合は最大時間かかってしまうが、
これは二つの画像の情報を持ってない状態から
思考するので判定上しょうがないのかも。
二つの画像が一致する、という事は逆に言えば
二つの画像が違わない事を証明する事であり、
その為に全てbitを判定走査せざるを得ない、かな？


無駄な考えの余談－－－
ブロックを二次元配列化して、例えばブロック[1]に
１ブロック内の全bit情報を配列化した後、
２つの画像の照合ブロック同士でXORをとり、
配列のスケールで0判定できれば一発確定かも。
但しLoadBitmapの仕様上、配置が超面倒な上、
可読性の面で無意味という感じ。
そもそもメモリ上の挙動が微妙に理解できてない;
四分木で高速化するならおそらくこの手法だとは
思いつつ。


更に余談－－－
差異を最初にマッピングして領域判定する事も
考えたんだが、領域が不定形なのでminやmaxを
取っても調べなくていい領域が多少増えるだけ、
空間分布をビットから逐一判定するのも冗長。
結局２つの画像情報を何も持たない状態から探査し、
処理が最短になるのは、
ブロック内で如何に早く差異ビットを見つけ、
その空間情報を保持させるかという結論に。


同日　17:23
しょーもないミスで時間食ったが複合描画まで完成。
たぬこに働いてもらう（藁

後は差異判定部分とブロック情報取得かな。
画像サイズ読み込みとブロックの動的確保も
考えなあかんが。


同日　18:40
サイズ取得及びブロック分割&画像差異判定による
ブロック分割部分引っぺがし関数完成。
判定はbit全走査で試したが、動いたわｗ

おおエロいエロい。
逆にすれば服を着るわけねｗ
後はブロック情報の動的確保と判定処理か。


同日　23:06
まずは四隅のチェック&ブロック動的確保完成。
ブロックの縦横の長さの指定も任意可変。
分かりやすくRectangleで描画してみたら、
マジで上手くハマッてキマシタワーw

見た目がウザイけどｗ
ちょっと買い物行ってから風呂入る。


3月31日　3:00
右クリック挙動の暫定ツール作成に取り掛かる。
こいつぁ初期化デバッグツールとして機能すりゃ
いいかなと思いつつ項目もあくまで暫定。
配置だけで中身は未設定なんで現状スッカスカ。

そろそろ今日は寝るか。