2Dのシンプルなパズルゲームなんだけどねぇ。なんかiアプリより手間がかかってるよ。
１）.NETのGraphicsクラスやImageクラスをベタに使う
速度はそこそこ、画像を描画する際に透過色指定もできて、確かに実装はラクなんだけど。画像をストレッチ（拡大縮小）するとご丁寧に補間処理してくれるので、悲しいほど美しくゲロ重い。そして補間処理を無効にする手段は見つからないのだった。
WILLCOM 03やAdvanced W-ZERO3[es]は補間されず速度も全く問題なかったんだけど、HYBRID W-ZERO3とX01Tではダメな事が発覚。ん〜、補間してくれるほうが「上等」な端末なんでしょうなぁ。今回はありがた迷惑だけど。
２）DDBを使ってBitBlt()やStretchBlt()する
試しにAPIを直接呼び出してGDIで実装してみたんだけど、期待以上に遅い。古典的な実装をしているので、描画回数が最大２倍になる*1のも良くないのか。しかし、画像のスキンを使うようなアプリが軒並みモッサリな事を考えると、これはWMの仕様なのかもしれない。なんかWinGが出る前のWindows3.1でゲームを作ってる気分（苦笑
３）とりあえずDDBからDIB（CreateDIBSection()）に変更してみる。
４）折角なのでDirecrDrawを使ってみる。
５）将来性を考えてDirect3Dを使ってみる。
６）iPhone用のOpenGLのコードを移植してみる。
の４択で迷い中。いまここ。いつ完成すんだろ。端末によってはDirectDrawよりGDIのほうが速いらしいけど、そもそも「GDIのほうが速い」って意見は罠だったりしないだろーか。そいつはアセンブラでDIBに直描画してるのかもしれないし（笑）。５）や６）が本望なのだが、時間的な問題もあるし、今回は機種依存するような実装は避けたいなー。
とりあえず、CreateDIBSectionに変更してみて、それでもGDI関数の描画では追いつかないようなら、Cで描画処理を書いてみるか。VC++のARMコンパイラはインラインアセンブラをサポートしてないらしいので、途中で間違いを犯さずに済みそうだ。もうコマンドラインアセンブラを使うほど若くないもんね。良かった良かった（何がだ＞俺）
*1:解る人に解る書き方をすると、マスク画像をSRCANDして色成分を含む画像をSRCPAINTしてる訳です。
