時乃工房-Windowsとアマグラマーな関係-

アクセスアップにオートリンクネット リンクが自動で増殖オートリンクの登録はこちら 節約内職情報検索局
ページランク向上リンク集
役立つリンク集 Web Links
SEO対策ディレクトリ型検索エンジン Su-Jine
メニュー
トップ
アマグラミング
C++編 目次
第15章
第17章
ソフトウェア開発製品
相互リンク

<勘違いだらけのアマグラミングな日々(C++編)>

第16章 伸びる豆腐(4)

2006年11月15日

Windows Vista RC1と付き合いを始めて、はや半月。
Aeroもおかげさまで快適に使えているわけだが、いろいろと不満もちらほら見え初めてくる。
Windows2000との付き合いがそもそも倦怠期(?)に差し掛かってきていたのも事実なのだが、今度の見合い相手は「見てくれ」こそ素晴らしく、起動を始めたところから、なにやら自機の性能がアップしたかの様な錯覚すら与えてくれる。
OSとしてのレスポンスも、ある条件下でなければ、個人的には特に気になることも無い。
では何が不満なのか?と仲人(いや、私を人柱にして様子を見ている友人どものことだが)の方々が口を揃えて尋ねてくる。
なにが、と問われれば、そう、一言で云わせていただければ、「神経質でおせっかい焼き」なところがちょっと・・・うっとうしい。
セキュリティに気を配らなければならない現代情報社会。
これも時代の流れなのかもしれないが・・・。
私はデュアルブートが嫌いなので、HDDを差し替えて使い分けているが、古女房(Windows2000)の元に帰るたびに、やっぱりお前しか俺を判ってくれるOSはいないよ、と愚痴をこぼしてしまう。
むー、せめて縁談(導入)がまとまる前にお互いを深く理解できる期間を与えてもらえたことが、唯一の救いなのかもしれない。
それに、いつかは乗り換えねばならない時期が来ることも、また事実なのだから。

あーさて、この記事はVistaRC1のページではないので、そろそろ話を戻していかねばならない。

前章で、関数BildClientArea()であることは判明した。
また、怪しい実験を決行した結果、関数BildClientArea()は、座標計算と白四角描画処理に対して50分の1の実行回数でも充分実用的なことが判った。
つまり全画面書換え処理は、適当な時間を置いて実行してやればよいことになる。
そこで、次の様な改良を施してやることにした。

List.002-014
main_window.h
main_window.cpp
main_callback.h
main_callback.cpp
main_process.h
main_process.cpp
graphics_control.h
graphics_control.cpp
bitmap.rc
main_menu.h
main_menu.cpp
main_menu.rc
<ソースのダウンロード>

”graphics_control.cpp”をみていただけば一目瞭然だと思うが、関数BildClientArea()スレッド分けしてやることにしたのだ。
スレッド起動は、関数SetupGraphics()内で行っている。
新しいスレッド関数BildClientArea()は、関数Sleep()によって、描画後、16ミリ秒の待機時間をもって繰り返される無限ループとして処理されている。
当然アプリケーション起動中は永遠に繰り返されることから、”main_process.cpp”内のスレッド関数MainTransaction()内で呼び出す必要がなくなるので、呼び出し処理を削除してある。

さぁ、実行して感想を述べよう。
クライアント領域をぺちぺち左クリックすると、なるほど、いびつな白い線がぱしぱし描画されていく。
しかし、幾つか描画したところである異常に気がついた。
線が描画されずに白四角がぽつっと描き出されるタイミングが存在するのだ。

実はこれ、デバイスコンテキストへのアクセスに伴う排他処理が正常に行われていない為に起こる現象なのだが、まぁ、大人の事情で(?)暫く放置しておくことにする。

あと、関数MainTransaction()の末尾に1ミリ秒の待機時間を取るよう関数Sleep()を置いて、これをコメントアウトしておいた。
これを有効にすることでどのような動作をもたらすかは予想の範疇だと思うが、その結果CPUの使用率はグッと減少する。
リアルタイム系のゲームと呼ばれるものは、確かに処理スピードの速さを要求されるが、実行マシンの性能にゲームのテンポが影響を受けるようでは真のリアルタイムとは呼べない。
そこんところを考慮すると、この待機時間の処理が肝となりそうだ。

さて、多少の問題を残したままだが、とりあえず「A描画処理の呼び出し方法」の問題はここまででいったん解決としよう。
・・・そうです。
書いてるほうも忘れかけていたことですが、ことの発端は第13章最後尾での問題定義にあったのです。
と云うわけで、残る「@白四角の描画位置算出」を考察してみましょう。

まず次の2枚の実行結果画面を、改めて比較しなおしてみることにした。

左が目標とする実行状態で、右がここまで作ってきたものの実行状態である。
云うまでも無くこの違いを生み出している原因は、関数MainTransaction()内のif文にある。
現状の計算方法だと、横座標も縦座標も単純に比較して増減しているため、両方異なっている場合には斜めに、縦座標が先に目標値に達した時点で横座標のみ移動し、同様に横座標が先に目標値に達した時点で縦座標のみが目標値に近づいていく。
結果、斜め45度(?)の移動と、縦、または横方向の8方向に限定された動きをとりつつ、目標となる座標を目指しているわけだ。

・・・まぁ、文章で書いても上手く伝わりそうも無いが。
それはともかく、では、真に要求される移動先座標はどのように求めればよいのだろう?
乏しい数学の知識を持ってこれを考察したなら、2点間の傾きを求めて移動先の座標を求めてやる方法が、まず思いつく。
y=ax+bなんて表現されるアレである。
ああ、そう云えば本稿でもプロローグで紹介したっけ!?
えーと、傾きを変数aとして、始点を・・・

なんて考えるのは、実はまったくもって無駄である。
なぜなら、こんな時の為に(?)先人が考案してくれたアルゴリズムが存在するからだ。
私がこれを知ったのは、大学生をやらせていただいていた頃のことだから、もう十年以上前のことである。
当時、某大学で機械について学んでいる振りをしていた私は、あるプログラミングの専門書を読んでこのアルゴリズムと出会った。
これを読んだ私は、もう、ブレゼンハム先生サイコー、と感激したものだ。
そう、聞いたことある方も少なくないであろう、「ブレゼンハムのアルゴリズム」、これである。

と云うわけで、次章はこの便利なアルゴリズムを使わせていただき、問題の解決に当たっていくことにしよう。

<前章> <目次>





<時乃工房>
Net Office Nakai
メビウスリング投稿掲示板には小説日記ゲームアニメコミック小学生中学生などの掲示板過去ログがあります。相互リンクも募集中。