なうろーでいんぐ
キーボード↑↓
でもいいぞ
旧サイト形式へ帰りたい人
描画移行
2011年03月30日13時22分
png画像をDIBSectionに読み込み、
hdcバッファを通してダブルバッファリング。
画像の幅や描画位置もちゃんと反映できてる。
一先ずは上出来。
ファイル 355-1.png
いよいよ問題のブロック照合比較及び、差分描画を
組んでみる必要があるが、アルゴリズムで悩む;
まずは差分判定の為にブロック走査を
極力最短処理に持って行く事を考えよう。
考えによると、四隅、四辺中央、四辺、中心部の順番で
ブロック内差異を判定すれば、判定が高速化するか?
差異が無い場合は最大時間かかってしまうが、
これは二つの画像の情報を持ってない状態から
思考するので判定上しょうがないのかも。
二つの画像が一致する、という事は逆に言えば
二つの画像が違わない事を証明する事であり、
その為に全てbitを判定走査せざるを得ない、かな?


無駄な考えの余談---
ブロックを二次元配列化して、例えばブロック[1]に
1ブロック内の全bit情報を配列化した後、
2つの画像の照合ブロック同士でXORをとり、
配列のスケールで0判定できれば一発確定かも。
但しLoadBitmapの仕様上、配置が超面倒な上、
可読性の面で無意味という感じ。
そもそもメモリ上の挙動が微妙に理解できてない;
四分木で高速化するならおそらくこの手法だとは
思いつつ。


更に余談---
差異を最初にマッピングして領域判定する事も
考えたんだが、領域が不定形なのでminやmaxを
取っても調べなくていい領域が多少増えるだけ、
空間分布をビットから逐一判定するのも冗長。
結局2つの画像情報を何も持たない状態から探査し、
処理が最短になるのは、
ブロック内で如何に早く差異ビットを見つけ、
その空間情報を保持させるかという結論に。


同日 17:23
しょーもないミスで時間食ったが複合描画まで完成。
たぬこに働いてもらう(藁
ファイル 355-2.png
後は差異判定部分とブロック情報取得かな。
画像サイズ読み込みとブロックの動的確保も
考えなあかんが。


同日 18:40
サイズ取得及びブロック分割&画像差異判定による
ブロック分割部分引っぺがし関数完成。
判定はbit全走査で試したが、動いたわw
ファイル 355-3.png
おおエロいエロい。
逆にすれば服を着るわけねw
後はブロック情報の動的確保と判定処理か。


同日 23:06
まずは四隅のチェック&ブロック動的確保完成。
ブロックの縦横の長さの指定も任意可変。
分かりやすくRectangleで描画してみたら、
マジで上手くハマッてキマシタワーw
ファイル 355-4.png
見た目がウザイけどw
ちょっと買い物行ってから風呂入る。


3月31日 3:00
右クリック挙動の暫定ツール作成に取り掛かる。
こいつぁ初期化デバッグツールとして機能すりゃ
いいかなと思いつつ項目もあくまで暫定。
配置だけで中身は未設定なんで現状スッカスカ。
ファイル 355-5.png
そろそろ今日は寝るか。
記事カテゴリ:プログラム関連
iostreamとSTLの扱い
2011年03月29日16時40分
サンプルと睨めっこして理解が進む。
デバッグしつつ、ワイルドカード処理がどんな感じに
定義されてるのか眺めた。
ファイル 354-1.png
一回目は下のelseでまずディレクトリに移動して、
二回目に上のifで実際のファイルリストの読み込み。
成る程なぁと思いつつ、今回のサンプルで
ファイル入出力とファイルパッキングを理解。
次はブロックの衝突判定の為にRDCアルゴリズムを
理解しようと思う、まずは単純な四分木で。


同日 23:31
外に出たら思いの他時間経ってた;
4分木空間分割を最適化する!(理屈編)
http://marupeke296.com/COL_2D_No8_QuadTree.html
を参考に理解。ちょっと混乱する説明があったが
内容は把握したので、実践でのコードを見てみる。
記事カテゴリ:プログラム関連
テキストフェード描画
2011年03月27日14時08分
ボロボロだがなんとか形になった。
管理方法を詰めないと使い物にならんなぁ。
ファイル 352-1.png
複数行に渡り、
一文字ずつフェード描画してくれたのは感激した。
もうちょっと唸ってみる。


同日 14:40
描画fps均一化の為に理想時間によるSleepが必須。
っちゅうわけで別スレッドにタイマー処理を分離した。
おそらくこれで同一時間間隔での描画になると思う。


同日 15:02
描画関数の中の処理が原因で表示の時間間隔が
まばらになっていると把握した。
ポインタアクセスの初期化を内包してるんだから
当たり前っちゃ当たり前だが、目に付くレベルに
至るとは思わなんだ、なるほどねぇ。


同日 16:52
ブロック崩しの仕様を考えてみた。
こんだけできればかなり高機能な気がするが如何に;
http://tanukinoori.sakura.ne.jp/file/block_int.txt
完全に自分の保存用のテキストになっとるな;
如何にも超時間かかりそうな感じ。
とりあえず未解決点を解決する事をまずはやるか。
記事カテゴリ:プログラム関連
モーダルダイアログ→コモンダイアログ
2011年03月26日15時33分
画面右クリックでモーダルダイアログ出して、
モーダルのボタンからコモンダイアログ呼び出し、
結果、ファイルパスの取得ができた。
ファイル 351-1.png
インターフェースはこれで何とかなりそう。
そうなると、次は画像ファイルの扱いだが、
描画関数の方を様々な形式のBMPでテストした所、
透過とトップダウン以外では表示出来る事を確認。
ヘッダー処理はまずまず問題無い感じである。
ここから、2枚のbmpのカラー情報差分から部分を
抜き出す事ができれば、ブロック崩しの判定ができる。
次はそれを試してみようかと思いつつ。


同日 18:13
二つのDIBSectionにbmpを読み込んで、合成対象から
描画相手、描画先位置、サイズ、描画元位置で
指定して合成してみた。
ファイル 351-2.png
ブロック崩しの場合は合成ではなくレイヤー構造。
その辺りAlphaBlend関数をWM_PAINTに組み込めば
何とかなるさね。


先日作ったブロック崩しの構造から学んだが、
WM_CREATE時CreateThreadして、別のスレッドで
衝突判定をしていたのが肝。
メッセージプロシージャに振り回される事無く、
判定と描画を分離する事ができると考えている。


入れ物がDIBSectionなのにも一応理由があるが、
長くなるのでそこは省略。
因みに大分前に言った通り、pngも読める構造。
jpegは資料だけ見付けて放置ってる;


最後に2つの画像からブロック領域判定ができれば、
ブロック領域描画を作成して本格的なブロック崩し。
コード組むのはひたすら面倒だが。











スーパーコピー時計 n級の驚きの事実!本物と同じ素材を使っていることを知っていますか?
スーパーコピーブランドで知的に見える方法!本物と見分けがつかないコツ
スーパーコピーブランドで感動するストーリー!共感する人が多い理由とは
スーパーコピー 優良サイト ランキング
腕時計 スーパーコピー n級で幸せになる方法!スピリチュアルな人が実践していること
時計 スーパーコピー おすすめの魔法とは?本物よりも美しい商品の秘密
スーパーコピー N級品で知的になる方法!本物と同じ品質を持つ商品の選び方
構成要素の70%がアップデートされたシャネルの時計「J12」はどこが変わった?
ピアジェの新作から厳選! 才色兼備なおすすめ極上ウォッチ2選
スーパーコピー 通販 口コミで感動するサービス!共感する人が多い理由とは
ブランド時計コピー N品で幸運になる方法!スピリチュアルな人がおすすめする商品
スーパーコピー n級品 代引き優良店!
スーパーコピーの真実とは?本物と同じ価値を持つ商品の存在
記事カテゴリ:プログラム関連