ファミコン等の限界について語るスレ Ver.6
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>866
まあ音色という意味合いなら出そうと思えば出せるでしょ SCCといえばフワッとしたサイン波(withプチノイズ)と
ゴギゴギしたシンセベース。
特にフェイドアウトの処理と波形の相性が悪いのか、
その部分がやたら耳に残る。 SCCとPCEの内臓音源ってスペック的にはどっちが上なの？ 基本はこれ
SCCは１音色８ビット３２サンプルで４音色ないし５音色が定義可能、同時発音数５
PCEは１音色５ビット３２サンプルで６音色定義可能、同時発音数６
たしかSCCはこれで全てだったと思う音量コントロールもCPUが頑張ってた気がする（間違えてたら訂正頼む、パニングもあったのかな？）
PCEはチャンネルごとの音量コントロールパンコントロールとLFOまたは音色合成とノイズモードDACモードを持つ（こっちもハード資料未確認の記憶のみなので以下同文）
多分R800を音楽に張り付けるとSCC、ゲームへの使いやすさではPCEといったところでどちらかが単純に良い悪いというものでもないかと思う >>871
ごめんなさい、チャンネルごとの音量コントロールあるってうぃきぺに書いてました、間違えてたみたい
（ハードウェアエンベロープがないという話と混ざったのかも……） >>871
PCEは波形メモリ6音モードと波形メモリ4音+矩形波・ノイズに2音のモードがあって
ゲーム制作の上で作りやすいようにしてる柔軟な設計だったと思う
まあこの時代のハードはどこもサウンドドライバの精度と制作側のスキルいかんで色々と特色出たな PCEの沙羅曼蛇は滅茶苦茶音が良かった
それが答えだ サウンドドライバの優劣が強すぎるハードNo1はスーファミだと思う メガドラのザラザラやシワシワのノイズも大概だったな それが今やサンプリング4和音鳴らせたり音程変えられたりするんだから
サウンドドライバの進化ってマジわけわかんねーな
ハードのカタログスペックって一体…って唖然とするわ XGMなら容量任せの力技だね（音程変化はコンパイル時に音程ごとの加工済みサンプルを作り再生時はひたすら加算、
ＳＦＣのように専用チップ載せてるならともかく、素のZ80でリアルタイム積和演算なんて無茶もいいところだし）
それが許されるほどメモリチップが安くなったということなのでハードの進化の恩恵をもろに受けているよ >>879
>>880 の言う通り、XGMはMDで動かすプログラムとデータにする時に
加工済みサンプリングデータを用意するだけなんでROM容量増大の力業。
8bit14kHz相当4和音合成を行う所がリアルタイム
ADPCMデータ→PCM相当データ→合成処理→ADPCMデータのX68kのPCM8よりは負荷軽いがね。 和音を鳴らせられないから独特のアルペジオ展開が開発されたのさ そういうの動画サイトで海外PCのゲーム見てるとコモドール64に圧倒的に多いな >>882
まあ、Windows等の時代になって、1つのPCM出力に効果音からWaveファイル、
ソフトMidi音源他何でもソフト合成するようになったのだけどな。
専用の音源チップや多重PCM音源再生は過渡期の物だった事に。 >>880
>>881
言い方が紛らわしかったかもしれないけど
自分の言った「ハード」ってのは「ゲーム機本体」って意味
カートリッジ側に拡張音源チップを積むとかでもなく、ただの容量増加であれだけ鳴らせるなら
自分には紛う事なき「ソフトの進化」なんだけど
だって容量増加って当時から全ハードの全ソフトでやってるわけだし
その規模が当時とは比べ物にならなかったとしても、サウンドドライバが当時と同じものだったら
鳴らせる音数や音質は当時と同じになる…でしょ？
逆に当時のソフトを当時のデータ、当時の容量のままであっても、XGMを使ってサウンド周りを作り直したら
多かれ少なかれ出てくる音には改善が見込めるのでは？ 見込めるっても現役の市場には納期ってもんがあってだな
時間というのは有限なのじゃよ >>885
ソフトの進化には違いない。
FCにはカセット側で音源拡張する余地があった
MDの場合は無理だっただろうが
遊びがちのZ80のお陰でメインCPUに影響を少なくしてソフトで拡張できるのは面白いよね。
XGMに差し替えるとサウンド回りが結構直しが必要になると思うよ
68000側で音源を扱う事でPCM音質改善してるソフトもあるし。
Z80を遊ばせているゲームなんかだとマシだろうけど。
それと当時のデータを使うとPCMを増やせない。 >>888
> MDの場合は無理だっただろうが
無理なわけねーべ >>８６６
これ聞いてるとＳＣＣって
PCEのＣＤの生音声に合いそうな音質だな ファミコンでのランダムの表現って手に入りにくいなってくらいの印象なんだが
らいじんのけんが簡単に手に入るカセットとそうでないカセットに出荷時に分かれていたら
入手確率は現実のランダムに似てくる？ >>889
FCの場合はカートリッジにAudioの端子が出ているけど、MDはアドレスとデーターしかないと思うの
（もちろん、カートリッジに乗せたコプロセッサでPCMデーターを合成してそれを本体のCPUが出力するという方法は取れなくもないけど、カートリッジ上のチップがダイレクトに音声信号は出せない） ごめん 「しか」 は不正確だったね
グラウンドやタイミング関連の信号などはあるので >>892
FCにはあるけどNESにはAudioの端子無いようで、拡張音源海外向けではないのよなあ。 >>892
カートリッジ上のチップに音声回路（AV出力）つければ良いだけ >>894
NESではMIRACLEというピアノ練習ソフトとキーボードのセットが出てたけど
ピアノの音はキーボード側から出力でNES側の音はメトロノームやミニゲームを担当だった
コナミのドレミッコよりサイズ大きくわりと本格的に弾けそう
https://www.youtube.com/watch?v=R9FZrn2MaR8 >>895
ああうん、カートリッジにスピーカー載せたりLINE OUT装備すれば可能だね、32X方式 >>891 は何を言ってるんだろう？
誰か解読よろしく >>898
おそらくドロップ率含む乱数がゲーム機依存だと思い込んだ上で、ドロップテーブルが違うカセットをバラバラに流通させたらランダム性が向上する
と言いたいのだろう アイテムを落とさないモンスターと別IDで
100％アイテムを持とす同種のモンスターが混ざっていないのは何でや？みたいな話
所持しているかいないか倒してみるまで分からない、というのは変だと思う >>900
>所持しているかいないか倒してみるまで分からない、というのは変だと思う
それがなんで変なのか、もっと説明してみて
一応言うけど倒す前に（エンカウントした時点で）持ってるか持ってないかをランダムで決めることは可能で簡単だよ
マインドシーカーでいえばユーザーが選択する前に当たりがコンピュータ内で決まってないとフェアじゃない
（超能力開発ソフトとして偽物になっちゃう）とかそんなような話なのかな？
そういう意味でDQ世界内でリアルなレアアイテムのあり方をさせることはROM１種で可能だ
太閤立志伝とかはそれに近い。ただしちゃんとやるほどバックアップメモリがもっといる
逆にポケモン赤緑式にROMの種類を増やすのは、そんなしょーもないことのために
バグのリスク等考えると良い手とは思えない >>892
市販ソフトで採用される事はなかったが、MDもFCと同じくカートリッジ側に拡張音源を追加可能だよ。 >>903,892
メガCD相当の機能を持つメガSDではカートリッジ側からの音声出力していると思う。
MD本体ではカートリッジ端子経由で音声入力し本体側のFM音源とミックスした後、音声出力端子から出力していると思う。
【メガSD】(PCM／CD音声)
↓カートリッジ端子
【MD本体】
↓音声出力 >>902
アイテムを持っている個体は身体に隠していたとしても
動きが遅かったりはぐれてたり情報が漏れてたりして
所持しているかどうかが戦う前に分かると思うから そんなこと言い出したら均一に経験値やお金持っとるのもおかしくなる
そういうフェアさを求めるならテーブルトークRPGとかジャンルを変えるしかない >>903
>>895さんの話受けて>>897で気づいて、>>904さんも述べているけど、言及しているのはこのことですよね？ もし違ったら詳細下さい
ただ、カセット本体に外部出力端子持たせる事許し始めると究極的には32Xに行きつくので、個人的にはその方式は拡張音源というより外部音源かとは思いますが
（信号の流れとしてはカセットにMIDI OUTつけてCM64で音鳴らすのと相似であるため） そもそもファミコンなどの拡張音源ってどういう仕組みなの？ どこで拡張音源側でジェネレートした音源をミキシングしてるんだ？
ファミコンやMSXなど、普通に考えて最初から拡張音源というものを想定してアーキテクチャを設計していたってわけじゃないだろう？ >>907
FCと同じ仕組みでMDも本体の出力からカートリッジの拡張音源の音を出す事が可能。
当時は市販されていないけど今は拡張音源の機能を持つカートリッジが存在している。 >>908
ファミコンならカセット側でやってる。
カセットの端子にオーディオOUT／INがあるので、音源のないカセットは短絡してそのまま本体に戻すだけだし
音源のあるカセットは本体からの信号と音源の出力をミキシングして本体に戻す。そんな回路になってる
最初から拡張音源を想定してたわけじゃないだろうが２コンにマイクがあったり
前面端子にも音声出力があったりとか何らかの拡張性を持たせる設計だったのは間違いないと思う
NESではその仕様がカットされてるので拡張音源が載ったソフトはないらしい >>891=900=905なのか？
さっぱりわからん。ゲームをプレイしてて仕様が見えてこないレベルの人かな？
だとしたらどうしようもないｗ
>>899
聞いておいてなんだけどもっと斜め上の話だったみたいね。解読乙でした >>910
そこらへんの回路が前期後期ニューファミコンで異なるから音量バランスに違いが出るのよね
拡張音源自体は最初から想定してたと思うわ。ディスクシステムとかそうだし
まあ拡張音源カセット数珠繋ぎしてシンセサイザーにすることまでは想定してないと思う……思うがリソース競合起こさないのがすごいよな 色々ゲームが出てたファミコンだが、
ャtァミコンの限滑Eでどれくらいｂﾌゲームができｂｽかどうか語り麹№ﾁてくだされ
ファミコン以外のハードも可 >>909
下図がMDカートリッジスロットのピンアサインのようだけどのピンで音声情報受け渡しているのだろう？
ttps://gendev.spritesmind.net/forum/viewtopic.php?t=3124 >>911
システム上は持っていないぞと判断されたら
そのアイテムは事後処理的に消されてしまうでしょ
>>906
それもそうだけど経験値やお金はちゃんと手に入るよね
RPG世界で考えるとアイテムを持っているかどうかが周辺の村人や歴戦の戦士や
そのモンスター自身すらよく知らなくて
仮に所持していたとしてもそのアイテムは乱数神の意思でなかったことにされてしまう
だから不透明だな、というか手に入りにくいなって感じる >>914
B1、B3がサウンド関係（SL＝Sound Left SR=Sound Right） >>912
ディスクシステムは本体寿命を延ばすために後から考えたハードなのはインタビューか何かで
言ってたと思うので、それで使ってるから当初からの想定ってのは理由にならないと思う
元々は教育ソフトとかおもちゃ的な展開で、マイクやスピーカーなんかを
追加実装できるようにしたのが想定だったんじゃないかと思う
NESの仕様からは外されてることを考えてもその時点でそっち方面の拡張はないって判断だと思うし >>908
> ファミコンやMSXなど、普通に考えて最初から拡張音源というものを想定してアーキテクチャを設計していたってわけじゃないだろう？
ファミコンはされている。
> そもそもファミコンなどの拡張音源ってどういう仕組みなの？ どこで拡張音源側でジェネレートした音源をミキシングしてるんだ？
カセット端子にSOUND_INとSOUND_OUTがあって、SOUND_INからファミコン本体の音声がカセット側に流れ、カセット内部でミキシングして、SOUND_OUTからファミコン本体に戻っている
。 >>921
ジョイカードのサンスイ版とかで音声をラインアウトすると拡張音源側は出力されないんだよな >>921
自分の見解としては想定外なのはすでに >>919 で言ったとおりだが
逆に拡張音源だけを想定していたのならOUTとINにしてカセットを素通りさせずに
カセットからのINだけをつけて本体側で内部音源とミキシングする設計の方が合理的だと思う
あとついで別の話を言うと
RAM拡張やバックアップに関しても本体設計時には想定外だったはず
ROM領域以外のアクセスにはハードバグっぽい仕様があって、各社設計の差でハードで補ったり
メモリが壊れないようソフト側で工夫したり、いろいろあったみたい（記憶で言ってるので嘘だったらごめん） > RAM拡張やバックアップに関しても本体設計時には想定外だったはず
ファミリーベーシックが出たのはファミコン発売翌年だったが
これはブーム前でも出すのは既定路線だったと思う >>922
カセットからの音声入力はそのままRF基板に行ってて
前面の拡張端子からは内臓音源しか繋がってない
こんな設計なのも拡張音源は想定外だった状況証拠の一つかもね >>924
ファミリーベーシックは開発にハドソンが大きく絡んでてて岩崎氏が経緯を語ってたような気がする
ファミコンが発売された当時にはすでに８ビットパソコンのブームは起きてたから意識してたのかもね >>908
MSXは楽器ルートのヤマハ初代機からFM音源がスロット経由で接続されてた。 本体とカードリッジの役割をきっちり切り分けて分担するぞ、この機能はこういう使い方をすると決まっているぞ、
というポリシー自体が時代的に別に存在してなかったんじゃないか？
動くなら何でもござれなんじゃないか？
そういう意味では何でも想定内でもあり想定外でもあるみたいな >>920
結果として間違えていたのは申し訳ないのですが
外国のサイト含めて自力で調べられた範囲で該当ピンが音声ラインと明示している情報を見つけられなかったもので……
NESのnesdevのようにまとまっているサイトあればご教示いただけると助かります 素晴らしい、名前だけでなくきっちり説明まであるし他にもいろいろまとまってていいね、ブックマーク入れた
しかし、
genesis
develop
sega
cartridge
pin assign
他、類する単語でさっぱりヒットしなかったのが
genesis ⇒ mega drive
pin assign ⇒ pinout
だと、画像検索でズラッと出てくるとは >>923
>カセットからのINだけをつけて本体側で内部音源とミキシングする設計の方が合理的だと思う
ファミコンって販売価格を抑えるために仕様を削ってコストダウンを図っているので
本体にミキシングする回路を設けず、後からカセット側で対応できるように端子だけ出したんだと思うけどな。
>RAM拡張やバックアップに関しても本体設計時には想定外だったはず
本体のVRAMのメモリを有効にする端子(CS)がカセット側に出ていて
本体のVRAMを使う/使わないの制御がカセット側からできる仕組みがあるので、
カセットで機能を拡張することは考えられていたと思うよ。 >>932
ミキシング回路と言っても本体側に増えるのは下手すりゃ抵抗一本
そこをケチって、カセットの信号を一本増やすのはコストダウンの見地からしたら割に合ってないと思う
CS信号は普通に動作させるのに必須な信号であって拡張用じゃないよ
BG用のスクリーンを縦並びにするか横並びするかのアドレス線が出てるけど
カセットにメモリ積めばスクリーンを４画面にできた。これはもしかしたら想定内の設計かもしれない
あとこれはレスじゃないけど
スーパーマリオ１の時点でバンクを使わない最大メモリを使ったカセットの集大成という位置付けで
それ以降の大容量はディスクシステムでって予定だった。って話を見た気がする
なのでMMCとかバンクによる大容量ってのも本体の設計当初からは想定外だったと思う >>933
> カセットにメモリ積めばスクリーンを４画面にできた。これはもしかしたら想定内の設計かもしれない
カセットに積んだVRAMを使うときに本体のVRAMを動作させないようにするためにCS信号を制御できるように作られています。
もしかして、本体VRAMのCS信号がカセット側に出力されていると思っています？
PPUのA13を反転した信号(/PA13)がカセット側に出力されていて、カセットにVRAM載せない場合は、
カセット側で/PA13を本体VRAMのCSに接続して本体側に信号を戻しています。
カセットにVRAM載せて本体のVRAMを使わない場合は、/PA13をカセットのVRAMのCSに繋いで、
本体VRAMのCSは常にHにするって感じになりますね。
> BG用のスクリーンを縦並びにするか横並びするかのアドレス線が出てるけど
本体VRAMのA10に繋がる線がカセット側に出ていて、カセット側でPPUのA11かA10を接続して本体に信号を戻すことで、
本体VRAMのメモリマッピングを変える仕組みです。カセットにVRAM載せた時の制御には使えないですよ。
> ミキシング回路と言っても本体側に増えるのは下手すりゃ抵抗一本
> そこをケチって、カセットの信号を一本増やすのはコストダウンの見地からしたら割に合ってないと思う
Ⅱコンのマイク入力や前面拡張コネクタの音声端子からの入力をカセット側で処理できるように考えていたんじゃないかなと思う。 >>934
よくわかった。あなたの言うVRAMという言葉がBGテーブルとアトリビュート用の本体RAMだけを指してる
（敢えてくどい説明）ってことが判った。こちらはVRAMと聞くとCHR-ROMはROMであることが多いとは言え
PPU側バスに繋がる全般のメモリだと思っていた。本体VRAMとも言ってるのだからそれ以外にあるか？
と言われると苦しいのだけど 933 を書いたところまでそんな風に思ってしまってた
> もしかして、本体VRAMのCS信号がカセット側に出力されていると思っています？
と言うより >>932 がそういう意味で言ってるのだと思ってた
> カセットにVRAM載せた時の制御には使えないですよ。
これはまさに前半の説明の/PA13のことも含んで「～のためのアドレス線が出てる」と言ったつもりだった
> Ⅱコンのマイク入力や前面拡張コネクタの音声端子からの入力をカセット側で処理できるように考えていたんじゃないかなと思う。
ここはそうだろうね。おもちゃ的な展開を考えてたんじゃないかとはすでに言った通り
と言うことで 933 を書いた時点までは回路図も確認せず記憶だけで言ってたので不明瞭だったと思うし
長々とレスさせてすまないと思う。でも結果としては、現状の回路がどうなってるのかを踏まえて言わんとすることは
そう遠く違ってなくてその上で、当初どうだったのかと思うところは相違があるってことなんだろうなと思ったよ まあ任天堂もファミコン設計時には後にあんな大ブームになって
何年も市場が継続するというのは想定外だったろうな
当時のテレビゲーム市場は1機種で長くても大体2年くらいだし
なので最初から何年もの市場継続を考慮しての拡張性を持たせてたというのは無いだろうなあ ファミコン２が出てたら面白かったかもね
ゲームボーイカラーに近いスペックの
事実上PCEがそれだけど もしディスクシステムを出さずに上位互換のファミコン2を出すとしたら、
BG画面をもう1レイヤー追加とか、拡張音源搭載、
コンポジット出力装備、4人対戦向けに拡張コネクタ追加あたりだろうか。
当然新型対応ソフトもオリジナルの本体でも動作することを義務づけた上で。 コントローラは５個までインターフェースあったけど使ってないしね
ツインファミコンで短絡してあったとこ >>937
SFCの前にんな中途半端なもんだしてたら大惨事になってだろうな >>905
それならエンカウントした時点でモンスター個々の持ち物を（乱数で）確定してそれが分かるように表示することもできる
「ドラゴンＣは なにか もっていそうだ！」みたいに表示するとか、モンスターの絵に何か印つけるとかね
一応そういうRPGはすでにあって、物持ちなやつから先に倒すなんて戦略も生まれたりする
でもそれをやると追い剥ぎが戦闘中の意識の大部分を占めるようになってゲーム性も雰囲気も変わるよ
正義の勇者というより目が＄マークになってる感じ
まあそれ言ったら「今でもはぐれメタルが出た時はみんな目が＄マークなってるやん！」と反論するかもしれない
じゃあ別のアイディアで、出現率が超低率で、見た瞬間に稀少と分かる「（○○の剣持ちの）ドラゴン」みたいなモンスターを出す手もあるね
ROMを分ける必要はないし、容量も全然食わず出せる
ただそれだと変わったアイテムを取れるモンスターがそこに出るというのが一度見たら分かってしまうから、
隠し要素感がかなり薄れてしまうかな
まあ一番の理由は単にウィザードリィ等の仕様の踏襲なんだろうね >>942
そんな事よりFC位だとRAMがとても少なくて苦労するのだから
出現時に決定するよりギリギリまで後回しの判定の方が合理的だろう。
FCなんか2kBしかないのだよ。ゼロページとスタックページで1/4食うし スーファミはちょっとした改造で同軸デジタル音声出力出せるけどメガドライブもYMF276に配線繋ぎ変えて回路整えたらデジタル出力できるのかな？ >>943
話の発端までちゃんとさかのぼって読んでる？ >>945
は？
エンカウントした時点で確定してるって事は敵毎にRAMに記憶させとかないといけないのよ？
判定後回しなら不要になるので合理的と言ったまで。 つーかこの話はいい加減自重して欲しいと思う
スレタイ的な限界の話とは関係なくて
どこまでも行ってもただの「俺の遊びたいRPG仕様」の話でしかない気がするんだが
そうじゃないと言うなら、その理屈を合わせて議論してくれりゃいいが >>948
ただ、RAMが少ない事による制限は限界の話に合致はする。
FCより後のスーパーカセットビジョンなどはCPU内蔵分の128Bしかないトンデモマシン。
サウンドも実質1音だし、ライバル見てないよな。
SG-1000も1kBしかなく、mk3で8kBに。
FCが少ないと言っても高価なSRAM使って2kBは当時としては妥当。 >>949
話題になってる仕様の話を全部追えてるか自信がないから間違ってたらスマンと先に言っておくけど
１、他のハードの話は無関係だと思うのでノーコメント
２、RAMが少ないと言ってもDQ3以降のバックアップメモリありならワークとして使えるRAMも増えてて
話題の仕様を載せること自体たいした問題じゃないと思う
３、逆にバックアップメモリなしならやれることの限界はさがるが
２と３どちらにせよ、たとえばDQ2や3の完成後にやりくりしてその仕様を追加で載せるとかなら非現実的な話だろうけど
システムをどうするか検討の余地がある開発初期の話なら、どっちにしろ普通に可能っちゃ可能だと思う
ただ、どっちにしろDQ系のランダムエンカウントする仕様でドロップアイテムだけ先に判別できる仕様ってのは
ゲームの仕様としてバランスを欠いてる感じがするし、作り手の側から見たら無駄な追加仕様にしかなってなくて
システムを複雑化させた割に旨みがないと思う >>950
SFC位のRAMあれば可能だろうが、追加RAMの無いFCのDQ2で可能とか簡単に考えすぎ。
ゲームの状態を記憶しとくRAMがとても少ないのだぞ。
仲間を呼ぶ系の敵とかのマドハンド増殖とか考えて足りるのか？ 何度見てもFCソードマスターの多重スクロールの原理が分からない >>950
>２、RAMが少ないと言ってもDQ3以降のバックアップメモリありならワークとして使えるRAMも増えてて
>話題の仕様を載せること自体たいした問題じゃないと思う
同感
DQ3以降ではバックアップメモリがあるし預かり所に預けられるモノの上限がやたら多かったりと余り気味に思える
>３、逆にバックアップメモリなしならやれることの限界はさがるが
>２と３どちらにせよ、たとえばDQ2や3の完成後にやりくりしてその仕様を追加で載せるとかなら非現実的な話だろうけど
>システムをどうするか検討の余地がある開発初期の話なら、どっちにしろ普通に可能っちゃ可能だと思う
>システムを複雑化させた割に旨みがないと思う
うんうん
仕様の方も元話題を満たすだけならやりように幅があって
「今回のまもののむれがとにかく何かをドロップするか否かだけを確定、それを教える」
「モンスターのどれを倒せば何かドロップするかだけを確定（1匹だけ）」
「モンスターごとにそいつを倒せば何かドロップするかを確定」
「モンスターのどれが何のアイテムを所持しているかまですべて確定」
等々、使えるワークに応じて仕様のリッチも変えられる（最初のなら1bitで済む）
ただそんな技術的なことよりも、
果たしてそれをやったほうが本当にゲームとして良くなるのか？というソフト的な問いの方がずっと重要で
あんまり実用的なUIを付けるとモンスターが数字にしか見えなくなってくるみたいな良くない現象が起こることから
できたとしても、思いついたとしても、やらない気がするよ
逆にローグみたいにヒロイックなシナリオに浸るよりも命のやり取りのゲーム性を楽しむゲームなら、ありだろうね >>949
それ、本体のメモリ不足は当時でもカセット側にデータ書き込むためのSRAM積むなり大容量ROMなりにすれば実現できたろうから、価格という制約があっただけで限界ではないのでは？
プログラムが使用するメインメモリが少ないというなら、限界かもしれないが。
>>950
ステータスを記憶するだけだからカートリッジ側に補助記憶としてメモリ追加するだけでいいね。
>>951
ゲームの状態を記憶するのはメインメモリである必要はないよ。手間はかかるが都度読み込めばいいだけ。
本体のメインメモリが少ないのはどうしようもないが、外部メモリはカネさえ出せば増やせる。
また、敵キャラAをアイテムを持たないA-とアイテムを持つA+に分けることと、
アイテムを持たない敵キャラAとアイテムを持つ敵キャラB を作ることは敵キャラの種類が増えるという点で同じ事だよ。 >>952
バックの遠景がパターン書き換えのアニメーションでスクロールと同期させてるやつ >>953
プレイヤー側がドロップするアイテムを所持してるか否かで
敵がアイテムを落とさなくなるというパターンもある
ファミコンの2のふしぎなぼうしとかがそれか
リメイク版では撤廃されてる仕様なのでこの辺もメモリ容量と関係あるんだろうな >>954
＞ゲームの状態を記憶するのはメインメモリである必要はない
DQ2で可能とか簡単に言っている前提無視すればな。
じゃあ、DQ2の時点でバッテリーバックアップ他組み込んで価格UPしとけと？
PCEはROMカードがアレ何とCD-ROMも有るので本体側の付属品に記録するのが主流になったが
FCはターボファイル他、カセット外で記録するのは少なかったな。
ターボファイルも拡張用の感じだし。 >>957
価格アップして売れなくなるというのは制約であって限界ではないよ。
当時は半導体単価が高くて実現できなかっただけだね。 >>952
擬似２重スクロールはCHR-ROMのバンク切り替えが使えれば可能
過去スレに出てきた話題だと思う
原理は遠景用に１ドットずつズレた絵のパターンを持っておいてバンク切り替えで実現するだけ
メモリ食いの力技ではあるけど繰り返しの小さめのパターンなら普通に載る容量になる >>951
ゲームの状態を記憶する、と言っても普通だったらバトルで勝ち確定後に抽選を行うアイテムのドロップが
出現時に抽選してアリかナシかを保持するだけでしょ？
マジメに実装する方法として考えても、やらなきゃいけない事はバトル中のワークとして１体１ビットずつ確保するだけ。
下手すりゃワークの中で余ってるビットをやりくりできるかもしれないし、もしカツカツだったとしても
たとえば、１バトルで最大何体でるのか知らないけど最大数を１体減らせば余裕で確保できると思う
そして >>953 もやりようの幅があると言ってるように
ドロップ率０％とドロップ率１００％の２体のモンスターを内部的に別物にしてしまえば
エンカウンター時の出現テーブルで、確定ドロップするか確定でドロップしないかの抽選ができちゃうと思う
全体に適用したらモンスターIDがかなり増えちゃうけど、ドロップで稼ぐようなモンスターとかが数体ぐらいしかいない
のであれば数ID増えるくらいで済むから、ROMの方でやりくりするだけでやりたいことができちゃうんじゃないかな？ ドラクエ3は岩バグとか聞くと起動ごとにSRAMのワークエリア（データ保存領域以外）をクリアしておけばよかったのに、と思ったけど多分これは浅い考えなんだろうな。 ファミコンで動画再生するデモを見たが、カートリッジ側の拡張で全部やる構成だと当然できるよねという感じで実際に動くモノとして組み上げたことは素直に評価はするけど技術的な感動はなかった
アンドアジェネシスの浮遊はすごいと思ったので、多分現役時代のうちに商用として世に出た拡張の論理MAXまでがすごいと当然の分岐点なのかも >>961
内藤寛のYoutube見てないのかな？
>>962
DOOM実装したときの技術解説を見たとき、何をどうやったら
FCのPPUで動画再生に使えちゃうのか理解した時は技術的に感動したけどねｗ >>963
> 内藤寛のYoutube見てないのかな？
見たから言ってるんだが？
何が言いたいんだ？ お前 いい歳したおっさんが「お前」とか喧嘩越しになっちゃってるよｗ >>963
４色ビットマップの実装のタネが既知だからというのもあったのかもしれませんね
これがフルカラーだったらびっくりしたと思います >>964
見てたなら >>961 のような感想にはならないだろうな、と思ったからだが？
>>965
ほんとだよね。 964 を喧嘩腰だと思う時点でどうかしてると思うｗ レス数が950を超えています。1000を超えると書き込みができなくなります。
