スプライト 4本目
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パターン放り込んで パレットでキャラクタの表示を切り替えていたりする 「三杯飲んでもまだ余る」はずなのに・・・ ってネタがあったな大昔>< read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる