昨日は急遽先輩の家で鍋をしてしまいました…。

TCP/IPの基礎の基礎から勉強中。
先日はメールを簡易的に送信するプログラムだったが、
本格的にwinsockを勉強となると資料が膨大な範囲
なのでゆっくりと読み進めてます。

一方先日のストリーミング再生は、こちらを参考に
その３ Oggファイルでストリーム再生
http://marupeke296.com/OGG_No3_Stream.html
これまた読解中。
マルチバッファ自体は、2つの波形データとヘッダを
用意するだけで実現できたが、スレッド動作で
任意にバッファを切り替えつつ読み込みをさせるとなるともうちょっと詳しくやらねばならぬ。
それも後半に載ってるので後は理解だけ。

ストリーム再生において、CreateFileの戻り値が
HANDLE型（VOID*)という事は、
無理矢理すればReadするメモリの場所を移動可能か？
バッファサイズ分だけメモリに保持して残りを
引き出さなきゃならんと考えているが、ファイルから
引き出すオーバーヘッドがどうも気になって調べた。
取得位置を保持していれば読み込みの最適化に
利用できないかなぁと思うものの、
パスからCreateしてるし微妙なヨカンはしつつ。
…もうちょっと考えてみるとしよう。


同日　19:36
WAVEOUTハンドルを２つ用意して、
別個のデータとヘッダをそれぞれ登録し、
スレッドで同時に再生してみた所、
Sleepは必要だったが、同時に再生した。
DirectSoundではこれはミキシングされて結果を
出す方法もあるらしい。何にせよ、直に二つの音が
同時に出る事を確認できた。
あとの問題は必要分の動的管理だけ・・・。
先程の件は、DirectSoundのセカンダリバッファに
ついて調査する事で進行中。
分かったのは、やはりCreateFileもDirectSoundの
セカンダリバッファもこれから再生すべきファイルの
先頭場所をキューで格納して軽量化してるという点。
つまりCreateFile自体はファイルオープン同様
これから開くべきアドレスをハンドラとして渡し、
用が済んだら速やかにcloseする必要があるだけで
バッファからの読み込み位置だけを注視すれば
ダブルバッファリングの実装自体は難しく無さそう。
複数同時再生も先程試したので、効果音のバッファと
BGMのダブルバッファを別管理すれば、
特に音に関して困る要素は無くなった予感。
実装して結果を見ないと後は何とも言えないが。

ブロックを破壊した時にアイテムオブジェクトを
生成するのは、さほど難しくないとぼんやり考えた。
バーを長くしたり、ボールの速度を上げたり、
定石は用意してもいいかもしれん、
それまたフラグで出現管理できたらいいだろうし。
（最初から要らないと言われる人も居るだろうが;）
面白い挙動と言えばなんだろう、ボールの動き関連
マウストラックロールとか、爆発とか色々あるけど。

それはそうと、次の勉強。ネットワーク関連に
進もうと思う。ブロック崩しとは無縁に思うが、
だからこそ発見できる何かがあるやもしれん。
あと個人的に勉強したい事山盛りなので。
とりあえずそんな感じでまずはソケットでの
サーバークライアント通信からC++でやってみるか。


同日　14:18
コンソールでメール送信起動。

サイト右上にもあるhi-hoのサーバーを使用。
パスワードは念の為権限の無い物で一度試してみる。
名前はBASE64で上手く通った。
画面は失敗しているが、おそらくpassが通れば
必然的に通りそう。
ある程度は理解しているが、解読が大変そうである;

もっとも、メーラーやブラウザの起動は
ShellExecute関数で簡略化はできそうだが;

急遽BGMでやり忘れてた事を思い出したｗｗｗ
ストリーミング再生してねぇｗ
効果音ならメモリに置いて再生でもいざ知らず、
まさかメモリにBGM全置きするわけにはいかん;
慌てて調べなおすのであったorz

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
やねうらお先生の文章にもちょいとかかってくる。
ちくしょうめ。