フォント描画完成。
早い。解像度精度10倍でやってても早い。

背景色を加味した上での2重の透過度の扱いに
滅茶苦茶時間かかった。
白は255.255.255だが周辺色との関係でのα値と
実際に描画する際のα値を考えるとその計算式が
画面の通りである。
兎に角時間かかった。

同日　17:11
3連デバイスコンテキスト組んでクリック即表示、
文節によるストップ可能、連続透過表示可能な
文章表示プログラムできたで。

解像度精度10倍を維持するには対応サイズの
ビットマップ3つ用意すると管理しやすかったね。
メモリリークしていないかも確認済み。
GetGlyphOutlineで最小範囲算出してから
配置してるのがメンドクサイ所だなぁ。
プロポーショナルフォントとかの特性を
活かせるっちゃ活かせるが、
文字位置の調節が面倒かもしれんね。

同日　21:06
トランジション命令判定とその枠組みまで実装。
処理中に命令文が来た時には一旦現状の文字列まで
全部描画した上で、命令文と内容を処理して、
しかる後に元のスレッド処理に戻る用に組んだ。
で、肝心のトランジション処理だが、
頭の中ではできているものの面倒なので明日に回す。
手始めに、黒色度判定してみようと思う。
吉里吉里のトランジションレイヤーと同じやね。
アフィン変換とかの座標変換系と
アニメーション画像読み込みどちらが早いかも
パーティクル実装の検証としてやりたいが、
それは後で。

ImeUi.cppのImeUi_ProcessMessage読んだ。
ANSIとUNICODEでIMEの処理を変えてる。
WideCharに対する扱いでキャレット等の
位置関係が変化するので、
そこまで計算した上で値を登録して描画反映してた。

で、ここでは実際に描画する訳ではなく、
（ここで描画する場合はCallback指定と
virtualの実装が必要。）
描画部分はDXUTgui.cppにあった。
最終的にテクスチャを登録してDirectXのDRAW。
キャレットはRECTを用意して、予め取得しておいた
位置関係、点滅秒数で点滅しているように見せかける。

実に巧妙な騙し処理だった。
SendKeyMsgとかCancelCompStringの扱いが肝。

同日　12:48
http://marupeke296.com/DXG_No66_OutlineFont.html
に倣って文字列描画をwindows.hのみで作成。

ナルホド、これなら高速描画できるかも。
前作ったDirect3Dテクスチャフォントでは
速度面で不安があるという結論だったので
単純に2Dの透明度加味した処理なら
こちらの方がかなり現実的だと目から鱗である。
こいつをクラス化するのを次の目標としよう。

結局DirectX読む羽目になるというね・・・。
EditBoxの定義をDXUTから遡る事、5時間。
RegisterによるDialogの登録や、COMによる登録
まで見てしまったが、要点はアレだ。
MSDN
http://msdn.microsoft.com/ja-jp/library/bb206300(v=vs.85).aspx
が間違いなく答えだ。
WM_INPUTLANGCHANGE
WM_IME_SETCONTEXT
WM_IME_STARTCOMPOSITION
WM_IME_COMPOSITION
WM_IME_ENDCOMPOSITION
WM_IME_NOTIFY
を自分で全て制御するようにプロシージャを
通す必要がある。
この際、デフォルトのIMEレンダリングを
使わないように適宜return falseを入れて
DefWindowProcに通さない部分が出てくる。
WM_IME_NOTIFYのIMN_OPENCANDIDATEで
LPARAM=0返せばいいかと思ってたが、
そんな単純な話ではなく、正直半端無く面倒。
ImeUi.cppのImeUi_ProcessMessageが根幹か？
クラス内のvirtualでオーバーライドしてる点も
かなり勉強になった気がする。
ID3DでSetTextureとかしてるのが見えたり、
COMの根本的な原理を知ってたから判ったが
数年前の自分じゃ確かに無理だったな・・・。

画像読み込んでキーボードの矢印で動かす奴作った。

作ったらこんな時間になっているのは悲しい。
そして眠い。

同日　14:35
ドラクエ的な移動方法までは斜め移動含めて
簡単に実装できた。キーを離した瞬間に
リサイズのフラグを用意すればいい。
忘備録として、2Dマップの先読みについて残す。
各マップを管理Noで管理し、No１つにつき
数枚の画像で構成されるとする。
現在の自分の座標と、描画する枠範囲から
上下左右のずれを考えると、描画範囲は
最高4枚の画像から描画をロードする必要がある。
左上　上　右上
左　　中　　右
左下　下　右下
となるから。
すると、再描画範囲に対して、現在地点と
そのズレに対して必要な画像計9枚を保持して
移動方向に応じて読込先を指定する必要がある。
移動した先の座標で再度現在地点を判定して
必要な画像9枚を更新し、
現在地点からのズレで再描画を行う。
これで2Dマップが管理できる。
・・・ここまで来ると後のネックはフォント関連。
アレ超面倒なんだよなぁ。