[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 21:13 / Filesize : 335 KB / Number-of Response : 948
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

ロックマン8をFC風にリメイク Part3



385 名前:Dr. Juicy ◆PIev8nwW8c mailto:sage [2009/02/18(水) 00:34:57 ID:y8eZioci]
>>384
謝る必要なんてありませんよ。
むしろ受け入れてくださってありがとうございます。

>一応一枚ごとのサイズは〜〜
誤解が在るといけないので、情報共有の意味で、もう少し解説しますね。

皆さんがUpしてくださった画像ファイルには、モーションごとにキャラクターが複数書いてありますね。
例えば、32*32のキャラクターで4モーションであれば、128*32の一枚絵にしてUpするでしょう。
PG側は一般的には、「128*32の一枚絵」をそのままグラボのVRAMへ転送し、
テクスチャの元画像(テクスチャソース)として登録します。
32*32のキャラクタ画像毎に4つに分けてVRAMへ転送(登録)するわけではありません。
そして、32*32のキャラクターを表示するときには、VRAM中の「128*32の一枚絵」の中から
表示させたい32*32エリアだけをポリゴンにテクスチャとして貼り付けレンダリング(表示)します。

このとき、2のべき乗ルールが課せられるのは、テクスチャソースのみ。
つまり、「128*32の一枚絵」の縦横幅が2のべき乗であればよく、
各キャラクタは2のべき乗の幅である必要はない、というのがポイントです。
24*32のキャラクタを5モーションにして、「128*32の一枚絵(8ドット余り)」でも良いのです。

もっというと、各キャラクタのサイズは小さければ小さいほど、
レンダリング時に計算を施すピクセル数(フラグメント数)が少なくなり、処理は高速になります。

シシロール画像を参考にすると、
そのまま使った場合はかなりVRAMに無駄がでます。↓
www12.uploader.jp/dl/rock8/rock8_uljp00252.png.html
どのみち広げられる縦を128にしてしまって一部移動するとVRAMは半分で済みます↓
www12.uploader.jp/dl/rock8/rock8_uljp00253.png.html

ゲームドッター目指す人には少し参考になるでしょうか。






[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](;´∀`)<335KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef