ファミコン等の限界について語るスレ Ver.6
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>674
> DQ3とかのデータ圧縮はここでいってるようなファイル圧縮＆解凍とは違うんだよ、アホ
じゃあ何の話なんだ？ >>669 にそれとは違う話をしてるという根拠をどうぞ >>676
それはプログラムコードに限る話だろ？
容量余ってるタイトルならともかく、VRAM側に転送しなきゃいけないデータも同じROMに載ってて
DQ3みたいにカツカツなタイトルで圧縮しないって方が意味不明だろ
そもそもワークを大きめに使う辞書展開するのが圧縮の全てじゃないぞ
ワークはほとんどいらない圧縮方法もある >>697
667からの話の流れで「データの圧縮展開」 ファミコンでもロードが長いのがあった」みたいな事からはじまってるだろ >>695
でもDQ3あたりからCHR領域にROMじゃなくてRAMを搭載したタイトルがぼちぼち出てて
総数としては結構あるんだけど
>>696
それはCHR領域にROMが載ってる場合だろ？ >>698
> DQ3みたいにカツカツなタイトルで圧縮しないって方が意味不明だろ
> そもそもワークを大きめに使う辞書展開するのが圧縮の全てじゃないぞ
> ワークはほとんどいらない圧縮方法もある
だから「明確に待ち時間となるようなロード時間がでる」という圧縮展開みたいなの（昨今のロード時間問題でよくある圧縮ファイルを読み込んでメモリ上で解凍するのに時間がかかっている、というような）は無い、って話だろ…ほんと何もわかってねぇのな >>700
↑
え、こいつちょっと馬鹿うぎひん？ｗｗｗｗｗ CHR領域にROMが載ってる、というパワーワードｗｗｗｗ アホがイキってしたり顔で技術を語るとこうなるという見本だなｗｗｗｗｗｗ >>699
その流れで何の間違いでもないじゃん
> ってかSFCでロード時間とみなせる程度の待ち時間が出るのに「データの圧縮展開」なんか基本的には無いからね
とか言ってるから否定したまでで。
ZIPの展開とかしてるわけじゃあるまいし独自のフォーマットやアルゴリズムで
時間もかからずワークもたいして使わない簡易な展開を実装してるタイトルは相当数あったと思われるが？
疑うなら、すでに言ったとおりDQ3もその一つだから内藤寛のYoutubeでも見てくれ >>701
> ってかSFCでロード時間とみなせる程度の待ち時間が出るのに「データの圧縮展開」なんか基本的には無いからね
これって「ローディング画面なんか当時なかったのに圧縮データの展開なんてやってる訳ないだろ」と言ってるだけじゃん
> だから「明確に待ち時間となるようなロード時間がでる」という圧縮展開みたいなの（以下略）
お前の意図が本当に最初からそれだとしたら、俺のレスを見て自分の書き方がまずかったと気がつかないとヤバいんじゃね？
後のレス見ないで >>697-968 を書いちゃったけど、他の人も同じようなレスしてるじゃんよ 706の最後の行のアンカー間違えたが >>697-698 ね >>702-704
出たよ。何の技術的な反論もしないで人格否定で攻撃しだす奴ｗ
間違いを指摘されたらキレる典型例の奴だなｗ
このスレで一番滑稽な存在。ちなみに相当恥の上塗りしてるからな、そのレスｗ >>708
下品な言葉使いですぐ分かるよｗ
歳取ってこじらせたままだとこうなっちゃうんだろう >>659
いやお前だけ浮いてる
昨日5ch始めたのかってレベル >>708
いや普通にアンタがおかしなこと言ってるから >>706
> > ってかSFCでロード時間とみなせる程度の待ち時間が出るのに「データの圧縮展開」なんか基本的には無いからね
>
> これって「ローディング画面なんか当時なかったのに圧縮データの展開なんてやってる訳ないだろ」と言ってるだけじゃん
違うわｗ
ファミコンはロード時間なんか無いと思われてるけど実はロード時間っぽい待ち時間あったよね、それは圧縮データの展開とかやってたんじゃないの？っていう流れから
いや待ち時間はあったとしても別の理由で、「圧縮データのメモリへの読み込み＆解凍展開に時間がかかっているケース」というものは無いよって言ってるんだよ >>695
そもそもロード時間がどうのって、SFCの話だろ？
何故FCの話にするんだ？ ファミコンというのはテレビでなく256x224という変わったモニター用に作られたのかな？ >>715
横256は8ビットの最大数、縦224は当時のテレビで可視可能な最大走査線数だからでしょ >>711
おかしいなら、どこの何ががおかしくて正しくは何なのか？それを返せばいい
なのに罵詈雑言で人格否定に走る痛さは言い訳できないし
実際反論できてないじゃん。それが客観的な答えだよ >>716
捜査線という点では448だけどな。
448ラインだとメモリが足りなかったんだろ。 >>715
テレビは4：3で比率違うし領域的にも広い気がするけど
べつに悩む要素ではなかったわけか… >>712
> いや待ち時間はあったとしても別の理由で、「圧縮データのメモリへの読み込み＆解凍展開に時間がかかっているケース」というものは無いよって言ってるんだよ
だからお前の意図がそうだったとして、この >>706 の引用部分やそれ以前のレスからそれが分かる根拠って何？って聞いてるんだよ
そもそも >>676 みたいなレスが後から出てる時点で、途中から意図すら誤魔化すように変えたんじゃないの？
それともこのレスは別人なのか？
お前の後出しでの真意はだいたい分かったが、それより前からお前の意図がレスから読み取れる表現だったのか？
それを問題視してる。もしそこにわかって当然な表現があるなら、俺の見落としになるし
それがないなら、お前の表現では伝わらなくて当たり前だったって話になるだけ。
これはことさらお前が「そういう話じゃないだろ」と否定してくるから聞いてる訳だ
> DQ3とかのデータ圧縮はここでいってるようなファイル圧縮＆解凍とは違うんだよ、アホ
結局、この圧縮展開の話が違うって部分も、具体的に何が違うのか不明瞭なままだよな？ ピクセル圧縮展開しない補完もカットも必要ない
アス比ピッタリのファミコン専用モニターはなかったんかな >>718
捜査線→走査線。その意味では525本。解像度の448はインターレース対応での解像度。
本来NTSCはインターレースで2フィールド30フレームだけど
アーケード含めて当時のゲーム機は毎秒60フレーム的に使ってるので縦の解像度は半分になる
最低限の環境で実現する場合なら、メモリの問題じゃなくて
CRTC（FCならPPU）が対応してる必要があるのと処理落ちすると画面の乱れが酷いことになる
というデメリットもある >>724
そだな。
必ずしもメモリ不足という訳ではない。 なぁ…ID:KgMaQBG80って以前からちょくちょくでしゃばってくる 前スレでも暴れた「長文馬鹿」「長文荒らし爺」じゃん？
反応の癖が前スレで暴れてた時とまったく同じだぞ >>726
あ、やっぱそうか
ってか文体からしてもそうだし、話の流れも読めずにいきなり横入りしてきて筋違いな事いいまくりあげく長文たれながして暴れる性質といい間違いないなｗ
無視が一番だな アイレムの基板は縦256dotの仕様になってたけど、あれは
「ゲーセンのモニタはプロが調整するからヨシ」みたいな
思想だったのだろうか。
CPUも前世代にZ80を使ってたものが多かったせいか
V30やV33を使ってるし、設計に何か強い意思を感じる。 >>694
データバスの件も含めて低コスト優先で設計されたからだと思うぞ。
それとCPUに速度あんまり求めてなかった節が有る。
回転拡大縮小機能持ったVDP含めて色数とスプライトの使ったらとか。
カートリッジ側に本体CPUより速いの載せられるように、ってのもいいけど
本体のが貧弱過ぎるからチップ積んだカセットばかりになるとかもなあ。 ファミコンの画像チップをVDPと言うやつはニワカ
はっきりわがんだね >>727
結局 >>721 には答えられないから「無視する」というテイで逃げるわけだな
それが答えならそういう事だから構わんよ >>728
アーケードの場合はNTSC規格にこだわる必要が無いからね
ただ量産品で一番コストが安いのはテレビ仕様のモニタなので、
その手のモニタが追従する範囲内で独自仕様にしてるのが多いのかと
縦256ドットならNTSCで言うオーバースキャン部分とブランク期間の一部を
表示範囲にするよう調整したモニタが使われてるんだと思う ファミコン/スーファミはPPU
PCEはVDP
メガドラもVDPだっけ？ ファミコンの絵って
ブラウン管テレビの画質コントロール機能と衝突してなかったのかな 赤白のAV化とニューでかなり画質というか縦縞ノイズや線の荒れかたが違うけど中身はほぼ変わらないのが不思議 >>736
赤白FCの縦筋ノイズは純然たるアナログノイズらしいしAVファミコンとは回路はほぼ一緒でも
基板の配線パターンや部品配置を変えることでノイズ対策したんだろうね >>737
そういう書き込みをしたらeverdriveの作者がカートリッジ下駄方式のNESRGBを発表してた偶然のすれ違い
カートリッジスロットだけでRGB生成できふのかかなり気になる
https://i.imgur.com/pIN4t7D.jpg >>738
なるほどなー。無改造で行けるのは衝撃だな
本体改造型のNESRGBは、パレットデータを横取りして
PPUの未使用ピンからのパレット番号出力を得てRGBを生成してるって理解してるけど
この下駄型の場合は、パレット以外にCPUバス側からOAMやPPUレジスタの設定値も横取りして
PPUバス側からはスプライトとBGのアクセス横取りして、自前で重ね合わせとか実現してんのかな？
理屈ではそんな感じで実現できそうだけど、そうなるともう表示部分のエミュレータがこの下駄に載ってる感じかも
動作中の動画もあるのか
https://www.youtube.com/watch?v=1QQu-etn658 その昔、とあるゲームメーカー勤務だったプログラマから聞いた話なのですが。
ファミコンのドラクエ2（1の記憶違いの可能性あり）では縦にラスタースクロールする場面がある。横にするのはふつうだがあのシーンはいったいどうやって実現しているのかわからない、ということでした。
ここの猛者の皆さんなら、この内容を評価できると思います。分かる方教えてください。
なお私はドラクエをやっていないのでそのシーンがどれのことか、想像も付きません。 どこのことかわからないな
ドラクエ4の船が出航するシーンでなくて？ >>740
ドラクエやってないなら教えても無駄だからスルー ファミコンで縦ラスターっぽいのは大抵BGのアニメーションとスクロールを同期させてるやつだろ
MMC5を積んでようやく可能 ディスクのスーパーロードランナーのタイトルも横だったな。 もしファミコンにアクセスランプがあったら
つきっぱなしになるんだろうか ありゃアクセスランプじゃなくて電源が入ってるかどうかの確認用だと
ランプ付けるのを企画した人が前にインタビューで言ってたな 俺も記事見たけど電源オンの確認用ってなんだろ
やみのなかでテレビ無しで使う人なのかな 通電してるかどうかの確認用でしょ
スーファミ以降はちゃんと本体側にLEDランプ常設だったね 同人ハードの電源LEDキットで無加工でもスイッチ部だけ光るようになってたりするから設計段階ではLED内側だったのかもしれない
同期のマークⅢとかはLED搭載してるしコストカットかもしれない
https://bakutendo.net/blog-entry-401.html この程度の改造にわざわざキット買う奴がいるんだな
それが驚いた >>754
回路わかる俺すげー自慢。
値段にもよるがキレイに仕上がるキットなら買う。 時間が余ってる人は自分で改造する
お金が余ってる人はキットを買う うーん。LEDつなぐのなんて、小学校理科の乾電池と豆電球のレベルに抵抗が必要ってだけだし
中学の時に技術の授業でLEDの光らせ方はまんま受けた奴もいると思うが
いくら小中の授業にあったとは言え興味ない奴が忘れるのは仕方がないが
ファミコン改造しようって層に、これが本気で知識マウントだと思う奴がいるのなら
それはそれで驚きだけどな >>759
レトロゲーム趣味でも中学校出てからハンダごて握って無いのはたくさんおるぞ どうでもええけどメトロクロスのイントロの部分ってカウントの音なんだな スカイキッドのイントロもステージとターゲット表記を兼ねてたな 8/16bitの家庭用機へのアフターバーナーの移植は、どれも背景がスカスカで寂しかったけれど、
ROMの容量を増すだけであれを密にすることは難しい？
VRAMに同時に展開できるパターンの数には限界があるだろうから、メディアの容量だけ増やしても
如何ともしがたい気もしなくはない。
もしメガドライブ2ミニにアフターバーナーが収録され、ニアアーケードモードもつけるとしたら
M2はどういうアプローチで改良するだろうか。
仮想ハードなのでCD部分の機能やV.R.のDSPを利用するみたいな大技もできなくはないけれど。 >>765
データ容量の問題以前に表示能力の問題だから難しい以前に無理だろ。
PCEやMDなんかでも表示中のデータはVRAMに持つ仕組みなのでVRAMに入るだけしか扱えない。
VRAMへの転送もそこまで速くないし。
FCはROMを直接読むけどバンク切替使っても同時に読める量は少ない。
MDのハード縛りでアフターバーナーを態々作る位ならAC筐体エミュで動かす方が良いのでは？
儲けを出す仕事でやるなら今更新規開発する理由が足りない。 >>765
アーケードと同じく背景をスプライトで書くと横並び制限で全然だめなので、やるとしたら背景を疑似ビットマップにしてそこに疑似スプライトを書く方式にするとかかな。
速度的には厳しい気がするけどナイストのように荒いドットすればどうにかなるかも？ 海面や雲海以外は、楕円形(これは回転させた時に破綻しずらい形だから？)の
草むらや水たまりの繰り返しが多くて、もう少し何とかならんのかなぁと思ってたけど、
それでもVRAMがカツカツなのだとしたら、ROMの容量があっても大して改善は望めないか…。
MDだと初期のタイトルで4MROMだったから、容量の足かせ無しに今の技術で移植したら
どんな風に仕上がるか見てみたいんだよね。
M2はPCEミニのグラディウスやファンタジーゾーン、ファミコンのギャプラスみたいな
ロマン枠というか採算度外視枠がある時があるので、期待してしまうんよ。 前回ダライアス新規移植がサプライズだったからファンタジーゾーン新規移植以上のことはしないでしょ
MDダライアスのカセット版は簡易ディスプレイチャートとか入ってて同人気質を感じたなぁ 生放送でもファンタジーゾーン以上のサプライズ要素はありませんってきっぱり言ってるしな アフターバーナー、他の人が言ってる通りだけどスプライト表現力の限界の問題だから難しいだろうね
FC版の場合、ロールの回転も擬似3Dスクロールもバンク切替えの力技だったと思うので
回転やスクロールをヌルヌルにするためにROMを増やすってのはできそう
横方向への並び限界があるから実用的かどうかわからないけど
シューティングの背景の星と同様、表示キャラが少ないときは地面のオブジェに回して表示物が増えたら消えてく
って技は使えそうだけどやってるのかな？ >>739 のRGB下駄、150ドルぐらいでもうすぐ発売みたいね
パレット変更とかもできるあたり横取りしたデータをFPGAで処理してアンプ噛ませて出力してるのかねぇ
議論はあれどファミコンのRGB出力が手軽になるのはありがたい
https://i.imgur.com/GXQl8Oq.jpg >>776
>>739 の理屈通りで当たってるならPPUハードエミュって感じかと RGBが話題だけど、俺はブラウン管に映した滲んだ映像が好きだ。
HDMI経由でも滲んで欲しい。 PPU出力だと仕様的に垂直線がギザギザなるのが気になるから個人的には嬉しい
もちろんにじみの味もわかるけどソフトフィルタで調整できるしなぁ ツインファミコンの画質には当時は衝撃受けたけど今見たらどうってことないんだろうな。 XBOX360の接続をビデオ端子からD端子に変えただけでも格段に良くなって驚いた思い出 PCエンジン龍虎の遠景近景切り替えってどうやって実現したんだろう？ あれは拡縮をやってたわけじゃなく解像度のモード切替でそれらしく見せてただけ >>783
SFC版はどうやったんだろな？
Mode7じゃないだろうし... >>783
縦方向はそれじゃ無理でしょ
ラスターで切って上下方向に描画位置をずらす手法を使ってる >>786
背景はモード7でいけてもキャラは無理じゃね？ キャラは全部スプライトでズームアウト時は元データ少し間引いてそれらしく見せてる ちなみにPCエンジン版の餓狼伝説2はアーケードカードの容量を活かして
手前と奥のキャラパターンを全部持って表現してた力業 >>790
スーファミ版の餓狼伝説2もこの方法だった記憶 >>790
スプライトの表示数から言って全てを細切れスプライトで実現するのではないと思うね。
SFCもVRAMに表示用にキャラパターンを持つのだから、ROM上のデータからの
間引き方を定義しとけばVRAM展開時に必要なデータが用意出来る。
問題は容量なんで最初に全て持っておくのは無理かもしれない。
ヨッシーアイランドタイトルはFXチップでリアルタイムスプライトパターン書き換えの力業だったようだ
https://www.nicovideo.jp/watch/sm14077914
この15分前後 >>792
表示数からしても余裕でしょ
ってか単にデータ総数としては一番デカい時のキャラ絵をスプライトで分割多めでもってるだけだし
背景はBG一枚絵 >>792
スーファミ版の龍虎の拳のキャラは全部16ｘ16のサイズで構成
いくらスーファミでもくのくらいは十分余裕持って表示可能
>>793
エミュで調べたら拡大時も縮小時も基本キャラのスプライトの枚数は変わらんかったよ
タカラのネオジオ移植みたいに技が出にくいこともなかったし上手いこと作ってたよスーファミ版の龍虎の拳 このSFC龍虎の拡縮のやり方は知った時には感心したわ
コロンブスの卵的だけど、なるほどなー！って まぁキャラを構成するスプライトをめちゃ分割してデータ削減（一種の圧縮）する手法はメモリが極小だったころのPCやファミコン世代では当たり前の手法だが、
それらはいろんなキャラに共通の部分をつくったりで「キャラパーツの流用」ってものだったからなぁ
キャラパーツ分割構成をうまく間引きに利用して拡大縮小を3～4段階も表現するっていうのは素晴らしいアイデア ファンタジーゾーンのアイダさんか
そういやファンタジーゾーンのボスがバラバラになる表現って普通に破片ひとつひとつのデータ持ってるのかな >>793
>>790 の検証というサイトの分割数だと足りないぞ、8x8クラスの分割
>>794
16x16での話なら 分割数内容ともズレてるというのでパターン用意と併用の可能性も有るけど
単に同時に2つのスプライトサイズしか使えない都合だろう。
＞ スプライトのサイズは、8 x 8、16 x 16、32 x 32、または 64 x 64 のいずれか
重ね合わせた時の優先順位制御と切れ目の位置が合ってるか？ > 16x16での話なら 分割数内容ともズレてるというのでパターン用意と併用の可能性も有るけど
> 単に同時に2つのスプライトサイズしか使えない都合だろう。
わかりやすいようにスプライトの枠付き表示でスクショ撮ってみた
ご覧の通りゲーム中は16x16のみでキャラを構成してキャラセレなどの一部で8x8を使用
1サイズ固定でやった方がゲーム中は処理速度を稼げたのかも？
https://nejitsu.minus-y.com/up/h/hgbCe1rG.png >>800
16x16ドットのスプライトが２ピクセルずつオーバーラップして87.5％表示になってるんだね >>800
１キャラ24とか25個のスプライトなので8x8ではスプライト表示数が足りなくなるね（１キャラ当たり同面積で４倍必要になるので） スーファミのモード7だっけ？回転とかするやつ。
あれって通常の背景重ね合わせできるの？
レースゲームで遠景あるけど。 >>803
無理
F-ZEROとかの遠景はラスタースクロールでそこだけ別に処理しているだけ >>804
スクロールではないね
画面上が別の画面モードで遠景表示
特定のラインでのラスター割り込みでモード７に切り替えてコース表示
上下２画面分割だったらラスター割り込み３回と垂直同期割り込みとかで
通常背景モード７通常背景モード７と切り替える感じ メインちょっと少ないけど基本ワークメモリで、ROM読み前提だからね。
ファミコンなんか2kBしかねえ。
CD-ROM2でメイン64kB そういえばファミコンの限界を超えたとか言って拡張チップ搭載のソフトが紹介されることよくあるけれど……、それ限界を超えたといっていいのかとふと疑問に思うことがある
究極的にはカセットにゲーム機の機能を丸ごと乗せてファミコン本体は電源とコントローラーの提供というカセットビジョン的なところまで行ってしまえるので
（MDの32Xなんてまさにそのノリだよね） さすがに限度があらぁなｗ
その拡張カセットそのものに別途電源がいるようなものはもう別ハードといっていいだろう >>808
ごめん、主語がないので何を主張したいのかさっぱりわからないよ
拡張機器（チップ）と限界の関係の話なのか、カセットビジョンについてなのか、32Xのことなのか
>>809
確かに32Xのゲームはメガドラの限界を超えたとか言われませんよね、メガドラではなくて32Xって機種
あれは確か映像出力も32Xからテレビのコンポジット端子に繋いだ記憶
（もちろんカセットビジョンと違って本体も電源とコンソールだけの提供ではないけど主体は32X側だと思う） NES DOOM あたりは意見がすごく分かれそう
あれも本体はカセット内のラズパイだけど映像は本体のPPU使うし、電源も本体からまかなえるし >>811
どっちが｢補助｣かによって印象違ってくるだろう。
個人的にはNES DOOM はファミコン本体のほうが完全に補助になってるものだからアウトかな。 拡張音源を数珠繋ぎして凝ったnsf再生してるのはもはやシンセサイザーだしなぁ
拡張カセットそのものに電源云々で定義するとディスクシステムの電池が引っかかるから難しい問題だな 何かのソフトのROMを逆アセンブルして、ソース風にラベルやコメント等も付けた上でそのプログラムの巧妙さを解説してあるようなサイトやブログはありませんかね。
故岩田聡氏らスーパープログラマの逸話はいろいろ伝えられていますが、もう一段、プログラムに近づいてみたいです。 N-BASICでそれやって出版差し止めになったのが35年前
ttp://www.isc.meiji.ac.jp/~sumwel_h/doc/juris/tdcj-s62-1-30.htm >>807
わかる
〇〇(ハード名)の限界ってのは、まあ便宜上というかキャッチコピーというか
ゴシップの見出しみたいなものだってのはわかりつつも
厳密にはどこまでがOKなんだろう…ってね
SFCにMDカセットを挿せるようにするアダプター型のMD互換機も
SFC本体からは電源とコントローラだけ貰ってていわゆるハード性能は全く使ってないし
逆にSFCだと処理落ちやロード時間が発生するようなMDのゲームがすんなり動作するし >>807
個人的には当時存在していたマッパーを使って後はソフトウェアでどうにかしている系のほうがワクワクするね 当時の環境なら使用ROM容量も最大8メガビットまでの制限付けないと >>811
過去スレでNES DOOMが話題になったときもその話になったよ
普通にそれぞれが別方向に突き詰めであるってことを理解してれば
それはそれ、そこはそこって話にしかならないと思う >>814
プログラム本位で解説するのを主眼とするとそういうのがあるか知らないけど
youtubeの内藤寛ちゃんねるでドラクエ絡みの動画を見れば
部分的にソースレベルのコードを解説して何をどう工夫したのかとか語ってる >>810
スーパー32Xはメガドラ側から32X側へケーブル接続して映像信号を入力して
32X側から合成して映像出力だっけか。メガドラ側は映像はBGだけ使用であとは音源の制御か >>809
ならディスクシステムもダメってなるなぁ
個人的見解は
あくまでもファミコンの性能ベースに拡張(メモリや音源)は有
32XとかNESDOOMみたいなのは無し >>825
ディスクシステムは拡張音源がRAMアダプタにある。これはOKだろう。
別電源が要るのはメディア駆動の為のドライブだから微妙だがOKでも良いのでは？
メガCDみたいなのはCPU追加とかが有るからダメ？
PCEのCD-ROM2はOKかな。 > PCEのCD-ROM2はOKかな
CD-ROM2もインターフェースユニット内にMPU内蔵して
CD-ROMドライブの制御などを受け持ってたけどな >>825
ディスクシステムは完全にファミコンだろｗ
極端だがデータ読み込むメディアが違うだけと言っても差し支えない あんまり厳密に考えすぎると原理主義的になって喧嘩になりそうだな
SA-1みたくメインCPUを置き換える動作をする拡張チップだってあるんだし、事例ごとに判断したほうがいいよ ファミコンの株式トレードのやつとかシャープのファミコンタイトラーとか扱いが難しそうなのも出てたな >>53
今更だけどファミコン互換にしようとしてた事（※結局頓挫）と関係あたりする？ >>826
自分のスタンス言うなら
メガCDも機能拡張だからOK
FCカートリッジゲームの追加容量や追加音源ももちろんOK
32Xはうーん…ってくらい
自分の発言は追加機能許さない原理主義者に対しての話
昔、ニコニコでFC音源チップチューン投稿してたが、
超原理主義者に文句言われまくって全消しした都合で原理主義者には過敏に敵対反応しめしちゃうんだよなw
奴ら追加音源ですらない内蔵DPCM使っても文句言ってきたからな 32Xはサターンの影に隠れて泣かず飛ばずだったけど、
本体側のスプライトとBG、32X側のビットマップが
それぞれの得意な部分を描画する役割分担の仕組みが
面白かった。
伸びしろは少ないがSH1使って1年早く出てたら、
後期MD市場はもっと盛り上がったかもなぁ。 >>827
言うけど、大抵ドライブにはコントローラチップがあってCPU扱いにするか微妙。
PC-8801系のFDDはZ80付いててサブCPUの様にも使えて面白い使い方幾つも有ったようだよ
ディスクアクセスしながらゲームと音楽が止まらないとか、簡単な圧縮データの展開とか
CD-ROM2のIFユニットはSCSI接続だったからSCSIコントローラとかじゃね？
当時のPCのキーボードにも付くくらい。
>>832
DPCMは割と知られてないからな、無知なだけなのに突っ込んでくる。
RAMアダプタ含め、拡張音源使った音楽も作ったのかい？ まだ現行ハードだった時期よりだいぶ後に出た製品とか、非公式ハードとかをアリかナシか話すのはともかく
現行ハード時代に出てた公式周辺機器をアリかナシかとかナンセンス過ぎないか？
以前、NES DOOMの話が出たときもこのスレの範疇を超えてるか超えてないかの話であって
別に個人的にアリかナシかとかそんな話じゃなかったからなあ
そんな話を一切するなとは言ってる訳じゃないんだけどね >>834
FDS+SCCとかN163とか自分がやってみたかった混成音源とか色々やってた
ファイナルラップ(←重要)N163単体あればPCEの内蔵は余裕で超えられたし、
更に内蔵音源同時でACやX68タイトル曲とかやってた 間違えたついでに
MSXでも音源フル(PSG+OPLL(MSXAUDIO)+OPM+SCC+tRPCM)で使ってみたとかやってた >>836
余裕で超えられるはないな
実機では発生数増えればノイズ多いしモノラル出力のみだし他にも色々と制限は多い >>839
ファイナルラップ(←重要)の意味知らないならもう良いわ >>840
それ込みでもPCエンジンの音源を余裕で超えるはねえわｗ
基本的にこのスレは実機で動作時を基準に語ってるし 音源チップ２個搭載で音質低下を抑えているのかなと検索してみたら、LPF搭載で音質改善しているってことね
ナムコの波形メモリ音源は実用的には４（５だったかな？）ポリが上限とアーケードの開発者インタビューで見たので
ファミコン拡張音源もそうスペックは変わらなさそう
モノラルなことを除けば内蔵音源との合わせ技で良い音鳴らすことはできそうだね 両方比較して「余裕で超える」その余裕ってとこがサッパリわからんわ
多分本人も詳しく説明できないんだろうｗ PCエンジンで内蔵音源を限界かそれ以上に使い倒した音ってあるんかいな
ファミコンでは複数挙げられるがPCエンジンはCD生音が出てきたこともあって少なくとも印象は薄い >>836
おお、FDSや波形メモリ含め、音色にも手を出したのかな？
なんかPCE実機のは波形メモリでも何かイマイチなのが多いのよね、SCCの方が良い感じ。
以下の人みたいに逆に拡張音源無しのMD本体音源で比較的新しい音源ドライバで作ってるのもある
https://www.youtube.com/watch?v=CFaXGosdvNs
音源ドライバが面白くてFM1ch使ってPCM再生出来るのを頑張って4chまでZ80でソフト合成
コチラも良く出来てる
https://www.youtube.com/watch?v=U9w4pK85tRw
>>840
ファミコンだとモノラルしか出せなかったと思うが違ったのかな？
時々疑似ステレオ加工してるのあるけど。 >>845
PCEのは確かFM音源のと違い1chで左右の音量変えられたんだった気がする。
音楽が割と良かったと思うのは、THE功夫、ネクロマンサー、R-TYPE、ネクタリス、マジカルチェイス
サイバーコア、はにーいんざすかい、魔境伝説、ベラボーマンも頑張ってた方か。
FCだとヘクター87とか月風魔伝とかグラディウスII
MDだと音楽だけしか取り柄が無いヴァーミリオンてのがあったな >>843
何故高音質化されたかというとスキール音で高音を綺麗に出すため
その影響で8ch使っても音質低下ほぼ無し
だからPCEは余裕で超えられる
>>846
左右に振るだけパンだからステレオって言わないんだよね(某氏の受け売り)
この場合のステレオモノラルは差異に入らない
>>844
あんたが>>843で説明して貰えて漸く分かっただけなのを人にすり付けんでくれない？
こっちが説明したらわかった口聞くのバレバレだから控えてたんだからさ >>847
ステレオの音響効果も良かったけどサンプリングをゲーム中に
実用レベルで曲やSEに組み込んで使えるってのが大きかったね
>>848
これで余裕で超えたか認識とか草だわｗ
左右のパンニングだけとかドヤで言ってるし
やはりこの程度のゲハ煽りだったかしょーもな
>>849
いい歳してゲハ語りは痛いよね > ファミコンだとモノラルしか出せなかったと思うが違ったのかな
ファミコンの音声出力はモノラルのみだよ
ハドソンのサンスイ版のジョイカードを接続してヘッドフォン端子からラインアウトさせると
十字キーの動きに連動して左右にパンニングさせ疑似ステレオにできたものもあった
ただこのサンスイ版ジョイカードからは外部音源の音は出力されないのでそこが残念 >>850
左右のパンニングの話は、俺の書いた疑似ステレオに対する話だと思うぞ。
従ってN163とPCE音源の比較に一切関係ないだろうに、
勘違いした上に煽り含めての対応は良くねえな >>850
無知晒してまだ足掻くのか
みっともねぇなぁ
>>841
❮知ったか❯それ込みでも❮無知❯
込まれてたのは嘘と見栄だけ
恥ずかしくないのかね >>846
ファードラウト伝説と風の伝説ザナドゥI・II はかなりいい音出してる
SCCの音が好みというのはサンプルの深さが違ってるのでその差なのかもしれませんね
>>848
（ニコニコは消したそうですが）ツベかどこかに実機録音のムービー残っていたりしますか？ コンパイルはファミコンでもPCエンジンでも良い音出してた
ぷよぷよがブレイク前は本当良ゲーたくさん出してたね >>855
＞サンプルの深さ
そうかもしれんね、PCEの方は初期の頃ビックリマンとか音割れ起こすのあったが
以後それを避ける為か、全体的に音量低めになったように思うのよね。
そこでサンプル時点で5bitフルで使わなくなったのかなと。
しかし設定時に8bit使うのに中途半端に5bit分しか使えないとか色々勿体ないよなあ
でも本当の所はD/A変換含めた音合成がSCC等よりタコなんじゃなかろうか >>857
元ウエストンの坂本さんがSNSでビックリマンの音響関連についてこうコメントしてた
移植は坂本じゃないので臆測ですが、当時は音量を合わす規定が無かったのもあり、
あまりケアは無かったのかもしれません。その上でモンスターランドの音を再現する為に矩形波を敢えてならすと
矩形波はエネルギー的に最も大きく歪んだ音ようなものなので他のゲームより大きくなったのだとおもいます。 メガドラばっかり言われるけどPCEも音割れ問題抱えてたんだな
まあ当時のコンシューマの音源なんてどれも問題あって当たり前だったけど >>858
マップデータだけ使い回して初期化処理から書いてるのか
先がずいぶん長そうだなｗ >>860
自分の遊んだ範囲では内蔵音源の音に問題感じたことはないので、初期作品の一部が問題持っていただけではないかな
ビックリマンは遊んだこともデモ見たこともないのでわからないけど、初期作品でいえばThe功夫は別に問題なかったよ >>862
The功夫は問題なかったよ、だけどビックリマンではボス倒した後のコイン散らばる所だったかでな。
多分>>859 の言う通り、5bitレンジの波形メモリで0と31だけで波形作った上で
ボリュームも最大とかやってしまったのではないかなと。
普通に波形作るならピークを31にすると思うのでピークの時間が短いサンプルになるはず ビックリマンワールドだけ当時のTVのモノラルスピーカーだと音割れしてたな
ロンチ組の中でも制作期間が短い上に制作ノウハウもまだ少ないとか色々事情があったんだろう
業務用のデータをPCEへコンバートを急増ドライバでやって調整不足なのもあったかもしれない
今聞くとビックリマンだけ他のPCEソフトとは音の鳴り方が異質な感もある PCE版R-TYPEのサウンドはコナミのSCCにかなり近くて
当時はグラ2と同じ音色だと感じたっけな pceの内臓音源でSCCのこのポワーンとした音色って出せる？
https://youtu.be/q9P5qw4B0R0?t=114
↑この部分のような ビックリマンはコインがダントツだけど全体に音デカかったような印象があるな
店でのカーソルの音とかピンチの時のアラームとか
タイトル画面のパンパカパンパンパーン！ってファンファーレとか >>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を超えると書き込みができなくなります。
