※題に【疑問】とは言っても、ライブラリ側に何か非がある訳では無いので、悪しからず。

このフォーラム?内で、他でも、少し、触れて居ますが、
私は、線分を足場にしたアクションゲームを鋭意制作中です…。

線分は、両端、二点のX,Y座標で管理して居ます。

特にint型以外にする必要が無いと思うので、
線分データの構造体を用意し、int型のメンバ変数として使用して居ます。

いや、使用しようとして居ます。

紆余曲折あって、実は、float型にして居ました。
しかし、前述の通り、特に意味が無いと思うので、int型に書き換えよう…と、
馬鹿みたいに書き直して居ます。

そこで、問題に成ったのが、ベクトル…、DXlibに置けるVECTOR構造体の扱いについてです。

Segment_Segment_MinLength関数 等を利用したいので…利用して居るので、
VGet関数 を使わないといけないと思います。

元は、線分データの構造体と、
float型の"世界"座標に置ける線分データのXY座標と、
float型の"画面"座標に置ける線分データのXY座標を、
それぞれ二次元配列で、適当に300と、線分の2点と言う事で2として、
VECTOR Line[300][2];
の様にして居ました。

流石に、これは、もっと一つに纏めた方が良いのではないかと思った次第です。

この様に、元は…と言うか、以前は、
線分の座標データは、VECTOR構造体の二次元配列?として管理して居ました。
付け加えれば、その前は、ただのfloat型の変数で、単にXとYで分けて管理して居ました。

その為、要するに、何が問題かと言うと、
300分、全ての線分の分だけ、
構造体のint型のメンバ変数で管理して居る線分の座標データとは別に、
VECTOR構造体の二次元配列?として、線分の座標データを管理するか否か…と言う事です。

そもそも、DXlibだけなのか、他も、そうなのかは知りませんが、
VECTOR構造体がint型だったら…と思ってしまいます。

それか、元の様に、VECTOR構造体を利用しつつ、int型を使いたい時等は、
無理矢理(int)を付けて、キャストしてしまう方が良かったのだろうか…。

---

300も用意するのはなぁ…と考えれば、
1つだけ用意し、VECTOR構造体を要求する、DXlibの関数を使いたい時だけ、
その1つに代入して利用する、と言う方法が良いんだろうか…。

---

そもそも、300と言う線分用の配列を確保するのは、
もっとこう、動的に変えられる様に、するべきなんだろうか…。

---

うーん…。

自分にとって　最も楽な形　でまずはやってみてはいかがでしょう．

考えることも必要ですが，考えすぎてそこでストップしてしまうのも困りものです．（自戒）
「　方法を定めたい　→　でも定められない　」という無限ループから抜け出すには，とりあえずやってみるしかありません．（自戒）

ある程度書き方を自分で考えられるようになるには
【クソなコードを山盛りに書いた経験があり，且つ，今ではそれがクソだと知っている】
という経験者になる必要があり，そのためにはまずはクソコードを量産せねばなりません．

知識不足でまともな準備もせずに冬山を登りに行ったり，大陸間をボードで横断しようとしたりしたら，おそらく取り返しの付かないことになるでしょうが，
有り難いことに，プログラミングであれば，ふわっとした状態でとりあえずやってみても無事に帰ってはこられると思います（※仕事でなければ※）し，
望むならば，任意の地点からリスタートすることだってできるのですし．（※仕事でなければね※）

ああ、usaoさん…。usaoさん、大好きです…。

そうですね。そうですよ!

プログラミングでもゲーム作りでも何でも、
何かを作る事と言うのは、
失敗を重ねて然るべき事ですよね!

私は、絵も描けませんが、
下手だからと言って恥ずかしがっては前に進めませんものね!

多くの痴態を晒してでも、上達してやりますよ!

仕事じゃあ無いですからね!
失敗しても、恥ずかしいところを見せても構わないですよね!
人として、恥じらいの様な大切な何かを失うかも知れませんが…!
それが、大人に成る、何かを得るって事なんですよね…!
(歳で言えば既に大人。失ったものは沢山有るのに私は…。)

私ならできる(自己暗示)。

蛇足ですが、大人と言うか、歳の事も思うと、
今時は、いや、昔からそうでしょうが、
若い時に、既に何か大きな事を成し遂げたりして居る人の存在を知ると、
会った事も無いのに、自分が小さくと言うか、駄目に思いますよね…。

趣味とは言え、もう大人なのに、今から上達したって…と思う節があります。
いや、でも、私個人としては、大人の中では新米みたいなものですし、
歳なんて関係が無いですよね!

今時、こうして、顔も知らない人を相手に感動したりするのですから、
良い作品は、作者がどうこうでは無いですよね!

うん(自己満足)。

>失敗しても、恥ずかしいところを見せても構わないですよね!

別にわざわざ見せなくてもよいのではw
密室で失敗し，隠蔽してしまえば，世間は気付きませんぜ．


>仕事じゃあ無いですからね!

そう，そのとおり．
要約すると

仕事
とても
つらい
(;_;)

ということです．現在進行形で辛いんです．うう…

返信が遅くなってしまい、すみません。
もう、ご覧になられないやも知れませんが、返信させて頂きます。

実は、返信を頂いて、直ぐに拝見して居りましたが、
色々ありまして…、言い訳ですが、頭痛や腹痛が激しくて…遅くなりました。

マップ管理ツール云々の質問の方も、やっとこさ、解決とさせて頂きました。

usaoさんには、とても感謝して居ります。ありがたやです！

そちらに、usaoさんとのやり取りを鑑みて、
個人の趣味に置いての事なので、仕事では…と、
最後に注意書きをしようかと思いましたが、止めて置きました。

お仕事、頑張って下さい…!

頑張ってと言う言葉は、無責任と言うか、上から申して居る様な感じもしますが、
素直に、受け取って頂ければ幸いですw

痴態を見せる云々については、
別に、公衆の面前で～と言う訳では無く、
少ない人の前での事ならば(インターネットなんて不特定多数が見る事ができるので同義とも言えますが…)、
そんなに気にせず、頑張ろうと言った感じですｗ

ソースなんて、趣味ならば、人の目に触れる事は、殆ど無いでしょうし、
それこそ、密室で失敗して、隠蔽する気持ちで、
頑張りますね!w

ではでは、頭痛腹痛も治まってきましたので、明日から、また頑張ります!
おやすみなさい。

>マップ管理ツール云々の質問の方

「グラフィカルなエディタ」を作るのって，本当に面倒ですよ．
…という事柄に微妙に関係するお話を．

ここの　「作品お披露目掲示板」　に私のWin32Ballsというのがあり(宣伝)，
このソフトでは基本的に線分の集合でマップ(?　というかステージの形状)が構成されています．
データとしては各頂点の座標が必要です．
Win32Ballsでは，この座標群データはハードコーディングされています．
（これは，当初はステージデータは固定的なものだ　と考えていたから．
　後になって，外部ファイルから読み込んで任意のマップを追加できるようにしようとか思いましたが，結局それを行うことはなく今日まで至る）

で，【その座標値はどうやって用意するのか】　という事柄がやはり問題になりました．
できれば「専用のステージエディタ」なんてものを作りたくはありません．激しく面倒なので．
そこで，データ生成作業の手順としては，

(1)Windowsの「ペイント」で形状を描き，BMPファイルとして出力する
(2)「線画なBMPファイルを読み込んで，画像処理で頂点座標を特定し，テキストファイルに出力するプログラム」を作り，
　　それに(1)の絵を与えて頂点群座標データを得る
(3)Win32Ballsのコードに(2)のデータを書く

ということを考えました．
最も面倒な「グラフィカルなデータエディット手段」の部分を自分で作らないで済ませる方法，というわけです．

＃結局(2)のプログラムの実用性がどうにもうまくなくて，最終的には
　「ペイント上で表示される座標値を目視して，それをWin32Ballsのコードに書き写すぜ！」という残念な作業形態になりましたがｗ

今回の横スクロールのゲームにも，同じような手段が取れるのか否かはわかりませんけど，
面倒を回避する方法が（ちょっと不格好でも）存在しないかどうかを考えてみるのも良いかもしれませんよ．

usaoさん、コメントありがたやです!

読み進める中で、
「ええっ!やっぱり、線分でマップなんて、誰でも思いつくよなあ…。」
「二番煎じだった…。素直に、それを拝見して教えて頂こう…。」
と思ったのですが、
「ペイント」で～と言うところで、何と言うか、困惑してしまいました。

usao さんが書きました:ということを考えました．
最も面倒な「グラフィカルなデータエディット手段」の部分を自分で作らないで済ませる方法，というわけです．

そ、それは、その文面だと、簡単そうに仰って居ますが、
とても面倒と言いますか、ちょっと間違えてしまった考えなのでは…と、
素直に思いました。

私が、画像から判断させるプログラムの書き方が分からないだけで、
意外と簡単な事なのかも知れませんが…。

usao さんが書きました:＃結局(2)のプログラムの実用性がどうにもうまくなくて，最終的には
　「ペイント上で表示される座標値を目視して，それをWin32Ballsのコードに書き写すぜ！」という残念な作業形態になりましたがｗ

!?
そ、それは、つまり、結局のところ、所謂、"手打ち"と言う事ですか…!?

それはそれは、お疲れ様です…。
やっぱり、usaoさんでも、誰でも、そう言った試行錯誤と言うか、
変わった失敗をしてしまうものなのですね…。失礼な物言いで、すみません。

妥協できるところは妥協と言いますか、
不格好でも、なるべく面倒を回避して、作りたいと思います。

不格好な点は、作り終えてから、修繕すれば良いですよね…w
---
ところで、私の作って居るアクションゲームは、
横にしかスクロールしない訳では無く、縦横にスクロールするものとなって居ます。

背景を、昔のゲームの様に、多重にして、
奥行きを持たせると言いますか、町や山等の風景が見える様にするつもりです…。

そうは言っても、やりたい事が見栄えの良いだけで、
私自身の技術は粗末なものなので、何か、特別な訳では無いです…。

私の中だと、線分でマップを作る際に、問題だなと感じるのは、
1.線分の情報の管理
2.線分に対しての画像の表示
3.線分とキャラクターとの判定
だと、今のところは思います。

1.は、usaoさんとお話した通りです。

2.は、私の場合は、マップチップの要領で、
等しい大きさの画像を、線分に合わせて、並べて表示して居ます。
ここは、一列とは限らず、斜めの線もありますので、色々と工夫するつもりです。

3.は、前にベクトルについての投稿をした様に、
ベクトルを用いて、判定するのが良いのかな…と考えて居ります。
ですが、元々と言うか、今のソースだと、
小難しい公式を用いて、線分と線分が交差して居るか…と言った計算をして、
判定して居ます。

例えば、重力の掛かって居る中、キャラクターを、線分の上に立たせるには、
毎フレーム?、キャラクターの現在の位置をA点、落下先をB点として、
その2点からなる線分と、その付近の、限られた大きさの範囲の中で、
交差する線分が無いかを、先述の公式を用いて探し、
交差して居たら、その線分の位置に合わせる～と言った事をして居ます。
---

また長くなってしまいました…。
近い内に、文では無く、画像や動画で、マップ管理ツール云々と言った、
アクションゲームについての日記を、投稿させて頂きますね…!

失礼しました。

>「ペイント」で～と言うところで、何と言うか、困惑してしまいました。

困惑しますかw

「紙と鉛筆でステージのデザインを考える作業」
をＰＣ上で行うとしたら，最も手っ取り早い手段の一つがペイントだと思うのです．
（線分データをあれこれ扱えるソフトを探してもいいかもしれないけど，探すこと自体が面倒．
　ペイントは最初から入っているから即使える）


>画像から判断させる

画像処理的な手段はゲームでも使えますよね．
例えば，当たり判定とかって，地形のシルエット画像(通れる箇所が黒，通れない箇所白，みたいな絵)があれば
ピクセルの色見れば有益な情報が得られるだろうし，
衝突箇所の（地面や壁の）法線とかは，5x5くらいのSobelフィルタで方向算出しても実際上は十分だよね，とか．

ペイントを使ったマップ作りは、他でも、たまに見掛けますよね…!

「画像から判断と言うか、ペイントで描いた絵?線?を元にすると言う事は、スクリーンショットの様な、情報量の多いものから、何やら難しいアルゴリズム?で判断するのだろうか…? やはり、何か縛りと言うか、自分で制限を設けたりして居るのだろうか…?」と、前のコメントをした際は思いました。

ま、まあ、それは、そのソフトを試してみないといけないですよねw
それも、近い内に試用させて頂きますね…!

その、シルエットから考えるなら、ペイントで描いた絵の色は、背景色か背景色では無いかだけで判断して、背景色では無い、描かれたものの影と言うか、シルエットとして判断し、オブジェクトと言うか、地形にすると言う事なのでしょうか…?

聞くと、簡単な話だと思いますが、それは思い付きませんでした…。
画像処理と言うと、もっと、形とか色とか、複雑に判断するものなのだろうと、難しく捉えて居ました。
これは、とても良い事を聞きました。

画像と言うか、色で判断するのは、よく使われる方法ですよね…!
画面上の特定の色を足場にしたり、
色を切り替えて～と言うのは、ゲームで、よくありますよね。

sobelフィルタと言うのは、全く知らなかったのですが、これは、見るからに便利ですね…。
要するに、輪郭を検出してくれるんですね。
これを利用すれば、全体の絵を描いて表示するだけでも、そのままゲームのマップにできますよね…。凄い…。

確かに、こう言うのを利用して居そうなゲームは、まま見掛けますよね…。
知識が多いと少ないとでは、やはり、違いますね…。
これを思い付いても、これを利用するとしないとでは大違いですものね…。

こういった、ゲームで使われる技法?アルゴリズム?を、色々と知ったり、見付ける事が、楽しいなと思います。

それを、きちんと利用して、ゲームを作らなければ…ですがw

うーん。奥が深いですね…!!