スプライト 4本目
9918系でバンク切り替え実装できたのは
MSX系とSG1000系ぐらいじゃね?! >>146
MSXのようにM1サイクルにウエイトを入れてはいなく高速ROMを使ってるとかかな 8ビット機でそれなりの解像度の多色ビットマップ画面を持とうとすると、
鬼バンク切替を甘受するか、VDP方式を選択するしかないのが辛いところやのう。
メインを張るには微妙な性能ゆえ、安売りされてる16bitプロセッサがもし都合よく見つかれば
そいつにグラフィックサブシステムの制御を任せるという手もあるかもしれないが。 ヤマハYIS(PU-1-20)かな
512×384ドット表示(256色中8色)
グラフィックサブCPUZ8001 >>141
m5ってファミコンやMSXみたいにメガロム使って大容量のゲーム走らせること出来ないのか? メガロムなんて余裕で乗る
メガロムの仕組みを確認しなはれ 乗っても、使えるのはそのうち8kBです
とか(笑) MSXはシステムの根幹にバンク切り替えの仕組みがあり、メガROMもその仕様の上に増設する形だったが
(具体的にはスロットのページ1のバンク1枚16KB、もしくはページ1と2で32KB(16KBページ2枚)をバンク切り替え)
M5はそういうの無いんだろ?
なんならROMの内容がCPUのメモリ空間に0番地から直で出ているくらいの
それでROM側でバンクを切り替えると、0番地からバチンと全部切り替わるような、凄まじい(乱暴な)仕様で。
ファミコンなんかもそういう作りだが(そういう作りにするしかなかったのだが)、まあそれで動くなら問題なかろう… カセットのアドレスは16本フルに配線されてるんだからバンク切り替えの細分化は積むかどうかだけだろう
ttp://blog.livedoor.jp/hardyboy/archives/9448294.html
SORD M5 ROMカートリッジ調査
ttps://livedoor.blogimg.jp/hardyboy/imgs/a/3/a39e9d36.jpg PCが指している(実行中のコードの載っている)空間が切り替わるのは、ちょっと落ち着かない
OSなりBIOSなりがあって、あるいは別ページにバンク切り替えや管理用のルーチンがあって
そこへ飛んで切り替え、とかならまあ… プログラムコードの載ってる部分を切り換えると乱暴なのか?
バンクはデータ部分だけにしろと?
全くもって意味不明だな バンクごとにバンク切り換えの共通プログラムを同じアドレスに書いといて、
まるごと切り換えなんて普通にあるが
落ちつかないってどういう意味 m5はカートリッジスロットに拡張スロットを付けてFDDを使うシステムだから
バンク切り替え用の信号も作ることは出来るだろうね >>157
m5のカートリッジスロットのバス配置はsordに問い合わせしたら教えてくれたよ ROMカートリッジにFDDとか少し怖いな
カセットちょっと触れただけでフリーズとか >>165
カートリッジにスイッチを付けたファミリーベーシックにも言ってください >>165
MSXにスロット経由でFDD増設してたけど、よほど力を加えない限り普通に使う分には大丈夫。
スロットにトラウマ抱えてるサターンユーザーかな。 MSXのカートリッジスロットってかなり頑丈で、深く刺すように作られてるよね >>168
MSXはそうだけど、m5はどうなん?
PC-6001とかはI/O使用が確実だったので、むちゃくちゃ深く刺さるようになってたけど P6はスロット内にリセットスイッチついてたね
指突っ込んだらカチッと落としてリセット掛かって入力中のプログラムが台無しになった覚えが >>170
消しゴムキーボードが4つ千切れるまで使っていたけど最後の方は振動に敏感だったねぇ・・・
新品の頃は問題なかったけど。スロットに紙を挿してグラつかないようにしてた
カートリッジを挿さないと電源が入らないようになってるのがまた曲者で
ACアダプタからカートリッジスロットを経由して本体に電源が引き戻されてた
ヤフオクなんかで電源が入らないというのはこのパターンもありそう >>168
ファミコン時代ですでに経験してると思うよ
サターンの場合は振動を与えるまでもなく差してもて認識しないレベルだからw
で、何度か抜き差ししてると中身が飛んでるwwww サターンの狭ピッチのスロットは抜き差しに耐えられるように作られてないよな で本題ですが
サターンのスプライトでちらついたりした例は? >>175
サターンのスプライトの仕様でチラつくなんてあり得んの? >>177
結局おまいらが言うところの疑似スプライトやん TOWNSを散々バカにしといてだよなぁ
手のひらくるくる まあ、だいたいoh!Xの無知なライターが悪い
あの雑誌、TOWNS関係は嘘ばっかりだったよ
鵜呑みにするX68Kユーザーもアホだけど >>141
パワーパック(スーパーパックマン)も8KBなの?
BGM単音だしコーヒーブレイクも無いけど
スーパーパワーエサでパックマン巨大化するし
ドット(フルーツ)も面毎にキチンと切り替わるし >>181
両方DOS/Vごときに負けた理由がよくわかったわ DOS/Vに負けた?
どこの世界線ですか
Windowsに世代交代したのならわかるが まあDOS/Vのアーケード移植ゲームをみると、見るも無残なものばかりだけどな
ガイジンってあんなので満足しちゃうんだ >>182
ギャラックスもマッピーも全部8KBだね
マッピーはBGMが中途半端にループするし
16KBを使ってるのはBASIC-Gだけ
M5で気になる点と言えばカートリッジスロットの電源端子を繋げて
カートリッジを挿さなくても電源が入るようにすると電源ONと同時にカセットのリレーがONになる事かな
もしかするとRAMだけのカートリッジを出す予定があったのかも?
RAMカートリッジとカセットテープでソフト供給みたいな感じで いや、既にあるのよ32KB増設RAMカートリッジ(EM-5)
超レアだけど >>185
そんな一般ピーポー向けなパソコンではそもそも無い2機種
マニアの関心としてDOS/Vに負けてマニアな人材を取られて流れ変わってた
Hi-TEXTとか出たのでどんどんと切り替わってた
1991年あたりでマニアの趨勢は決まってたぞ
OADGとして富士通もシャープもこれからはDOS/Vでやって行くって決まってたし
テキストの一覧性の高さがプログラミングにもコミュニケーションにもいかに効率上がるか一度接すると離れられなくなる
Windowsでは3.0の頃で別にWindowsが勝つとはまだ決まって無かった 98も68もTOWNSも、製品寿命を迎えて、
次の世代はAT互換機に譲ったってだけなのにな
なんでDOS/Vが勝ったことになってんの
しかも1991年に
IBMなんか1993年頃にTOWNS互換機なんか作ってたりするのにな >>188
あれって拡張スロットを使ってBASICと2本差しなじゃなった?
32KBのSRAMも今となっては数百円だしキーボードも今の知識なら作れるから廃棄しなければよかったなぁ
BASIC-Gのカートリッジとカートリッジから引っぺがしたROMだけ残ってる >>191
本来の用途はそうなんだけど、
電源スイッチの代わりにRAM刺したらどういう挙動をするかって話だので
自動的にマシン語のテープを読みに行くってのはあるんじゃないかな >>189
>>190
実質無条件降伏やん
98は21世紀まで粘ったのにな townsはFMRベースだからFMRを続けないとなった時点で袋小路だったからな
プログラミングに関心有る層は富士通がDOS/V陣営に入った時点で先が無いのは当然に読める >>193
本体基板側にROM用?の空きパターンが有るから
そこを利用してある程度ジャンパ飛ばすだけでなんとかなりそうだったんだよね ハードウェアマウスカーソルって、8x8dotで1個だけ定義できるスプライトってコト?
OSがGUIではない時代でも、マウスを使うアプリであればこの機能があるのとないのとは大違いなので
EGAや(GUIなOSで使うことが想定されていない時代の)VGAのチップにも既にあったりしたのかな。 そいえばPC98のMS版マウスドライバはテキスト画面でマウスカーソルを出すモードもあったな >>198
IBMPCだとテキストモードはテキストだけしか出せなかったと思う
マウスカーソルはキャラクタ単位でカーソル(というかカラーアトリビュートでの反転?)が動くだけだったよ
>>199
PC88/98ってグラフィック画面とテキスト画面が違うプレーンだから
割り込みなんかを使ってグラフィック書き換えさえれたら区別付かないんじゃない? 98用QuickBasicとか、テキスト画面のマウスカーソル使ってたね ありがとうございます。
反転した■がキャラクタ単位で動いてカーソル代わりにしている感じのようですね。
(テキストモード時でも一般的な斜め矢印カーソルを表示しているアプリは、力技で描いているらしい。)
グラフィックモード時については海外の掲示板の書き込みを翻訳に突っ込みながら読んでみたのですが、
VGAの段階ではハードウェアによるカーソル表示の仕組みは無いみたいでした。(XGAからはあった模様。) VESAのBIOSがXGAベースの拡張で規格化されたのでスプライトも規格化されてたのか ラインバッファはコンシューマ機ではPC-FXが最後になるのかな? XGA辺りから乗り始めたマウスカーソル用のスプライト?は、ハードウェア側の実装が曖昧だったり、ソフトウェア的にも不安定にならざるを得なかったので
少なくともLinux系のディスプレイドライバ(デバイスドライバ)では利用されなかったり、利用しているものでも注釈つきだったり、それで誰も使わないので、メンテも碌にされなくなり…で、ほとんど活用されていないと思う
Windowsでも、マウス用のハードウェアカーソルなんてろくに活用していないだろ
Vista以降は全部GPU(かCPU)描画だし LinuxはVESAのBIOSがプロテクトモード対応するよりも前からプロテクトモードで動いてたから自前でやるしか無かったからでは TMS9918を9928に乗せ換えてRGB化してる人が楽しそうだなぁ 三杯飲んでもまだ余る
・・・ってネタ。おぼえてる? >>205
そういえばWindows95とか98の頃ってマウスカーソルの動きガタガタだったよな
同時期のMacOSのカーソルはスムーズだったのに >>210
どんな安物マシン使ってたのよw
95の頃はもうGDIで1ドットづつ描いてもスプライトと同じ程度の処理ができるゆになっていた >>212
いやあどう見ても20fpsぐらいで滑らかじゃなかったわ
プリエンプティブマルチタスクじゃないからカーソル描画に回ってくる間隔が長いのかも 今でもマウス素早く動かすと10分身くらいに見えるね 通常使いでは気にならなかったけど
「炎のコマ〜!」ってやるとカクカクになったな
現在のマシンだとちゃんと追従している Win3.1から95になった時のWinGの進化は結構すごかったな。
Windows95が出て間もない頃にリリースされた"Pitfall: The Mayan Adventure"は
スーファミやメガドラに見劣りしない感じだったので、これならスプライトはもう
イランなと思った。 最近のxboxもpsも、中身は只のAT互換機だもんな
OSがWindowsかLinuxの違いくらいか >>213
3.1はともかく95はプリエンプティブだぞ? >>218
2000からだろ
95や98は一つのアプリが暴走するとシステム全体に影響を及ぼす >>85
ソフトウェアによる完全重ね合わせ処理のことをソフトウェアスプライトと称するのは当時の一般的な用法だよ
移動単位は関係ない >>219
通常はユーザーコード以外にタスクスイッチの契機が有るか無しかの違いなので、これに従えば95は非協調的マルチタスクを実装していると間違いなく言えるよ 95の頃はDOS窓でsymdeb立ち上げてg=ffff:0000とやると簡単にリセット掛かったもんな プリエンプティブマルチタスクとシステム保護を混同してるアホが居ると聞いて、助走をつけて殴りに来ました 95の頃はDOS窓1つ死ぬとマシン全体が簡単に死んだりする
所詮、DOS上で走るGUIに過ぎなかった
しかも死ぬと再起不能に陥ることも多く、バックアップCDが欠かせなかった プロセス保護が(DOS環境との互換性維持のために)意図的に緩くなっていたことと
プリエンプティブマルチタスク「でない」という理由は直結できない
プロセス管理(保護)が未熟であることとプリエンプティブマルチタスクは両立し得る
実際にプリエンプティブマルチタスクでありながらユーザープロセスからOSを破壊できる実装も、黎明期にはWindows以外にも幾つも存在した
なお同時代のMacはなおイベントドリブンの原始的で劣った疑似マルチタスクであった
たぶんこっちの方が指摘されたくない「不都合な事実」ってやつだろう ということで、「最初にプリエンプティブマルチタスクを実現したメジャーなコンシューマ向けOS」は、アンチがどう泣き叫ぼうとWindows95で間違いない
MacOSは9の途中辺りまでイベントドリブンの疑似マルチタスクで、Windows3.xのレベルのまま見た目だけでユーザーを騙していた
フルプリエンプティブな、近代的な32bitOSと言ってよいOSXに切り替わる(「登場する」ではない)まで、さらに4~5年くらいか。WindowsはNT4から2k、XPととっくの昔に、完全に地盤を固めた後で、ようやくのお出ましで。
それでMacの方が先進的とか言っていたものだから、ちゃんちゃらおかしい それと9x系が「DOS上にGUIを載せた~」的に騙る連中はド素人で、騙る内容も本人自身が理解できていない受け売り。
こういう連中が吹聴するデマによって今でも誤解されがちだが、9xのWin32環境は完全に32bit化されていて、Win32プロセスは16bitコードの影響など受けずに完全に32bitで動作していた。95の、最初の段階からだ。
95に残されていた16bitコードはDOSとWin16(Windows.3.x)との互換性のためのもので、DOSやWin16のバイナリ(アプリケーションのみならず、当時はデバイスドライバも16bitとの互換性を残していたので、これが安定性(の低下)に影を落としていた)を利用しなければ、これらとは無縁で居られた。
まあ、現実にはWin3.1で使っていたWin16のバイナリをそのまま移行し、DOS窓でもまだDOS環境を併用し…というのが実態だったわけだが
デバイスドライバ周りだけでも32bitで固められれば、それだけで安定性は有意に向上した。
まあ32bit版のドライバが既にあるのにconfig.sysでDOS版のドライバを組み込むアホとか、普通に居ましたからね…そんなアホでも(とりあえずは)使えたWin95 3.1は確かMS-DOS+エクステンダな構造だったと思うけど、95の時点で既にMS-DOS7部分は単なるローダーに過ぎなかったような? ブート時に起動されるDOSは、Windows起動後のDOSモードやDOS窓で呼ばれるDOS環境ではないしな…本当にただのローダー
16bitの(DOS用の)ドライバを読み込むだけのローダー。そんなもん使わん人にとっては文字通りのレガシー 95/98はまだDOSしてる
config.sysが廃止されたMEこそDOSではなく只のOSローダー >実際にプリエンプティブマルチタスクでありながらユーザープロセスからOSを破壊できる実装も、黎明期にはWindows以外にも幾つも存在した
Amigaとかこれだったなあ…OS/9系もか
Macは、かなり後年までイベントドリブンの疑似マルチタスクで
Finderでフロッピーのフォーマットがバックグラウンドでできるのでマルチタスクだ!Windows(当時は3.1)にはできない!!とか言ってホルホル勝ち誇ってたけど
TSRでフォーマット専用のプロセスを用意していたという、完全に見せかけだけの騙し
誰かDOS上でバックグラウンド動作するTSR型のフォーマッタ作ってたよね(笑)実用は禿げしくお薦めしない(笑)とか明記されてた DOSエクステンダの一種なDPMI仕様でマルチタスク対応プロテクトモード化したDOSの上のGUIって形でしょ
単にプロテクトモード化するだけだったVCPI仕様DOSエクステンダでも32bitDOSな32bitOSと言えてたのに、
更にマルチタスク対応でDPMIがOS本体なような話になってるが一応はDOSに積み上げて行ってる形
単なるローダーの上書きして消されて行くのとは違うかと X68000やTOWNSのスプライトやBG性能に満足できない人が増えてきた頃に、
スプライトは無いが解像度320x240くらいの画面全体を60fpsで描き換えられる性能の
AT互換機が身近な存在になっていたら、新天地を求めてそちらへ移行する人が
少しは出たのだろうか。 そいえばセガマークIIIのスペースハリアーがスプライト使わずにBGを直接書き換えて巨大なキャラを表現してたね
縁に8x8ドットの輪郭が出てたけど、Z80の力技でここまでやるのすげぇと思ったよ あの時、中さんが頑張んなかったらマジでX68ファンタジーゾーンのスペハリ面みたいな横シューがスペハリ移植第一弾になってたかもだぞ エキサイトバイク化したエンデューロレーサーはスペハリの後か?
あれコンシューマ移植に恵まれないな。ひょっとしてマーク3が唯一か? アフターバーナーやギャラクシーフォースも
ゼビウスかグラディウスに毛が生えた代物だったろうな 縦シューになったアフターバーナーは見たい
ギャラクシーフォースはザクソンみたいな感じで
スペハリが横になったらロストワールドみたいになるか? >>240
Windows95発売と同時にリリースされたピットフォールは、まだCPUパワー不足だったのか、
全体的にガクガクで、いかにもスプライトの無いPCでアクションゲームを動かしてみたって感じだった
まともに動くようになったなと感じたのは、Pentium-120MHz機上で2Dシューティングゲームが動いているのを見た時か 486とWin95からならアクセラレーターのBitBlt性能に依存するだけでは
全部アクセラレーター任せでも遅延するほど486は遅く無いかと DOSならmameとか普通に動いてたな
スプライト要らんと思った当時 高速書き換え可能なビデオメモリ環境とプロセッサが用意できれば
スプライト機能やスクロール機能といった将来足枷になるハードは要らなかったのは確か
只それを当時実現しようものなら新車一台買える値段をPCやゲーム機購入に要求される Win95からは、それまでの3.1の16bit環境でしかないWinGとは違う、32bitなDirectXが使えるようになった
DirectX向けに高速化競争が始まる前の初期対応でもS3社Trio64世代な訳で
3DとなるとViRGEが1996年のDirectX2.0で実際に使えてからとなるが、
あくまでも2D性能での話ならそこまで高くも無かった
VRAMにEDOが使えるようになって汎用なDRAMにできて低価格化できてた
当時のカードとしての販売価格で199米ドルとかの
http://www.dosdays.co.uk/topics/Manufacturers/paradise.php#BAHAMAS
Bahamas 64VL
Launched: 1995
Bus: VESA Local Bus
Chipset: S3 Trio64 (86C764)
Memory: 1 or 2 MB DRAM
RAMDAC: (Integrated)
RAMDAC Speed: 135 MHz
FCC ID: JDF-764VL-001
Cost When New: $199
The Bahamas64VL was a 64-bit DRAM-based accelerator card for Windows. Based around the S3 Trio64 graphics chipset, it featured hardware cursor, BitBLT, pattern fills, short stroke vector and line draws in hardware. DOSゲーやるならET4000って当時の雑誌でよく見かけた プレステですら多重スクロールする2Dゲームになると苦しかったのに486なんてムリムリ >>248
MAMEなんかで遊べるのは何世代も前のゲームだったし
リアルタイムではスプライトも回転拡大縮小の時代に突入したりで常に最先端だった覚え
ポリゴンをスプライト代わりに使えるようになったけどスプライトという概念は残り続けてる気がする VRAMが32bit以上で接続されたビデオカード(マザボとはVLまたはPCIバスで接続)の出現で、IBM-PCのイメージが結構変わった気がする。
時期的にX68000やTOWNSの性能にも限界が見えてきて、新しい箱庭が求められていたタイミングとも重なるので
このタイミングでPCを対象としたホビープログラミングに主眼においた専門誌が創刊されて、日本語情報の少なさを補う環境が
できていたらよかった。
もしそこを起点にソフトが充実してハードも普及する好循環が生まれていれば、国内ゲーム業界のガラパゴス化も多少は防げたかもしれない。 PCの開発情報なら
ftpでInterrupt List入手したらほぼ網羅できたよ
英語っていってもコンピュータ英語で平易
洋ゲーのマニュアルの方がよっぽど難解だった いろんな規格のパソコンが有ったからこそユーザーは楽しめたという見方もあるとは思うけどな
とはいってもAC機ではBG+スプライトの構成はポリゴンゲームが出るまで変わらなかったし
スプライトやBG以外にグラフィック面を持ったゲームってかなり少なかったと思う
リブルラブルのグラフィックの描画速度に驚愕したけど あれ日本初の68k使ったアーケード機だったんだよな・・・
ちなみに同時期のポールポジションはアドレス空間64kBのZ8002 CPUの計算とビットマップの画面更新が追いつけば、
スプライトも回転拡縮も要らないって未来は見えてた 今でもGPUに依存してCPU任せな低品種なんて論外扱いでは
CPUだけでできる程度ではその時代時代での低品質扱いなままで来てたかと
例外はスペースインベーダーくらいのような インベーダーは完全なビットマップ画面だったし
凄い高度なことやってたんだなと感心する
それこそ1ドットの当たり判定も可能 沙羅曼蛇等は全面を埋めきるだけのBGパターンが利用できるのでBGをビットマップ画面のようにも利用できたね
細胞壁や火山の岩堀りシーンなどの破壊可能な背景等で利用していたはず >>260
インタビューによるとCPUだけでは無理だったそうです
亀井氏「あれだけの多くのキャラクターを動かすとなると,あのCPUでは非力なので。シフトレジスタっていう回路を組み込まないといけなくて」
ttps://www.4gamer.net/games/464/G046469/20200324041/ インベーダといえば、PC-6001へのソース移植
https://www.youtube.com/watch?v=5Pjs-Ce45gg
Z80の8080エミュレータを使って、ソースだけで動くみたい >>263
パックドピクセルなら要らないがプレーンなら表示にはシフトレジスタを使うのが当たり前で意味が分からない
多分、書き換えの方でCPUとVRAM間にシフトレジスタを入れててプレーンなのにパックドピクセルのようにドット単位で書き込めるようにする回路が入ってるって事なのだろうが >>255
むしろX68000・TOWNSの性能限界云々以前に
98VM以降と言う環境に慣れすぎてしまったとしか グラボが故障した時にドライバをオフにした状態でウィンドウの操作をやってみたら、
X68k版沙羅曼蛇のフレアみたいにペラペラと画面を書き換えているのが丸見えだったな
こんだけCPUパワーが上がったんだからCPU描画だけでも余裕じゃなかったのかよ >>267
CPUパワーが上がっても常時VRAMにアクセスできるわけじゃないから
緩衝材としてのビデオプロセッサは必要になるだろうな >>262
TMS9918のグラフィックなんかはまさにそれだよ
キャラクタを敷き詰めてキャラクタのパターンを変更する事でグラフィック画面を作ってる
メガドラのハードドライビン、スタークルーザー、シルフィード、スターブレード、バーチャレーシングなんかも
BGのパターン書き換えでポリゴン画面を作り上げてる システム自体は相変わらず無効リージョンがたまったらまとめて描画するスタイルなのでCPUの速さとか関係ない
ゲームみたいに動かすにはダイレクトドローで60fpsなんなりアップデートするようにプログラムするんだよ WindowsがXPになった時、インストール直後のビデオドライバ未導入の状態でも画面表示が16色ではなくなって
一瞬気分が上がったが、スクロールとかウインドウの移動時に描画がやけにモタついて困惑したな。
いくらアクセラレータがまだ使えずCPUで描画している状態とはいえ、XPってどんだけ重いのかと戦慄しちまったぜ。 7になってもエアロ切ってクラシック表示でGDI描画使ってたな 動画でみたがメガドラ用のマジコンでメガCD対応?テラドラでも動いてた
ってことはカートリッジにメガCDのVDPやCPUついてるのかな(えみゅだろうけど) >>273
カートリッジ内にARMが入っていてメガCDの機能をエミュレーションしてるよ
SDカードにCDROMのイメージを入れておけばOK
メガCDにはCD再生機能が有るんだけど音楽CDのイメージは認識しなかった
試しにゲームのイメージ+CDDA差し替えを行ったら音楽CDは再生できるようになった 面白い機能としてはファミコンのROMが使えてる
ARMがファミコンのエミュを行った上で
ファミコンのスプライトとBGをメガドラで表示できるBGとスプライトの形式に変換して
メガドラがその受け取ったデータをフレーム毎に表示してるっぽいね
BGMはARM側がアナログ出力の段階までエミュレーションして
メガドラのカートリッジスロットにあるサウンド入力に流し込んでる
ただマッパーには未対応で初期の32KB+8KBまでのROMしか使えない
ファミコン版エバドラのマッパーを取り込んでくれれば出来そうなんだけど Everdrive PROだったらメガドラでDooMもWADを用意すれば遊べる
コンシューマー機でアーチバイルにも出逢える数少ない環境だぜ 脱線回避ついでに
>>268
と言うかCPUでさえメモリ内蔵だしな
更にGPUはVRAM以外のメモリも内蔵するようになったし 結局はメモリとプロセッサとの間がボトルネックなのは変わらずと
32bitCPUが出た頃にキャッシュを増やすならと試されてたメモリの方にプロセッサを内蔵してメモリの数だけマルチプロセッサにするってのにGPUの方で勝手になってってるのかな
メモリ空間を跨ぐとプロセッサの処理もバトンタッチして行ける連続メモリマップなんかが研究されてたな >>275の補足でファミコンのスプライトは横8ドットで横並び8枚までだけど
メガドラのスプライトの横並び制限は256x224時で16枚or256ドットだから
ファミコンでスプライトが欠けるゲームでもメガドラでは欠けなくなる
ただ、ソフト側で優先順位のローテーションを行っている場合は
欠けないけどちらつきはそのまま起きる 優先順位を順繰りで変更することでスプライトが一瞬だけ消えるからちらつくって理解してるけど、
メガドラのVDPだと消えなくなるのにちらつくってどういうことなんだろ >>271
重いのではない描画が優先順位で最低だから
ディスクI/Oや内部計算がアイドル状態になってやっと描画する
ビジネス用OSだからなあ
ゲームはフルスクリーンで実行が基本になってる >>280
説明不足だった
スプライト同士が重なった時ね
ローテーションしていて不定期なタイミングで上下が入れ替わるから これから開発するファミコンソフトは、エミュや横並び制限が緩和された改良型PPUの存在も考慮して
ローテート表示オフのオプションをつけておくと一部で喜ばれるかもしれないな。
メガドライブの話が出て思い出したけど、「慶応遊撃隊」の後半ステージはスプライトが派手に
チラついたり欠けたりした記憶があるけど、あれもう少しなんとかならなかったのだろうか。 横にいくつまで並べられるかはスプライトVRAMのアクセス速度次第? もう何周目になるのか数えるのも面倒だが、横○個制限はスプライトLSI内のラインバッファ(ラインレジスタ)の本数依存。
この時代のラインバッファ型(ラインレジスタ型)のスプライトに「スプライトVRAM」なんてものは存在しない
フレームバッファになる直前、ほんの一瞬だけラスターバッファ型のスプライトが実装された歴史はあるが
日本の少なくともコンシューマゲーム機はラインバッファ(スプライトLSI内部のラインレジスタ)型からフレームバッファ型へ一足飛びしたので
実装例はおそらく存在しない、あるなら提示ヨロシク スプライトLSI内のレジスタ数は、Hブランク期間中にスプライトのステータスやパターンを1ライン分読み取ることのできるメモリやバスの速度に依存している(上限がある)、という言い方はできるかもしれないが
特に初期のスプライトLSIは、そこまでギリギリの実装でもないだろう。集積度の方が制約として大きかったのでは >>284
メガドラだと欠けを意識してローテーションするようなゲームは多分無いんじゃないかな
スプライトアトリビュートはローテーションを意識した作りになってる気がするんだけど
スプライトナンバーと優先順位はそれぞれ別に割り振られていて
スプライトナンバーはアトリビュート順なんだけど、そのアトリビュートにリンクデータという物が有る
0番だけは固定で0番スプライトのアトリビュートには次に表示するスプライトナンバーを指定するようになってる
リンクデータが0になったらスプライト表示はそこまでで終了する
0番のリンクデータが40なら次は40番のスプライト、40番のリンクデータに21番が有ると次は21、・・・という感じ 前に聞いた話だと
Vブランク中にスプライトアトリビュートのY座標を読み込んで
スプライトをどのラインで表示するのかをあらかじめ取り込んでおく
Hブランク中に該当するスプライトのX座標を取り込みスプライトを表示していく
この時のX座標用のバッファが20枚分しかなくそれ以上は欠ける
とかなんとか。ただ、これだと表示期間中にスプライトアトリビュートを書き換える
スプライトダブラーという手順が踏めないような気がするしちょっと謎 ハードウェアスプライトダブラーと言う発想はなかったのか >>263
なかなか貴重なインタビューだな
音源の76477がUFO飛来音だけで、後は抵抗やコンデンサの組み合わせで出してたのは知らんかった >>290
スプライトダブラーが使えるシーンは限定的だからねぇ
ソフト側が意識的に操作する必要もあるし >>263
ここで言うシフトレジスタってのは、例えばOUT (xxH), Aと書くと、あるラインをAドットずらす
みたいな機能かな >>290
コナミのタイムパイロットがそれだね
多重スクロールしている背景の雲(隕石)がスプライトで、1募スプライトを縦横128ドットオフセットした箇所に複製して表示することで背景がスカスカにならないようにしてる模様
ttps://www.youtube.com/watch?v=6DBrw6LAVDQ の 1:40秒くらいから
動画の説明は要領を得ないので mameのソース確認したところ上記ような処理のようでした タイムパイロット・・・BGM豊富なコナミにしちゃ地味なゲームだったな 3杯飲んでもまだ余・・・
うん、いいんだ我も知らなくても・ 昔は500mlと言ったらホームサイズだったが、今は完全にパーソナルサイズだもんな
コンピュータやネット以外でも時代は確実に変わったよ タイムパイロットはコナミ時代の岡本吉起の貴重な作品 >>290
横同時表示可能数以上に設定できるスプライト数がハードで対応してるスプライトダブラーそのものでは
スプライトとして物理的に配線されてるのは横同時表示可能数そのものなのだし
それ以上のスプライト数はスプライトダブラーで表示してもスプライト 数として確保されてても表示自体の違いは見えない >>300
そのりくつはおかしい
それだったら
MSXは最大4〜8枚まで(実際は32枚)
X68は最大32枚(実際は128枚)
になっちまう
むしろ
32枚を64枚に
128枚を256枚に
ならないと意味ないし 配線されてて直接表示可能な数が横に並べられる数として最大数なのはそのままだから
表示できないから横最大数を超えると消える
消えるが座標だけはハードとして確保して空きができたら表示して行くのだからスプライトダブラーと同じ事をハードでやってるって事 スプライトダブラーを行う時はVDPが参照しているスプライトアトリビュートの切り替えが必要だから
80枚のスプライトを仮に160枚として使おうとした時、画面上半分に160枚表示させるのは不可能
例えば縦の解像度が224だとしたら0番スプライトはY座標0~111の範囲と112~224に分けて表示する必要がある
ハードでやろうとしてもソフト側でそのことを意識する必要があって
その事を考慮しない場合は表示できずに消えるだけ
そう考えると>>300の言いたい事も分かる気がする
ハード側で横並び20枚制限が有ったとしてソフト側で25枚並べてしまったら
21枚目以降はデータとして存在するけどハードでは表示されないからねぇ
PCエンジンやメガドラの場合は枚数制限の他にドット数の制限もあるけど 水平の表示上限と総数制限は別種の上限ですよ
スプライトダブラーというのは表示【上限を超える】手段のことを示すわけで、水平制限を超えることは不可能なので(ローテーションは超えていない)
スプライト属性テーブルの数以上の表示が出来ないならばダブラーとは称せないのではないでしょうか
あらかじめ用意されたテーブルの数以内なら幾ら表示しても上限超えとはなりませんので
タイムパイロットのように機械的に属性テーブルを二重に使用できる特殊ケースを除くとハードウェアダブラーは存在しないのでは?
(ソフトウェアで行うような柔軟な調整を実装しようとするよりも、属性テーブルを増やすように再設計する方が手っ取り早いでしょうし) その属性テーブルを増やす事がハードウェアダブラーなのでは
最小な属性テーブルは水平最大数なのだから、それ以上の属性テーブルはハードウェアなダブラーと同じ事って 回路A、水平256ピクセル、テーブル数32
回路B(A改)、水平256ピクセル、テーブル数64
という2つのハードウェアがあったとして、回路Bは回路Aに対してダブラーを実装したと見做すってこと? ハードウェアダブラーを要求して、単に増やしたので対応したのではダブラーとは言えない別なハードウェアダブラーって何?って事 じゃないか、上で言うと256ピクセル以上表示可能な属性テーブルがあればダブラーとみなすということでいいのかな
いや、制限超えてないよこれ
実際の回路との比較でなく仮想的な回路、例えば
回路0、16x16ドット固定スプライトで水平16個、テーブル数16
という回路があったと想定して、
回路1、16x16ドット固定スプライトで水平16個、テーブル数64
という回路が実際にあったとしたら、仮想回路0に対して回路1がダブラーを実装しているとは言えるかもしれないが、実際の表現力に変化出るわけでもないので言葉遊びの域を出ないよね >>307
306 のように元の回路を改修してテーブル増やせば、元の回路に対してのダブラーとは言えなくもないかもね
308 のように元の回路がなく仮想的な回路に対して増やしてもダブラーとは言えないかな 294は回路に実装されたテーブルを機械的に再利用して実装テーブル数以上の表示を実現しているのでダブラーと言えると思う 294は追加の属性が固定のダブラー
308の回路1は任意の属性を指定できるダブラー ファミコンはスプライトに透明+3色使えるのに、透明+2色で済ませてたキャラがあるゲームがあるのは、絵のデータ量を削るため? >>312
ちょっと違うケースだろうけど
ファミコンのキャラクタはプレーン方式でドットパターンが2枚重なってて
そしてBG,SP各256キャラクタしか持てないから1つのキャラに単色2パターン放り込んで
パレットでキャラクタの表示を切り替えていたりする 「三杯飲んでもまだ余る」はずなのに・・・
ってネタがあったな大昔><