アカウント名:
パスワード:
そもそも15FPSはどこの話なのかが問題。描画処理の話しなら入力とは別だから全く無関係。mainループが15FPSになるように調整しているなら関係してくるが。例えば昔のPCゲームとかするとFPS限界を設定してないのがあったりして、PCスペックの限界までFPSが上がってしまうのがある。200FPSとかでたりで。で、そういうゲームにFPSリミットをかけて60FPSにしたからって内部的には処理速度が大幅に余裕があるので制限掛ける前の200FPSで回ってたりする。ただ、描画部分だけは60FPSで回るように同期をとって表示するだけで。
ついでに必ずしも入力待ちをしている時に入力をするといったこともないので連打は早ければ早いだけ良い。
衝突判定を描画より速い速度で回すと、プレイヤーから見ると当たっていないのに、当たったと処理されるシーンが出てくるのですが。
勢い良くぶつかってすり抜けるのはFPSの問題じゃなくて判定のロジックがザルだからだろ…円判定だけとかでコリジョン判定を済ませてたりすると起こる。
円判定なんてやるような余裕は6502の1.79MHzにはないよ。単純に座標に”アタリ”の矩形サイズを足したもの同士が干渉するか見るのが精々。
移動が速い時?半分の速度で2回移動させりゃ引っかかるさ。
円(球)判定が一番軽いよ?中心同士の距離を求めるだけだから
6502だとかの8bitCPUには、かけ算器は内蔵してませんので、「二乗計算」が必要になる「円判定」は非常に計算が重いです。だから、当時としては、衝突判定は「矩形の重なり」で行うぐらいがせいぜいだったんですね。
キャラクタサイズを考えると乗算テーブルは現実的ですよせいぜい32エントリー
それでも円判定はないわー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
サンプリングの問題 (スコア:2)
必要なのは正確さで、ちょっとでもタイミングがずれると抜けが出ますし、秒間16連射とか秒間17連射だとどんなに正確でも同期が取れなくなって所々抜けます。
そういう抜けが出ないような、16回押したら16回と認識されるような実装を作り込んだという制作秘話が面白そうです。
Re: (スコア:2, 興味深い)
そもそも15FPSはどこの話なのかが問題。
描画処理の話しなら入力とは別だから全く無関係。
mainループが15FPSになるように調整しているなら関係してくるが。
例えば昔のPCゲームとかするとFPS限界を設定してないのがあったりして、PCスペックの限界までFPSが上がってしまうのがある。
200FPSとかでたりで。
で、そういうゲームにFPSリミットをかけて60FPSにしたからって内部的には処理速度が大幅に余裕があるので制限掛ける前の200FPSで回ってたりする。
ただ、描画部分だけは60FPSで回るように同期をとって表示するだけで。
ついでに必ずしも入力待ちをしている時に入力をするといったこともないので
連打は早ければ早いだけ良い。
Re: (スコア:0)
衝突判定を描画より速い速度で回すと、プレイヤーから見ると当たっていないのに、当たったと処理されるシーンが出てくるのですが。
Re: (スコア:0)
Re: (スコア:0)
勢い良くぶつかってすり抜けるのはFPSの問題じゃなくて判定のロジックがザルだからだろ…
円判定だけとかでコリジョン判定を済ませてたりすると起こる。
Re: (スコア:0)
円判定なんてやるような余裕は6502の1.79MHzにはないよ。
単純に座標に”アタリ”の矩形サイズを足したもの同士が干渉するか見るのが精々。
移動が速い時?
半分の速度で2回移動させりゃ引っかかるさ。
Re: (スコア:0)
円(球)判定が一番軽いよ?
中心同士の距離を求めるだけだから
Re:サンプリングの問題 (スコア:1)
6502だとかの8bitCPUには、かけ算器は内蔵してませんので、
「二乗計算」が必要になる「円判定」は非常に計算が重いです。
だから、当時としては、衝突判定は「矩形の重なり」で行うぐらいがせいぜいだったんですね。
Re: (スコア:0)
キャラクタサイズを考えると乗算テーブルは現実的ですよ
せいぜい32エントリー
それでも円判定はないわー