MSX3 Part2
■ このスレッドは過去ログ倉庫に格納されています
MSX3出すなら
ハイパーホームパソコンとか
パーソナルホームステーションとかカッコイイサブ名称をつけて欲しいな
キャッチコピーは「ホームコンピュータが変わる。MSX3が変える。」「妄想を超えた!」 昔MSX3はZ280で計画されてたんでしょ?幻のZ800(Z280)搭載唯一無二パソコンならすげーソソるんだよね。
R800は西さんとMSXユーザーの思いが深いし、ライセンス上も問題ないんだろうけど、
ザイログ製品ではないので他機種の人にはあんまりグッと来ない・・・ >993ナイコンさん2022/08/05(金) 18:50:34.66
>>>990
>ゲームで2つのCPU使うのって難しくね?
>並列処理できる部分って殆ど無い
>サウンド処理ぐらいか
キャラや弾の移動計算とか、独立している処理はいっぱいないか? >>10
ゲームプログラム作ったことある?
独立してないぞ
順番に処理していかないと整合性が取れなくなる アーケードゲームを作ったことはないが具体例をたのむ。 ゲームのキャラクタの動作を決めるのと、複数のスプライトに展開するので普通に分業してたぞ アーケード機って昔からマルチCPUのボード多かったと思うけど、
クロスバースイッチを独自実装したのだろうか。 >>13
それプロセス別に動かしてちゃんとプロセス間通信とかやってたんだろうな? >>8
そのキャッチ、1980年代感があっていいな >>15
昔のゲームはそんな風には出来ていないぞ
OSなんかないんだからな 順番に処理以前にMMU無しでマルチタスクは無謀だな。 この手の話はしたくないな
分かってない人だけで議論しても解決しないし、負けず嫌いが無駄にスレ伸ばすだけ サターンのツインCPUもほとんど使われなかったらしいからなあ
マルチタスクOSあってこその多コアじゃないの? 2Dゲームはゲームロジック処理自体が実行時間の大半なんで、並列処理するうま味はほとんど無い
これが3Dゲームになると、キャラやオブジェクトの移動や手を伸ばす等の変形処理自体に複雑な計算が必要なんで、並列処理の効果が大きい
背景オブジェクトとか完全に並列処理出来る サターンのツインCPUはバーチャファイターでシングルCPUの1.8倍位は性能を引き出してたらしい
ただし、使い方は片方が格闘ゲームロジックとキャラの変形処理とかして、もう片方はひたすら座標変換(透視変換)をしていた
で、ゲームロジックの方が先に終了するので、残りの時間は2つのCPUで座標変換する ちなみに座標変換の方はゲームに依存しないので、どのデベロッパーもそれだけは使ってたらしい
なので、ほとんど片方のCPUしか使ってなかったと言われてるけど、実際はもう片方が裏で平行して座標変換をしていたので、2つのCPUはちゃんと使われていたと言う話
これらはどこかのサターン解析記事の受け売り ライブラリに任せてたから自分でサブCPUを使った実感がないんだろうな いやいやサターンはエミュで見ればわかるけど片方のCPUはほとんど使われてない
多く使ってても20%程度だよ >>24
俺の聞いた話じゃ1.2倍程度って話だったぞ PC-88だってマルチCPUでしょ。当時のマルチCPUなんてだいたい、PPIなりUART同士でCPU間通信させてるんじゃ? 自転車で豪快に転んで大開脚で白パンティを披露している
セクシー眼鏡マダムの画像をお願いします。 >>29
それは絶体無い
他のゲームの正確な使用量は分からないけど、バーチャファイターは1.8倍だ
何しろ当時のサターンマガジン等で優秀なプログラマーなら1.7倍位は引き出せるだろうけど、バーチャは1.8倍近く引き出してると散々自慢気に話してたからなw
何しろ俺がその記事を当時見ている 何かマルチスレッドの並列処理を記事をざっくり読んで分かった気分になった奴が
全部同じだと思ってグラ2の話を振った感じだったので、触らないほうがよかった 格ゲーの場合は、最も負荷の高いキャラ同士で最も負荷の高いステージで計測しないと駄目だね
そこで処理落ちしないようにしてるから、軽いキャラ同士だとスッカスカになる そもそもエミュレーターでCPUの使用率なんて正確に分からんだろ
見てるのはWindows上のCPU使用率だ
ハード本来のCPU使用率が正確に分かるエミュレーターだったら、専用のCPU使用率モニターがあるはずだし、動かしてるゲームは処理落ちが完全再現されるはず
そんなの有るのか? ゲーム雑誌なんて相手がゲーマーだと思っていい加減なことを書いてるから >>32
え、でもバーチャファイター1のサターン版って30fpsしか出てないよw
単に無駄だらけだから1.8倍なんじゃ…w
バーチャファイター2は60fpsだけど BeOSみたいに横のLEDで使用率わかるようになっていればおもしろかったのにね。 >>37
バーチャファイター1はACも30fpsだよ。 >>37
サターン版のバーチャ1はテクスチャを全く使わずにポリゴンだけで顔とか模様(?)を付けていた
それがバーチャ2ではテクスチャーで模様を付けていたので、サターン版では実は2の方がポリゴン数は少ない
なので60fpsに出来たのだろう
1も2も忠実に移植したかったからそんな実装になってるのだろう OSないのにCPU使用率どうやって把握したんだろ。
計り方がマチマチだったら意味ないよな だから平均すると1.2倍程度だって
最大瞬間風速で1.8倍出てるかどうか
ただし1個しか使ってないソフトも山ほどあるけどな
無理に2個使ったら足引っぱって遅くなるレベルだからサターンのツインCPUって >>43
ICEの何をみてCPU使用率を判断するの? サターンの設計はまじでゴミだからな
3D対応させるために後付けでCPU1個追加しただけだから開発者も大変だったよ
それを64bit級とか今なら景品表示法で訴えられてもおかしくない >>44
ポリゴンの座標変換は、何千とあるポリゴンの頂点を変換する訳だけど、全て全く依存関係が無くて何千何万頂点を完全に同時に変換しても全く問題が無い
それでも1.2倍とか言ってるのはさすがに知識が無さすぎると思う ちなみに今は座標変換はGPUがやってる
ちょっと前にハードウェアT&LとかGPUの売り文句になってたけど、このTはTransformの事で座標変換の事を意味していた サターンのマルチCPUって現在のSMP環境のようなバス調停が自動で効率よくできるようなものとは全く違うから
1本のメインバスに無造作に2つのSH2がぶら下がっているだけで、何も考えなければ先にアクセスした方のアクセスが終わるまで他方は何もできず
他方がアクセスを始めれば作業の途中でもおれが先だったとほざこうが何しようが待ち呆け
このバスの取り合いをタイミングからアプリケーションレベルのプログラマに管理させるというクソシステム
普通なら祟られたくないから起動したら速攻でサブ側にHALT発行するよね
当時から2倍は無理でも1.8倍~とか言ってるセガ信者(プログラムはBASICすらまともに扱えないアホ)が居たが
こんな現実なんざ知る由もない
SDLだったかSGLだったか、バーチャ2の開発知見から得たサブルーチン群などをライブラリ化したものが配布されたが、これも要するにバーチャ2以降の話で
バーチャ2以前なんてポリゴンのクリッピング動作すら怪しいようなのがゴロゴロしていた
セガ内製でさえそんなザマだったので、3rd製ソフトなんてもうな… サターンはどちらかと言うとSH-2の乗算命令の存在が効果あった MDのZ80と68kはバスが分離してるだろ
ゲームで遊ぶことしかできない連中は、このレベルですらわかってない 普通はゲーム機で開発する機会はないからな。
詳細な構造は知る機会もないだろう。 サターンはバスが分離してないから1.8倍なんだろ
座標変換はレジスタだけで完結する(させる必要がある)
いかにメモリアクセスを減らすかが当時のプログラマーの腕の見せ所だろ
さすがにセガのプログラマーを馬鹿にしすぎ >>50
どれが変換済みかのフラグや双方のCPUからのメモリアクセスが入るのにそんなに効率よく処理が流れるわけないだろ >>59
座標変換は言うなれば行列計算なんで、頂点を1つ読み出し行列と掛け算して書き出す
これをひたすら繰り返すだけなんでフラグとか関係無い
ちなみにみんなキャッシュの存在を無視してないか?
キャッシュはライトスルーなんで座標変換には全く寄与しない
というか普通キャッシュを汚さないようにキャッシュに載らない設定にする
なのでキャッシュはもう1つのゲームロジックの方でほぼ独占的に使うので、頻繁にメモリアクセスが競合するなんて事は無い 分からない人に分かりやすく説明するとサターンのツインCPUは心臓2個あるから速く走れますって言ってるようなもん
OSはシングルタスク、プログラムでCPU切り替え
そんな設計で速くなるわけがない セガ信者「サターンはツインCPUで1.8倍の速度!」 ツインCPUで速くならないと言ってるのはマジで無知をさらしてるだけだぞ
プログラミングを勉強してくれ
もはや義務教育だからな サターンの2CPUは速くなってもせいぜい20%程度
これは昔から色んな識者から言われていることだよ
今さら議論する意味もない >>64
マルチスレッド使えるOSないと一般的なプログラミングの勉強では無理だろ。 >>65
取り敢えず根拠が分かるソースを出してくれ
鈴木裕が1.8倍とか言ってるのはサターンマガジンとか漁れば出てくる
自分の方でも探してみるけどね
あと、サターン解析記事はググればすぐ出てくる 最大瞬間風速1.8倍だろうな
セガは32bitx2を64bit級とか誇大広告を流してたクソ企業だからな Use of Slave CPU in comercial games
https://segaxtreme.net/threads/use-of-slave-cpu-in-comercial-games.16808/
検索したらスレーブCPUの使用率を計測した書き込みを見つけた
これ見ると、サードパーティのゲームは本当に1CPUしか使われてなかったのかも知れないw
バーチャ2は鈴木裕の言ってる通り80%使われてるようだ
ただ、これをもって2CPUで1.8倍の性能を叩き出してると結論付けるのは、動いてるコードの質も関係するから何とも言えないけど、まぁバーチャだし1.8倍と言っても過言ではないだろう 1.8倍なら実際は57.6ビット級だったってことか >>69
この計測はエミュレータのCPU速度調整によってゲーム進行が遅くなるかどうかで行われているようだけど、
プロセス間通信のコストも一緒に有効なCPU処理として計測されているのではないだろうか。
メインCPUだってサブCPUの影響で止まるだろうし、1.8倍からはほど遠いなー プロセス間通信なんて高度なことやってねえよ
CPU1がCPU2の書き込んだデータを見張って処理完了フラグが付いてたらそれをCPU1が使う原始的な方法だよ
だからCPU1は常にメモリ見張ってなきゃならないしCPU2も次の命令が来るまで待たされる
こんな内部処理でどうやって1.8倍も出すんだ?誰かが言ってた最大瞬間風速でもせいぜい1.5倍程度だろ
1.8倍なんてどうせフカシ 当時本当に64bitだったのはニンテンドー64だけ
R4300カスタムの93MHzというワークステーションに使われるような高級CPUをCS向けに卸してきた メモリ見張っている時間もCPU使用時間にカウントです。 なら実効性能は0.8倍ってところか
ツインCPUで逆に遅くなるというお馬鹿な設計で な?俺のレス>>19の通りだろ?
どっちも正しいことは言ってない メモリ見張ってる時間て…
データもコードもキャッシュに載ってんだからそんな頻繁にメモリアクセスは競合しないっつの
コンピューターの基礎を知らんやつばっかり さすがにポーリングによる共有メモリ監視とは考えにくいな。
処理終了は割り込みで通知するのではなかろうか。
キャッシュは4Kbyteのライトスルーでスペックがしょぼい。
メモリアクセスはそれなりに競合すると思う。 SH2には実験的にマルチプロセッサの機能が搭載されてて
それがあったから二個搭載できたってのは知ってる
SMPじゃなく、共有メモリと独立したローカルメモリの方式だと思うけど 3Dゲームの一般的な流れは、
1. CPUがキー入力を受け取りキャラのモーションデータを姿勢行列へ適用する
2. 適用した姿勢行列を描画命令と共にコマンドバッファ1へ書き込む
3. 垂直同期待ち
4. 垂直同期が発生したらVRAMのダブルバッファを切り替える
CPUは1へ戻るが今度はコマンドバッファ2を使う
GPUはコマンドバッファ1を読み込み描画を開始する
以下コマンドバッファ1と2を切り替えながら繰り返し
CPUとGPUが待つことは全く無い サターンのスレーブCPUは子プロセッサ的に使ってたわけだから、姿勢行列(マトリックスパレット)をダブルバッファにすれば、メインCPUと同期を取る必要は全く無い
当たり前だが垂直同期だけは待つ必要は有る
取り敢えず、これでポーリングだの言ってる人は疑問が解消したか? サターンのツインCPUはサブ側の動作中にメインが待ち惚けを食らっても良いタイミングでしか回せないので
Vブランクで割り込みが起きてI/O処理とかしてる間にサブで座標変換を回しておく…みたいな使い方ができない
メインに迷惑のかからない時間となるとメインループ中の後半以降、つまりサブ側はCPU時間の過半は寝てるしかない
こんなもんで1.8倍なんか出るかよバーカ、って一瞥してわからん連中は雑魚 >>90
あからさまに文系が書いたような文学だなw 西氏からの情報が止まってしまったのは、更に延期濃厚って事かね? サターンまで来ると複雑すぎるからか情報が少ないな。 どっちにしろプレステに負けてんだから仲良くしろよw ソニーはナムコと組んだのが大きかった
ナムコもいち早く3Dの技術を研究してたからね
むしろSEGAは一見3Dに長けているように見えるだけで、実際は他社の技術を使ってるだけだった
プレステの勝利はナムコの技術力の勝利でもあった >>96 の資料からは >>72 が近いように読めた。
他の制御方法も実装されているかもしれないけどね。 ■ このスレッドは過去ログ倉庫に格納されています