結局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マップが管理できる。
・・・ここまで来ると後のネックはフォント関連。
アレ超面倒なんだよなぁ。

cgi側からskinに対してjavaアプレットを吐き出す。
この際にurl_saveをデータ受け取り用のcgiに指定。
受け取りcgi側はSTDIN(画面標準入力)からデータを
受け取って解析して画像やアニメーションを保存。
この一連の流れの解析に午前を費やした。

クラスが多くなると、製作者以外が全体を見回す際に
それが密に結びついていればいるほど面倒臭い。
同じ関数が別の場所にも存在したら、本当に同じか
一度確認するその手間がはっきり言って勿体ない。
オブジェクト指向で自分が嫌いなのはそこで、
カプセル化によって内部隠蔽されると、解読する側は
そこに紐付く全てを無から学習しなければならない。
まぁ、作る側からすると管理しやすいし、
プログラムに隠蔽は付き物なので、こうしてぼやくのも
面倒くさいという単なる愚痴なわけだが。
さて・・・外出るか。

同日　20:42
久々にWindowsアプリケーション読み直した。
oggのpcm音源waveformatex再生方法が判った。
早い話が.oggでサウンドテストが作れる。
イベントドリブンの管理が超面倒だから
やる時間が出来たらやろうと思う。
本当に久々にC++した気がする。

こうすると如何にもな感じ。
opacityかけても大丈夫っぽい。
となると後はbackground-image時のclip位置ぐらい？
http://tanukinoori.sakura.ne.jp/test/test12.html
文章隠蔽してあるけど流石にpostをCSRFすると読める。
そこは引き渡す値の暗号化にかかっとる。

同日　16:40
ぼちぼち色塗る。


同日　19:39
追記


同日　21:51
更に追記