パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

NEOGEO、誕生から20周年 」記事へのコメント

  • PS3/PSPにNEOGEOアーカイブスができて、過去のNEOGEOソフトを遊べるっていう噂が出てますね
    本当だとうれしい

    • Re: (スコア:1, 参考になる)

      by Anonymous Coward

      Wiiだと既にバーチャルコンソール化 [snkplaymore.co.jp]されていますね。
      流石にプログラムそのままではないでしょうが、Xbox 360のXbox Live ArcadeでもいくつかNEO GEO用ソフトを見かけますし、PS3の性能だったら完全再現も難しくないんじゃないですかね。

      • by Anonymous Coward on 2010年03月03日 22時42分 (#1727119)
        フレームバッファを採用したアーキテクチャのPS3で完全再現はけっこう難しいと思います。
        親コメント
        • ああいうのは内部で仮想VRAMを持っていて、フレームの最後にVRAM内容を転送するだけですね。
          だからむしろグラフィック的には負荷は低いと思います。
          親コメント
          • by Anonymous Coward
            表示の遅延はどうやって解消するんですか?
            • 遅延が発生するのですか?

              実機 V-Blank-In
                VM 処理開始
                VM V-Blank-Out
                VM V-Blank-In
                  描画処理>BLT
                VM 処理終了
              実機 V-Blank-Out

              特に発生する要因は無いと思いますが・・・
              親コメント
              • by Anonymous Coward
                フレームバッファ方式では、フレームの上半分を見てプレイヤーが入力した処理を下半分の描画に反映させることはできませんが、そんなゲームは存在しないでしょう。
              • by Anonymous Coward

                実機 V-Blank-In
                    VM 処理開始
                    VM V-Blank-Out
                    VM V-Blank-In
                        描画処理>BLT
                    VM 処理終了
                実機 V-Blank-Out

                見方が分かりません。VMって何ですか? あと、プレイヤーの入力、入力に対するMPUの処理、ラスタースクロールの処理なんかはどこになりますか?

              • by Anonymous Coward

                実機はVDPの出力を即表示させてますが、エミュレータはVDPの出力を一旦仮想ディスプレイ
                として裏のフレームバッファに書いて、その処理が終わってから表示対象のハードウェアに
                あわせて画像のコンバートをかけているので最低でも1~2フレーム分は遅れて表示されます。

              • by Anonymous Coward

                遅延は発生しますよ。
                ビデオゲームの多くは表示期間と垂直帰線期間を合わせたフレームという単位で動かしているものが一般的ですが、そのフレームのなかでのプロセッサの処理は、大よそ以下の通りとなります。

                ----------------------------------------
                フレーム1表示期間
                ・プレイヤー操作入力
                ・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)
                ・ラスター処理(スクロール、パレット書き換えなど)
                ----------------------------------------
                フレーム1垂直帰線期間
                ・スプライトテーブル書き換え
                ・BG書き換え
                ・パレット書き換え
                ----------------------------------------
                フレーム2

              • コンバートを即時に行えば良いだけでは?
                むしろフレームをまたいで描画する理由がわかりませんが。
                何故1-2フレームも後で処理するのですか?
                親コメント
              • by Anonymous Coward on 2010年03月04日 1時44分 (#1727190)

                間違いです。

                フレーム毎に
                ・実機ではレンダリングしながら表示
                ・エミュレータではレンダリングを終わらせてから表示
                という違いだけです。ですから実機とエミュレータでディスプレイに表示されるものに差は出ません。
                (実機が画面上半分のレンダリング中にあったリアルタイムな外部入力を処理し、それを下半分のレンダリングに反映させる場合は除きますが、そのようなゲームは存在しないでしょう)

                > 最低でも1~2フレーム分は遅れて表示されます。

                遅れとおっしゃいますが、何が何から遅れるのか理解して書いていますか?

                親コメント
              • by Anonymous Coward
                ラスタースクロールなんかは表示されるオブジェクトテーブルの内容が確定した後での操作となる筈ですが、どうやって即時行うんですか?
              • ラスターの値を記録しとけばいいじゃない・・・
                むしろなんで頑なにそんなに遅延すると思ってるのか謎。
                親コメント
              • by Anonymous Coward
                疑問が理解しかねますが、
                エミュレータはフレームバッファにレンダリングしている時にラスター割り込みもエミュレートしますので問題はありません。
              • by Anonymous Coward

                実機でのラスターの処理は次のフレームですよ。
                その(MPUの)処理が終了するまで画面イメージのビットマップは決定できないと思いますが、それから表示を行うと遅延は生じないですか?
                プレイヤーの入力から画面への表示まで、遅延は大きいのではないですか?

              • まぁそう思うならそうなんでしょうねぇ

                とりあえず、VMの処理時間が限りなくゼロに近いと仮定して色々考えられてはどうですか?
                それでも遅延が出るのなら、それは絶対に出る遅延なんでしょう。

                ラスターの値をライン毎に記憶しておいて
                全てのレンダー要素が揃った所で
                その記憶しておいた値を使ってレンダリング
                この間の時間がゼロだとしても遅延します?
                親コメント
              • by Anonymous Coward
                あなたの言う VM って何ですか?
              • by Anonymous Coward

                実機とエミュレーターで処理の順番が違う以上、発生するウェイトによって遅延が出るのは不可避ですね。
                この遅延というのは実機と比べてタイミングが遅れるっていう意味で、処理能力とは関係ない。
                だから「VMの処理時間がゼロ」では間に合わない。
                マイナスじゃないと。

                ただそれが深刻な問題かといわれると、全くそうは思いませんけど。

              • PS3では表示中のフレームバッファを書き換えられない、と仮定すれば、エミュレータが頑張って書いてる仮想フレームバッファから本物のフレームバッファ(裏)へフレームの途中でも頻繁に変換するとしても、変換に加えて表と裏を切り替える時間分は論理的にどうしても遅延しますね。数十nsくらいでしょうか。

                親コメント
              • > フレーム毎に
                > ・実機ではレンダリングしながら表示
                > ・エミュレータではレンダリングを終わらせてから表示
                > という違いだけです。

                「表示」を行ったら、一瞬で画面に反映されると勘違いしてませんか?

                テレビやコンピュータディスプレイなどの「ラスタースキャン」方式での画面表示では、
                「画面上である瞬間に光っているのは「点」一箇所だけ」で、
                「それを左上から始めて、右方向にいって画面端にきたら次のラインをまた左から右へ」と繰り返します。

                たとえば、解像度が320x240で60fpsなら、
                1つの点が光っているのは約160nsです。
                これを320回繰り返して、帰線期間を入れて、横1ライン320ドットの表示にかかる時間が160ns×320+α=約64μsになります。
                さらにこれを縦方向に240回繰り返して、帰線期間を入れると、1画面縦240ラインの表示にかかる時間が64μs×240+β=約17msかかる、
                といった形で1走査(1画面の表示)になり、また左上に戻ってこれをずっと繰り返します。

                ここで、「エミュレータではレンダリングを終わらせてから表示」を行うと、
                「表示」を指示してから、「画面を光らせ始める」ことになりますから、
                「実機ではレンダリングしながら表示」に比べると、1走査分遅れることになります。
                実際には、「表示を指示した、ちょうどピッタリのタイミングで、左上からの走査が始まる」とは限りませんから、
                タイミングが悪かった場合も考えると、「1~2フレーム遅れる」という元コメントの主張になります。

                たとえ、ダブルバッファリングを行わずに、
                「ライン単位で表示完了したラインから画面表示のフレームバッファに転送する」ようにしたとしても、
                エミュレータ内部の「画面操作エミュレーションのタイミング」と
                実際の「画面表示の走査タイミング」が同期しているわけではありませんから、
                最短なら1ラインの64μ秒の遅れですみますが、最大で1フレームの遅れが発生します
                (書き換えたラインが運悪く表示直後だった場合、結局1走査待つことになる)
                ので、それでも「0~1フレーム遅れる」ことになります。

                でもって、それをやっちゃうと画面表示のタイミングのズレで「ティアリング」が発生しますから、
                普通はダブルバッファリングするんじゃないかな。

                親コメント
              • 「ちょっと待ってくれ、例えばどのゲームのどの部分がどういう状況でどれだけ遅れるのか、
                 具体的な例を挙げてもらえないか?」
              • by Anonymous Coward

                私も、そのへんはソフト側で感覚的に調整すればいいだけのような気が
                します。

                実機の動作に拘る人は実機を動態保存すればいいんで、なんで「完全に再現」
                に固執するのか微妙に解らなかったりします。

              • by Anonymous Coward on 2010年03月04日 10時44分 (#1727288)
                > 実際には、「表示を指示した、ちょうどピッタリのタイミングで、左上からの走査が始まる」とは限りませんから、

                ええとですね、エミュレータはディスプレイの垂直同期信号と同期して動きます。
                nフレーム目の出力が終わり垂直帰線期間に入ると、エミュレータは一瞬でターゲットVDPのエミュレーションをし、n+1フレーム目のレンダリング結果をホストのフレームバッファに書き込みます。n+1フレームの表示の開始時にはレンダリングは終了しています。(AZUCO氏の説明とまったく同じです)

                > ここで、「エミュレータではレンダリングを終わらせてから表示」を行うと、
                >「表示」を指示してから、「画面を光らせ始める」ことになりますから、

                エミュレータは表示は指示しません。表示は1/60毎にホストPCのビデオコントローラが勝手に行います。
                エミュレータは垂直帰線期間中、つまり画面に何も表示されていない間に、次のフレームの描画の開始に間に合うようにレンダリングするだけです。

                >「実機ではレンダリングしながら表示」に比べると、1走査分遅れることになります。

                遅れないことは以上の説明でおわかりいただけたと思います。
                親コメント
              • by Anonymous Coward

                Vブランクに入ってから、Vブランクを抜けるまでの間に

                ・入力情報の取得
                ・内部状態の更新
                ・フレームバッファ書き換え
                ・フレームバッファのフリップ(画像コンバート含む)

                まで済ませてしまえば、遅れないですね。
                きょうびのハードウェアでネオジオをエミュレーションするぐらいであれば、
                余裕でしょう。

              • by Anonymous Coward

                どこにぶら下げればいいのかわからんけど。

                要は液晶とCRTの方式を比べてホールド形式(だっけ?)はどうしてもスキャンライン形式と比べて一フレーム遅延するみたいな話をしたいのかなこの人は。そういう話ならまあそうですねとしか言えないが。

              • by Anonymous Coward
                そういう手合い完全に再現<strong>してほしくない<strong>んですよ
                なにがしかの差がないと実機を持ってない人をバカにすることができませんから
              • V-Sync時に表示されるか、H-Sync時に表示されるか?って事を言いたいんじゃないかと。
                走査線が一画面書き終わってから表示なのか、1ライン(より正確にはもっと少ない時間で横に書いていく)で表示なのか・・・っていう。

                ラスタースクロールの場合は1ライン書き終わりの割り込みでグラフィックコントローラ叩いて表示をスクロールさせてるわけで。

                もっと言うとX68000等々で使われてたスプライトダブラなんかは画面の上半分をハードウェアがモニタに出力し終わった瞬間に
                スプライト関係のハードウェア叩いて表示するパターンや位置を切り替えてますね。

                #FF6はH-Sync割り込みでパレット書き換えてSFCの同時発色を超えたとか聞いたなぁ・・・

                親コメント
              • なるほど。納得しました。
                そうなると、ラスタスクロールのことなどを考えると、VDPだけでなく、
                「CPUを含めた全システムの、1フレーム=17ms間の挙動のエミュレーション」を、
                「帰線期間、およそ0.8ms間に行う」必要がありますね。

                実機の20倍超の速度でエミュレーションができるなら、フレーム遅延無しにできるってことで。
                NEOGEOぐらいなら可能そうですが、
                今時の「ゲーム機のエミュレーションはこうなっている」と一般論として語れるものなのでしょうか?

                #最近の情勢に詳しくないせいか、にわかに信じがたかったり。

                あと、

                実機が画面上半分のレンダリング中にあったリアルタイムな外部入力を処理し、それを下半分のレンダリングに反映させる場合は除きますが、そのようなゲームは存在しないでしょう

                なんかは、結構あるような気がします。ていうか「入力→処理→出力」の1サイクルが画面表示と同期してないようなプログラムだと、当然「反映される」挙動になりますよね。そうならないようにするためには、処理を画面表示と同期させて、スプライトの座標設定をわざわざ帰線期間の間に行う、という一手間が必要。

                もっとも、フレーム遅延が問題になるようなシューティングや格ゲーなんかでは速度調整を行なわないなんてことはないでしょうし、
                非リアルタイム系のRPGだとかシミュレーションだとかでは速度調整してないでしょうけど、そもそもフレーム遅延が問題になることもなさそうですし、
                実質問題にはならないと思いますけど。

                親コメント
              • そういう手合いは完全に再現してほしくないんですよ
                なにがしかの差がないと実機を持ってない人をバカにすることができませんから

                まああたしも実機の方を好みはしますが
                違和感を感じるのは遅延とかではなくコントローラの感触ですな
                変換コネクタメーカーの皆様お世話になっております
                って言うとまたそこで遅延が、って怒られるのよね

              • by Anonymous Coward
                > そうなると、ラスタスクロールのことなどを考えると、VDPだけでなく、
                > 「CPUを含めた全システムの、1フレーム=17ms間の挙動のエミュレーション」を、
                > 「帰線期間、およそ0.8ms間に行う」必要がありますね

                依存関係を満たしさえすればいいので「全システム」というわけではないですが、(実機がフレーム描画の裏で行っている作業はエミュでもそうできます)
                リアルタイム制約があってクリティカルな部分なのは確かです。

                > 今時の「ゲーム機のエミュレーションはこうなっている」と一般論として語れるものなのでしょうか?

                エミュレーションの正確さを重んじているもの
              • by Anonymous Coward

                と言うより、その話とエミュレータにおけるレンダリング処理の話を完全に混同しているようにしか見えないのですが。

                まあ、「安直に」ダブルバッファリングすれば、「理論上は」1フレーム遅れますけど、回避方法はいくらでもあるし、そもそも実機からしてフレームバッファ機だったりダブルバッファリングしていたら何の問題も無い訳で。

                #NEOGEOはラインバッファスプライトですけど、その程度の無遅延エミュレーションが今時のハードで出来ないとはとても…

              • by Anonymous Coward
                > まあ、「安直に」ダブルバッファリングすれば、「理論上は」1フレーム遅れますけど、

                遅れるというのが、何が何から遅れるのか理解していますか?
              • そうですw正解ですw
                何度もそう説明してるのにw

                みなさんなじみが薄いと思いますが

                実際の時間の流れ
                実機の時間の流れ
                VMの時間の流れ

                これらの時間はいくつかの要素の閾値によって、関係したり、しなかったりするのです。

                VMの処理が十分に速ければ、VMの時間はかなり自由度が高まります。
                (例えば早送りすら出来る)

                遅延云々言っている人は、それらVMの処理が「実機での1フレームで、VMの1フレームが終わらない」と思い込んでいるのだと思います。
                親コメント
              • by Anonymous Coward

                ええ。
                遅延が遅延がと大騒ぎしているACは、「ゲーム処理上の」1フレーム描画から、「実際の表示装置に送られるまでの」間に、ラインバッファとフレームバッファの違いのせいで、実機よりもレンダリングウェイトが入るんじゃないの? という話をしたいんだと思います。
                要は、データを表示装置に逐次送信できるラインバッファスプライトと違い、フレームバッファ上に一度全スプライトを描画した上で(=1フレーム分の処理が終わった後で)送信しなきゃならない、だから遅延するんだ、と言う論法だと思います。
                「ゲーム側が行っているのは、オブジェクトの『位置を決定』す

              • by Anonymous Coward
                逆に本物に近づけるために意図的に遅くするソフトとかありますよね実際
              • by Anonymous Coward

                もちろん遅延しますよ。
                「全てのレンダー要素が揃った所」というのが実機での表示がし終わったタイミングですから。

              • もちろん遅延しません。
                実機での表示を行う前に「全てのレンダー要素」を揃えるので。
                親コメント
              • by Anonymous Coward
                遅延という言葉の定義を見直したいんだけど、ゲーム機のエミュレータに限定して言えば、

                - 実機でnフレーム目の画面が表示されて、
                - プレイヤーがその画面を見て、それに対して何かしらの操作をして、
                - その操作の結果が(n+1)フレーム目に反映される

                といった感じで、プレイヤーの操作が画面に対して遅延なく反映されるか、ということですよね?

                - エミュレータの実行環境でnフレーム目の画面が表示され終わって、
                - プレイヤーがその画面を見て、それに対して何かしらの操作をして、
                - エミュレータがその入力を取得して、
                - (n+1)フレーム目の期間だけエミュレータの仮想環境を駆動して、
                - それに応じてレンダリングして、
                - レンダリング結果のフリップが(n+1)フレーム目の表示開始に間に合えば、

                エミュレータだからって遅延する訳じゃないでしょう、ってことじゃない?
              • by Anonymous Coward

                エミュレータの動作はこうです

                ----------------------------------------
                フレーム1表示期間
                ・プレイヤー操作入力
                ・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)
                ×ラスター処理(スクロール、パレット書き換えなど)
                ----------------------------------------
                フレーム1垂直帰線期間
                ・スプライトテーブル書き換え
                ・BG書き換え
                ・パレット書き換え
                ○フレーム2ラスター処理(スクロール、パレット書き換えなど)
                ----------------------------------------

                > ラスター処理は、前のフレームで生成したイメージへの操作であるため、

                違います。実機ではH-Blank

              • by Anonymous Coward

                > ○フレーム2ラスター処理(スクロール、パレット書き換えなど)

                どうもこのへんに誤解の源泉があるようですから、もう少し正確に書きますと

                ----------------------------------------
                フレーム1表示期間および垂直帰線期間(リアルタイム)
                ・プレイヤー操作入力
                ・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)
                ・スプライトテーブル書き換え
                ・BG書き換え
                ・パレット書き換え
                ・フレーム2レンダリング
                ・フレーム2ラスター処理(スクロール、パレット書き換えなど)
                ----------------------------------------

                リアルタイムの1フレームの間にエミュレータは必要な処理をこなせばよく、1/60秒以上の精度の正確な動作は求められていません。
                むしろ垂直帰線期間の始まりで同期していると考えればいいかもしれません。

              • by Anonymous Coward
                > 対して、これをフレームバッファ式のアーキテクチャで実現しようとすると、フレーム1でのプレイヤー操作入力に対して表示するビットマップの内容を決定できるのはフレーム2のラスター処理を終えた時点です。それからイメージをレンダリングし、テクスチャとしてVRAMに転送し、描画したあとページをフリップすることとなるため、プレイヤー操作入力の結果としての表示の遅延はラインバッファのものに比べて大きいものなります。解決する方法はありますが、「内部で仮想VRAMを持っていて、フレームの最後にVRAM内容を転送するだけ」というレベルの仕事では済みません。
              • by Anonymous Coward

                エミュレータの動作はこうです

                ----------------------------------------
                フレーム1表示期間
                ・プレイヤー操作入力
                ・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)
                ×ラスター処理(スクロール、パレット書き換えなど)
                ----------------------------------------
                フレーム1垂直帰線期間
                ・スプライトテーブル書き換え
                ・BG書き換え
                ・パレット書き換え
                ○フレーム2ラスター処理(スクロール、パレット書き換えなど)
                ----------------------------------------

                ラスター処理のシーケンスを変更するにはオリジナルのプログラムの変更が必要になると思いますが、エミュレータでそんなことやっているのですか?

              • by Anonymous Coward
                > ラスター処理のシーケンスを変更するにはオリジナルのプログラムの変更が必要になると思いますが、エミュレータでそんなことやっているのですか?

                シーケンスではないので。
                ラスター処理はH-SYNC割り込み駆動ですから、それをエミュレートしているだけです。
              • by Anonymous Coward
                H-SYNC割り込みの初期化や割り込みルーチンに渡す値等、割り込み処理の外で行うものだしシーケンスは存在するのではないですか?
              • by Anonymous Coward
                > H-SYNC割り込みの初期化や割り込みルーチンに渡す値等、割り込み処理の外で行うものだしシーケンスは存在するのではないですか?

                通常のプログラムシーケンスはありますが、それはそのままエミュレートします。
                ただし、実機が画面のリアルタイムのフレームの描画中にやる処理を、エミュレータはそれより前、つまりリアルタイムの直前のフレームのH-BLANK中にやってしまいます。
                実機がリアルタイムのH-BLANK中にやる処理は、エミュレータでもリアルタイムのH-BLANK中にやりますので、シンプルに実装すれば、全処理をリアルタイムのH-BLANK中に押し込めることになります。(勘の鋭い方が指摘なさったとおりです)
              • by Anonymous Coward
                NEOGEOに搭載されてた12MHzの68KでH-BLANK中にそれほどあれこれ処理できる訳はないし、H-BLANK中に処理する値などは大凡割り込み処理の前に生成していると思いますが、その生成処理がオリジナルのプログラムでどのタイミングで行われているか特定できない限り、安易に割り込みのタイミングなど変更できないと思いますが。
              • by Anonymous Coward
                > その生成処理がオリジナルのプログラムでどのタイミングで行われているか特定できない限り、

                タイミングではなく依存関係がわかれば十分です。
              • by Anonymous Coward
                依存関係というのは各アプリケーション個別のものではないですか? それか、アプリケーション毎に応じた個別対応という話ですか?
              • by Anonymous Coward
                > 依存関係というのは各アプリケーション個別のものではないですか?

                個別ではなく、ゲームの超基本的な作法で決まりますから、すべてのゲームで共通です。

                あるフレームのラスター処理に必要なデータ(ラスタースクロールオフセットやカラーパレットなど)は、そのフレームのリアルタイム開始時刻Tにはすべて揃っています。
                エミュレータのCPUエミュレーションは実機より必ず高速ですから、データが揃うリアルタイム時刻T'はTより前になります。
                T'からTの間に、エミュレータは1画面をフレームバッファにレンダー(+ラスター処理)しVRAMに転送すればよいです。
        • これが本当の「フレームの元」。

          #誰もが思いつきそうなネタで恥ずかしいのでAC。

        • by Anonymous Coward

          あの当時のスペックのマシンなんて変態ハードでも余裕でエミュできますy

身近な人の偉大さは半減する -- あるアレゲ人

処理中...