[過去ﾛｸﾞ] PC-FXは何故失敗したのか？ Pert7 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
400(1): 2024/11/15(金)04:43 ID:ajd16r9Z(1/13) AAS
>>399
PC-FXのスペックなら、アレンジ移植にはなるけど画面の同時発色を限界まで増やして（可能なら原画から再取り込みで16M色表示する勢いで）PCよりも解像度が低い分を補ってほしかった
音声が充実してたりして結果的にFX全ソフトでトップクラスの高評価を取った移植作品であることには異論無しですがね
それから70のドットクロックについて。
元はラインバッファ描画でVCEと協調して動く設計だったのでドットクロックと最終解像度の関係は切り離せなかった。
でもFXはフレームバッファになり、カラー合成する後段では21が頑張る仕様になったので解像度そのままドットクロックだけを上げても差し支えないはず（倍速でも21とのアクセスがノーウエイトでできるものと仮定する）
で、これをツイン70の代わりになるべく単純に32bit化するとして、たぶん問題が出るのはスプライトの横並び問題。
実際のFXでも残念ながらスプライトを欠けさせてる
401: 2024/11/15(金)05:13 ID:ajd16r9Z(2/13) AAS
↑
つまりスプライトオーバーしてしまってるタイトルも見受けられるが、32bit化するならその制約は無くしたい
よってラインバッファ運用なのは元の設計のまま、どうすればスプライト情報をたくさん取り込めるか考えたら、ドットクロック倍速にすれば理屈上ラスター当たりVRAMアクセス回数が倍になるので横512ピクセルまでスプライトを取り込めるだろうと。
1ラスター分のラインバッファも倍に長くしないとならないでしょうね
VRAM内のBATやSAT、CGやSGの仕様も本当ならバス32bit化とともにより使いやすい32bitベースなフォーマットに変更すべきとか、パターンの回転機能も付けろとか、開発者側の要望を言い出したらおそらく完全に別物チップに変わってしまうのでそこはあえて従来のまま16bit扱いとする。
あとVRAMアクセスも、16bitワードのままアドレス32bit化して総容量512kアドレス（つまり1MB）くらいあるとCGとSGで取り合いしなくて済みそうなので嬉しい
まあVDC設計はこんな口で言うほど内部実装が簡単にできるはずがないので、当時73の開発遅延をリカバーするついでに少しでもFXで使いやすいまともなチップに改修する気があったなら、というifの妄想。
402: 2024/11/15(金)05:17 ID:ajd16r9Z(3/13) AAS
こんな小手先の改修でコストを上げるより、素直に73が完成するまでFXの仕様確定と発売をいくらでも遅らせておけ、というのが当時NECに一番言いたかったことなのは言うまでもありません
アニメ再生特化マシンなんて要らんかったんや
403: 2024/11/15(金)05:34 ID:ajd16r9Z(4/13) AAS
よく考えたらFX当時でドットクロック倍速にノーウエイト対応できるアクセススピードを発揮するメモリ搭載は少々厳しい
50nsより短くしないとならない気がする
前世代VDCのためだけに再び大容量SRAM採用するなどハドソンなら絶対にできない
やはり、ドットクロックはそのままで全体的に32bit処理してトータル高性能化するしかない（チップ設計1からやり直すと同じ）結論になりそう…
405: 2024/11/15(金)11:49 ID:ajd16r9Z(5/13) AAS
>>400
21と思い切り書き間違えたけど6261のことでした
これコードネームがNew鉄観音らしいね
7upはまだ6270と関連あるけど、変な名前付けてくれると覚えらんなくて困る
ともかく70を2つまとめた描画性能があっても内部でパターンの拡縮すらできず、73と比べたらまるで足元にも及ばない
頑張ってもメガCDとしか戦えない
アーケードで回転拡大機能ある作品が出たのFXの数年前だし、SFCのモード7にも劣るとけなされても仕方ない
406(2): 2024/11/15(金)12:25 ID:ajd16r9Z(6/13) AAS
6271の動画再生、6272でバッファRAMの転送能力を全力で使えば同時に2本のミニサイズ動画を低いフレームレートで交互に更新しながら表示、みたいな芸当は出来たんだろうか？
CD-ROMから両データの交互読み込みが間に合わない可能性あるけど、これが可能なら例えばバトルヒートなんかも理屈上は、キャラ動画の透過合成（背景無しのキャラアニメだけ2人分重ねる。背景は別途BG面で出す）ができて表現力の自由度が増しそうだけど。
motionJPGだから収録された全てのセル画をスプライトパターン変換してレイヤーとしても使えそうなのよねえ
407: 2024/11/15(金)12:33 ID:ajd16r9Z(7/13) AAS
↑ただし動画を綺麗に重ね合わせるための指示データ作り（座標、サイズ、タイミング指定その他諸々）を、開発者が設計構築する莫大な工数は一切無視するものとする
409: 2024/11/15(金)14:29 ID:ajd16r9Z(8/13) AAS
PCで遊べるエロゲ方面をやたら移植したのが最初からコンシューマでもシェア取る気もない戦略としか思えないところがキツい
当時PC-9801の古い型でもそれらエロゲは遊べるのが多い（HDD無くてもいいのすらあった）ので、成人さえしてればFXにウン万円払うよりも中古のDOSマシンとソフト掘り出してオリジナルを遊ぶ方が満足度高かったまである
普通のゲーム作ってるメーカーが参入しづらい閉じた環境にする意味が分からなかった
PCエンジンでソフト出してくれたサードパーティに申し訳ないとかミリも思わなかったのかねえ
412(3): 2024/11/15(金)21:00 ID:ajd16r9Z(9/13) AAS
>>411
なんでできないの
さしあたり実行速度（フレームレート）は無視すれば、やることはひとつの動画から取り出したセル面を別のBG面に移してもうひとつの動画の上に重ねるだけのことなのに。
もしかして動画の面にはクロマキー使えないんか
415: 2024/11/15(金)22:29 ID:ajd16r9Z(10/13) AAS
毎コマ抜き出すんじゃなくバッファメモリに入るだけ程度まとめて取ってきて交互にデコードするという話だよ
416: 2024/11/15(金)22:33 ID:ajd16r9Z(11/13) AAS
当時だから専用デコードチップ使うとしてもjggの伸長にそれなりの処理コストかかるのかもしれないが、圧縮時には画像サイズ100ピクセル四方程度（PCエンジンのHuVIDEOより小さいサイズ）ならバッファに何秒分かは取り込んでおけるんじゃないかね
動画のフレームレートは毎秒8コマくらいでかろうじてアニメに見えればそれで良しとして。
417: 2024/11/15(金)22:49 ID:ajd16r9Z(12/13) AAS
バトルヒートはアニメ素材の撮影の方で対戦カード決め打ちからの全パターン組み合わせを収録してしまう力技で2人分のキャラの絡みを描画してると思うが、ストIIのようにスプライトアニメでやるなら各キャラパターンをリアルタイムで重ね合わせるので、動画で同じことやれればいいのにという話
もしメインメモリ拡張してたら、バッファが増やせてより作りやすそうではある
CDドライブへの過酷な負担は無視するものとする
ていうか、バトルヒートって制作スタッフ100人ほどいるけど大半はアニメ制作スタッフでゲーム部分は微々たる人数なんで、それじゃテストプレイも真面目にやらず飛び蹴り最強みたいないつの時代のベルトアクションだよというショボいCOMパターンなゲームバランスになってしまうのも無理もない
こういう無理やりな格闘アニメゲーム作るのも斬新でいいんだが、ローンチでタイムギャル完全移植させてもらえば良かったと思ってる
MSXやMCD版よりキレイな画面になったかどうかは作ってみないと分からんが、思い入れあるプレイヤーには売れただろうからな
419: 2024/11/15(金)23:30 ID:ajd16r9Z(13/13) AAS
対戦格闘ゲームのバランスは対人戦で取るものだとは思うけど、果たしてどれだけのユーザが対戦したのかは疑問が残る
もしCD-ROMを超大容量ROMに置き換えるなどした上でアーケードで出してたなら、読み合いがメインの風変わりな後出しジャンケンゲームと呼ばれたんだろうか
今の技術水準でバトルヒート2作れば当時より相当柔軟なアニメ操作とエフェクト（3Dモデルを一切不使用としても）で対戦中の両キャラの絡みを描画できるんだろう
まあスト6に勝てる要素は微塵もないがゲームデザインの試みとしては面白い。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.031s