▼▼▼▼テクスチャ１６色ＰＳ２▼▼▼▼

ださいＹＯ！

氏ね！

クソスレ乱立するな、氏ね。

AC3の真実
http://ps2media.ign.com/media/previews/image/ac43/ac4_7.jpg

>>4
AC4だってば

たてなおしかよっ

>>4
AC3ってこんなキレイだったっけ？
なんつって、オマエACシリーズ知らないだろ（藁

>>4
いたるところで恥さらしてるな。
微笑ましい。

AC4の真実
http://ps2media.ign.com/media/previews/image/ac43/ac4_7.jpg

３でも４でもいいじゃないかｗ

>>9
被写界深度使いまくってるねえ

>>11
まるで拡大したベタ張りのテクスチャのように見えるのはそのためか！

クソスレだＮＥ！

ギザボケマンセー！！

>>11
どこに？

被写界震度じゃなくて、ただ単にバイリニアでボケまくっているだけだと思うが。

ネタだろ＞被写界深度

AC4ガッカリ
これじゃあ解像度高いAC3じゃん

フィルレート馬鹿のGSにとって被写界深度とか陽炎だけは朝飯前だよ

>>19
あと、ブラーも得意だYO!
語尾はYO!で頼むZE!

　　　　　　　＿　＠｀ ― ､
　 　 　　＠｀−'　　｀　 　　 ￣ヽ_
　 　 　＠｀'　　　　　　　　　　　 ヽ
　　　　(　　　　　　　　　　　　 ）
　　　 （ 　　ノ｀ｰ'ｰ'ヽ　　　　　）　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　（ 　 ﾉ●。　●（　　　　)　＜　まいう〜♪ １６色ってうまいか？
　　　　｀ｰ'(〇　o　 〇 )( 　　 ）　　 ＼
　　　　　　/　　~~　　　 | ｀ー'　　　 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　ω　　 |_/　|　　　　

256色でだめだから16色か。
駄目人間だな>>1

ＤＣ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ＰＳ２＝マミー石田

16色もあれば十分じゃないの？
ＰＣの初代クエークだってテクスチャ１６色だし（藁

なんでポリゴンで作らないの？

>>25
PSはそんなに湯水のごとくポリゴンの使えるマシンではないことが露呈したからです。

>>23 >>26
吉田必死だな（藁

わざわざポリゴンで作らなくちゃいけないなんてのも無駄な労力だな

>>27
君も必死にがんばれ

ＰＳ２は、もうポリゴンしか取り得がないのに、
それを否定したら、ただＤＶＤが見られるだけの
くそ高いＰＳになてしまうよ。

ＰＳ２のテクスチャは16色か256色だけど、
メモリ効率が良い分、
やわらかでリアルな映像表現には向いていないね。
広範囲で単色陰影の映像が多いのはそのせいだな。

一見リアルな映像でも止め絵だったりムービーだったりして
ごまかされているだけ。
ＧＴ３の映像もなんとなく全体の色数が少なく見えるしね。

やっぱりJPEG圧縮による65536色が使えるＤＣには敵わないか。

もうＰＳ２なんてどうでもいいじゃないか
ＰＳ３に期待しようぜ！

>>31
まだ洗脳が解けないのか・・・・・・・・くたたんパワー恐るべし。

ネタ書き込みにネタレスか・・・この板はどうなっていくんだ（厨房化

>>32
吉田必死だな（藁

>>34
俺はセ川だ!
余裕だぜ。

２１世紀にもなって
テクスチャ１６or２５６色のＰＳ２って低性能でイカスよね

セ川はハードではもう失うものが無いからある意味最強だな（藁
360度全方位叩き放題

テクスチャのサイズだけどさ、
PS2で、65536色から16色のテクスチャにしても、メモリーは1/4にしかならん。
でも、DCのPowerVR2だっけ？　ベクター何とか圧縮でフルカラーを1/6だか1/8にできるんじゃなかったっけか？
とても比較にならん。

>>36
それ以前にＮＴＳＣが基本になっている事自体、
時代遅れのハードだぜ。

>>39

しかも基本が出来てないのでギザチラです。
チップのスペック見てハイレゾもいけると言っていた詐欺師を逮捕して欲しいですね。

>>30
DCはJPEG圧縮なんて使えないよ。

>>38
VQ圧縮は今でも色々研究されている。
画像の特徴を抽出して符号化する点が、人間の画像認識に近いなんて言われている。
東北大学がこの研究を推進している。
http://www.mainichi.co.jp/digital/computing/archive/199909/30/1.html
なかなか面白い記事。
33MHz動作のVQチップで450MHzペン2の3倍高速なんだとさ。
データ圧縮率は静止画で80分の1だとか。とんでもねえ。

DCのVQ圧縮はコードブックが少ない低画質バージョンみたいよ。

256個だっけ？

>>43
所詮640*480だからそれで十分だろうな。

デジカメに使うわけじゃないんだからコードブック256個もあれば充分だよ。

コードブックが8bit(256種類)で済むから16bitカラーの絵が
1/4×1/2で1/8に圧縮できるんだよね

s3tcで充分

コードブック256色で16bitカラーなら
コードテーブルだけで2KBくらいになる(256×4×16bit)
小さなテクスチャだとコードテーブルの分でかえって元データより大きくなりそう。
CLUTのカラーテーブルはその数分の１のデータ量で済むけどね。

>>49
VQ圧縮なんてどうせデカいテクスチャの分にしか使わないんだから別に問題無いだろ

Ｓ３ＴＣはアンリアルで見た限り強烈だな
Ｘ−Ｂｏｘに期待。

>>51
S3TCはGCも採用してるぞよ。
しかもテクスチャキャッシュが巨大（512*512圧縮テクスチャ8枚ぶん）
なので、壁のようなパターン系はかなり緻密な書き込みが期待できる。

DC…VQ圧縮
GCとXbox…Ｓ３ＴＣ
PS2…CLUT256+OPTPIX、またはCLUT16+ドット職人
なんかPS2苦しそうだな(藁

>>49
×コードブック256色
○コードブック256種類

ＧＣのS3TCとＸ−ＢＯＸのＤＸＴＣは同じだろ？
圧縮しているからたっぷりテクスチャが入るね
サベージ４でアンリアルやったときはマジでビビった

ＤＣのＰ−ＶＲ２はなかなかやるじゃん

近くによるとぼけぼけにポリゴンからおさらば出来るんだね！

>>49
コードデーブルが2KBもあるとすると元データが
2KBの32×32パターンだと確実に元絵より大きくなるんだね

３ＤＦＸのＦＸ１だったけ？一度は見てみたかったな

>>57
ちょっと違う。
それはＭＩＰＭＡＰじゃないのか

DCのVQ圧縮の圧縮率(16bit色、コードブック256種類)
32×32…2048Byte→2048+256＝2304Byte(0.9倍)
64×64…8192Byte→2048＋1024＝3071Byte(2.7倍)
128×128…32768Byte→2048＋4096＝6144Byte(5.3倍)
256×256…131072Byte→2048＋16384＝18432Byte(7.1倍)
間違ってたらつっこんで

やっぱテクスチャにはS3TCが一番

>>60
違くないよ
MipMapは遠くをのぼかす機能だ

近くによるとボケルのはバイリニアでしょ

X-BOXってS3TCなの？
nVidiaって3DFX買収したから、FXT1も使えると思うんだけど。
FXT1の方がよさげなんだが。間に合わないのかな？

>>63
MipMapは複数の大きさのテクスチャを距離によって差し替えること

>>66
それによってぼかすしてチラツキを防ぐから
63は間違いではないんでは

被写界深度の処理と間違ってたらアレだけど

そうだな。トライニリアフィルタリングだな
>>65
ダイレクトＸでサポートされていないよ
FXT1の方が上らしいけど、見たことがない（笑）

MipMap＞遠距離ぼかし
トライニアフィルタ＞近距離ぼかし
たぶんこうだろ
もしかしてＰＳ２は無いのか（笑）
近くに寄ると荒くなるぞ

ダイレクトＸはＳ３ＴＣ＝ＤＸＴＣ
FXT1は３ＤＦＸのＧＲＩＤＥの技術

>>70
> MipMap＞遠距離ぼかし
おいおい・・・ネタか？

>>66
それはＰＳ１の話な
最近はハードでやってくれるんだよ

PS2の画面は懐かしさを感じさせます。
うーん、エモーション！

ノスタルジアシンセサイザー搭載。
ＰＳ下位互換もあるしバッチリｸﾀ

http://www.dailyradar.com/previews/game_preview_604.html
ＰＳ２は2000万ポリゴン出ます。定説です。

FXT1なら圧縮・復元のサンプル用PhotoShopのプラグインも配布されてたよ。
使ってみたがDXTCのほうが綺麗だった。

PS2とDCのテクスチャデータ量比較
●CLUT8bit(カラーテーブルは768Byte)
32×32…768＋1024＝1792Byte
64×64…768＋4096＝4864Byte
128×128…768＋16384＝17152Byte
256×256…768＋65536＝66304Byte
●CLUT4bit(カラーテーブルは48Byte)
32×32…48＋512＝560Byte
64×64…48＋2048＝2096Byte
128×128…48＋8192＝8240Byte
256×256…48＋32768＝32816Byte
●DCのVQ圧縮(16bit色、コードブック256種類)
32×32…2048+256＝2304Byte
64×64…2048＋1024＝3071Byte
128×128…2048＋4096＝6144Byte
256×256…2048＋16384＝18432Byte
間違ってたらつっこんで

まとめると
CLUT8bit、CLUT4bit、DCのVQ圧縮
32×32…1.8KB、0.56KB、2.3KB
64×64…4.9KB、2.1KB、3.1KB
128×128…17KB、8.2KB、6.1KB
256×256…66KB、33KB、18KB

まとめると、
ＤＣはもうただのゴミ。
ＰＳ２は安価なＤＶＤ再生マシン。

そんなの自慢したってさ
作りにくい開発環境で誰がそこまで引きだせんだよ
テクモ
「XBOXは開発していて本当に楽しいですよね。
今回の実機デモは一ヶ月しか作っていません
これはXBOXでしか作ることの出来ない映像です。
DOA3はXBOXでの開発となりました」
ソースbyドリマガ４／２０号

DC馬鹿にしていることしか出来ない出川どもは
よくよんどけ(゜Π゜)ｺﾞﾙｧ

いや、ＤＣでも楽しくないってことだよ？

>>81 テクモを信じてるバカは逝ってよし！！

テクモはPS2のときも7500万ポリゴン/sって宣伝してたよね。

ＰＳ２やＤＣで作ったモデルデータがあるから
1ヶ月であれくらい作れないと会社としての立場が。。。

デモなんかつくってる暇ないだろ
テクモは。

もうすぐ、ＰＳ２のＨＤＤがでますが、
素人考えですが、テクスチャーのメモリとしてつかえないのですか？
詳しい方、教えていただけるとうれしいです。

>>87
本体に32Mのメモリ領域があるので、そこで使ってます。
それだけあればとりあえず十分です。
もちろん、元データはCD-ROMあるいはDVD-ROMにあるので
そこにおいておくより、HDDにあったほうが、
アクセス時間は減ります。

多分、そういうことじゃないと思うので、本当の回答としては、
テクスチャはある程度VRAMの空き領域に置いておきます。
そうすれば高速描画が可能。
でも、PS2ではVRAM領域が少ないから、メインRAMにおきます。
あくまで高速転送が必要なので、HDDなんぞ置けない。
でも、メインRAMは32Mあるので、一時置き場としては十分です。

>>87
そんなことしたら、HDD必須になってしまうぞ。
やめてくれ
>>83
あの書き込みで妄想判断者しているやつ発見
電波スレへ逝って来い

出川必至だな(藁
》》》》》》＿＿
≫　 　　　　 ＼　　 　　　 　　 ＿＿＿＿＿＿＿＿＿＿＿＿
≫　　　　（★） ＼　　　 　　／
≫　　　　　　　 ＜　　　　＜　出川必死だな(藁
≫　　　　　　　 ／　 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿／
》》》》》》
　∧ ∧
( 　ﾟ∀ﾟ)　　　　／
( 　　　)　　　＜ ﾜﾗﾜﾗﾜﾗﾜﾗﾜﾗ
( 　　　)　　　　＼
( 　　　)
( 　　　)
( 　　　)

>>89
ひょっとして>>81=>>89ですか？ といっても正直に名乗るわけねーよなぁ（ ﾟ∀ﾟ)ｱｰﾋｬﾋｬﾋｬ

>>87
えーと、お話になりません。
まず外部記録装置とメモリーの違いから勉強してください。

》》》》》》＿＿
≫　 　　　　 ＼　　 　　　 　　 ＿＿＿＿＿＿＿＿＿＿＿＿
≫　　　　（★） ＼　　　 　　／
≫　　　　　　　 ＜　　　　＜　出川オナニースレ�V(藁
≫　　　　　　　 ／　 　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿／
》》》》》》
　∧ ∧
( 　ﾟ∀ﾟ)　　　　／
( 　　　)　　　＜ ｼﾞﾌﾞﾝﾉｻﾞｰﾒﾝﾉﾝﾃﾞﾛｺﾞﾗｧ
( 　　　)　　　　＼

>>88
>PS2ではVRAM領域が少ないから、メインRAMにおきます。
それはソニーが提唱している夢物語であって、
実際にその方法を使っているタイトルは殆ど無いでしょう。

気楽に使えない機能は使えないのと同じ。

ハードディスクにテクスチャ置くってぇ？！！！！！！！！

−−−−−−−−−−−−−−−−−−−−−−−−（絶句）

>>94
ポリゴン減らせば同期できます。
必要に迫られた時にしかやらないけど。

みなさんありがとうございます。ＨＤＤで
何らかの効果を期待していたのですが･･･。
ＰＳ２のことではなかったのですが、
ＨＤをテクスチャのキャッシュにするだとか
いうのをみた記憶があったので。素人すぎて、すんまそん。

>>97
あやまらなくていいよ
はじめはみんなわからないものだから

>>98
わかった気になってる奴も痛いけどな。

つーか出川のレベルが分かって楽しいです。

>>94
ていうか、どんなゲームでもやってるぞ？
ＤＣだってそうだが。
いきなりロムから、VRAMにおくなんて思ってるのか？
いったんメインメモリに置くんだぞ？
じゃないと、馬鹿丸出しソフト（アクセス頻発）になるんだけど。。。
おわかり？

でぐぁわ頭悪くてカックイイー

何ですかコレ？ ( ＾▽＾)σ |16色PS2|~
だめだ、笑いがとまんねえ(＾＾)

>>103

　　　＠｀ﾍ_ﾍ　　　／￣￣￣￣￣￣￣
　　 （ ・_・）　　　おもしろくないー
　 〜(＠｀＿ﾉ　　　＼＿＿＿＿＿＿＿

レポート作成の為、彼女のパソコンを借りた。
「いって」を打った時、始めの変換で「逝って」となった。
ん？と思い、「うつ」を変換するといきなり「鬱」となった。
ええ！？まさか、うそだろ！？と思い「はぁ」を変換した。
すると「(ﾟДﾟ)ﾊｧ?」となった・・・。

>>105
コピペか。むなしくないか？(藁

　　　　　　　＿　＠｀ ― ､
　 　 　　＠｀−'　　｀　 　　 ￣ヽ_
　 　 　＠｀'　　　　　　　　　　　 ヽ
　　　　(　　　　　　　　　　　　 ）
　　　 （ 　　ノ｀ｰ'ｰ'ヽ　　　　　）　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　（ 　 ﾉ●。　●（　　　　)　＜　まいう〜?
　　　　｀ｰ'(〇　o　 〇 )( 　　 ）　　 ＼
　　　　　　/　　~~　　　 | ｀ー'　　　 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　ω　　 |_/　|　　　　　　　

S3TCってどんなアルゴリズムなんだ？誰か解説キボン

テクスチャー圧縮技術Ｓ３ＴC（ダイレクトＸでの名称はＤＸＴｎ）
最大でテクスチャーを六分の一まで圧縮することができるので
この技術に対応したソフトは容量の大きいテクスチャーを難なく扱えることができます

>>109
ありがとう。
でも、それはこのスレ読んでれば分かるので、
圧縮アルゴリズムが知りたいんです。
空間周波数系だとかベクトル量子化だとかパレット系だとか

http://homepage1.nifty.com/open-prog/compress/tip003.html
S3TCはS3社が開発した圧縮形式で、フルカラー画像を４×４画素のブロックに分割して、
2ビットのインデックス化されたパレット付き画像に変換することで圧縮を行います。
DirectXが標準サポートしているテクスチャ圧縮形式でもあります。

特徴としては、デコードが非常に高速かつブロックサイズが一定なので
ランダムアクセスが可能だということ
高い品質のパレット設定すれば、高品質に圧縮できるということ。
LZ系などの２次圧縮が利くことなどがあります。

S3TCの原理は、減色と単純な線形補完っす。
データは4x4の16ピクセル単位（計64bit）で格納され、
そのうちの半分32ビットに16bitの色データABがふたつ格納されます。
そして16個のピクセルは二つの色そのものまたはその補完色二つ
（すなわちA:B＝1:0、2:1、1:2、0:1）の四種類2bitで記録されます。
16x2+2x16＝64bit
αを使用する場合はA:B＝1:0、1:1、0:1の三階調に制限されます。

S3TCの原理は、減色と単純な線形補完っす。
データは4x4の16ピクセル単位（計64bit）で格納され、
そのうちの半分32ビットに16bitの色データABがふたつ格納されます。
そして16個のピクセルは二つの色そのものまたはその補完色二つ
（すなわちA:B＝1:0、2:1、1:2、0:1）の四種類2bitで記録されます。
16x2+2x16＝64bit
αを使用する場合はA:B＝1:0、1:1、0:1の三階調に制限されます。

>>111
>>112
おおっ、ありがとう。
どちらかっていうとパレット系なのね。
VQのコートブックとかCLUTのカラーテーブル
みたいに余分な参照データが無い分、
小さなブロックでも確実に６分の１になるんだね。
そうなると、コードブックが必要なDCのVQより実圧縮率高そうだね。

人間の目って、輝度分解能に比べて色分解能の方が低いから
色データを16ピクセル毎にしか持たないS3TCは
圧縮アルゴリズムとして理にかなってる感じだね。
パレット系は展開が速いから、その点でもリアルタイム用途に向いてる。
DCのVQもコードブック参照がパレット的だから展開劇速だけどね。

S3TCマンセー！！GCマンセー！！

GSでも工夫すればS3TCもどきができるかも。たとえばこんな感じ…
(1)縦横それぞれ4分の1に縮小された16bitカラーのデータ
(2)2ビット4階調のグレイスケール(元データと拡大した(1)の差分のグレースケール)
(GSがグレースケール扱えるかは知らん、だめなら4bit-CLUTで代用)
この二つのデータをGSに格納しとく。この場合圧縮率は８分の１になる。
使う時になったら(1)をバイリニアで元のサイズに拡大して､それと(2)を
アルファブレンドすれば輝度成分の解像度をある程度保ったまま
色成分の解像度だけ間引いたデータが作れる。妄想かましてスマソ。

>>117
それってミドルウェアにそういうのあったとおもったが。
どっかもうすでにやってるんじゃねーの？

>>117
マルチテクスチャは2パスになる。
それだけEEの資源が無駄になる。

３月にSCPH-18000買ったばっかやのにーーーーーーー！
HDD格納庫付きのやつだすなんて、やってられんわ、ほんまに！
どう考えても、それのほうがええわ！Sonyに講義したいわ！
シャレならんわ！うっふ〜ん。好きチュ〜ッ。
って、なんでやねん！金返せ〜〜〜〜〜〜。XBOXにするわ。
マイクロソフトに期待してみるわ、西川君。
のりおちゃん、ぽ〜ん。ぽっ！天下御免のむこうみず、ぽっ！
ツッタカタ〜、ツッタカタ〜、ツッタカタッタ〜坊やのお通りだ〜！
ぽっ！天下御免のむこうみず、ぽっ！

>>117
S3TCでは色情報は１６ピクセル毎に２色だが、それだと１色だよね。
ブロックの境界が目立ちそうな気が・・・。

S3TCだと小さいテクスチャを大きなテクスチャにまとめたときに
色が散っていても大丈夫だから、CLUTに比べて領域の有効利用ができそう。
２次圧縮が効くならAメモリーまでは２次圧縮した状態で持っておくのかな。

>>121
確かに>>117ではS3TCより色情報は少なくなるみたい
ただ、バイリニア使っての補間拡大だからブロック境界は無いはず。

エロゲーから抜いた絵をS3TC圧縮してみたら凄いことになった。
境界のハッキリした絵は苦手なのかな。

>>123
俺も>>111のリンク先のエンコーダをDLして試してみた。
S3TCは、境界のハッキリした絵だと2ｘ2のブロック境界が目立って
露骨に低解像度になった感じになるね。
http://www.webtech.co.jp/optpix/sample.html
これと比較すると
8bit CLUT＋OPTPIX256＞S3TC＞4bit CLUTてな感じかな？

2ｘ2じゃなくて4×4ブロックだった…

>>120
ﾅﾝｶﾜﾗﾀ。

>>124
そのエンコーダーがヘボイだけです。（ぉ
PhotoShopの減色とOPTPiXの減色では天と地ほどの差があるでしょ？
それと同じ。
ベクトル量子化系の圧縮はアルゴリズム次第で
かなり品質が変わります。
S3TC形式ももっと高度に最適化されたエンコーダーなら
高い品質を維持できます。まあ、限界はありますが。

またS3TCはテクスチャ向けの圧縮技術なので、
エッジのきつい画像には向きません。

age

VQ圧縮(ベクトル量子化)と一口に言っても様々な
アルゴリズムがあるけど、例えばCLUTだって言ってみればRGB色空間VQ圧縮だよね。
DCのVQ圧縮って2×2のタイルパターンを
参照してくって話だけどそれってタイリングとどう違うの？

下げちまったよ

>>112
感謝！！
S3TCの原理、暗記しました。

>>123-124
俺もエロゲの絵で試したけどかなり再現度高いんだが。ていうか予想以上に
きれいだわ。色がはみ出てるのは髪の輪郭部分において少しくらいのもんだ。

他にもピンぼけ写真みたいなのやPS2のゲーム画像（藁 でも試したけど
全然問題なかったよ？

縦横が4の整数倍の解像度のBMPがあれば簡単に試せるから疑うなら
やってみれば？

>>134
主観の問題では？

密かに>>111のリンク先のエンコーダがバージョンアップしてやがる（藁

>>124
8bitCLUT＋OPTPIX256はフルカラー画像を３分の１に圧縮するのに対し、
S3TCはフルカラー画像を６分の１に圧縮するのだから、
8bitCLUTの方が画質が良くて当たり前。
さらに、
http://hp.vector.co.jp/authors/VA013060/software/test/index.htm
なんかをエンコードしてみると、S3TCのメリットを実感できると思うよ。

>>134
フリーソフトのPadieでパレット256色に減色した方が綺麗だったよ。
http://www.vector.co.jp/soft/win95/art/se063024.html

http://www.webtech.co.jp/optpix/sample.html
ここのJPGをS3TCで圧縮してOPTPIXの8Bit画像と比べてみた。
JPGからなのでS3TCにとって少し不利な条件だが
SAMPLE1は互角、SAMPLE2はS3TCの勝ち、
SAMPLE3はOPTPIX8Bitの勝ちって感じだった。

なんか、S3TC職人とか出てきそうだな。
昔は8×8キャラクタ16色でドット打ってんだから、
4×4ブロック4色でドット打つ職人がいてもおかしくないかもね。

>>136
S3TCはアニメ絵では輪郭とか色の境界部が苦手だったけど
そのリンク先の６角形のグラディエーションの再現性はとても高かった。
グラディエーションに関しては線形補間系の面目躍如だね。

重要なのは減色をいかに自動化できるかってことなんだから
S3TCのメリットは大きいよ。4bitのCLUTじゃこうはいかないし。

>>139
エロゲの画像見た感じでは輪郭線を極端に違う色で描いてなければ
綺麗に圧縮できるみたい。ドット単位で打つほどシビアに考えなくても
経験積めば大丈夫だとおもう。

>>117がもし本当に可能なら
バイリニア使ってるだけにグラディエーションは強いかも。

いずれにせよ、S3TCは4bitCLUTと同等以上の圧縮率で
8bitCLUT並のクオリティーがあるんだから、
CLUT＜S3TCは間違いないでしょ。

CLUT使えないS3TCオンリーのシステムはイヤだな。

DCのVQって2×2を256種類のパターンに置きかえるだけの
かなり単純なVQなんだよね？
だとしたら>>136のグラディエーションとかは辛そうに思うんだが

>>142
テクスチャ１メガならそうかもね（藁
8bitCLUTくらい使わしてくれよ

gradation：段階的変化、段階、少しずつ変化すること。

graduation：卒業

graduation：卒業：グラデュエーション

終わった？

まだ

>>142
117が使えるのは本当にグラデーションばかりのときだけだよね。
S3TCのような色の区切りがないから。

>>150
ブロック単位で処理するタイプのアルゴリズムが
エッジの表現に強いなんてことは有りません。
元絵のエッジ部分とブロック境界の干渉はかなり不自然さが目立ちますから。

>>151はどっちについて言ってるの？
150は単に117の方法がS3TCと違って色について常に隣とのブレンドに
なるといってるだけだよ。

>>150
まあ人間の目は色彩に関しては輝度に比べて
高い空間周波数に追随できないからいいんじゃないかな。
輝度を残して色情報をケチるのは視覚心理学に正しいと思う。
ＲＧＢ→ＹＣｂＣｒが可能ならそこらへんもっと巧くやれるんだろうね。

>>153
いくらなんでもケチりすぎでは。16倍の差があるんだから。

というかS3TCだと色の高周波成分もそれなりに残ってる。
117だと輝度情報に比べて色情報の周波数が1/16しかないってことね。

>>154
>>155
まあ、確かに>>117は色をケチり過ぎなのは否めない感じ。
一部のJpegなんかみたいに４ピクセル毎に色情報つくらいがいいのかもね。

バイリニアやるほど拡大されたら目が当てられないよS3TC。

>>157
無理やり減色した画像の方がもっと醜いよ

はいはい。

醜いといわれると自分より醜い人を探す、心の醜い人

>>157
よほど相性が悪い画像以外は拡大しても綺麗だよ。
自然物の模様なんかならほとんどの場合うまく行きそう。

アニメ絵等の色境界がはっきりした絵
8bitCLUT＞S3TC
自然画
8bitCLUT＝S3TC
グラデーション
8bitCLUT＜S3TC
圧縮率
8bitCLUT＜S3TC

グラデーションは引き分けです。

グラデーションはS3TCの圧勝じゃない？
とくにバイリニアで拡大すると。

これの元絵エンコードしてみたら、
グラデーションはS3TCの圧勝だった
http://hp.vector.co.jp/authors/VA013060/software/test/index.htm

色が広く分布したグラデーションはS3TCの圧勝

スレタイトルはアレだけど、珍しく建設的なスレだね。

>>166限定するのー？卑怯だなあ。

>>166
純粋なグラデーションだったらフルカラーのまま単純に縦横のサイズを小さくして、
使う時にバイリニアで拡大した方が効率的だと思う(笑)

>>169
165のサンプルで試してみたら、
確かに単純に縮小しといてバイリニアで
拡大が一番綺麗にグラデーション再現する。あたりまえだけどね(藁

>小さいテクスチャを大きなテクスチャにまとめたときに
>色が散っていても大丈夫だから、CLUTに比べて領域の有効利用ができそう。
>>166はこういうのを想定している。

117のやつやってみたよ。
フォトショップで縦横1/4にしたあと元に戻した画像と、
グレースケールにした画像を通常合成（グレースケールの不透明度50％）して
元画像に近くなるまで色画像の彩度を上げてみた。
使った画像はCG絵描きさんの絵。

やっぱ全体にボケた感じがするが絵の輪郭は保たれるので絵として見れない
ほどではなかった。少し色落ちしてソフトフォーカスがかかったような感じ。
というかエロゲのCanvasの絵をイメージするとわかりやすいかも（藁

みなさん、俺のくだらない思いつきに付き合わせちゃってゴメンネ。
>>172
おおっ、試してくれましたか。自分もその方式試してみました。
本当はグレースケール同士の差分を合成したかったんだけど差分を取り出す
ツール持ってないので、素直にグレースケールとボケカラー画像を合成しました。
γ値下げて明度と彩度を上げてなんとか色彩も再現できました。
意外にもそこそこの解像度出てました。
実用には合成前の画像の最適化が必要そうですね。

117はS3TCに比べて輝度の低周波数成分の再現性が圧倒的に劣る。
S3TCは低周波数域においては輝度精度が約5bitあるのに対し、117では周波数に
よらず2bitしかない。Photoshopで117をエミュレーションするなら
グレースケールを4色にポスタリゼーション掛けないと駄目。
また117は3bit/pixelなので2bit/pixelのS3TCより圧縮率は劣る。

ごめんS3TCは4bit/pixelだね

>131

ピンポーン、大正解です。
このスレでアホな事書いているやつは、一度数学を勉強しなおしたほうが良い。
２軸直交系とか複素共役とか基底とかの辺りをな。

PS2やってて、うんこしたくなって
どこが悪いんじゃーーーーーーーー。
テクスチャ、テクスチャ(笑)

>>177
うんこはてんかんの前触れです。

ＰＳ２の疲れる映像によりう自立神経が衰弱してます。

本屋で立ち読みするとうんこしたくなるってほんとか？

>>165のオリジナル画像をVQ圧縮のテストプログラムで圧縮してみたら、
オリジナルと殆ど変わらないんで驚いた。
まあ、VQ圧縮自体はコードブックの数で再生品質が極端に変わるから、
単純に比較はできないんですが。
一応URL
http://www.din.or.jp/~ch3/rd_pict.html
この、非可逆式フラクタルVQ圧縮というやつです。
コマンドは
FVQC -v4 -f
です。

>>181
訂正。コマンドは
エンコード
FVQC e -V4 -F
デコード
FVQC d
でした。

まあ、難しい話もよいけど。

http://www.acclaim.com/games/crazytaxi/
PS2版クレイジータクシー

>>181
ちなみに、そのリンク先のVQ圧縮は全然DCに使われてるヤツとアルゴリズムが違うね。
DCはRGB→YUVなんてやってないし2×2ブロック単位だし。
VQ圧縮と言っても>>131の話じゃないが範囲が広すぎるんだよね。
CLUTとかタイリングだってVQ圧縮の一種だから。

ＰＳ３版クレイジータクシー
http://www.acclaim.com/games/crazytaxi3/

>>185
はぁ？

>>131の、CLUTとVQの違いは分かるがタイリングとの違いは分からない。
マンハッタン距離がどうだとかいう話しか聞いたことないな。
コードブックの作成法に何かポイントがあるんだろうけど。
DCのVQ圧縮アルゴリズムってどこかに説明ないかな？
ところで、PS2が8bitCLUTで良しとした背景って何なんでしょうね？
VQ圧縮やS3TCに比べて圧縮率でも再生品質でも良いとは言えないのに…。
テクスチャなど8bitで十分、という認識があったのかな？
それとも始めから4bitCLUTで通すつもりだったんでしょうか？

S3TC、確かにアニメ塗りの画像は拡大するとつらい部分があるが、
こういう画像に特化しての代表色の選び方のアルゴリズムはまだ
改善できそうな気がする。

粗が目立つのは暗い色を使った輪郭部の周りだと思うのだが、
「領域1」「領域2」「輪郭」と分けると、今は片方の領域と輪郭の色を
代表色として取っているので片方の領域の色がかなり違ってしまっている。
で輪郭は暗い色なら何でもいいと考えて、片方の領域を暗くした色と
もう片方の領域の色を代表色に選ぶという方法。
普通に圧縮して差が大きすぎたブロックだけこれで圧縮しなおすとか。
少しはましになるかな・・・？

117のは2bitグレースケールが実際に使えるのかどうかがポイントだな。
4bitCLUTで代用すると5bpp相当だから、描画に2パスかかることを考えると
8bitCLUTの方が特かもしれん。
ところでこれってテクスチャのパース補正も２回必要になるのか？

これじゃやっぱだめだね。忘れて。

認識自体間違ってた…。こういう選び方した上で色が変になってるのね。

117は輝度精度が低すぎて実用に耐えないので改良版。
(1)元画像をPhotoshopのバイキュービック法で1/2に縮小、
　OPTPiXで彩度を+20%してからアニメ調CGディザなしで256色に減色する。
(2)元画像と(1)のバイリニア2倍拡大との差分から
　以下の2bitCLUTのARGB4444画像を生成する。
c[0] = {1＠｀0＠｀0＠｀0};
c[1] = {0＠｀0＠｀0＠｀0};
c[2] = {1＠｀15＠｀15＠｀15};
c[3] = {3＠｀15＠｀15＠｀15};

表示する際には(1)のバイリニア2倍拡大と(2)を合成表示する。
圧縮データは4bit/pixel+CLUT(512byte)となる。
なおPS2で2bitCLUTを使う話は聞いたことがないが、
4bitCLUTが使えるなら2bitCLUTもちょっと工夫すれば可能。

合成画像を生成するテストプログラムを作ってみたが、
元画像に比べると若干ぼけた感じになり、込み入った絵柄の部分で
彩度が落ちる。S3TCと比べると色再現性や階調性は完敗だが、
輪郭に関しては圧勝。拡大しても自然に再現される。

>>192
テクスチャ圧縮に求められるのは、
輪郭の再現度より、色再現性や階調性だよ。
よって実用性なし。

>>193
192ジャないけど、そうとも限らないよ。
例えばビルの窓とかまでテクスチャで表現したいような
時なんかかは輪郭の再現度は必要だろうし。
なによりも192の方法がほぼ同じ圧縮率の4bitCLUTより
再現性が高ければ何がしかの用途があるかも。

VQばかり話題になっているDCのテクスチャフォーマットですが
DCには、PS2のCLUTと同じ4bppテクスチャ（16色パレット）と
8bppテクスチャ（256色パレット）があります。それ以外にも
TWテクスチャ、レクトアングルテクスチャなどありますよ。
通常DCでは、小さ目のテクスチャにはVQフォーマットは使っていません。
PS2には、RGBA4444のフォーマットがないので半透明のテクスチャが
厳しいですね。

>>192
なかなかやりますなあ。俺のいい加減な思いつきを改良してくれて感謝してます。
だけど自分はPhotoshop持ってないのでそこまで試せないのが悲しい。
彩度や色再現性に関しては、元絵での色の最適化次第だと思うので、
テストプログラムの時点そこそこのクオリティーなら充分実用的だと思ったりします。

>>195
DCのテクスチャやるじゃん。
やっぱりテクスチャのフォーマットは用途によって使い分けが大切なんだね。

ああ、ＤＣのテクスチャフォーマットは多彩だよ。ＰＶＲさまさまってわけで。
ＹＵＶもあったような・・・。なかったような・・・。

age

clutやVQ圧縮ってバンプマップとかにも効くのかな。

ドンどこッド度々ddッドｄどのｋどｋどこｋどどどどど、こらー！
ＰＳ2のビデメモリなんで4メガやねん！なんで圧縮でけへんのや！
ＰＳ３買いにいこ。ｂｙ未来人より

>>198
ＹＵＶってＹＵＶ４：１：１とかにしてサイズ小さくするってこと？

サイズが半分になってたような、どうだったかなぁ？

確かにＲＧＢ→ＹＵＶ４：４：４→ＹＵＶ４：１：１にすれば
かなりの高クオリティーのままサイズ半分にできるね。

>>165
Optpix Image Studio for PS2　だと
そこのwebdesigner使ったサンプルよりずっと綺麗に
減色できたよ。
やっぱwebdesignerは手抜きなのか・・・

>>205
ディザ無しで比較したかったんじゃないかな
ディザ使えばPadieでももっとましになるしね。

webdesignerは元々Optpix（販売終了）の機能限定版だからね。
っとディザの有無の方がデカイか。

192をさらに改良。
(1)元画像をPhotoshopのバイキュービック法で1/2に縮小、
　OPTPiX webDesignerでアニメ調CGディザなしで256色に減色する。
(2)元画像と(1)のバイリニア2倍拡大との差分から
　以下のARGB8888の256色画像を生成する。
c[t] = {(127-t)*2＠｀0＠｀0＠｀0}; //(0≦t≦127)
c[t] = {(t-128)*2＠｀255＠｀255＠｀255}; //(128≦t≦255)
この画像をtはそのまま256階調グレースケールに変換し、OPTPiXで
アニメ調CGディザなしで4色もしくは16色に減色する。
(1')(1)と(2)を合成した画像は元画像と比較すると彩度が落ちるため、
元画像と同じになるように(1)のCLUTの彩度を補正する。

表示する際には(1')のバイリニア2倍拡大と(2)を合成表示する。
圧縮データは4bit/pixel+CLUT(512byte)または6bit/pixel+CLUT(512byte)と
なる。

208の画質評価ですが、OPTPiX webDesignerの標準で減色した時の色数を
基準にすると、

6bit/pixel:総合的に見て256色より高画質。元画像と比較しないと減色画像には
　見えない。256色と比較すると色再現はやや落ちるがグラデーションは綺麗。
S3TC:総合的に見て128色と同程度。色再現やグラデーションは良いが高周波成分
　の再現性で劣る。輪郭付近はぼろぼろ。
4bit/pixel:総合的に見て64色と同程度。64色と比較すると薄い模様の部分が
　消えがちだが色再現やグラデーションは良い。

>>206
ディザは等倍では綺麗に見えるが、
縮小するとエイリアスが激しく発生し大変なことになる。
なので、テクスチャ用途にディザを使うことは少ない。

>>210
バイリニアかかるんでしょ？

>>211
縮小っていってるじゃん。

>>212
馬鹿に説明しても無駄。
こいつらは、「バイリニアかけるとボケる」程度の認識しかないのだから。

>>208
面白いこころみだね。
グラテーションと細部の書き込みを両立するにはいい方法かもしれない。

>>211
バイリニアフィルタは拡大時に元画像の近傍４画素から補間する方法で、
縦横２次元（バイ）の線型（リニア）補間を行います。拡大時に画像が
ブロック状にならず自然にぼけ、処理が比較的軽いのが特徴です。

高周波成分の含まれた画像を縮小する場合、単純な間引き縮小では
エイリアス（モアレや偽輪郭など）が生じます。バイリニアフィルタは
縮小時のエイリアス改善にはほとんど効果がありません。

綺麗に縮小するには元画像の範囲の色の平均を求める（バイキュービック法）
のが良いですが、この方法は縮小率が大きいと処理量も増えてしまい
リアルタイムでは処理できません。
元画像を1/2＠｀1/4＠｀/1/8＠｀...と縮小した画像（ミップマップ）をあらかじめ
作っておき、縮小率に応じた画像２枚の近傍４画素から（計８画素）から
縦横縮小率３次元（トライ）の線型（リニア）補間するのが
トライリニアフィルタです。

>>215
オヒオヒ、縮小時でもバイリニアの近傍四画素補完はされるよ。

>>216
で、補間はされてもエイリアスはどうするの？

>>217
四画素混ぜた時点でディザのエイリアスなんかあらかた消えるだろ。
昔のパソゲーの「赤と黄色で肌色」みたいな無茶なタイリングはしてまい。
ミップマップはまた別の話。

>>218
白黒市松模様のディザをバイリニアで1/2(1/4や1/6でも同じ)に縮小して
座標を動かすと、バイリニアを掛けなかった場合は白一色←→黒一色で
点滅します。バイリニアを掛けると白一色←灰色→黒一色で点滅します。
エイリアスは多少ましにはなりますが消えはしません。

やっぱりPS2は凄いや。
http://ps2movies.ign.com/media/news/video/anoop/trailer/ff10.mpeg
http://ps2movies.ign.com/media/news/video/anoop/trailer/dmc.mpeg
http://ps2movies.ign.com/media/news/video/anoop/trailer/gt3.mpeg

テクスチャにディザなんか使うわけないじゃん

>>219
1/2以上に縮小かけたらエイリアスが出るのは
ディザじゃなくても一緒でしょ。何のためにミップマップが有るのさ。
それに「白と黒の市松模様」なんて使わないだろ。218を読んでくれ。

どうせ16色なんだからディザも減色も糞も無えよ

＞綺麗に縮小するには元画像の範囲の色の平均を求める（バイキュービック法）
それはバイキュービックじゃないって（藁

別にディザを使ったテクスチャでなくても、ビルの外壁の
模様みたいのが遠景で小さくなったときには、同じ症状が
出てしまうよ。

>>224
エリアアベレージフィルタだね。

>>225
そんなの当たり前ジャン。馬鹿かお前。
ディザかけると
ちょっと縮小するだけでも激しくエイリアスがでるんだよ。

>>222
トライリニアフィルタを使わない場合、テクスチャに色の差のはっきりした
ディザを用いると縮小時にエイリアシングが発生する。
これでいい？

>>227 ディザってハードの機能でしょ？ 元絵にディザかけておくって話知らないけど・・・。

>>228
このスレは１６色テクスチャの話しだからな。
ディザを使うのは選択肢の一つでしょ。
ただ、使い方に工夫が必要と言う事で、論議が
続いていたんじゃないか。

>>229 ああ、そういうことか、納得。

>>222
確かに256色有れば誤差拡散も綺麗に出来るだろうけど
現実のPS2ゲーは16色ばっかりだから、結構難しいんでない？

ＧＴ３はどうみても１６色ゲームだよね。

２０世紀に置いてくるべきマシンだったな、ＰＳ２は。
まさか２００１年にもなってパレット１６色でどうこうしてる時代だとは考えなかっただろ、みんなも。
ましてやＰＳの次世代機がそんな風だとは。
大失敗作だね。

>>233 チミはもう一回このスレ読み直したほうが良くないかい？

>>224
失礼。バイキュービックは３次補間ですね。用語を勘違いしてました。
縮小は215で書いた通り平均を取った方が綺麗です。特に縮小率が大きい場合は。
PhotoShopには平均補間縮小はないのでいずれにしても縮小は
バイキュービック法を使います。

>>234
やっぱり時代遅れのハリボテハードでした。

１６色・・・へぼ！

>>187
容量さえ問題なければテクスチャの品質は8bitCLUTで十分でしょう。
CLUTは画像サイズが小さいほど再現性が良くなるので適切に分割して
やることで画質を上げられます。
256×256サイズではほとんどの場合画質は8bitCLUT＞S3TCでしょう。

S3TCは色の込み入った部分（高周波成分）を原理的に再生できないため、
画像を縮小して高周波成分が増えると再現性ががた落ちします。
640×480でS3TC＞8bitCLUTでも、同じ画像を320×240に縮小すると、
8bitCLUT＞＞S3TC、てな具合。

極端な話、文字フォント（白地に黒で輪郭にアンチ）であれば
4bitCLUT＞S3TCです。

>>238
テクスチャ圧縮は、
大きなテクスチャを効率的に利用するためにあるのだから
小さなテクスチャで良し悪しを語るのはナンセンス。
大きなテクスチャにおいては近傍画素を4色で十分近似できる。

そもそも高周波成分の多い画像が、
どれだけテクスチャに用いられているというのか。
高周波成分の多いテクスチャはエイリアスが激しく発生するので
好まれない。

何がテクスチャ圧縮に求められているのか、
それを考えれば、おのずと答えは見えてくるはずだ。

ＧＴ３て１６色なの？
へぼ・・・・

>高周波成分の多いテクスチャはエイリアスが激しく発生するので好まれない。

それは時と場合によると思うよ。もし高周波成分が重要じゃ無いなら
そもそも高解像度のテクスチャなんてそれほど必要無いってことになるけど。
低解像度をバイリニアで済むからね。

自分は３Ｄのゲームは開発したことがないので分からないんだが、
PS2でもし、
(1)S3TCが使えるようになったら、
(2)混載VRAMが1MB増えて5MBになったら、
開発者にとってはどっちが嬉しいだろう？　自分は(2)じゃないかと
思うんだが。

>>242
わしもVRAM増える方が嬉しいが、1M程度じゃ焼石に水なんで S3TCの方が
いいや。選択肢が増えるから。

どっちみち標準的な解像度で描画・表示フレームがVRAMの1/2占めるような
バランスはツライよ。表示解像度が上がった分テクスチャの解像度の必要量が
上がるんだから。
表示・描画フレームの必要量がVRAMの1/4ぐらいの比率が欲しかった。
PS2なら最低８Ｍ
3/4残っていてまだ足りんってのは、表示解像度に対してテクスチャ
細かすぎだろと思うから、それ以上はあれば嬉しい程度。

>>241
4×4ブロックの中で、色が急激に変化するほどの高周波成分は必要無いだろ？

>>244
高周波成分要らないならサイズが大きい高解像度テクスチャも要らんてことになるけど？

GSで展開できないので意味ないですが、S3TCは以下のように改良した方が
画質いいですね。

(1)画像を適当な大ブロック(64×64ないし256×256が妥当)に分割し、
　大ブロック毎に256色に減色する。
(2)大ブロックをさらに4×4ピクセル毎の小ブロックに分割し、
　この小ブロックを256色中4色(2bitCLUT)に減色する。

　小ブロックは8bit×4色+2bit×16pixel=64bit。これに大ブロック毎に
8bitCLUT分の4096bitが加わります。大ブロックを128×128にした場合で
4.25bit/pixelになります。
　小ブロック内が２色のグラデーションしか使えないS3TCと比べ、
独立した4色が指定できるため輪郭付近の再現性が格段に良くなります。

ＰＳ３はでます！断言できます！
ソニーは、へこたれません！勝つまでは！
というか、勝ちつづけます！
ていうか、勝ってます！
いや、勝ちです！
勝ちじゃ！ボケーーーーーーーーーーーー！
テクスチャーは、

>>247
おいおい途中で止まってるぞｗ

なんでSCEはGSにテクスチャ圧縮付けようとしなかったの？
おかしいよ、そんなの・・・

>>249
CLUTだって実質的には３倍または６倍のテクスチャ圧縮だよ

>>246
色テーブルが大きくなる。1ピクセル読むのに必要な情報量が大きい。
画質だけではテクスチャ圧縮フォーマットとしては使えない・・・。

16色はさすがに辛そう

>>252

>色テーブルが大きくなる。
CLUT分含めて4.25bit/pixel。4bit/pixelのS3TCより少し大きくなるが
画質差の方が大きいです。

>1ピクセル読むのに必要な情報量が大きい。
S3TCは1pixel読むのに2bit+16bit×2、さらに補間演算が必要。
>>246では2bit+8bit+16bit。演算不要。こっちのが速いです。
メモリアクセスが離散的になるのは欠点ですが8bitCLUTほどでは
ないのである程度の高速キャッシュを積めばいいでしょう。

そういばvoodooのGLIDEに採用されてたFXT1ってどういう仕組みなんだろう。
S3TCよりも綺麗と吹いてたが・・・。
というか、GLIDEの開発キットってもう手に入らないの？

>>255
このスレでも話題になってたような。２５６いろのほうのスレだったかな？

CLUTってけっこう処理大変なのかも。テクスチャ読みにいってから
パレット読みにいくのかな？
PS2だけテクスチャ使うとピクセルフィルレート半分になりますよね？

>>257
処理事態の複雑さで言ったら、S3TCには補間処理が入るので
S3TC＞CLUT＝DCのVQ
だと思うよ。ただGCはノーペナルティーで
デコードできるS3TCのデコーダーを持ってるらしいから関係ないだろうけど

>>254
その流れだと2bit>8bit>16bitの順に3回読む必要があるのか？
フィルレートが1/3になったりして。

>>253
めちゃめちゃつらいです。
これで綺麗なグラフィックを表現しようと思ったらまさに力技。
優秀なドッターによる物量作戦しかありません。
PS2では大手メーカーと中小とのグラフィックの差はこんな所にも現れてくるんですね。

>>259
何故同時に読んでパイプライン処理じゃいけないの？
GCのS3TCのデコードだってそうでしょ。

>>261
2bitを読むまでどの8bitを読むのか分からないから。

>>262 テクスチャ16bit分は一回読むだけじゃなかったっけ。

>>262
パイプライン処理すれば問題無し

投機実行だろ？

PS2のピクセルパイプラインが16個、
全部バイリニアするにはテクスチャから64ピクセル同時に
読まなくてはいけないし、さらにパレット？も同時となると
混載DRAMとはいえかなり大変そう。

>>266
TMUに送られるのはフィルタ済みピクセルだよ。
あと、誤解してる人が居るけど、PS2もSRAMテクスチャキャッシュが有るよ。
いくら帯域が広いといっても、レイテンシ10クロックの混載VRAMから直読みはしない。

パイプラインさせないとＰＳ並の速度しか出ないＹＯ!
スーパスカラもね。

GCの1T-SRAMはランダムアクセス速いみたいですが直読みするのかな？

>>269
多分そうだと思う。
テクスチャキャッシュのバス帯域はXやPS2以下かも。

でもそのぶん量は膨大だから、アニソみたいなフィルタや
高解像度テクスチャの使い回しにはバリ強だとおもう。

>>255
>そういばvoodooのGLIDEに採用されてたFXT1ってどういう仕組みなんだろう。

4×8ブロック単位に圧縮、
ブロックごとに識別フィールドを有し複数の圧縮モードの混在可能。

CC_HIモードは15bit２色から5色を線形補間、3bitインデックスで指定
CC_CHROMAモードは、15bit４色、2bitインデックスで指定
CC_MIXEDモードは、15bit2色+線形補間2色を4×4ブロック単位に指定可能。
カラーキーの指定可能。DXT1に近い。
CC_ALPHAモードは
15bitRGB×３、5bitα×３を有する。
lerpビットが0の時、
15bitRGB+5bitαのペアを2bitインデックスで指定、インデックス0は透明。
lerpビットが1の時、
左4×4ブロックは、0と1の色を、右4×4ブロック1と2の色を用いて、
RGB２色、α2色を線形補間で生成し2bitインデックスで指定

各ブロックに適応した圧縮方法を選べるのが特徴、
αチャンネルを持つ画像や不透明画像を同じテクスチャマップに混在できる。
32bitARGBで圧縮率は1/8

>>270
混載で1MBあるテクスチャキャッシュの帯域幅は9.6GB/sじゃなかった？
んで、外付けの1T-SRAMも3.2GB/s。
性能スレッドじゃ、最もXboxに都合のいい条件でXboxとタメを張っていた気がする。

>>273
GCの混載RAMはテクスチャキャッシュは12.8GB/s
フレームバッファ9.6GB/sの計22.4GB/s

>>272
圧縮率表記はまぎらわしいので4bit/pixelと書いた方がいいと思う。
S3TCはα付きだと8bit/pixelになるのに対し、FXT1はα付きでも4bit/pixel
なのでこっちの方が使いやすいような気がする。

>>272
S3TCの原理を元に、
「こうしたらどうかな？」
ってのが全て詰め込まれたような感じっすね。
nVIDIAに買収されたから、そのうちDXT6として採用されるのだろうか。

おもしろいページを見つけた。
http://www.digit-life.com/articles/reviews3tcfxt1/

>>277
なに

FTX1しょぼ！

英語だけど。
http://www.hardwarecentral.com/hardwarecentral/reports/140/4/