- 1 名前：名前は開発中のものです。 mailto:sage [2008/12/24(水) 08:20:03 ID:utsXxQQb]
- このスレはSS・PS用発売ソフト、ロックマン8をFC風にリメイクするスレです。
職人さん随時募集中（プログラム、ドット絵、音楽など）、下手でも過疎でも気にしない。
誰でもいいのでとにかくアップすべし！！
まとめWiki←スレであがったものはここに保管
www31.atwiki.jp/rockman8/
専用アップローダー←何か作ったものはまずここで
www12.uploader.jp/home/rock8/
ロックマン7FC化wiki←すごく参考になるサイト
www12.atwiki.jp/rockman7/
関連スレ
ロックマン7をFC風にリメイク Part20
schiphol.2ch.net/test/read.cgi/retro2/1223708124/
過去スレ
【懐】ロックマン8を8bit化しよう【ロックマン】
pc11.2ch.net/test/read.cgi/gamedev/1214655870/
ロックマン8をFC風にリメイク Part2
pc11.2ch.net/test/read.cgi/gamedev/1222579762/
- 516 名前：Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/03/12(木) 19:48:33 ID:nInAcUCt]
- おつゆ。
>>515
基本>>510スタイルで行こうってことでそ。
それで、VRAM関係について少し。
僕の考えは>>514さんとはと異なって、
「仮にファミコンと同じ素材を使っても、PCで作るとVRAMが結構厳しい」
と考えてます。
理由を書くと信頼性の無い駄文になりそうですが、ゲ製板ってことなので、
まあこういう情報や技術に関するやり取りもありだろうと思います。
ということでちょっとだけ長文書きますんで、興味のない人は読み飛ばしてください。
- 517 名前：Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/03/12(木) 20:10:55 ID:nInAcUCt]
- まず、そうね、スプライト画像がどれくらいのサイズになるかを考察しましょうか。
一般に画像をPCのディスプレイに表示するときには、赤緑青(RGB)の三色で色を表現しますが、
このときそれぞれの色の濃さを 1 byte ( 8bit ) のデータとして表現するようになっています。
そうすると、表現できる色の種類は 256 (1byte) * 256 * 256 = 16777216 色 ということになります。
これがよく言われる24bitカラーというやつですね。
（今でこそ24bitカラーのPCが一般的ですが、僕が始めたころは性能も低く16bitカラーが一般的でした。）
さて、24bitカラーの場合、1dotごとに 3色(RGB) * 1 byte = 3 byte のデータが必要になります。
すると、512*512dotの画像の場合は 3 byte * 512 (横幅) * 512(縦幅) = 768KB のデータサイズになります。
もうちょっと大きければだいたい 1MBですね。
このスレでも職人さんがアップしてくれた素材も、平均的に256〜512dot幅の物が多いですし、
他のゲーム素材でもこれくらいのサイズが一般的でしょう。
そうすると素材一枚につき 1MBくらいの容量が必要と思っていいと思います。
続く
- 518 名前：Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/03/12(木) 20:29:49 ID:nInAcUCt]
- さて、素材１枚につき１MB（まあそこまで行かず小さいものでも0.1MBはあるでしょう）ということですが、
ゲームに使う素材は一枚ではなく、全部合わせると100枚くらい平気で行っちゃいます。
これは旧世紀には大問題でした。
今でこそHDDの容量がテラとか言ってますが、win95時代なんてHDD容量が500MBくらいでした。
ゲーム一本インスコするだけでHDDの五分の一が持っていかれます。
それこそシムシティなんて入れた日にゃ、、、
それでどうしていたかというと、当時はパレット形式の画像が主流でした。
これは、先ほど示したような1ドットごとに色を持たせる形式、ではなく、
「使用する色の情報だけを先にデータ（パレット部分）として持たせ各色に番号付けをしておき、
色の番号だけを各ドットのデータとして収める」
ということをしていました。
こうすることで、24bitフルカラー画像に比べて3分の1くらいのサイズになります。
でも、まだサイズが大きい。で、どうなったかというと、
JPEG,GIF,PNGといった様々な圧縮形式が登場したわけです。
これらの圧縮技術によって、画像ファイルのサイズは24bitフルカラーの10分の1〜100分の1のサイズに
することができるのです。
ちょっと前にオガワンさんの、
「upするゲームファイルのサイズが大きくて困っていたけど、画像をbmpからpngにしたら10分の一になった」
というケースはまさに、無圧縮の24bitフルカラーbmpからパレット＆zlib圧縮のpngにしたために、画像サイズが
小さくなったというわけですね。
続く
- 519 名前：Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/03/12(木) 20:52:46 ID:nInAcUCt]
- （なんか脱線しすぎて駄文もいい加減にしとけって感じですが、ここから徐々に本題）
さて、圧縮形式のおかげでファイルサイズは小さくなったのですが、これで助かるのは
HDD容量だけなんです。
実際にアプリケーションが画像をディスプレイに表示するときには、
24bitフルカラーの情報を必要とします。
よって、圧縮されたファイルを解凍し、メモリ上には元のMBオーダーの画像データを保持する必要があります。
今でこそメモリ2GBとか言ってますが、旧世紀は、、、はやめておいて。
OpenGLやDirectXを使う場合、１MBのデータを置くするのはメインメモリではなく、
ビデオボードのメモリ(VRAM）に置く必要があります。(それがテクスチャ)
さて、VRAMはメインメモリと比べて遥かに少ないです。
最初に1枚1MBの画像をゲームなら100枚くらい使う、といいましたが、
これら合わせて100MBを全てVRAMに置くことはできません(ここ一年くらいのグラボなら可能かもしれませんが)。
そこで、PCゲームでは普段はメインメモリに画像データを置いておいて、
必要になったときにだけVRAMに転送してディスプレイに出力します。
（このへんからだんだん僕の話が怪しくなります、、、）
ここでの最大の問題はメインメモリ<-->VRAM間の転送が遅い、ということです。
この仕組みは、ドラクエ的なRPGのようなものでは、戦闘前のロード時間を充分にとれるので上手くいくのですが、
アクションや３Dゲーでは「60FPSで処理落ちさせない」という厳しい制限が付きます。
ここでVRAMへの転送時間がネックとなります。
転送待ちの間処理が落ちるので、理想としては例えば1ステージ分の画像を全部VRAMに置いておきたいのですが、
まだそんなことができるのは一部のハイエンドPCだけで、
使われているPCの多くは、まだまだVRAM容量が足らないものが多いと思います。
（もうちょっとだけ続くんじゃ by第23回天下一武道会終了後の亀仙人）
- 520 名前：Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/03/12(木) 21:10:23 ID:nInAcUCt]
- VRAM容量が足らない問題をどう解決したかというと、再び「圧縮」が行われます。
しかし、今度はファイルを圧縮するのではなく、データを圧縮した状態でVRAMに置くのです。
世に言う圧縮テクスチャです。
これによって、1MBの画像を表示するときもVRAM使用量はもっと少ないて済みます。
圧縮テクスチャによって使えるテクスチャの量が増し、３Dゲーは一気に華やかになりました。
じゃあ２Dは、というと？
駄目なんですよ、、、圧縮テクスチャじゃ駄目なんですよ、、、
圧縮テクスチャは、不可逆圧縮なんです。すなわち、解凍しても元に戻らないんですね。
違いをごらんくだしあ！
（上）通常
www12.uploader.jp/dl/rock8/rock8_uljp00268.png.html
(下）圧縮テクスチャ
www12.uploader.jp/dl/rock8/rock8_uljp00269.png.html
これは、どうでしょうか。今や２Dゲームの命といっても過言ではないドット絵が、
潰れて変な色になっちゃってるんですね。jpeg保存したみたいでしょう？
３Dゲーの場合はポリゴンに貼り付けて光の反射や影の処理をするので比較的目立たないのですが、
ドット絵の２Dゲームだとオワタと言わざるをえない。
- 521 名前：Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/03/12(木) 21:33:27 ID:nInAcUCt]
- さて、結局PCで２Dドット絵ゲーム作るなら、画像は非圧縮のままVRAMにおくしか手は無さそうです。
んじゃ、>>514さんからご指摘のあったように、FCではどうやってんだよ！？
という話になります。
（ここから怪しさに拍車が掛かる）
FCやSFCの場合、VRAMはPCなんかよりももっともっと小さいです。
1MBも無かったはずです。
FC等ではとりあえず画像サイズを小さくするために、最初の方に出てきたパレット形式を採用しました。
しかも、グラフィックチップもパレットカラーのまま処理するものを採用することで、
(というか、安価なチップは当時パレット形式だけだったのかも、）
VRAMにもパレット形式のままのデータを置く事ができました。
これによって24bitフルカラーのデータをVRAMに置くよりはかなり節約できました。
しかもFCはパレット数を16までにすることで、1ドットあたり4bit(2dotで1byte)となり、さらに小さくなっています。
54色使えるはずのFCなのに同時発色が16色までというのは、ここの1dotあたり4bitから来ている制限なんですね。
SFCでは1dotあたり1byte(8bit)としたことで、同時発色が増えてカラフルになりました。
ところが、これだけではVRAM不足は全然解決しません。
そこで、FC等のコンシューマ機の取った戦法は、メインメモリ<-->VRAM間の転送速度を
ものすごく速くすることで、VRAMへのデータ転送による処理落ちを防いだのです。
逆に言えば、1フレーム(60FPSなら16ミリ秒)の間にデータ転送できる量のスプライトしか
使わせないハード仕様にするということもあったかもしれません。
（スプライト数の制限には他にももっと重要な要因があるので突っ込まないでください）
もう一つ細かい点を言えば、一枚のスプライトのサイズを8*8dotに制限することで、
素材画像中の無駄な空白を作らない、という点も上げられます。
今だと1キャラクターを64*64dotごと区切って書いたりしますが、隙間って結構あるでしょ？
あれを8*8dot単位で全部削り取れば、半分かそれ以下のサイズになると思います。
もちろん、これを今の時代に行うのはナンセンスすぎるのでやめておきましょう。
- 522 名前：Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/03/12(木) 21:48:55 ID:nInAcUCt]
- とまあ、実機だからこそできる高速メインメモリ<-->VRAM間転送と、
8*8dotの無駄を省いたスプライト形式によってFC,SFC,は高速描写を行い、
これはゲームボーイアドバンスにも受け継がれています。（もしかしたらDSも？）
ロクゼロなどは基本64*64のスプライトにしておいて、
収まらなかったツノや髪だけ8*8dotスプライトを使ったりしています。
（注意：PSなんかでロードが長いのは、CD→メインメモリの転送であって、
PSでもメインメモリ<-->VRAM間転送を高速にすることでVRAM不足を補っています）
で、要は、実機は実機ならではの高速な部分を生かして速度を出しているんですね。
PCの方が見た目のスペックは全然高いのにエ○ュの動きがもっさりしているのは、
このへんの実機ならではの転送および通信速度をPCで出せないためだと考えられます。
結局、PCゲームの場合は
・フルカラーを直に扱わなければならない
・メインメモリ<-->VRAM転送は遅い
・２Dゲームではテクスチャ圧縮するとドットが死ぬ
・VRAM容量は、ユーザーによってバラバラ
という問題が残っているんですね。
もうちょっと言うと、
・透過表示用に、RGBに加えて透過度α(1byte)が必要
です。 1 dot あたり 4 byte すなわち、512*512dotの画像で丁度 1 MBとなります。
で、結局は、ゲーム中の処理落ちしてもいいようなところでインメモリ<-->VRAM転送するしかないんですが、
その変のさじ加減が、僕が経験不足というわけです。
FC7動いてるじゃねーかって話なんですが、あれも、
実は動かなかったり動作が遅くて遊べなかった人も少なからずいたのかなと思うと、なんかかわいそうで。
以上、駄文失礼しました。
- 523 名前：Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/03/12(木) 21:56:14 ID:nInAcUCt]
- あ〜、本当に、よくこんな長い駄文を恥ずかしげも無く書いたもんだ。。。
ちなみに、前回アップしたバージョンのゲームをVRAMチェッカーで調べると、
すでに10MB近くのVRAMを消費してます。
たったあれだけの敵で。
個人的にはなんとか低スペックの人に遊んでもらいたいなぁと思うと、
32MBまで、う〜ん欲を言えば16MB。。。
と書いておいて、ちょっとシビアすぎる気もしてる。
|
 |
