アカウント名:
パスワード:
そもそも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エントリー
それでも円判定はないわー
なので、後期にはI/Oポートをポーリングしたときの信号を拾って連打する、同期型の連打パッドが出てましたな。各々のソフトの最高速度で連打できるというシロモノ。
V-Syncとは別に、高サンプリングレートでパッドの入力履歴をリングバッファに記録する処理を走らせるしか。
ファミコンのコントローラ(パッド)はパラレルではなくシリアルなので、サンプリングレートはどうしてもクロックに依存します。それ以上のサンプリングはできません。連射回路を後づけした場合、ON/OFFを1クロックずつ繰り返した場合にはソフトによっては読みこぼしがあるので、ONを2クロック、OFFを1クロックで回す設計のほうが安定していました。その場合、迷宮組曲等のカウントでたしか21~22連射程度だったことから、V-syncと同じ60Hz程度のクロックが流れていたと想像しています。(おそらく「1秒(10秒)」の区切りが正確ではなく若干長かった?)つまり、ハード的には各ボタンを毎秒60回検出して最高30連射までですが、どの程度までを認識するかはソフトの実装次第です。
ここからは感覚的な話ですが、ゲーマーなら 60/30/15fps の区別は出来ていて、スターフォースでは描画も入力も60Hzだったような記憶があります。間違っていたらすみません。実際、私の約14連射程度では取りこぼしなく、それ以上が要求される局面もありました。一方フレームレートが遅いゲームの例を挙げると1942やエグゼドエグゼス等です。私の知る限りではギャラガの応答が早く、A/Bボタンを区別して検出しているので、これに限ってはもしかしたら合計60連射も可能だったかもしれません。
>ファミコンのコントローラ(パッド)はパラレルではなくシリアルなので、サンプリングレートはどうしてもクロックに依存します。それ以上のサンプリングはできません。
ゲームとしてのコントローラ状態のサンプリング(ソフトの実装に強く依存する)と、コントローラからの読み取り方式(ソフトの実装にちょっとは依存する)は別の話です。 他の処理を考慮しないならば、ファミコンでも秒間1万回程度のコントローラ状態の読込は十分に可能なはずです。
#ソフトウェアでシリアルに読み込む必要がある分、ポートを1回読むだけでコントローラ1の全情報をとれるSG-1000等に比べれば不利ですが。
前のフレームでボタンが押されておらず、かつ現フレームでボタンが押されたと検出できた場合に「ボタンが押された」判定されるのですから、60fpsで回っているとするなら最大30連射しか検出することが出来ないはずです。
仮に秒間60回ボタンを押すことができたとしても、それは「押しっぱなし」と判定されるはずです。
ボタンが区別されていなければその通り。ソフトの実装次第ですが、機能の重複する2ボタンが個別に認識されているものは逆位相で交互に押すようにすると、押しっぱなしというではなく全フレームでmake/breakが認識されるものがあります。確実にそうなっているのは、例えばアーケードのテトリス。
ファミコンのギャラガはボタンが同じ機能かつ区別されているのは間違いない(一方を押したまま他方を連射可能)のですが、どの程度まで連射を受け付ける仕様なのかは試したことがないのでわかりません。
A/Bボタンを区別して検出するのであれば、ABを毎フレーム交互に押し下げればAボタンで30連射 Bボタンで30連射 の合計60連射ができるかも、ということでは。
これ [famicom.biz]を使うんですかね
違います。AもBも同じショットですが、Aを押したままBを連打しても普通に撃てる独立仕様だったのでAとBのon/off逆転させた30連打で合計60連射できたかも?という話です。
実際、ABずらし押しで弾を極端に繋げて撃てました。まぁ、1画面に2発しか撃てないゲームなんですけどね。
> 前のフレームでボタンが押されておらず、かつ現フレームでボタンが押されたと検出できた場合に「ボタンが押された」そうすると楽ちんだしそこまで早押ししないだろうからそうしているソフトが多かろうというだけで、複数回確認してるソフトの存在は否定できないでしょう
それが他で書かれている迷宮組曲の計測モードなんかがその例なんだけれど、CPUでI/Oポートをポーリングする必要があるんで当然ながら重くなります。連打系のゲームなどを除いて、おおよそメリットのある処理ではないですし、そんな実装はしないでしょう。
1フレーム毎に8ビット分溜めて、前フレームの値をxor取って立ち上がったビットを判定するのがありがちなパターン。AボタンとBボタンを区別する意味もないから、2bitマスクして立っていれば弾発射、なんて書くので、交互に入力できれば毎フレーム発射は可能になるわけですな。
高橋某の記憶とは裏腹に、スターフォースもきちんとハードでシンクロ連射 [twitter.com]すれば32連射できるそうで。http://www.nicovideo.jp/watch/sm10467304 [nicovideo.jp]
V-Syncとは独立してカウントしている迷宮組曲ではこの通り。http://www.nicovideo.jp/watch/sm10467159 [nicovideo.jp]
迷宮組曲なんかはそうやったんじゃないかって元記事で書かれてますね。
そういう実装はほとんどの場合していません。PAL版では50FPSのゲームにするのです。 60FPSのゲームをそのまま50FPSで動かすとキャラの移動量が5/6になるので、6/6になるように調整してやるのです。
でもNTSC→PALへの移植なんかだと面倒なので、5フレームに1回キャラの移動処理を余計に回していました。なんとかなるもんです。
炎のコマでいいんじゃね
水魚のポーズ!
リンク先のブログにも触れられているけれど、「1画面上で最大3発のショットしか表示出来ませんでした。」とある。
1/30sec トリガーON→1発目の弾を生成2/30sec トリガーOFF確認3/30sec トリガーON→2発目の弾を生成4/30sec トリガーOFF確認5/30sec トリガーON→3発目の弾を生成6/30sec トリガーOFF確認7/30sec トリガーON→ここで1発目の弾が画面外に消えていないと、次弾は生成不可
そもそも、いくら画面上方で連打したからといって、そんなに弾速早いんかねアレ・・・・
ファミコンロッキーではツインビーで連射しまくって弾幕で画面を埋め尽くしていたなhttp://www5d.biglobe.ne.jp/t-suzuki/sousyuhen/rokky_twinbee.jpg [biglobe.ne.jp]
そういえば、1ライン上に出せるオブジェクトの制限ってのもありましたね。縦スクロールゲームは沢山弾を撃っても表示できるけど横スクロールゲームは表字数制限に引っかかって弾詰まりが発生する。
> 30秒に1回それは確かに至難の業だ。つーか無理じゃね?
> 30秒に1回、ボタンが押されているかどうかを判定
それはさすがに判定頻度が少なすぎますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
サンプリングの問題 (スコア: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エントリー
それでも円判定はないわー
Re:サンプリングの問題 (スコア:2, すばらしい洞察)
当時のゲームに同じパルスを送り込んでも、Aというゲームでは綺麗に連射されて、Bというゲームではまだらな連打になったり、ほとんど押下を拾わなくなったり。
すこしパルスをずらすとまた違う反応があって、子供心に実装の違いを肌で感じていたもんです。
Re:サンプリングの問題 (スコア:2, 興味深い)
なので、後期にはI/Oポートをポーリングしたときの信号を拾って連打する、同期型の連打パッドが出てましたな。
各々のソフトの最高速度で連打できるというシロモノ。
Re: (スコア:0)
V-Syncとは別に、高サンプリングレートでパッドの入力履歴をリングバッファに記録する処理を走らせるしか。
Re:サンプリングの問題 (スコア:4, 参考になる)
ファミコンのコントローラ(パッド)はパラレルではなくシリアルなので、サンプリングレートはどうしてもクロックに依存します。それ以上のサンプリングはできません。
連射回路を後づけした場合、ON/OFFを1クロックずつ繰り返した場合にはソフトによっては読みこぼしがあるので、ONを2クロック、OFFを1クロックで回す設計のほうが安定していました。
その場合、迷宮組曲等のカウントでたしか21~22連射程度だったことから、V-syncと同じ60Hz程度のクロックが流れていたと想像しています。
(おそらく「1秒(10秒)」の区切りが正確ではなく若干長かった?)
つまり、ハード的には各ボタンを毎秒60回検出して最高30連射までですが、どの程度までを認識するかはソフトの実装次第です。
ここからは感覚的な話ですが、ゲーマーなら 60/30/15fps の区別は出来ていて、スターフォースでは描画も入力も60Hzだったような記憶があります。間違っていたらすみません。
実際、私の約14連射程度では取りこぼしなく、それ以上が要求される局面もありました。
一方フレームレートが遅いゲームの例を挙げると1942やエグゼドエグゼス等です。
私の知る限りではギャラガの応答が早く、A/Bボタンを区別して検出しているので、これに限ってはもしかしたら合計60連射も可能だったかもしれません。
Re:サンプリングの問題 (スコア:1)
>ファミコンのコントローラ(パッド)はパラレルではなくシリアルなので、サンプリングレートはどうしてもクロックに依存します。それ以上のサンプリングはできません。
ゲームとしてのコントローラ状態のサンプリング(ソフトの実装に強く依存する)と、コントローラからの読み取り方式(ソフトの実装にちょっとは依存する)は別の話です。
他の処理を考慮しないならば、ファミコンでも秒間1万回程度のコントローラ状態の読込は十分に可能なはずです。
#ソフトウェアでシリアルに読み込む必要がある分、ポートを1回読むだけでコントローラ1の全情報をとれるSG-1000等に比べれば不利ですが。
60連射? (スコア:0)
前のフレームでボタンが押されておらず、かつ現フレームでボタンが押されたと検出できた場合に「ボタンが押された」判定されるのですから、60fpsで回っているとするなら最大30連射しか検出することが出来ないはずです。
仮に秒間60回ボタンを押すことができたとしても、それは「押しっぱなし」と判定されるはずです。
Re:60連射? (スコア:1)
ボタンが区別されていなければその通り。
ソフトの実装次第ですが、機能の重複する2ボタンが個別に認識されているものは逆位相で交互に押すようにすると、
押しっぱなしというではなく全フレームでmake/breakが認識されるものがあります。
確実にそうなっているのは、例えばアーケードのテトリス。
ファミコンのギャラガはボタンが同じ機能かつ区別されているのは間違いない(一方を押したまま他方を連射可能)のですが、
どの程度まで連射を受け付ける仕様なのかは試したことがないのでわかりません。
Re: (スコア:0)
Re: (スコア:0)
A/Bボタンを区別して検出するのであれば、ABを毎フレーム交互に押し下げれば
Aボタンで30連射 Bボタンで30連射 の合計60連射ができるかも、ということでは。
Re: (スコア:0)
これ [famicom.biz]を使うんですかね
Re: (スコア:0)
違います。
AもBも同じショットですが、Aを押したままBを連打しても普通に撃てる独立仕様だったので
AとBのon/off逆転させた30連打で合計60連射できたかも?という話です。
実際、ABずらし押しで弾を極端に繋げて撃てました。
まぁ、1画面に2発しか撃てないゲームなんですけどね。
Re: (スコア:0)
> 前のフレームでボタンが押されておらず、かつ現フレームでボタンが押されたと検出できた場合に「ボタンが押された」
そうすると楽ちんだしそこまで早押ししないだろうからそうしているソフトが多かろうというだけで、
複数回確認してるソフトの存在は否定できないでしょう
Re: (スコア:0)
それが他で書かれている迷宮組曲の計測モードなんかがその例なんだけれど、CPUでI/Oポートをポーリングする必要があるんで
当然ながら重くなります。
連打系のゲームなどを除いて、おおよそメリットのある処理ではないですし、そんな実装はしないでしょう。
1フレーム毎に8ビット分溜めて、前フレームの値をxor取って立ち上がったビットを判定するのがありがちなパターン。
AボタンとBボタンを区別する意味もないから、2bitマスクして立っていれば弾発射、なんて書くので、交互に入力できれば
毎フレーム発射は可能になるわけですな。
Re: (スコア:0)
高橋某の記憶とは裏腹に、スターフォースもきちんとハードでシンクロ連射 [twitter.com]すれば32連射できるそうで。
http://www.nicovideo.jp/watch/sm10467304 [nicovideo.jp]
V-Syncとは独立してカウントしている迷宮組曲ではこの通り。
http://www.nicovideo.jp/watch/sm10467159 [nicovideo.jp]
Re:サンプリングの問題 (スコア:2, 興味深い)
迷宮組曲なんかはそうやったんじゃないかって元記事で書かれてますね。
Re:サンプリングの問題 (スコア:1)
Re:サンプリングの問題 (スコア:2)
じゃないとPAL圏に輸出した時におかしくなっちゃう
Re:サンプリングの問題 (スコア:2, 興味深い)
そういう実装はほとんどの場合していません。PAL版では50FPSのゲームにするのです。
60FPSのゲームをそのまま50FPSで動かすとキャラの移動量が5/6になるので、6/6になるように調整してやるのです。
でもNTSC→PALへの移植なんかだと面倒なので、5フレームに1回キャラの移動処理を余計に回していました。
なんとかなるもんです。
Re: (スコア:0)
炎のコマでいいんじゃね
Re: (スコア:0)
水魚のポーズ!
Re: (スコア:0)
リンク先のブログにも触れられているけれど、「1画面上で最大3発のショットしか表示出来ませんでした。」とある。
1/30sec トリガーON→1発目の弾を生成
2/30sec トリガーOFF確認
3/30sec トリガーON→2発目の弾を生成
4/30sec トリガーOFF確認
5/30sec トリガーON→3発目の弾を生成
6/30sec トリガーOFF確認
7/30sec トリガーON→ここで1発目の弾が画面外に消えていないと、次弾は生成不可
そもそも、いくら画面上方で連打したからといって、そんなに弾速早いんかねアレ・・・・
Re: (スコア:0)
ファミコンロッキーではツインビーで連射しまくって弾幕で画面を埋め尽くしていたな
http://www5d.biglobe.ne.jp/t-suzuki/sousyuhen/rokky_twinbee.jpg [biglobe.ne.jp]
Re: (スコア:0)
そういえば、1ライン上に出せるオブジェクトの制限ってのもありましたね。
縦スクロールゲームは沢山弾を撃っても表示できるけど
横スクロールゲームは表字数制限に引っかかって弾詰まりが発生する。
Re: (スコア:0)
> 30秒に1回
それは確かに至難の業だ。つーか無理じゃね?
Re: (スコア:0)
> 30秒に1回、ボタンが押されているかどうかを判定
それはさすがに判定頻度が少なすぎますね。