アカウント名:
パスワード:
PS3/PSPにNEOGEOアーカイブスができて、過去のNEOGEOソフトを遊べるっていう噂が出てますね本当だとうれしい
Wiiだと既にバーチャルコンソール化 [snkplaymore.co.jp]されていますね。流石にプログラムそのままではないでしょうが、Xbox 360のXbox Live ArcadeでもいくつかNEO GEO用ソフトを見かけますし、PS3の性能だったら完全再現も難しくないんじゃないですかね。
実機 V-Blank-In VM 処理開始 VM V-Blank-Out VM V-Blank-In 描画処理>BLT VM 処理終了実機 V-Blank-Out
見方が分かりません。VMって何ですか? あと、プレイヤーの入力、入力に対するMPUの処理、ラスタースクロールの処理なんかはどこになりますか?
実機はVDPの出力を即表示させてますが、エミュレータはVDPの出力を一旦仮想ディスプレイとして裏のフレームバッファに書いて、その処理が終わってから表示対象のハードウェアにあわせて画像のコンバートをかけているので最低でも1~2フレーム分は遅れて表示されます。
遅延は発生しますよ。ビデオゲームの多くは表示期間と垂直帰線期間を合わせたフレームという単位で動かしているものが一般的ですが、そのフレームのなかでのプロセッサの処理は、大よそ以下の通りとなります。
----------------------------------------フレーム1表示期間・プレイヤー操作入力・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)・ラスター処理(スクロール、パレット書き換えなど)----------------------------------------フレーム1垂直帰線期間・スプライトテーブル書き換え・BG書き換え・パレット書き換え----------------------------------------フレーム2
間違いです。
フレーム毎に・実機ではレンダリングしながら表示・エミュレータではレンダリングを終わらせてから表示という違いだけです。ですから実機とエミュレータでディスプレイに表示されるものに差は出ません。(実機が画面上半分のレンダリング中にあったリアルタイムな外部入力を処理し、それを下半分のレンダリングに反映させる場合は除きますが、そのようなゲームは存在しないでしょう)
> 最低でも1~2フレーム分は遅れて表示されます。
遅れとおっしゃいますが、何が何から遅れるのか理解して書いていますか?
実機でのラスターの処理は次のフレームですよ。その(MPUの)処理が終了するまで画面イメージのビットマップは決定できないと思いますが、それから表示を行うと遅延は生じないですか?プレイヤーの入力から画面への表示まで、遅延は大きいのではないですか?
実機とエミュレーターで処理の順番が違う以上、発生するウェイトによって遅延が出るのは不可避ですね。この遅延というのは実機と比べてタイミングが遅れるっていう意味で、処理能力とは関係ない。だから「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フレーム遅れる」ことになります。
でもって、それをやっちゃうと画面表示のタイミングのズレで「ティアリング」が発生しますから、普通はダブルバッファリングするんじゃないかな。
私も、そのへんはソフト側で感覚的に調整すればいいだけのような気がします。
実機の動作に拘る人は実機を動態保存すればいいんで、なんで「完全に再現」に固執するのか微妙に解らなかったりします。
Vブランクに入ってから、Vブランクを抜けるまでの間に
・入力情報の取得・内部状態の更新・フレームバッファ書き換え・フレームバッファのフリップ(画像コンバート含む)
まで済ませてしまえば、遅れないですね。きょうびのハードウェアでネオジオをエミュレーションするぐらいであれば、余裕でしょう。
どこにぶら下げればいいのかわからんけど。
要は液晶とCRTの方式を比べてホールド形式(だっけ?)はどうしてもスキャンライン形式と比べて一フレーム遅延するみたいな話をしたいのかなこの人は。そういう話ならまあそうですねとしか言えないが。
V-Sync時に表示されるか、H-Sync時に表示されるか?って事を言いたいんじゃないかと。走査線が一画面書き終わってから表示なのか、1ライン(より正確にはもっと少ない時間で横に書いていく)で表示なのか・・・っていう。
ラスタースクロールの場合は1ライン書き終わりの割り込みでグラフィックコントローラ叩いて表示をスクロールさせてるわけで。
もっと言うとX68000等々で使われてたスプライトダブラなんかは画面の上半分をハードウェアがモニタに出力し終わった瞬間にスプライト関係のハードウェア叩いて表示するパターンや位置を切り替えてますね。
#FF6はH-Sync割り込みでパレット書き換えてSFCの同時発色を超えたとか聞いたなぁ・・・
なるほど。納得しました。そうなると、ラスタスクロールのことなどを考えると、VDPだけでなく、「CPUを含めた全システムの、1フレーム=17ms間の挙動のエミュレーション」を、「帰線期間、およそ0.8ms間に行う」必要がありますね。
実機の20倍超の速度でエミュレーションができるなら、フレーム遅延無しにできるってことで。NEOGEOぐらいなら可能そうですが、今時の「ゲーム機のエミュレーションはこうなっている」と一般論として語れるものなのでしょうか?
#最近の情勢に詳しくないせいか、にわかに信じがたかったり。
あと、
実機が画面上半分のレンダリング中にあったリアルタイムな外部入力を処理し、それを下半分のレンダリングに反映させる場合は除きますが、そのようなゲームは存在しないでしょう
なんかは、結構あるような気がします。ていうか「入力→処理→出力」の1サイクルが画面表示と同期してないようなプログラムだと、当然「反映される」挙動になりますよね。そうならないようにするためには、処理を画面表示と同期させて、スプライトの座標設定をわざわざ帰線期間の間に行う、という一手間が必要。
もっとも、フレーム遅延が問題になるようなシューティングや格ゲーなんかでは速度調整を行なわないなんてことはないでしょうし、非リアルタイム系のRPGだとかシミュレーションだとかでは速度調整してないでしょうけど、そもそもフレーム遅延が問題になることもなさそうですし、実質問題にはならないと思いますけど。
そういう手合いは完全に再現してほしくないんですよなにがしかの差がないと実機を持ってない人をバカにすることができませんから
まああたしも実機の方を好みはしますが違和感を感じるのは遅延とかではなくコントローラの感触ですな変換コネクタメーカーの皆様お世話になっておりますって言うとまたそこで遅延が、って怒られるのよね
と言うより、その話とエミュレータにおけるレンダリング処理の話を完全に混同しているようにしか見えないのですが。
まあ、「安直に」ダブルバッファリングすれば、「理論上は」1フレーム遅れますけど、回避方法はいくらでもあるし、そもそも実機からしてフレームバッファ機だったりダブルバッファリングしていたら何の問題も無い訳で。
#NEOGEOはラインバッファスプライトですけど、その程度の無遅延エミュレーションが今時のハードで出来ないとはとても…
ええ。遅延が遅延がと大騒ぎしているACは、「ゲーム処理上の」1フレーム描画から、「実際の表示装置に送られるまでの」間に、ラインバッファとフレームバッファの違いのせいで、実機よりもレンダリングウェイトが入るんじゃないの? という話をしたいんだと思います。要は、データを表示装置に逐次送信できるラインバッファスプライトと違い、フレームバッファ上に一度全スプライトを描画した上で(=1フレーム分の処理が終わった後で)送信しなきゃならない、だから遅延するんだ、と言う論法だと思います。「ゲーム側が行っているのは、オブジェクトの『位置を決定』す
もちろん遅延しますよ。「全てのレンダー要素が揃った所」というのが実機での表示がし終わったタイミングですから。
エミュレータの動作はこうです
----------------------------------------フレーム1表示期間・プレイヤー操作入力・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など) ×ラスター処理(スクロール、パレット書き換えなど) ----------------------------------------フレーム1垂直帰線期間・スプライトテーブル書き換え・BG書き換え・パレット書き換え ○フレーム2ラスター処理(スクロール、パレット書き換えなど) ----------------------------------------
> ラスター処理は、前のフレームで生成したイメージへの操作であるため、
違います。実機ではH-Blank
> ○フレーム2ラスター処理(スクロール、パレット書き換えなど)
どうもこのへんに誤解の源泉があるようですから、もう少し正確に書きますと
----------------------------------------フレーム1表示期間および垂直帰線期間(リアルタイム)・プレイヤー操作入力・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)・スプライトテーブル書き換え・BG書き換え・パレット書き換え・フレーム2レンダリング・フレーム2ラスター処理(スクロール、パレット書き換えなど)----------------------------------------
リアルタイムの1フレームの間にエミュレータは必要な処理をこなせばよく、1/60秒以上の精度の正確な動作は求められていません。むしろ垂直帰線期間の始まりで同期していると考えればいいかもしれません。
エミュレータの動作はこうです----------------------------------------フレーム1表示期間・プレイヤー操作入力・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)×ラスター処理(スクロール、パレット書き換えなど)----------------------------------------フレーム1垂直帰線期間・スプライトテーブル書き換え・BG書き換え・パレット書き換え○フレーム2ラスター処理(スクロール、パレット書き換えなど)----------------------------------------
----------------------------------------フレーム1表示期間・プレイヤー操作入力・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)×ラスター処理(スクロール、パレット書き換えなど)----------------------------------------フレーム1垂直帰線期間・スプライトテーブル書き換え・BG書き換え・パレット書き換え○フレーム2ラスター処理(スクロール、パレット書き換えなど)----------------------------------------
ラスター処理のシーケンスを変更するにはオリジナルのプログラムの変更が必要になると思いますが、エミュレータでそんなことやっているのですか?
これが本当の「フレームの元」。
#誰もが思いつきそうなネタで恥ずかしいのでAC。
あの当時のスペックのマシンなんて変態ハードでも余裕でエミュできますy
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
PS3でネオジオソフトがプレイ可能? (スコア:3, 興味深い)
PS3/PSPにNEOGEOアーカイブスができて、過去のNEOGEOソフトを遊べるっていう噂が出てますね
本当だとうれしい
Re: (スコア:1, 参考になる)
Wiiだと既にバーチャルコンソール化 [snkplaymore.co.jp]されていますね。
流石にプログラムそのままではないでしょうが、Xbox 360のXbox Live ArcadeでもいくつかNEO GEO用ソフトを見かけますし、PS3の性能だったら完全再現も難しくないんじゃないですかね。
Re:PS3でネオジオソフトがプレイ可能? (スコア:0)
Re:PS3でネオジオソフトがプレイ可能? (スコア:2)
だからむしろグラフィック的には負荷は低いと思います。
Re: (スコア:0)
Re:PS3でネオジオソフトがプレイ可能? (スコア:2)
実機 V-Blank-In
VM 処理開始
VM V-Blank-Out
VM V-Blank-In
描画処理>BLT
VM 処理終了
実機 V-Blank-Out
特に発生する要因は無いと思いますが・・・
Re: (スコア:0)
Re: (スコア:0)
見方が分かりません。VMって何ですか? あと、プレイヤーの入力、入力に対するMPUの処理、ラスタースクロールの処理なんかはどこになりますか?
Re: (スコア:0)
実機はVDPの出力を即表示させてますが、エミュレータはVDPの出力を一旦仮想ディスプレイ
として裏のフレームバッファに書いて、その処理が終わってから表示対象のハードウェアに
あわせて画像のコンバートをかけているので最低でも1~2フレーム分は遅れて表示されます。
Re: (スコア:0)
遅延は発生しますよ。
ビデオゲームの多くは表示期間と垂直帰線期間を合わせたフレームという単位で動かしているものが一般的ですが、そのフレームのなかでのプロセッサの処理は、大よそ以下の通りとなります。
----------------------------------------
フレーム1表示期間
・プレイヤー操作入力
・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)
・ラスター処理(スクロール、パレット書き換えなど)
----------------------------------------
フレーム1垂直帰線期間
・スプライトテーブル書き換え
・BG書き換え
・パレット書き換え
----------------------------------------
フレーム2
Re:PS3でネオジオソフトがプレイ可能? (スコア:2)
むしろフレームをまたいで描画する理由がわかりませんが。
何故1-2フレームも後で処理するのですか?
Re:PS3でネオジオソフトがプレイ可能? (スコア:2, すばらしい洞察)
間違いです。
フレーム毎に
・実機ではレンダリングしながら表示
・エミュレータではレンダリングを終わらせてから表示
という違いだけです。ですから実機とエミュレータでディスプレイに表示されるものに差は出ません。
(実機が画面上半分のレンダリング中にあったリアルタイムな外部入力を処理し、それを下半分のレンダリングに反映させる場合は除きますが、そのようなゲームは存在しないでしょう)
> 最低でも1~2フレーム分は遅れて表示されます。
遅れとおっしゃいますが、何が何から遅れるのか理解して書いていますか?
Re: (スコア:0)
Re:PS3でネオジオソフトがプレイ可能? (スコア:2)
むしろなんで頑なにそんなに遅延すると思ってるのか謎。
Re: (スコア:0)
エミュレータはフレームバッファにレンダリングしている時にラスター割り込みもエミュレートしますので問題はありません。
Re: (スコア:0)
実機でのラスターの処理は次のフレームですよ。
その(MPUの)処理が終了するまで画面イメージのビットマップは決定できないと思いますが、それから表示を行うと遅延は生じないですか?
プレイヤーの入力から画面への表示まで、遅延は大きいのではないですか?
Re:PS3でネオジオソフトがプレイ可能? (スコア:2)
とりあえず、VMの処理時間が限りなくゼロに近いと仮定して色々考えられてはどうですか?
それでも遅延が出るのなら、それは絶対に出る遅延なんでしょう。
ラスターの値をライン毎に記憶しておいて
全てのレンダー要素が揃った所で
その記憶しておいた値を使ってレンダリング
この間の時間がゼロだとしても遅延します?
Re: (スコア:0)
Re: (スコア:0)
実機とエミュレーターで処理の順番が違う以上、発生するウェイトによって遅延が出るのは不可避ですね。
この遅延というのは実機と比べてタイミングが遅れるっていう意味で、処理能力とは関係ない。
だから「VMの処理時間がゼロ」では間に合わない。
マイナスじゃないと。
ただそれが深刻な問題かといわれると、全くそうは思いませんけど。
Re:PS3でネオジオソフトがプレイ可能? (スコア:2)
PS3では表示中のフレームバッファを書き換えられない、と仮定すれば、エミュレータが頑張って書いてる仮想フレームバッファから本物のフレームバッファ(裏)へフレームの途中でも頻繁に変換するとしても、変換に加えて表と裏を切り替える時間分は論理的にどうしても遅延しますね。数十nsくらいでしょうか。
Re:PS3でネオジオソフトがプレイ可能? (スコア:1)
> フレーム毎に
> ・実機ではレンダリングしながら表示
> ・エミュレータではレンダリングを終わらせてから表示
> という違いだけです。
「表示」を行ったら、一瞬で画面に反映されると勘違いしてませんか?
テレビやコンピュータディスプレイなどの「ラスタースキャン」方式での画面表示では、
「画面上である瞬間に光っているのは「点」一箇所だけ」で、
「それを左上から始めて、右方向にいって画面端にきたら次のラインをまた左から右へ」と繰り返します。
たとえば、解像度が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フレーム遅れる」ことになります。
でもって、それをやっちゃうと画面表示のタイミングのズレで「ティアリング」が発生しますから、
普通はダブルバッファリングするんじゃないかな。
ご冗談でしょう、ファインマンさん (スコア:0)
具体的な例を挙げてもらえないか?」
Re: (スコア:0)
私も、そのへんはソフト側で感覚的に調整すればいいだけのような気が
します。
実機の動作に拘る人は実機を動態保存すればいいんで、なんで「完全に再現」
に固執するのか微妙に解らなかったりします。
Re:PS3でネオジオソフトがプレイ可能? (スコア:1, 興味深い)
ええとですね、エミュレータはディスプレイの垂直同期信号と同期して動きます。
nフレーム目の出力が終わり垂直帰線期間に入ると、エミュレータは一瞬でターゲットVDPのエミュレーションをし、n+1フレーム目のレンダリング結果をホストのフレームバッファに書き込みます。n+1フレームの表示の開始時にはレンダリングは終了しています。(AZUCO氏の説明とまったく同じです)
> ここで、「エミュレータではレンダリングを終わらせてから表示」を行うと、
>「表示」を指示してから、「画面を光らせ始める」ことになりますから、
エミュレータは表示は指示しません。表示は1/60毎にホストPCのビデオコントローラが勝手に行います。
エミュレータは垂直帰線期間中、つまり画面に何も表示されていない間に、次のフレームの描画の開始に間に合うようにレンダリングするだけです。
>「実機ではレンダリングしながら表示」に比べると、1走査分遅れることになります。
遅れないことは以上の説明でおわかりいただけたと思います。
Re: (スコア:0)
Vブランクに入ってから、Vブランクを抜けるまでの間に
・入力情報の取得
・内部状態の更新
・フレームバッファ書き換え
・フレームバッファのフリップ(画像コンバート含む)
まで済ませてしまえば、遅れないですね。
きょうびのハードウェアでネオジオをエミュレーションするぐらいであれば、
余裕でしょう。
Re: (スコア:0)
どこにぶら下げればいいのかわからんけど。
要は液晶とCRTの方式を比べてホールド形式(だっけ?)はどうしてもスキャンライン形式と比べて一フレーム遅延するみたいな話をしたいのかなこの人は。そういう話ならまあそうですねとしか言えないが。
Re: (スコア:0)
なにがしかの差がないと実機を持ってない人をバカにすることができませんから
Re:PS3でネオジオソフトがプレイ可能? (スコア:1)
V-Sync時に表示されるか、H-Sync時に表示されるか?って事を言いたいんじゃないかと。
走査線が一画面書き終わってから表示なのか、1ライン(より正確にはもっと少ない時間で横に書いていく)で表示なのか・・・っていう。
ラスタースクロールの場合は1ライン書き終わりの割り込みでグラフィックコントローラ叩いて表示をスクロールさせてるわけで。
もっと言うとX68000等々で使われてたスプライトダブラなんかは画面の上半分をハードウェアがモニタに出力し終わった瞬間に
スプライト関係のハードウェア叩いて表示するパターンや位置を切り替えてますね。
#FF6はH-Sync割り込みでパレット書き換えてSFCの同時発色を超えたとか聞いたなぁ・・・
Re:PS3でネオジオソフトがプレイ可能? (スコア:1)
なるほど。納得しました。
そうなると、ラスタスクロールのことなどを考えると、VDPだけでなく、
「CPUを含めた全システムの、1フレーム=17ms間の挙動のエミュレーション」を、
「帰線期間、およそ0.8ms間に行う」必要がありますね。
実機の20倍超の速度でエミュレーションができるなら、フレーム遅延無しにできるってことで。
NEOGEOぐらいなら可能そうですが、
今時の「ゲーム機のエミュレーションはこうなっている」と一般論として語れるものなのでしょうか?
#最近の情勢に詳しくないせいか、にわかに信じがたかったり。
あと、
なんかは、結構あるような気がします。ていうか「入力→処理→出力」の1サイクルが画面表示と同期してないようなプログラムだと、当然「反映される」挙動になりますよね。そうならないようにするためには、処理を画面表示と同期させて、スプライトの座標設定をわざわざ帰線期間の間に行う、という一手間が必要。
もっとも、フレーム遅延が問題になるようなシューティングや格ゲーなんかでは速度調整を行なわないなんてことはないでしょうし、
非リアルタイム系のRPGだとかシミュレーションだとかでは速度調整してないでしょうけど、そもそもフレーム遅延が問題になることもなさそうですし、
実質問題にはならないと思いますけど。
猫にボタンを押されました (スコア:0)
そういう手合いは完全に再現してほしくないんですよ
なにがしかの差がないと実機を持ってない人をバカにすることができませんから
まああたしも実機の方を好みはしますが
違和感を感じるのは遅延とかではなくコントローラの感触ですな
変換コネクタメーカーの皆様お世話になっております
って言うとまたそこで遅延が、って怒られるのよね
Re: (スコア:0)
> 「CPUを含めた全システムの、1フレーム=17ms間の挙動のエミュレーション」を、
> 「帰線期間、およそ0.8ms間に行う」必要がありますね
依存関係を満たしさえすればいいので「全システム」というわけではないですが、(実機がフレーム描画の裏で行っている作業はエミュでもそうできます)
リアルタイム制約があってクリティカルな部分なのは確かです。
> 今時の「ゲーム機のエミュレーションはこうなっている」と一般論として語れるものなのでしょうか?
エミュレーションの正確さを重んじているもの
Re: (スコア:0)
と言うより、その話とエミュレータにおけるレンダリング処理の話を完全に混同しているようにしか見えないのですが。
まあ、「安直に」ダブルバッファリングすれば、「理論上は」1フレーム遅れますけど、回避方法はいくらでもあるし、そもそも実機からしてフレームバッファ機だったりダブルバッファリングしていたら何の問題も無い訳で。
#NEOGEOはラインバッファスプライトですけど、その程度の無遅延エミュレーションが今時のハードで出来ないとはとても…
Re: (スコア:0)
遅れるというのが、何が何から遅れるのか理解していますか?
Re:PS3でネオジオソフトがプレイ可能? (スコア:2)
何度もそう説明してるのにw
みなさんなじみが薄いと思いますが
実際の時間の流れ
実機の時間の流れ
VMの時間の流れ
これらの時間はいくつかの要素の閾値によって、関係したり、しなかったりするのです。
VMの処理が十分に速ければ、VMの時間はかなり自由度が高まります。
(例えば早送りすら出来る)
遅延云々言っている人は、それらVMの処理が「実機での1フレームで、VMの1フレームが終わらない」と思い込んでいるのだと思います。
Re: (スコア:0)
ええ。
遅延が遅延がと大騒ぎしているACは、「ゲーム処理上の」1フレーム描画から、「実際の表示装置に送られるまでの」間に、ラインバッファとフレームバッファの違いのせいで、実機よりもレンダリングウェイトが入るんじゃないの? という話をしたいんだと思います。
要は、データを表示装置に逐次送信できるラインバッファスプライトと違い、フレームバッファ上に一度全スプライトを描画した上で(=1フレーム分の処理が終わった後で)送信しなきゃならない、だから遅延するんだ、と言う論法だと思います。
「ゲーム側が行っているのは、オブジェクトの『位置を決定』す
Re: (スコア:0)
Re: (スコア:0)
もちろん遅延しますよ。
「全てのレンダー要素が揃った所」というのが実機での表示がし終わったタイミングですから。
Re:PS3でネオジオソフトがプレイ可能? (スコア:2)
実機での表示を行う前に「全てのレンダー要素」を揃えるので。
Re: (スコア:0)
- 実機でnフレーム目の画面が表示されて、
- プレイヤーがその画面を見て、それに対して何かしらの操作をして、
- その操作の結果が(n+1)フレーム目に反映される
といった感じで、プレイヤーの操作が画面に対して遅延なく反映されるか、ということですよね?
- エミュレータの実行環境でnフレーム目の画面が表示され終わって、
- プレイヤーがその画面を見て、それに対して何かしらの操作をして、
- エミュレータがその入力を取得して、
- (n+1)フレーム目の期間だけエミュレータの仮想環境を駆動して、
- それに応じてレンダリングして、
- レンダリング結果のフリップが(n+1)フレーム目の表示開始に間に合えば、
エミュレータだからって遅延する訳じゃないでしょう、ってことじゃない?
Re: (スコア:0)
エミュレータの動作はこうです
----------------------------------------
フレーム1表示期間
・プレイヤー操作入力
・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)
×ラスター処理(スクロール、パレット書き換えなど)
----------------------------------------
フレーム1垂直帰線期間
・スプライトテーブル書き換え
・BG書き換え
・パレット書き換え
○フレーム2ラスター処理(スクロール、パレット書き換えなど)
----------------------------------------
> ラスター処理は、前のフレームで生成したイメージへの操作であるため、
違います。実機ではH-Blank
Re: (スコア:0)
> ○フレーム2ラスター処理(スクロール、パレット書き換えなど)
どうもこのへんに誤解の源泉があるようですから、もう少し正確に書きますと
----------------------------------------
フレーム1表示期間および垂直帰線期間(リアルタイム)
・プレイヤー操作入力
・ゲームロジック演算(自キャラ敵キャラの動き、当たり判定など)
・スプライトテーブル書き換え
・BG書き換え
・パレット書き換え
・フレーム2レンダリング
・フレーム2ラスター処理(スクロール、パレット書き換えなど)
----------------------------------------
リアルタイムの1フレームの間にエミュレータは必要な処理をこなせばよく、1/60秒以上の精度の正確な動作は求められていません。
むしろ垂直帰線期間の始まりで同期していると考えればいいかもしれません。
Re: (スコア:0)
Re: (スコア:0)
ラスター処理のシーケンスを変更するにはオリジナルのプログラムの変更が必要になると思いますが、エミュレータでそんなことやっているのですか?
Re: (スコア:0)
シーケンスではないので。
ラスター処理はH-SYNC割り込み駆動ですから、それをエミュレートしているだけです。
Re: (スコア:0)
Re: (スコア:0)
通常のプログラムシーケンスはありますが、それはそのままエミュレートします。
ただし、実機が画面のリアルタイムのフレームの描画中にやる処理を、エミュレータはそれより前、つまりリアルタイムの直前のフレームのH-BLANK中にやってしまいます。
実機がリアルタイムのH-BLANK中にやる処理は、エミュレータでもリアルタイムのH-BLANK中にやりますので、シンプルに実装すれば、全処理をリアルタイムのH-BLANK中に押し込めることになります。(勘の鋭い方が指摘なさったとおりです)
Re: (スコア:0)
Re: (スコア:0)
タイミングではなく依存関係がわかれば十分です。
Re: (スコア:0)
Re: (スコア:0)
個別ではなく、ゲームの超基本的な作法で決まりますから、すべてのゲームで共通です。
あるフレームのラスター処理に必要なデータ(ラスタースクロールオフセットやカラーパレットなど)は、そのフレームのリアルタイム開始時刻Tにはすべて揃っています。
エミュレータのCPUエミュレーションは実機より必ず高速ですから、データが揃うリアルタイム時刻T'はTより前になります。
T'からTの間に、エミュレータは1画面をフレームバッファにレンダー(+ラスター処理)しVRAMに転送すればよいです。
まだ言われてない? (スコア:0)
これが本当の「フレームの元」。
#誰もが思いつきそうなネタで恥ずかしいのでAC。
Re: (スコア:0)
あの当時のスペックのマシンなんて変態ハードでも余裕でエミュできますy