myugaruの色々構想中・・・!

「C#」「画像処理」「XNA未対応PCでゲームIDE作りの無謀な野望」

ホーム 連絡をする 同期する ( RSS 2.0 ) Login
投稿数  98  : 記事  0  : コメント  2322  : トラックバック  59

ニュース

myugaru
仕事(昔)=ヲタク系プログラマー~マスコミ系サポートデスク
仕事(今)=電子機器系サービス業
趣味a=パズルゲーム全般、シューティングは主に見学
趣味b=画像処理関係の勉強
趣味c=プログラミング言語の勉強
趣味d=アキバ系ヲタク
趣味e=芸能アイドル系ヲタク
d,e色の強いもう一つのブログ
最新目標=シューティングゲームを作る

わんくまりんく

わんくま同盟blog C#,VB.NET掲示板

ぶろぐつーる

あわせて読みたい

はてなりんぐ

書庫

日記カテゴリ

ギャラリ

お友達

リンク

●前回まで

[画像処理](x1,y1,x2,y2) vs (x,y,width,height)

[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その2

※以下PnPとPnSは私の造語です。
PnP・・・Point and Point。座標2つで矩形領域を表す方式
PnS・・・Point and Size。座標1つと領域のサイズで矩形領域を表す方式

(3/18 1:00 「長方形」という表現を「矩形」に改めました。 恣意のさんご指摘ありがとうございました。)


前回までの私の書き方もまずかったのですが、
注意深く考えるとこの話には2つの問題が隠れています。


1.PnPとPnSの違いでミスをする、という話

つまりこれが一般的なPnPとPnSの話です。
まずPnPとPnSの違いは第3第4引数が座標か大きさかという違いです。
第3引数=第1引数+大きさ横、第4引数=第2引数+大きさ縦
なのか
第3引数=大きさ横、第4引数=大きさ縦
なのか。

サイズを先に頭に思い描いた時、PnPでは足し算という手間が発生しうっかりミスをする、という問題になるかと思います。

(逆に2点を先に思い描けばPnSで引き算が発生します。同じことです。)

VS2008環境なら引数リストはヒントで表示されますので、
よっぽど慌てなければ間違うことは少ないと思います。
ということは・・・この問題は「慣れればどっちでもよい」で解決!?(汗


2.実際の図形の大きさが分からないという話

一般的なPnPとPnSの比較で考察を進めようと思ったんですが、
あまりこの2つの間に対立している技術ってなさそうですね??
なのでGDI vs GDI+の話に当面なりそうです。

そしてGDI vs GDI+の話になればPnPとPnSの違いよりも
ここで取り上げる描画ルーチンの特性の違いの話の方が問題は大きそうです。

まず最終目標を「横4ドット縦3ドットの矩形を表示する」とします。
第1第2引数が0であればPnPとPnSの違いによる足し算問題は
考慮しなくてすみますので左上は原点(0,0)としましょう。
矩形の描画はGDIに1種類、GDI+には2種類用意されています。(※1)

GDI:Rectangle(hdc, x1, y1, x2, y2)
GDI+:Graphics.DrawRectangle(pen, x, y, width, height)
GDI+:Graphics.FillRectangle(pen, x, y, width, height)

さてこれらにどういう引数を渡せば最終目標をディスプレーに実現できるでしょうか?
答えがすぐに分かる人は相当にGDI/GDI+に慣れ親しんだ方でしょう。

※1:
この種類数の違いは思想(発想)の違いにあります。
GDIに機能が少ないわけではありません。
ここではGDIのメソッドはGDI+の2つのメソッドの機能を
合わせ持っているという感じの理解でいいです。
(私はそれで困った事はないです)

 

答えは、

GDI:Rectangle(hdc, 0, 0, 4, 3)
GDI+:Graphics.DrawRectangle(pen, 0, 0, 3, 2)
GDI+:Graphics.FillRectangle(pen, 0, 0, 4, 3)

いつもの注意:
ここに書いている事柄は一度は必ず実物でご確認ください。
前エントリーに示したPnPPnSを使えば簡単に確認できます。
あるいは私のプログラムに頼らず自作するのも素敵だと思います。
確認せずに納得・推論を進める事は自己責任でお願いいたします。

さてこの結果を見ていくつか疑問が出てきませんか?

疑問1
GDIはPnPなので第3第4引数は右下座標のはず。どうして(・・・3,2)とならないのか?
疑問2
GDI+のDrawRectangleは第3第4引数は大きさのはず。どうして(・・・4,3)とならないのか?
疑問3
FillRectangleは”大きさ”という意味では(・・・4,3)で合っている。
しかしDrawRectangleと同じ数値でないのは変じゃないのか?


●疑問がでてしまうのは・・・

これは、そもそも画像処理ライブラリが「何を描画して」いるのかを理解していないために起きる疑問でした。

私は頭では色々と理解はしているつもりですよ。

でもやっぱりお手軽に画像処理を楽しみたいってのも私にはあります。

そこらへんをあえてブラックボックスとしてフィーリングで何とか理解できないかなあって思っていたりもします。


●続きは次のエントリーへ

全然進展してませんねえ。まあ今私UMLの勉強中であまり面白そうなことがおもいつかないのですよ。なのでしばらくこんなエントリーばっかりかもです(すみません)


●本日のアテにならないかも「知れない」

・GDI+はWindowなどのPnS思想にただ合わせただけかも知れない。
・GDI+はJavaの描画にただ合わせただけかも知れない。

投稿日時 : 2008年3月17日 17:22

コメント

# re: [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その3 2008/03/17 17:33 シャノン
PnPの場合、左上座標 > 右下座標になり得ますね。
PnSの場合、幅および高さが符号なし整数型であれば、この現象は起きません。

しかし、これが例外かどうかは状況によります。
例えば、マルチモニタを使用している場合、座標(0,0)はプライマリモニタの原点ですので、セカンダリモニタがプライマリモニタの左側にあると、負の座標というのが現実としてあり得ます。

# re: [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その3 2008/03/17 17:37 myugaru
To シャノンさん
コメントがお早いですね。
ちょっと文章が変だったところを直してました(汗
その問題もすごーく大事そうですね。
直線を引く場合だと2点は位置関係任意だったりしますしね。
問題をもっと細分化しなきゃいけなそうですね。


# re: [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その3 2008/03/17 17:41 シャノン
座標の指定方法対決で矩形以外も考慮に入れると、例えば線分は「始点、角度、長さ」で表す方法もあるかもしれませんね。
他の図形と違うインターフェイスを導入するメリットがあるかどうかは別の議論として。

# re: [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その3 2008/03/17 17:44 とっちゃん
GDI+ を語る上で注意したいのは、GDIの思想とは異なる部分なんですが...
一番大きいのは、NTの持つワールド座標系(もちろんベースはGDI)と、DirectX(とその前身にあたる、WinG<そこまでいくかよ!)との関係も重要ですね。

Java の影響とかもあるでしょうけど、この二つ(特にDirect2D<3Dではないのがポイント)の影響はかなり大きいです。
#それが故に、9x系で使えないわけでw

GDIのRECTは、r,b の座標を含まない座標系なんですよね。
#これ自身には何とかって名前があった気がするけど...覚えてないw
なんでそうなってるのかは歴史を知らないおいらにはわからんですが...w
きっと当時のグラフィック周りでは楽だったんでしょうね。
for( x = rc.left ; x < rc.right ; x++ ){}
と書けるしw


# re: [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その3 2008/03/17 18:18 恣意の

すでに「平面」から「長方形」に名称が変更されているうえに
第三回でいまさら突っ込むのもなんなんだけど
名称は「長方形」→「矩形」やね

# 「矩形座標」「矩形領域」の単語でググれるかどうかで
# 画像処理のアルゴリズムの取得状況が劇的に変わるはずなので
#
# つーか、シャノンさんがさりげなく使ってるやんw


# re: [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その3 2008/03/17 22:05 凪瀬
Javaの2Dはかなり3Dを意識しているように思いますね。
2Dまではドットの集合をどのように扱うかという話で完結していたように思いますが
3Dになってからより抽象的に画像を扱う必要が出てきたように思います。

線とかも、ドットの集合で考えている間はブレゼンハムアルゴリズムなんでしょうが、
3Dになると最終的なドットになるまではもっと抽象的に扱う必要が出てきてしまう、と。
Javaの2Dは2Dにしては抽象度が高いように思えます。
これは多様なOS上での動作を想定したからなのか3Dの影響を受けたのか…

そう言えば矩形(くけい、と読む)という単語を知ったのは何時だったろう。
矩形波倶楽部あたりで知ったのかもしれない。

# re: [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その3 2008/03/18 1:01 myugaru
To シャノンさん
ゲームでは角度と長さのほうが使いやすそう。

To とっちゃんさん
そうです。以上(≦)未満(<)の世界です。学校で数学の確率統計とかで分布を区切る時に以上未満で教わりますからね。よっぽどひねくれてる人以外は自然に受け入れられる考え方だと思います。

To 恣意のさん
>名称は「長方形」→「矩形」やね
わかりました。私もそれに賛成です。もちろん訂正します。

To 凪瀬さん
私も長くゲーマー生活してたので矩形波倶楽部には相当お世話になってます。
今も普通に手を伸ばせるところにCDが山に埋もれてるのが見えてます(笑

さっきはなんとなく「知れない」って書きましたが、.NETがJAVE殺しをもくろんだのは現状見てれば誰にだって想像できる話ですから、JAVAに似せましたでFAかもしれません。
#JAVAのお話は私じゃあまとめられそうに無いので凪瀬さんにパスします(を


# [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その4 2008/03/18 12:47 myugaruの色々構想中・・・!
[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その4

# 誰にも言えない!画像「ココだけの話」 2008/03/21 0:02 画像の究極エロブログ
本日は乗っています。がんがん最新情報をお届けしますよ!それでは早速いきます。目か...

# [画像処理](x1,y1,x2,y2) vs (x,y,width,height) その5 2008/03/21 15:53 myugaruの色々構想中・・・!
[画像処理](x1,y1,x2,y2) vs (x,y,width,height) その5

Post Feedback

タイトル
名前
Url:
コメント