636 ：
名前は開発中のものです。：
上に書いている話題とかぶるかもしれないのですが
STGにおいて当たり判定の形で 丸と四角を同時に使うことができるんですか？
持っている、STGの本だとどれも当たり判定が四角ののみなので、やり方を教えていただけませんか？
後、STGにおいて、特殊な形の当たり判定って四角を組み合わせてつくっているんですか？
基本は四角。
ドットは四角だからな
四角も円も、動かし方で見た目と判定にずれが出るよね。
見た目と判定を一致させる方法とか、実際にそうしてる作品とかある？
動かし方でずれるってのがよく判らない
>>636 四角が回転することがない軸並行なものならば、円の中心をcx, cy、半径をr、
四角をleft, top, right, bottomで表現すると
int d=0;
if (cx < left) d += (left - cx) * (left - cx);
else if (cx > right) d += (cx - right) * (cx - right);
if (cy < top) d += (top - cy) * (top - cy);
else if (cy > bottom) d += (cy - bottom) * (cy - bottom);
if (d < r * r) { 交差している }
else { 交差していない }
たしかGemsだかに載ってた言葉を借りると、
ユーザーは別に当たり判定の正確さを求めてるわけではない
ってのがあって、それは正論なんで完璧に取る必要はないとは思うけど、
でも当たりが正確だとヒットエフェクトとか出た時に気持ちいいんだよなぁ。
>>636 >STGにおいて当たり判定の形で 丸と四角を同時に使うことができるんですか？
まず、ヒットデータを、このデータは○です、このデータは□です、
データの実体はこのポインタです、全部で何個あります、みたいな構造にして
○と○のヒットチェック、○と□のヒットチェック、□と□のヒットチェック
にそれぞれ飛ばせばおｋ
>STGにおいて、特殊な形の当たり判定って四角を組み合わせてつくっているんですか
多角形のヒットを実装すればおｋ
丸い敵がそのまま丸だったり、複雑な形しているのが見た目
そのままだったりするとプレイヤーは激突しそうだが。
多少は重なっても大丈夫っていう認識が出来上がっちゃってるからな
まあ最近のシューティングっぽく作るなら、近づいて撃ちこんだりしないだろうから
平気だとは思うけどね。どっちにしても判定なんか単純な図形で問題ない。
多角形の当たり判定使ってる。
今のCPUなら1000個くらいのオブジェクト出ても、上手いことやれば問題ないよ。
まぁ円は矩形の組み合わせでもいいけどな。
□□┌──┐□□
□┌┼──┼┐□
┌┼┼──┼┼┐
│││□□│││
└┼┼──┼┼┘
□└┼──┼┘□
□□└──┘□□
実際、俺は16bitマシンの頃はこれでやってた。
つか今もこれでやってるｗ
矩形の配列や矩形のリストでもつのはまず基本だと思う
ここからがスタート地点
さらに進めて矩形というのをシェイプとかにして判定部分を矩形だろうが円だろうが意識させないで独立させるのが常識
円でやってたときは
ルートとらないで計算したり
二乗テーブル用意したりしてたなｗ
本当にしっかりとりたかったら
ツートンカラーの裏画面をつくって、ドット単位で■アタリ／□ハズレでチェックするといいお。
>>652 それだといくらでも自由にできるよね。
などといいつつ、実際にそれ試したやついるのかな？
満足できたのかどうか。
なぁに、bool型にデータぶち込んで座標適応させてifで判定するのをループさせれば良いだけだからな。
はふへほへ。
自機とそれ以外なら簡単そうだけど、全てのキャラクタ相互の
判定をしようとしたら面倒そう。
妙に判定を細かくやりたがる奴って、
格ゲー作るとしてもそんな風に判定作るんだろうか。
作ってる間の触感が楽しいんだよ。ただし、これにハマるとまるで
無限ループにハマったかのように、永遠に抜け出せなくなる恐れが・・・orz
細かく判定できるようにすると、ゲームとしては細かく作れるようになる。
しかし、全く別のゲームを作ってる気分になる。
つ～か、バランス調整で経験則が効かなくなる。
結果的に、マニアックで分かりにくいゲームが完成する。ｗｗｗｗｗｗｗｗ
orz
ロボット物横STGの自機やられ判定は本当に難しいな。
ゲージ制にして自機と同じ高さの縦線１本かもう少し太い位が結局一番なのか。
四角いロボットにすればいいじゃん？
四角いロボットって、東亜プランの敵みたいやな
アトミックロボキッドだな。きっと。
>>649 円で判定した方が早いし簡単なのに、なんでこんなことを？
>>664 乗算が今とは比べ物にならないほど遅かったのと、円以外の複雑な形状にも対応出来るから。凹とか。
今もこれでやってるのは単なる惰性。
矩形メインの場合、円を組み込もうとすると頭いたくなる・・・
nullpo
こういう話題ってこのスレ向きだよね。
偉そうに「これはこうだ」と言い放つ奴も来ないし、
個人が培ったノウハウを交換しあってるのが嬉しい。
横長の矩形キャラクタを回転させたい場合とかどうしてますか？
ふとバキュラに思いを馳せる
回転軸が違うってのｗ
そして詐欺判定。
OBBでぐぐれ
回転なんか使うな
8x16程度なら、8x8の正方形の判定を中央に置くという手抜きをしても
案外違和感が無い。
>>666 特殊な条件下なら円と頂点の内包判定4回で代用できるっしょ。
これなら簡単。
円の直径より大きい矩形があると途端に駄目になるが
円判定なんてどうせ、巨大ボムと隕石くらいでしか使わんだろ。
一番簡単なのは、矩形を円の半径だけ外側に押し出した矩形に
円の中心が含まれているか判定するやつだと思うな。
四隅で判定の精度が落ちるけど、通常はあまり問題にならないし。
ロバストな方法では、
>>642が一番計算回数が少なくて済む。
このスレでやってる限り
シューティングに厳密なヒット判定は不要
という結論にしかならんなぁ
逆に考えるんだ
厳密なヒット判定が必要な時ってどんな時？
ゆっくり当るとき。
スロー実装したゲーム作ってるけど、確かに衝突判定が見た目と少しでも違うとかなり違和感がある。
俺の作ってるゲーム弾もキャラも全て矩形ベースだから無問題だがな。
>>682 不要だし、やるべきじゃないとも言える。
ちょっと待て。「厳密な判定したいんだけど…」といわれれば、
厳密な判定のやり方を議論すればいい話であって、
厳密な判定が不要なんて意見は論外じゃないか？
技 術 板 の 技 術 ス レ な ん だ か ら！！！
じゃあ議論しろよ
自機敵機地形弾をポリゴンでモデリングしておき、ポリゴンvsポリゴンで判定すれば無問題。
さて、次のお題どうぞｗ
ヒット判定よりテクスチャよくした方がいいかな・・・
エスプガルーダとかスローあるよね。
あれって当たりは細かくとってるのかな？
細いも何も
自機の判定サイズ自体が既にゑと違う
よね？
>691
細いってなんだよ
>690
よく見てないけど60FPSを30FPSにしてるだけじゃないのか？
眼科に行くんだな
>>693 こまかい→細い
EGBridgeだが
ﾘｱﾙ辞書引いたら送りがな間違ってるな…
こまかい 細かい
こんなときに限ってことえりの方が正解だった('A`)
辞書に頼らないと細かいの送り仮名が分からないって、よほどの低脳だな
EGBridge！
9の頃使ってたな…
いやさ、矩形とか細かいとか、なんで本題よりそっちの方に話が行くわけ？
本題が大した話じゃないから
ヽ(´ー｀)ノ ｲｯﾁｬｯﾀ､ｲｯﾁｬｯﾀ
本題を語れる頭じゃないから
というか今言ってる本題って何？
ほら、バカがキタ
>>704 バカっていうほうがバカなんだぜ
っていうのは置いておくとして、今の本題ってあたり判定でしょ？
矩形とか細かいとか、って本題からずれた話か？
って疑問だったから本題を何か確認させて欲しかったんだが。
>>706 せっかく置いてくれたのに
バカはやっぱりバカだな
於くもんだというツッコミでなくて？
うるせバーカｗ
いつまでもシューティングの話なんかしてんじゃねえよ
Σ(ﾟДﾟ；ｴｰｯ!