プログラマ専用SNS ミクプラ

ご無沙汰しておりますm(_ _)m

以前投稿させて頂いた仰角のある攻撃範囲表示に関しては、一応それっぽい範囲を表示出来る様にはなりました。（所々怪しいのでもう少し精度を高めたいとは思っていますが。）

しかし攻撃範囲を表示させるボタンを押してから、表示するまでに若干のタイムラグが発生しました。（長い時で0，5秒ほど）

気になるほどではなかったのでスルーしておりましたが、今回移動＋攻撃範囲を表示するにあたりまして、上記のタイムラグが積もり積もって5秒ほど停止する自体に陥りました。
（因みに仰角がない（周囲一マスが攻撃範囲）キャラで↑の移動＋攻撃範囲を表示させた所全く処理落ちなしでした）

※移動＋攻撃範囲について・・・移動可能な範囲内のマス全てにおいて攻撃可能範囲を索敵し表示します。
　　　　　　　　　　　　　　　　　　　　移動可能外周マスだけ調べれば良いかなぁとも思っていたのですが、
　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　味方
　　　　　　　　　　　　　　　　　味方　敵　　　　　　自分
　　　　　　　　　　　　　　　　　　　　味方

　　　　　　　　　　　　　　　　　　　　の様な状態の場合、敵を狙えない可能性が出てくるため、移動可能範囲全マスで調べる必要性がありそうで　　　　　　　　　　　　　　　　　　　　　　　す。

そこで遠距離の攻撃範囲を索敵する関数内で一つづつ時間を計ってみたところ

・外周マスまで直線を引いた後、１ピクセル単位で座標を代入していき、その座標から得られたマップ値によって障害物判定などを行う

関数が原因でした。


一巡自体はすぐ終わるのですが、攻撃手から外周マスまでの座標差分処理を繰り返すため、結構な周回を行っております。

しかし障害物の判定に必要不可欠な処理ですので、いやはやどうしたものかなぁ・・と思い質問致しましたm(_ _)m

答えに窮する質問だとは重々承知しておりますが、何かアドバイスを頂ければ幸いで御座いますorz

例えばマップが３２ピクセル単位であれば、始点と終点は別にしてxかyが32で割り切れるポイントだけを調べれば良い気がします。

http://iup.2ch-library.com/i/i0656090-1339047815.png
上の青から赤へ直線を引いている場合の図
横３２　縦６４です

現在障害物判定をマス内に円柱の辺り判定を置き、それと接触したら障害物と認定しているのですが、ソフト屋さんの方法でも障害物判定には影響出ない様な気がします。

ただ色々な状況を考えてないので、取り敢えず実際にその方法でためしてみようと思います。

コレジャナイ さんが書きました:http://iup.2ch-library.com/i/i0656090-1339047815.png
上の青から赤へ直線を引いている場合の図
横３２　縦６４です

現在障害物判定をマス内に円柱の辺り判定を置き、それと接触したら障害物と認定しているのですが、ソフト屋さんの方法でも障害物判定には影響出ない様な気がします。

ただ色々な状況を考えてないので、取り敢えず実際にその方法でためしてみようと思います。

それは表示上の見た目の問題ですので内部的には整列した正方形ブロックとして処理できると思うですが。って前に書いたかな。
表示上の処理と内部的な処理は分けて考えたほうが楽になる場合があります。

コレジャナイ さんが書きました:・外周マスまで直線を引いた後、１ピクセル単位で座標を代入していき、その座標から得られたマップ値によって障害物判定などを行う

それだと同じマスを何回も調べることになりますよね。

ひとマスずつ直線と交差してるかどうか調べるようにしたら全マス調べてもお釣りが来るのではないですか？

縦３２　横６４の間違いでした

>>ソフト屋さん
恐らく一番最初の配列へのマップ値代入や描画関数のせいで、描画と内部で同じ座標値のマップを使用してしまっております。
今からここをいじるのは少々厳しいです・・・orz

>>ISLeさん
一度調べたマスは処理を飛ばしています
(※但し障害物はマスの中心から円状に当たり判定があるため、障害物とぶつかっているかどうかの判定のみ、同じマスでも調べています）

多少開き直ってピクセルではなく16x8ぐらいのでサイズ調べてもさほど絵に違和感は無いと思いますが？
これなら最大１６倍ぐらい早くなります。

>>ソフト屋さん
やはりどうしても狙えてはいけない地点が狙えるようになってしまいます・・・。
一度１ピクセル毎に探索しているプログラムと１６×８で探索しているプログラムをお送り致しますので、ご覧頂けないでしょうか？
ただ今からバイトのため、帰宅が０時頃になります。
そのため送るのが０時回ってしまうため、ご覧頂くのは明日以降お暇な時で構いません。

コレジャナイ さんが書きました:>>ソフト屋さん
やはりどうしても狙えてはいけない地点が狙えるようになってしまいます・・・。
一度１ピクセル毎に探索しているプログラムと１６×８で探索しているプログラムをお送り致しますので、ご覧頂けないでしょうか？
ただ今からバイトのため、帰宅が０時頃になります。
そのため送るのが０時回ってしまうため、ご覧頂くのは明日以降お暇な時で構いません。

すぐに見れるかどうかはわかりませんがＯＫですよ。

ただいま送信致しました。
宜しくお願い致します。

受け取りましたが起動時の射程が１の様です。裏技があるなら教えてください。

あ、えっと召喚は試して頂けました？
矢印がさしているキャラを左クリックするとメニュー出ます。
そこで遠距離のキャラを召喚してみてください。
お手数ですが宜しくお願いします。

コレジャナイ さんが書きました:(※但し障害物はマスの中心から円状に当たり判定があるため、障害物とぶつかっているかどうかの判定のみ、同じマスでも調べています）

何か別の理由があるのかもしれませんが、マスの中心から直線までの距離を求めればひとマスにつき一回の計算で済むのでは？

>>ISLeさん
あ～なるほど！
マスの中心から直線に対して垂線を引いて、交点の座標位置のみ計算すれば良さそうですね！

ちょっとそれで実装試してみます。
有難う御座います！

一応試して成功確認後解決をつけさせて頂きますm(_ _)m

駄目でした。

この方法ですと１ピクセル単位でｘの値を変えていった時、そのｘ、ｙピクセル座標がどのマス内に存在しているか調べる関数を毎回呼び出さなくてはいけなくなりました。
（→マスの中心座標を求めるために、マスのX,Yマップ座標が必要。マスの構造体にマス中心座標とｘ、ｙなどのマップ座標を収納しているため）

どうも解決に至らない・・・orz||

とりあえず問題点が分かりませんでした。
ソースコードもないので再現方法、問題となるポイント(画像つきが望ましい)など細かい情報が無い事には何も調べられないです。
あと処理落ちは全く発生しないと言うことだけは報告しておきます。

返信が遅れてしまって申し訳御座いません。
出先で確認はしていたのですが、携帯からは返信出来ず・・・orz

手順を詳しくメールにてお送り致しましたので、ご確認頂ければと思います。

攻撃範囲表示の際に処理落ちがしないというのはかなり驚きでした。
PCスペックの差でしょうか・・・orz


ソースコードにつきましては、もう本当正直に申しますと見て頂いて一緒に改善していきたいというのが本音で御座います。

しかしあまりに粗末で見難く汚いソースコードであり、かつ既に1万行を越え
恐らく第三者の方が追跡をするのはかなり大変であり、ご負担を掛けてしまうと思われます。



何かご不明な点があれば、出来る限り返答致しますので、どうか宜しくお願い致しますm(_ _)m

コレジャナイ さんが書きました:返信が遅れてしまって申し訳御座いません。
出先で確認はしていたのですが、携帯からは返信出来ず・・・orz

手順を詳しくメールにてお送り致しましたので、ご確認頂ければと思います。

攻撃範囲表示の際に処理落ちがしないというのはかなり驚きでした。
PCスペックの差でしょうか・・・orz


ソースコードにつきましては、もう本当正直に申しますと見て頂いて一緒に改善していきたいというのが本音で御座います。

しかしあまりに粗末で見難く汚いソースコードであり、かつ既に1万行を越え
恐らく第三者の方が追跡をするのはかなり大変であり、ご負担を掛けてしまうと思われます。



何かご不明な点があれば、出来る限り返答致しますので、どうか宜しくお願い致しますm(_ _)m

これといった処理落ちらしきものは今のとこ見ていません。メニューが消えるとか変な動作は沢山ありますが。
実はバグでメモリ破壊しながら動いているんじゃないかと疑いたくなります。

この時点で一万行だとすると相当リファクタリングしないと破綻が迫っていると思います。
すでに不審な動作が幾つか見受けられますが最終的にバグが取れないプログラムになるんじゃないかと。

コレジャナイ さんが書きました:この方法ですと１ピクセル単位でｘの値を変えていった時、そのｘ、ｙピクセル座標がどのマス内に存在しているか調べる関数を毎回呼び出さなくてはいけなくなりました。
（→マスの中心座標を求めるために、マスのX,Yマップ座標が必要。マスの構造体にマス中心座標とｘ、ｙなどのマップ座標を収納しているため）

繰り返しになりますが、なぜ1ピクセルずつ追う必要があるのでしょう？

届くかどうかの判定をする対象のマスをひとつずつ処理
→起点のマスと上記のマスを結んだ線分と重なるマスを列挙
→→重なるマスを超えられるかどうか仰角軌道計算をひとつマスずつ処理
というふうに繰り返すので良くないですか？
列挙ついでに距離でソートすれば効率良くなる気もしますし。

マスのデータ構造が、たった1回マップを作るのに効率が良いだけで、何回も参照するのに効率の悪い構造になっているように見えます。

>>ソフト屋さん

バグらしいバグはなるべく消していたつもりだっただけに・・・残念です。。

メモリ破壊しながら動いているというのは尋常ならざるバグかと思われますが、確認方法と対処方法は御座います・・？
迅速に修正しないと不味い気が・・・。

おっしゃる通りで、前回言われた時もリファクタリングを行い、かなりすっきりしたのですが、いつの間にか元に戻ってしまっておりました・・・。

再現性につきましてはメモか画像を用意致しますので少々お待ち下さい。。

>>ISLeさん

起点のマスと上記のマスを結んだ線分と重なるマスを列挙


この方法に関しまして、自分は１ピクセル毎に計算という方法しか持ち合わせておりませんでした。
（線分上の座標点を求め、それがどのマス内にいるかを調べる関数に送るという非効率的な作業です）

ISLeさんのおっしゃる通り、これをスムーズに求める事が出来れば、後は垂線の方法によりスムーズに求める事が出来そうです。

線分と重なるマスを列挙する方法に関しまして、どのように求めれば良いでしょうか・・・？

コレジャナイ さんが書きました:>>ソフト屋さん

バグらしいバグはなるべく消していたつもりだっただけに・・・残念です。。

メモリ破壊しながら動いているというのは尋常ならざるバグかと思われますが、確認方法と対処方法は御座います・・？
迅速に修正しないと不味い気が・・・。

おっしゃる通りで、前回言われた時もリファクタリングを行い、かなりすっきりしたのですが、いつの間にか元に戻ってしまっておりました・・・。

再現性につきましてはメモか画像を用意致しますので少々お待ち下さい。。

破壊されているとは確定したわけじゃなく単なるバグかも知れません。
メニューとか消えたりしてますが・・・。ハンドル情報の破壊の可能性はあります。

コレジャナイ さんが書きました: メモリ破壊しながら動いているというのは尋常ならざるバグかと思われますが、確認方法と対処方法は御座います・・？
迅速に修正しないと不味い気が・・・。。

Ｃ/Ｃ++なら家庭用ゲームでもよく有るバグです。
確認方法はデバッガで破壊されている部分を見つけ出すこと。大半は長年の勘が物を言います。
こいつらは、最終版やリリース版でよく出る質の悪いやつです。

現状では「移動＋攻撃範囲表示」を行ってキャンセルすると高い確率で「移動＋攻撃範囲表示」メニューの画像が消えてなくなります。

今確認致しました。
すみません、お渡しする前に確認しておくべきでした・・・・。

確かに酷い惨状でした。
デバッグモード起動時は全く問題が無いのですが、リリースした際に何かしらエラーが発生して壊れてしまったということなのでしょうか？

今まで幾度となく友人にリリースした実行ファイルを渡してきましたが、このような風になったのは初めてで、何をどうしたら良いのやら・・・。

コレジャナイ さんが書きました:今確認致しました。
すみません、お渡しする前に確認しておくべきでした・・・・。

確かに酷い惨状でした。
デバッグモード起動時は全く問題が無いのですが、リリースした際に何かしらエラーが発生して壊れてしまったということなのでしょうか？

今まで幾度となく友人にリリースした実行ファイルを渡してきましたが、このような風になったのは初めてで、何をどうしたら良いのやら・・・。

まぁ、このバグを追いかけるだけでも相当苦労かも知れません。
リリース時しか出ないのであればデバッガで追いかけるのも困難だからです。

可能性のある原因は、
(1)配列の添字外のアクセス
(2)ポインタ値の誤計算や無理矢理のキャスト、引数の受け渡し間違いないなど。
などが主ですが、それ以外もあるかも知れません。
少なくとも再現性はあるので、メニュー周りを色々調べるしか無いでしょう。
特定の条件で壊れるのであれば、その操作で通る処理ルートをシラミ潰しに調べます。

こっちに書いている方法が基本であり王道です。
「簡単RPG講座　番外編。　デバッグ入門 • C言語交流フォーラム　～ mixC++ ～」
http://dixq.net/forum/blog.php?u=114&b=982&c=2

了解です。

このサブメニューを実装してから初めて起こった現象ですのでサブメニュー関連の関数をあらってみます。

取り敢えず続きの話はこのバグを片付けてからという事で宜しくお願い致しますorz

もう一つバグ報告。
それぞれのチームで別キャラを召喚すると攻撃動作などで召喚キャラのアニメーションが入れ替わることがある。
画像ハンドルの管理が怪しい。

[補足]
その他に気なること。
・これもバグなのか未完成なのか分かんないですがタイトルのメニュー選択で、どれかをクリックすると下の字と重なり読めない現象が起きます。stroy modeとfree battleで確認。
・マップ画面でONにしてステータス表示するとキャラの週に表示される矢印がメニューの上に表示される。
・スクロールを放置すると画面外にぶっ飛んで戻すのが大変。
バグ。
・移動アニメ時に突然空中を動くことがあるが最終目的地はちゃんと着く。再現条件不明。　→　もしかしたら障害物を避けたとき？

>>ソフト屋さん
有難う御座いますm(_ _)m

すみません、わざわざ調べてもらったのにこちらから事前に言うべき事ばかりで・・・orz

攻撃モーションに関して
恐らくクロスボウ兵、マスター辺りが攻撃モーションを行うと別のキャラになります。
これは攻撃モーションを描くのが面倒で放置しているだけの怠慢です。
ので、すみませんがスルーしちゃってください。

タイトルについて
一応最初のメールにて申し上げてます通り、ちょっとタイトル作りたかっただけなので描画の順番がぐちゃぐちゃになってます。
怠慢その２です。
でもこれはすぐにでも直せます。


・マップ画面でONにしてステータス表示するとキャラの週に表示される矢印がメニューの上に表示される。
なんと！？
これに関しては初耳でした。
同じ事をやってみても起こらないのですが、あれですよね。黄色い下矢印がメニューの上に移動してしまうという事ですよね？
何か特定の動作をすると発生するのでしょうか・・・。


・スクロールを放置すると画面外にぶっ飛んで戻すのが大変。
これに関しては元から一応限界スクロール範囲を決めてあります。
ただステージ２の作成にあたり、マップの広さの上限が拡大したためにスクロール限界範囲を拡大してしまいました。
その結果ステージ１にはふさわしくない限界範囲となっております。

限界範囲はdefineしてありますので、ステージによって変更していこうと思っております。


・移動アニメ時に突然空中を動くことがあるが最終目的地はちゃんと着く。再現条件不明。　→　もしかしたら障害物を避けたとき？
すみません・・・これもお伝えしておくべきでした。
このゲーム空と地上の二階層なのですが、特定のキャラは空と地上の間を行き来する事が出来ます。
（ハーピーを使って空と地上の間を移動してみるとわかり易いと思います）

マスターキャラは空と地上を行き来させるアニメーションを例によって作っていないために、瞬間移動して空へと移動してしまっております。

条件としては同高度の移動ではたどり着けない場合（道中に障害物があるなど）Z軸高度を移動して目的地にたどり着く際に発生します。

空と地上の移動は、移動範囲表示中に右上にある空や地上ボタンを押すことで高度が切り替わりますので、それで移動する事が出来ます。

一応右メニューのキャラ情報内に空地上移動可能や移動不可などの文字が書いてあるかと思います。

コレジャナイ さんが書きました:・マップ画面でONにしてステータス表示するとキャラの週に表示される矢印がメニューの上に表示される。
なんと！？
これに関しては初耳でした。
同じ事をやってみても起こらないのですが、あれですよね。黄色い下矢印がメニューの上に移動してしまうという事ですよね？
何か特定の動作をすると発生するのでしょうか・・・。

黄色い矢印じゃなくてキャラクタの進行方向に出る白い矢印です。
あとは未完成なんですね。了解です。

コレジャナイ さんが書きました:線分と重なるマスを列挙する方法に関しまして、どのように求めれば良いでしょうか・・・？

線分と重なるマスというのは、マスの中を線分が通過しているマスということですからマスの輪郭(のいずれかの線分)と交わっているかどうかを調べていけば列挙できます。

始点と終点のマス以外の通過マスという事なら対角線と交わっているかどうかでも良いと思います。

輪郭なら一度に2マス求めることも可能ですが、そういうマップ構造になっていないようなので、対角線のほうが計算が少なくて済むのではないでしょうか。

>>ソフト屋さん
あ、なるほど！　有難う御座います。
メニュー表示より後に矢印を描画していた事が問題でした。

修正しました、有難う御座いますm(_ _)m


しかし、移動＋範囲表示での消滅の原因が分かりません・・・。
症状を見ていたのですが、マップ配列に保存してある値には変化はなく（マウスを消えたマスにあてがってみても、普通にマウスポインターが表示されるため）、完全に画像を収納してるGHハンドルの値がおかしくなってますよね。

移動＋範囲表示の際に描画ファイルには何ら影響を与えていないので（移動＋攻撃範囲が押されたら、移動範囲表示や攻撃範囲表示と同じ状態にしているだけです）、画像ハンドルの値がおかしくなるという現象が理解出来ないです・・・。

処理が重くなりすぎると画像ハンドルの値がおかしくなったりという事って起こりえるものでしょうか？

コレジャナイ さんが書きました:処理が重くなりすぎると画像ハンドルの値がおかしくなったりという事って起こりえるものでしょうか？

ありません。配列範囲外やポインタ操作ミスが９９％と言って良いでしょう。
一度リリースビルドでハンドル変数の値に変化がないかデバッガでデータブレークポイントで追跡して見ることをおすすめします。
※　条件により出来ない場合もあります。
http://msdn.microsoft.com/ja-jp/library ... 80%29.aspx

あるいは、画像ハンドル値を何処か別の変数に保存しておいで処理から戻る度に値の変化がないかチェックすればどの処理後に異常になるか突き止めらるはずです。

[補足]
上の方にISLeさんの返答があったので見逃さないでくださいね。

今ISLeさんへの返信をしたと思ったらサーバーエラーが発生したらしく全文消えてしまいました・・・orz|||
かなり長文だったために・・・ちょっと頑張って後で書き直しますorz

なんだかずっとこの掲示板に接続出来なかったのですが、自分だけ・・・？

>>ISLeさん

なるほど・・・。

ISLeさんのおっしゃる処理を漠然と思い浮かべたのですが、合っているかどうか判断して頂いても宜しいでしょうか？

まず各マスの列毎（ひし形マスのため縦横90度の直線）対角線の直線方程式を求める。
（これは攻撃範囲の所で行う必要が無いため、処理が軽い場所で事前に行い、値を保存しておく？）

次に攻撃範囲関数内で外周までの直線と、求めておいた各直線が接点を持つか調べる。

接点を持つ場合その接点の座標が、外周までの直線の始点から終点の間にある座標なのかを判定。

もしそうであればその座標をピクセル座標からマス座標を特定する関数へ代入し、マス座標を求める。


このような流れで合ってますでしょうか・・・？

不安点としては

・上記の書き方で処理が軽減されるかどうか

・保存されたマスが外周までの直線の始点から終点まで、順番良く保存されている訳ではない事。
　（これに関しては始点から各マスの中心へ直線を引き、その距離で整理すれば解決しそうですが）


このような感じです。だいぶサッパリしました。バックアップを取っておこう・・・。

おぉ無事投稿出来ました。

>>ソフト屋さん
なるほど。
ではその線で調べてみます。

しかしデバッグモードでは何も起こらないのに、リリースした際にバグるなんて事があるんですね・・・。
何故デバッグモードでも同様にバグらないのか不思議でなりません。

コレジャナイ さんが書きました:おぉ無事投稿出来ました。

>>ソフト屋さん
なるほど。
ではその線で調べてみます。

しかしデバッグモードでは何も起こらないのに、リリースした際にバグるなんて事があるんですね・・・。
何故デバッグモードでも同様にバグらないのか不思議でなりません。

変数のメモリの配置が最適化されて大幅に変わるからです。
逆にデバッグでしか出ないバグもあります。

前の方でsoftyaさんも書いてましたけど、ひし形で描画しても内部的には正方形で管理することはできないのですかね。
そうすればもっとシンプルにできるんですけどね。

コレジャナイ さんが書きました:まず各マスの列毎（ひし形マスのため縦横90度の直線）対角線の直線方程式を求める。
（これは攻撃範囲の所で行う必要が無いため、処理が軽い場所で事前に行い、値を保存しておく？）

線分と線分が交差しているかはそれぞれの線分の始点と終点の座標から求めることができます。
なので直線方程式を保存しておく必要なんてありません。
ひとマスずつ処理するときにマスの輪郭の図形の頂点座標はその場で参照できますよね。

コレジャナイ さんが書きました:次に攻撃範囲関数内で外周までの直線と、求めておいた各直線が接点を持つか調べる。

接点を持つ場合その接点の座標が、外周までの直線の始点から終点の間にある座標なのかを判定。

もしそうであればその座標をピクセル座標からマス座標を特定する関数へ代入し、マス座標を求める。

線分が交差していれば始点から終点の間にあることは明らかですよね。
ピクセル座標が出てくる理由が分かりません。
そもそもなぜこれらの手順が必要になるのでしょうか。

どうして攻撃が届き得るかどうかも含めてマス単位で処理できないんでしょう。
外周というのはどういうものなのでしょうか。

コレジャナイ さんが書きました:・上記の書き方で処理が軽減されるかどうか

コレジャナイさんはわたしの想像より遥かに何倍もの処理が必要と考えていらっしゃるようです。
というかピクセル単位の考え方から離れられないようです。
データ構造から見直す必要があるかもしれませんが、わたしが考えている方法は今回コレジャナイさんが整理した手順のさらに4分の1くらいの手順で済むように思います。

コレジャナイ さんが書きました:・保存されたマスが外周までの直線の始点から終点まで、順番良く保存されている訳ではない事。
　（これに関しては始点から各マスの中心へ直線を引き、その距離で整理すれば解決しそうですが）

これこそ最優先で取り組むべきなのでは？

>>ソフト屋さん
完全にバグを潰したものをお送り致しました。

やはりしっかりと有り得ない値を返してきた時はエラーメッセージを表示する様にしておかないと駄目ですね・・・。
猛省しましたorz

それとは別の話になりますが、実行ファイルを今度はしっかりテストしてみました。
そうした所、デバッグモードと違い移動＋攻撃範囲の表示がスムーズに行えたのですが、変数のメモリの配置が最適化された事のお陰なのでしょうか？
実行ファイルの速度でしたら大して気にならない速度で範囲表示されましたので、何かもうこれで良いんじゃなかろうかという気が少ししてしまいました。

ただISLeさんのおっしゃる方法を実装してみたいので、もう少し粘ってみます。

>>ISLeさん
まず始めに、取り敢えずマスの中心から垂らした垂線と直線の交点の座標のみ索敵する様に書き直しました。
（軽くなったのはこれのお陰もあるかもしれません。有難う御座いますm(_ _)m）


・ひし形で描画しても内部的には正方形で管理すること

恐らく可能なのだと思います。
ただそういった事をまるで考えもせずに設計していったため、思わぬ所で齟齬が生じるのではないかという不安があります。
（ピクセル座標からマス座標を求める関数を書き直せばそれで済む様な気もしますが・・・。）
どうなのでしょう・・・。
といっても自分で判断するしかない訳ですが・・・。。


・線分と線分が交差しているかはそれぞれの線分の始点と終点の座標から求めることができます。

すみません、お恥ずかしながら気が付きませんでした。
そうですよね、わざわざ直線方程式持ち出す必要がなかったですorz

図形の頂点座標については参照出来ます。


・そもそもなぜこれらの手順が必要になるのでしょうか

一つ上の項目を全く失念していたために見当違いの事を試行錯誤しておりましたorz


何だかとても簡単に求めれそうですね・・・。
明日実装を試してみます、重ね重ね色々申し訳御座いませんでしたm(_ _)m

コレジャナイ さんが書きました:>>ソフト屋さん
完全にバグを潰したものをお送り致しました。

やはりしっかりと有り得ない値を返してきた時はエラーメッセージを表示する様にしておかないと駄目ですね・・・。
猛省しましたorz

それとは別の話になりますが、実行ファイルを今度はしっかりテストしてみました。
そうした所、デバッグモードと違い移動＋攻撃範囲の表示がスムーズに行えたのですが、変数のメモリの配置が最適化された事のお陰なのでしょうか？
実行ファイルの速度でしたら大して気にならない速度で範囲表示されましたので、何かもうこれで良いんじゃなかろうかという気が少ししてしまいました。

ただISLeさんのおっしゃる方法を実装してみたいので、もう少し粘ってみます。

完全にバグを潰すのは奇跡ですよ。たぶん、他にもあると思っておいたほうが良いです。

>変数のメモリの配置が最適化された事のお陰なのでしょうか？
リリースビルドはデバッグ用の組み関数などを取り除き機械語命令レベルで処理自体を最適化するので、人間が思っていた以上に高速化されます。だいたい数倍から数十倍に高速化されますので処理落ちが気にならなくなったのはそのおかげでしょう。

すみません解決を付け忘れておりました

ISLeさんの方法を完全に実装した所、デバッグモードでも処理落ちせずに済むようになりました
有難う御座いますm(_ _)m