http://www.via.com.tw/en/Digital Library/PR040830SonyS3TC.jsp
Good news for the humble 2MB VRAM of PSP.
-ysoya
S3TC will be used in PSP
- Thread starter ysoya
- Start date
http://www.via.com.tw/en/Digital Library/PR040830SonyS3TC.jsp
Good news for the humble 2MB VRAM of PSP.
-ysoya
Panajev2001a
Veteran
You forget that the front-buffer, the back-buffer and Z-buffer are all considerably smaller (~2.2x) than their PlayStation 2 counter-part due to the lower resolution.
Evil_Cloud
Veteran
Now we only need MP3 support... 
S3TC and vector quantization texture compression (Simon's method) are different although the underlying concept is similiar.
Crudely put:
S3TC takes the 16 colors in each 4x4 block and finds the "major axis" (linear approximation) of the color vectors, then chooses two representive colors on this axis and explicitly stores them at 16 bit precision. Then two other colors are implicitly produced at 0.33*colorA + 0.67*colorB and at 0.33*colorB + 0.67*colorA. Then a 2 bit index is stored at each texture element which points to which of these four colors the texel will assume.
VQ on the other hand divides the screen into 2x2 texel blocks then selects (for example) 256 representive blocks that constitute a "best fit" (minimization of sum of the squares of the differences IIRC) for all of the original blocks. Each 2x2 block in the texture then has an index which points to its representive block (which are stored IIRC in an on chip cache). This has the disadvantage of a dependent memory read but the advantage of better quality in general.
Crudely put:
S3TC takes the 16 colors in each 4x4 block and finds the "major axis" (linear approximation) of the color vectors, then chooses two representive colors on this axis and explicitly stores them at 16 bit precision. Then two other colors are implicitly produced at 0.33*colorA + 0.67*colorB and at 0.33*colorB + 0.67*colorA. Then a 2 bit index is stored at each texture element which points to which of these four colors the texel will assume.
VQ on the other hand divides the screen into 2x2 texel blocks then selects (for example) 256 representive blocks that constitute a "best fit" (minimization of sum of the squares of the differences IIRC) for all of the original blocks. Each 2x2 block in the texture then has an index which points to its representive block (which are stored IIRC in an on chip cache). This has the disadvantage of a dependent memory read but the advantage of better quality in general.
akira888 said:
It's my understanding that PVR-TC =! VQ. MBX is using PVR-TC for the time being:
http://web.onetel.net.uk/~simonnihal/assorted3d/fenney03texcomp.pdf
Compression errors from the figures stated in the paper above of the 4bpp variant seem to be at a very high level, especially compared to S3TC quality. The 2bpp variant on the other hand shows itself still with less errors overall than Dreamcast-VQ.
Lazy8s said:
1. VQ texture decompression is much slower. Reading one texel needs two memory access.
2. VQ texture quality is worse than S3TC. (in case of DC-VQ)
3. Real size of VQ texture is not smaller than S3TC, because of codebook overhead.
IMHO, S3TC is the best solution for game industry for now.
-ysoya
marconelly!
Veteran
Oh man... Here we go again...
PS2 aside, are you even aware that Gamecube has even less VRAM than PS2, and uses texture buffers of about the same size as PS2 games do (which happens to be around 1MB)? Now how do you explain that developers seem to be able to almost consistently deliver nicely textured games on that console, if 'low' VRAM is such a big issue?
ysoya said:
DC-VQ was long since superceded by PVR-TC. The latter was presented at the joint Siggraph/Eurographics, Graphics Hardware Conference in 2003.
Having said that, you made a couple of incorrect assumptions:
The double access is inconvenient but it can be avoided by using this amazing technology called a cache. It's not free, of course, but then even Nvidia were using two levels of caching to implement S3TC.
That rather depends on what you are comparing. If you are comparing 4bpp (8bpp when doing alpha) against 2bpp VQ then, typically yes. OTOH, if you equalise the systems so that the images are stored with the same numbers of bits, then VQ tends to look much better.
The DC codebook could be up to 2kB in size. The max sized DC-VQ texture for a 256x256 image would thus be 18kB. The equivalent S3TC opaque only texture would be 32kB. Please explain how the VQ texture is not smaller.
Technically I do feel that BTC variants (eg S3TC) are probably more convenient systems then VQ-based solutions but I think there are better solutions than S3TC.
