アカウント名:
パスワード:
そもそも15FPSはどこの話なのかが問題。描画処理の話しなら入力とは別だから全く無関係。mainループが15FPSになるように調整しているなら関係してくるが。例えば昔のPCゲームとかするとFPS限界を設定してないのがあったりして、PCスペックの限界までFPSが上がってしまうのがある。200FPSとかでたりで。で、そういうゲームにFPSリミットをかけて60FPSにしたからって内部的には処理速度が大幅に余裕があるので制限掛ける前の200FPSで回ってたりする。ただ、描画部分だけは60FPSで回るように同期をとって表示するだけで。
ついでに必ずしも入力待ちをしている時に入力をするといったこともないので連打は早ければ早いだけ良い。
ハードウェアが固定のゲーム機だと、メインループの周期をVSYNCに合わせると言うのは一般的です。
ただ、たとえばメインループが16msで回っていても、I/O監視が16msかということはそんなことはなく、もっと高速な周期の割りこみで監視する(チャタリング除去とか、反応時間が短くてこの周期では拾えないとか言う時のために)というのもよくやる実装でしたから、「メインループが30fpsだからON/OFF判定で原理的に15ショット/sしか読めない」ことはないかと思います。
高橋さんが言ってるスターソルジャー以降の実装ではそういうことをやってたんじゃないでしょうか。
名人を付けろよデコ助野郎!
さかなクンにさん付けろとトゥイッターで言ってる奴と同じ…………
まあ知らなくても仕方はないが、とある漫画で有名なセリフのもじりです。調べてみるといいでしょうゲームネタなので漫画の内輪ウケ的ネタはあるかと
何でデコ助なの?データイースト信者はアンチハドソンなのか?
ファミコンがどうなっていたかは知らないけど、>「メインループが30fpsだからON/OFF判定で原理的に15ショット/sしか読めない」>ことはないかと思います。
ほかの実装がどうなっていたか分からないと、こんな判断はできませんね。ON/OFFがキューに入って溜まっているなら、読みにいくタイミングで何回ON/OFFがあったかまで検出できるけど、ON/OFFのフラグだけなら、1回の読み込みでON/OFFどちらかしか検出できないから、15ショット/sしかできないでしょ。# 16msって、どこから出て来たんだ?
# 16msって、どこから出て来たんだ?
1/60秒.
ファミコンのボタン検知程度でキューなんか作らないよねぇ常識的に考えて。
チャタリング除去まで考えた上で、単純にVSYNCごとに状態読み込みしていました。チャタリングの持続時間が最大数ミリ秒とのことなので、16msの間隔で読めば影響をなくすことができます。あと、キューに入れたらリアルタイム性が損なわれます。必要となるのは、先行入力が可能となった対戦格闘ゲームからではないでしょうか。
ファミコンだとVRAMのバスをCPUとPPUで奪い合うので、CPU側からVRAMに書き込めるのは垂直帰線の間だけ。DMAなんてイキなものもなく、横1ラインぐらいのBG書き換えが限度だった筈。
なのでゲームの作りもV-Syncで描画→次フレーム作成→ブランキング待ちのパターンがセオリーだったな。次のブランキングまでにフレーム作成が終わらない場合が、いわゆる「処理落ち」。
> 横1ラインぐらいのBG書き換えが限度だった筈
というかファミコン世代はそもそもラインバッファ方式ですから、横1ラインずつしか書き換えないハードウェアですね。これは水平帰線時間内の話なのでその間に書き換えきれない場合スプライトの描画が消えたりする。
ファミコンはPPUのポートにアドレスを叩き、あとはデータを叩く毎に勝手にアドレスがインクリメントされる単純なPIOですな。加算値は縦用に+32にも設定できた筈。これを垂直帰線の間に「できるだけ」やる感じ。垂直帰線内でスプライトDMAとどっちを優先するかは実装によるだろうけれど、普通はスプライトDMAでしょう。
水平帰線内はなんもやらない。0番スプライトの衝突を使って1フレーム1回なら拾えなくはないけれど。スプライトが8キャラ分以下しか横並びできないのはハードウェアの制限。点滅するのは、上記の場合に消えたままになるスプライトが出ないように、フレーム毎に描画するスプライトを変更しているため。
衝突判定を描画より速い速度で回すと、プレイヤーから見ると当たっていないのに、当たったと処理されるシーンが出てくるのですが。
勢い良くぶつかってすり抜けるのはFPSの問題じゃなくて判定のロジックがザルだからだろ…円判定だけとかでコリジョン判定を済ませてたりすると起こる。
円判定なんてやるような余裕は6502の1.79MHzにはないよ。単純に座標に”アタリ”の矩形サイズを足したもの同士が干渉するか見るのが精々。
移動が速い時?半分の速度で2回移動させりゃ引っかかるさ。
円(球)判定が一番軽いよ?中心同士の距離を求めるだけだから
その距離を求めるのに、三角関数とか使うの習ってないですか?
距離を求めるのに三角関数なんて必要ですか?# 当たり判定だけなら距離そのものでなく距離の二乗で十分だから、二次元平面なら引き算2回、掛算2回と足し算1回で済むような。
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:サンプリングの問題 (スコア:2, 参考になる)
ハードウェアが固定のゲーム機だと、メインループの周期をVSYNCに合わせると言うのは一般的です。
ただ、たとえばメインループが16msで回っていても、I/O監視が16msかということはそんなことはなく、
もっと高速な周期の割りこみで監視する(チャタリング除去とか、反応時間が短くてこの周期では拾えないとか言う時のために)
というのもよくやる実装でしたから、
「メインループが30fpsだからON/OFF判定で原理的に15ショット/sしか読めない」
ことはないかと思います。
高橋さんが言ってるスターソルジャー以降の実装ではそういうことをやってたんじゃないでしょうか。
Re: (スコア:0)
名人を付けろよデコ助野郎!
Re: (スコア:0)
名人を付けろよデコ助野郎!
さかなクンにさん付けろとトゥイッターで言ってる奴と同じ…………
Re: (スコア:0)
まあ知らなくても仕方はないが、とある漫画で有名なセリフのもじりです。
調べてみるといいでしょう
ゲームネタなので漫画の内輪ウケ的ネタはあるかと
Re: (スコア:0)
何でデコ助なの?
データイースト信者はアンチハドソンなのか?
Re: (スコア:0)
ファミコンがどうなっていたかは知らないけど、
>「メインループが30fpsだからON/OFF判定で原理的に15ショット/sしか読めない」
>ことはないかと思います。
ほかの実装がどうなっていたか分からないと、こんな判断はできませんね。
ON/OFFがキューに入って溜まっているなら、読みにいくタイミングで何回ON/OFFがあったかまで検出できるけど、
ON/OFFのフラグだけなら、1回の読み込みでON/OFFどちらかしか検出できないから、15ショット/sしかできないでしょ。
# 16msって、どこから出て来たんだ?
Re: (スコア:0)
1/60秒.
Re: (スコア:0)
ファミコンのボタン検知程度でキューなんか作らないよねぇ常識的に考えて。
Re:サンプリングの問題 (スコア:2)
チャタリング除去まで考えた上で、単純にVSYNCごとに状態読み込みしていました。
チャタリングの持続時間が最大数ミリ秒とのことなので、16msの間隔で読めば影響をなくすことができます。
あと、キューに入れたらリアルタイム性が損なわれます。必要となるのは、先行入力が可能となった対戦格闘ゲームからではないでしょうか。
それはPCの話 (スコア:1)
ファミコンだとVRAMのバスをCPUとPPUで奪い合うので、CPU側からVRAMに書き込めるのは垂直帰線の間だけ。
DMAなんてイキなものもなく、横1ラインぐらいのBG書き換えが限度だった筈。
なのでゲームの作りもV-Syncで描画→次フレーム作成→ブランキング待ちのパターンがセオリーだったな。
次のブランキングまでにフレーム作成が終わらない場合が、いわゆる「処理落ち」。
Re:それはPCの話 (スコア:1)
> 横1ラインぐらいのBG書き換えが限度だった筈
というかファミコン世代はそもそもラインバッファ方式ですから、横1ラインずつしか書き換えないハードウェアですね。
これは水平帰線時間内の話なのでその間に書き換えきれない場合スプライトの描画が消えたりする。
Re:それはPCの話 (スコア:1)
ファミコンはPPUのポートにアドレスを叩き、あとはデータを叩く毎に勝手にアドレスがインクリメントされる単純なPIOですな。
加算値は縦用に+32にも設定できた筈。これを垂直帰線の間に「できるだけ」やる感じ。
垂直帰線内でスプライトDMAとどっちを優先するかは実装によるだろうけれど、普通はスプライトDMAでしょう。
水平帰線内はなんもやらない。0番スプライトの衝突を使って1フレーム1回なら拾えなくはないけれど。
スプライトが8キャラ分以下しか横並びできないのはハードウェアの制限。
点滅するのは、上記の場合に消えたままになるスプライトが出ないように、フレーム毎に描画するスプライトを変更しているため。
Re: (スコア:0)
衝突判定を描画より速い速度で回すと、プレイヤーから見ると当たっていないのに、当たったと処理されるシーンが出てくるのですが。
Re: (スコア:0)
Re: (スコア:0)
勢い良くぶつかってすり抜けるのはFPSの問題じゃなくて判定のロジックがザルだからだろ…
円判定だけとかでコリジョン判定を済ませてたりすると起こる。
Re: (スコア:0)
円判定なんてやるような余裕は6502の1.79MHzにはないよ。
単純に座標に”アタリ”の矩形サイズを足したもの同士が干渉するか見るのが精々。
移動が速い時?
半分の速度で2回移動させりゃ引っかかるさ。
Re: (スコア:0)
円(球)判定が一番軽いよ?
中心同士の距離を求めるだけだから
Re: (スコア:0)
その距離を求めるのに、三角関数とか使うの習ってないですか?
Re: (スコア:0)
距離を求めるのに三角関数なんて必要ですか?
# 当たり判定だけなら距離そのものでなく距離の二乗で十分だから、二次元平面なら引き算2回、掛算2回と足し算1回で済むような。
Re:サンプリングの問題 (スコア:1)
6502だとかの8bitCPUには、かけ算器は内蔵してませんので、
「二乗計算」が必要になる「円判定」は非常に計算が重いです。
だから、当時としては、衝突判定は「矩形の重なり」で行うぐらいがせいぜいだったんですね。
Re: (スコア:0)
キャラクタサイズを考えると乗算テーブルは現実的ですよ
せいぜい32エントリー
それでも円判定はないわー