アカウント名:
パスワード:
まずは手を動かしてみましょう
で「描画の負荷が大変」、の意味は、SFC開発したことないので全然分かりません。SFCで直線描画するのが大変? 解説お願いします。
原則としてわずか1個の質体の物理シミュレーション(?)に帰着
魚---+ 床床床床床床 | | 川
まず、基本的には、スーファミには自由に描画できる機能がないらしいので、ロープはスプライトに描き、それを並べる必要があると考えています。というか、それしか考えられない。
それは違うよー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
作り手から見た今回の問題 (スコア:5, 興味深い)
# 後に聞いたところでは、これを作ったのは、X68000にキャメルトライを移植した職人肌のプログラマ。
Youtube動画などを見ていただければ、同じものを作るのがどれだけ難しいか判るでしょう。腕に覚えのある人は、どうやって作るのか考えてみても面白いかと思います。
（ちなみに、原作のプラットフォームはスーパーファミコンですが、このハードにはいわゆるグラ
Re:作り手から見た今回の問題 (スコア:2, すばらしい洞察)
別にやってることは単なる衝突判定と、頂点/線の交差判定と、
あとは単なるフックの法則(単なるかけ算)を考慮した加減乗除ですし、
しかも二次元に演算が限定されており三角関数すら登場しないので、
SFCの演算能力で難しいというほどのものではないと思いますが…。
(しかも今回たんなる移植だし)
逆に、今時、普通に3Dポリゴンキャラクター扱えるくせにこの程度の物理演算が
正しく動作しないなんて、そっちの方が「何者?」という感じです。
それとも「驚愕」なのは何かほかのファクター?
今時学生でもこの程度 [itmedia.co.jp]の物理演算ソフトがありますな。
Re:作り手から見た今回の問題 (スコア:3, すばらしい洞察)
- 頂点/線の交差判定
- あとは単なるフックの法則(単なるかけ算)を考慮した加減乗除
はい、おっしゃる通り「単なる」演算です。この内容で似た感じの動きのゲームは作れるかもしれません。PCでなら。
ただ、この通りで認識されているなら、おそらくスーパーファミコンでは60fpsで動かないと思います。
（このあたりはもはや想像でしかないですが）
イマドキのPCであれば、おっしゃるところの「物理演算」もきれいな実装にできるのかもしれませんが、当時の限られたリソースでは「いかに軽い処理でそれっぽく見せるか」が勝負でしょう。ソースを見せられたところで、その背景にあるモデルをすぐに理解できるかどうかは別問題だと思います。
# まあ、今回の移植のベースはスーパーファミコン版ではなく（PSPに近い）PS版でしょうから、
# ここまでの騒ぎになるというのは理解に苦しむところではあります。
Re:作り手から見た今回の問題 (スコア:2, すばらしい洞察)
当たり判定に関しては、他のゲームでもやっている作業ですから
資料を漁ればいくらでもいい例は出てきます
ましてや、2Dは最悪ピクセル判定出来ますのでたかが知れてます
肝心のロープに関しても、外積を10個も取れば処理が終わってしまいます
実際、高校程度の知識があれば綺麗に求まるので、まずは手を動かしてみましょう
方針としてはこんな感じ
・三角形の内部にある点に引っかかる
複数ある場合は交差しないように引っ掛けて逆引っ掛かりを取り除く
・引っかかりと外積が逆になった時、ロープは外れる
#ちゃんと考えない人は、今のPCがあっても挙動は再現できない気がするなぁ～
Re:作り手から見た今回の問題 (スコア:1)
おっしゃる通りだと思います。簡単だと思っている方は、PCでもなんでもよいので実際に組んでみるとよいかと。
PCで実現できたら、おめでとうございます。おそらく、PSやPSPでも実現可能です。
私もかつて、PCでモデル（ルアーと動く床除く）だけ真似てみたことがあります。が、スーファミだと、富豪的プログラマ（←誤用）な私にはちょっと無理です。
ゲームとして遊べるレベルまで組んだ人も複数いらっしゃるようですが、いずれも原作の爽快感を再現するにはいたっていないようですね。（まあこれは、パラメータが解らないと難しい）
# はてブで交差判定だけ考察されている方がいらっしゃいましたが、描画部分もぜひ。
# （スーファミ版は、おそらく描画では乗算も平方根も使ってません…想像ですけど）
Re:作り手から見た今回の問題 (スコア:2, 参考になる)
信用してくれる人だけどうぞ。右クリックで衝突判定オブジェクト出ます。
http://jn.swee.to/rubber.html [jn.swee.to]
もちろん、これそのものの計算量はSFCでは絶対無理です。負荷テスト兼ねて、1GHzのCeleronで内部600fpsで動かしてました。
あと現状、引き延ばしすぎるとオブジェクトをすり抜けるのも「仕様」です(笑)
川背の場合は、移動する可能性があるのはルアー部分(固定orコンベア移動)と、キャラクタ本人(重力受ける)の2カ所のみであり、他の頂点は動かず質量を持たずひっかかり判定に関わるだけなので、原則としてわずか1個の質体の物理シミュレーション(?)に帰着します。折れ線の衝突・ひっかかり判定の解決の方が難しく、それさえ解決できれば、極端な話キャラクターの複雑な動きは2種類の重力を受けているスーパーマリオに過ぎません。
ま、今回バグが出てるのはその紐の衝突判定の方らしいので、上のサンプルファイルの主眼とは異なりますが、一応参考に。
で「描画の負荷が大変」、の意味は、SFC開発したことないので全然分かりません。SFCで直線描画するのが大変? 解説お願いします。
Re:作り手から見た今回の問題 (スコア:1)
# すり抜け「仕様」は、いやん。:-)
ダラダラと長くて読みづらい文章が続きます、すいません。とりたてて「直線描画が大変」ということなのではなくて、スーファミでのロープ描画における様々な要素が組み合わさったうえで、「大変」ではないかと思える、ということです。
このあたり、大昔に仲間内で「どうやってるんだろうねえ」と色々話し合ったのですが、私もスーファミのハードに詳しいわけではなく、伝聞を含むので外しているかもしれません。（開発経験がある人がいても、守秘義務があるのであまり情報が出てこない）
なので、以下は話半分ということで一つ。それは違うよーって部分があればツッコミお願いします。＞識者な方（差しさわりない範囲で…）
まず、基本的には、スーファミには自由に描画できる機能がないらしいので、ロープはスプライトに描き、それを並べる必要があると考えています。というか、それしか考えられない。
どうもスーファミはスプライトの色やサイズにいろいろと制約があるようで、ロープの長さを考えると「ほんとにこれでできるのか」と疑問なのですが、実際にゲームとして実現しているので多分可能なのでしょう。
で、スプライト上にラインを描くとして（支点間のライン描画自体は8ビット時代からある問題だから省略、どのようにスプライトを並べるかも省略）、ここでロープのテンションに応じた紅白の描き分けをしなければいけません。
そのためには描画前にラインの長さを求め、テンションに応じて色の区間を決定し、どのポイントで色を切り替えるか決めないといけないのですが、ここがロープの支点判定と並んで悩ましいところで、富豪プログラマ（誤用）的な私の発想でストレートに実装しようとすると、こりゃスーファミの60fpsアクションでは厳しいだろう、という処理になってしまうのです。（それが乗算と平方根）
ということで、PCであれば単純化したモデル（ロープの紅白色分け含む）は実現できたのですが、スーファミで60fpsとなると私にはちょっと見当つかないです。(*1)
# 「楽勝だぜこんなの」という凄腕さんは、ぜひロケットスタジオへの転...以下略
当時の8～16ビットゲーム機のプログラマに話を聞くと、「こういう場面では、こんな軽い処理。誤差が出るけど、ここでの用途なら問題なし」といった、教科書に載ってないようなテクニックが色々とあるらしいので、本作でもそういった技を駆使しているのだと思います。
(*1) 現実には、オリジナルでも敵や支点が増えてくると処理落ちするので60fpsよりもハードルは低いです。ただ、おそらくスプライトへのパターン描画は垂直帰線期間内にやらないといけない。ここだけは処理落ち中でも遅らせるわけにはいきません。完全に終わらせるか、まったく処理しないかの2択。（じゃ、ないかと想像してます。表示が乱れないので）
あと、.exe動かしていない状態でちょっと申し訳ないのですが、ここだけ。- ルアーの先に魚がついている場合は考慮されているでしょうか？（本作では、落ちる魚に引っ張らせる技もあります）
- 摩擦は考慮されているでしょうか？ こんなケース↓で魚が右にズリズリ動いたりしませんか？ .exeでバッチリ再現できていたらゴメンナサイ。（私は、魚の実装まではやってないので）
Re:作り手から見た今回の問題 (スコア:1)
(自分も平方根はともかく乗除算くらいは使わないと咄嗟には思いつかない)
あと乗算20個でもSFCにとっては重いと言われちゃうと、確かに並大抵ではなさそうです。
(ただコンベアはあってもリフト/エレベータ系の壁は非常に少なく現実に動く頂点はせいぜい2～4個なので、中間の頂点で無駄に外積を毎フレーム計算する労力は相当省けるはず)
ルアー側にも敵キャラがいれば確かに2個の質体のシミュレーションになります。
exeファイルは想像されているものとは大分違うと思うので見なくていいです。
Re: (スコア:0)
それは違うよー
Re:作り手から見た今回の問題 (スコア:1)
もうちょいヒントいただけませんか。BG面使うのでしょうか？（枚数使い切っていると思うんですが）
Re:作り手から見た今回の問題 (スコア:1)
テンションに応じたパターンで順番に埋めてゆくだけで良いですね
-------- tear straight across --------
Re:作り手から見た今回の問題 (スコア:1)
一定の距離以内なら、って条件で判断可能です
条件に適合したら、引っかかり点を移動しちゃいましょう
移動した点がブロックの内部だったらラインブレイク！(笑
#まぁ、まずないし
Re: (スコア:0)
ライン引くなら基本 DDA でしょ。乗算? 平方根? バカじゃないの?
Re: (スコア:0)
Re: (スコア:0)
v1 × v2 = x1 * y2 - x2 * y1 = |v1| |v2| sin(θ)
ですよ? 外積10個とは、かけ算20個と足し算10個のことです。幾らSFCでもこれが無理なわけないでしょう。
Re: (スコア:0)
Re:作り手から見た今回の問題 (スコア:1)
とはいっても、乗除算は重い処理なのは確かだしSFCのスペックでは「外積１０回ぐらい楽勝」なんて主張はできないでしょうけど…
当時はパソコンのCPU(x86系なんかは当然乗除算命令はあります)でさえ、乗除算は重い処理の代表であり、
「DDA」だの「Bresenham」だのと、できるだけ乗除算を使わずに加減算だけで処理を済ませるようなアルゴリズムがいろいろ追求されてたものです。
最近のCPUはパイプラインを乱すことのペナルティが大きいので、
そのうち「加減算＋条件分岐」よりも「条件分岐の無い乗除算」が速くなって、Bresenhamなんかは過去の遺物になるんじゃないかと思ってるんですが、
数年前にPentium4で試したときは、まだ浮動小数点より整数Bresenhamの方が速かったです…
#そもそも、Bresenhamにこだわらなきゃいけないほど線形補間処理の計算量がクリティカルな場面って少なくなってますけどね…
Re: (スコア:0)
スターフォックスとかファイティングポリゴンのイメージが先行してるので「あの程度がいける」と思ってたけど、
あれは別チップをカードリッジに載せてたのかー。
素のSFCは厳しいのね。
平方根はどうですか?
Re:作り手から見た今回の問題 (スコア:1)
# このゲームやったことないけど
Re:作り手から見た今回の問題 (スコア:1, すばらしい洞察)
「単なる衝突判定」ですか……。
衝突判定の奥深さを前にすると、とても私にはそんなこと言えません。
あなたには信じられないかもしれませんが、世の中にはその単なる衝突判定すら正しく処理できないプログラマーが(ゲームプログラマに限っても)山のようにいるんですよ。
加減乗除にしたってそうですね。コンピュータ上での加減乗除を常に正しく扱える人がどれだけいるか。
そしてアイデアを一本のゲームとしてまとめ上げるのがどれだけ難しいことであるか。
過度に持ち上げるのもどうかと思いますが、驚愕する人がいてもおかしくないものだと私は思いますね。
Re:作り手から見た今回の問題 (スコア:1)
「カルドセプトサーガの時のコメント再び」な臭いがするなぁ。
>今時学生でもこの程度の物理演算ソフトがありますな。
それ、衝突判定のレベルは件のソフトと大して違わないよ？
#「角エネルギー」使えばわかる。漏れるし量子跳躍するし。
Re: (スコア:0)
実機で想定fpsでなかったんじゃないかなー
んで当たり判定の間隔が期待タイミングで起きずにおきた。
(シューティングで処理落ち時に擦り抜けできるって昔よくあったよーな)
デバックは、実機より性能の良い機材を使っているとか