ようは回転なんだけど。

元画像→転写先だと画素に穴が開くので、
転写先から元画像の位置を逆変換する必要がある。
なお、アフィン変換公式は
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一括処理すべき。

できた。

特定位置にカーソルが来た時にニョキっと
枠描画するUIも出来た。
javascriptで鍛えた速度処理が役に立った。
次はアフィン変換しながらのトランジションか。
検証の意味合いが強いので微妙ではあるが。
やらざるを得ない。
しかし、そろそろ遊びたいので外に出る。
こもりっきりは良くないヨネ。

フォント描画完成。
早い。解像度精度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の透明度加味した処理なら
こちらの方がかなり現実的だと目から鱗である。
こいつをクラス化するのを次の目標としよう。