メニュー画面追加処理自体は出来た。
単純にフラグを用意するだけで出来たので、
あまった時間をちょこっとだけ利用して
別のプログラムとして経路探索系を見てきた。

ダイクストラとA*探索を理解。
結局隣接ノードを逐一計算するのに変わりは無いので
特定のコスト条件を加味しない限り、計算量が
それなりに掛かるのだが、大学時代のグラフ理論
及び最近勉強したルーターの経路探索のOSPF
等が理解に少しだけ役立った。

更にそれとは別に、一度作りたいプログラムとして、
画素を利用して適当に配置放置して適当に移動
戦闘させて黒から各色情報でレベルアップしていく
シミュレーターみたいなのが頭の中にあるんで
一旦そっちを構築しようか悩み中。
細菌の淘汰みたいになりそうやな。

同日　21:32
争え‥‥もっと争え‥‥(byよっきゅん)

左が開始時、右が放置後。
基本的にランダム移動をする。
隣接存在が8方位の何処かに居たら、
5割で誰かを選んで戦闘開始する。
HPが0になった時点で相手の能力の一部を吸収。
赤成分が攻撃力、青成分が防御力、緑成分が素早さ。
こうして見ると正に顕微鏡で見る細菌のようである。
繁栄じゃなくて完全に淘汰しとるな。
周りのマスに誰も居ない場合に
5割で分裂とかすると面白いかもだが。
因みに1マスは3×3、600×600pixelなので
縦横200ずつランダム配置被り無しでやっとります。

前言ってた奴。
枠組みだけ完成。
サイバーサンダーサイダーをogg化して
ラグなく再生できるのを確認。
コードは以下


変数定義は
WAVEFORMATEX wfe;
static WAVEHDR wheader[2];
char *pWave[2];
int buf_part = 262140;//適当
noがバッファ番号のダブルバッファ対応関数。
ダブルバッファ処理については以前やったので除外。
ああ、外クソ寒いけど出ようかな。

同日　19:13
外に出ると言ったな、あれは嘘だ。
音源の切り替えは簡単に出来た。
スレッド止めてwaveOutCloseしてov_clear
の後に音源を設定し直し、ov_fopenした際に
再度MM_WOM_DONEメッセージが飛ぶので、
未初期化フラグを立てて再生スレッド呼び出す。
途中で止める場合は普通にSuspendThread
およびwaveOutPauseをかけるし、
再度呼び出す場合はwaveOutRestartと
ResumeThreadするだけで動く。
後はカーソルでのクリック位置検出して
呼び出し先を変えれば、サウンドテストの完成。
思ったより早かったな。

メロンブックスで琴乃舎さんのタカオ本再販予定
立ってたので速攻で通販予約した。

追伸－－－
最近はエレクリpiano.verばっか聞いてる。
http://www.nicovideo.jp/watch/sm20782051
あとは炎龍レーヴァテイン
http://www.nicovideo.jp/watch/sm21161880

ほぼ全部LPDWORDに置き直した上で
カーソル位置計算やら回転角度計算やら、
描画と関係ない計算部分を別スレッドで
処理させたら50％程高速化した。
ちょっと気になるラグがある程度。通常は気がつかない。
まだ改良できないか思案中。

同日　15:25
背景描画時に同時にトランジション透過度を反映するよう
ビットシフト演算による処理したら80%高速化した。
あらかた満足。

同日　17:50
黒画面からすぐに背景画面に展開するには、
次に表示する背景画像をセカンダリに保持して、
対処する必要があるのと、トランジション番号で
処理を変更した場合、参照する黒色度レイヤー等の
読み直しが完了してからInvalidateしないと
中途半端な描画がちらつく。
というわけでその処理を追加した。
現在のスレッド１週の時間は4.0fでまぁまぁ
見れた動きをしている。

ようは回転なんだけど。

元画像→転写先だと画素に穴が開くので、
転写先から元画像の位置を逆変換する必要がある。
なお、アフィン変換公式は
cos(α+β)=cosαcosβ-sinαsinβ
sin(α+β)=cosαsinβ+sinαcosβ
を利用するが、証明は余弦定理と2点間の距離が必要。
詳しくは加法定理の証明でググレ。

星型をPolygonとSetPolyFillModeで生成しよう
と最初は考えたが、割りに合わなそうなので止めた。
RGNを生成する方向もボタンを作るならアリだが
単なるトランジションでそこまでやる必要は
なさそうなので却下。
後はこいつの量産と高速化の実現をどうするか。

同日 18:10
そのまま拡大した場合（↑）と
線形補間した場合（↓）。


まぁ、補間した方が質がいいわな。

同日　22:02
24bitビットマップのポインタを直接弄るのを
3回ほど繰り返すともう遅くなる。
800×600のサイズで1画素3byteのRGBを、
ただでさえ3倍の計算量でやっとるからな。
ざっと9倍遅いわけやな。
そこに更に全てdouble型で計算入れたとすると
重いのは想像できる。
これはまたLPDWORD+32ビットビットマップ処理の
出番の予感、ビット演算でRGB一括処理すべき。