Jump to content

Recommended Posts

I'm quoting Avenger from the BGEE thread:




Ungzipped, you will find a pvr/3 file which has a header of 0x34 long, the rest is a bunch of dxt1 compressed pixels (though pvr files could have a hell of a number of pixel formats).

See this: http://www.imgtec.co...11.External.pdf


I have found that some pvrz files in BG2:EE have DXT5-compressed pixels. Anyone supporting PVRZ generally should be prepared to implement both DXT1 and DXT5. You can find algorithms to do so on Wikipedia (DXT1; DXT5). I can only anecdotally say that MOSxxxxx use DTX5 based on the 12 or so test files that I am currently using, but cannot yet say with a lot of certainty what the pattern of files that use DXT5 are, but I'll look into that once I have PVR decoding/displaying properly. I would hazard a guess that the MOSxxxxx images which might have some reason to include an alpha channel would be DXT5 (BAM icons, for example) but that is only a guess. I've not looked into BG:EE yet, either, but it could also share that compression.

Share this post

Link to post

That's right. A couple of PVRZ files, mostly referenced by BAM v2 files, are using DXT5 compression. BG:EE (since v1.2) also supports DXT5-compressed PVRZ files.


As a side note, DXT3 is not (yet?) supported by BG(2)EE, even though the compression format is very similar to DXT5. The game will crash if you try to use it.

Share this post

Link to post

Speaking to the PVRZ format itself, I'll reiterate what Avenger pointed out to consolidate information.


In a PVRZ file, as Avenger pointed out here, the first 4 bytes (DWORD) indicate the uncompressed data size. There is no header indicating the type or version.


The remainder of the data is the ZLib-compressed pvr file (for .NET people, there is a difference between Deflate and ZLib, so specifying is helpful). If you go to imgtec, there are apparently utilities that can read pvr files and Photoshop plugins for them.

Share this post

Link to post

Just as an overview for DXT compression, it's worth mentioning that DXT1 and DXT5 are 16-bit color compression algorithms, so standard 32 bit colors are converted into 16-bit color, then split into 4x4 squares and lossily compressed according the the specified algorithm.


It makes me chuckle a bit how the 32-bit color renders that were preserved immediately get axed down to 16-bit color.



A final note on the DXT1 and DXT5 compression algorithms:

If you follow the Wikipedia article's algorithm, Read the colors as unsigned 2-byte shorts. These values indicate whether color0 > color1 or color0 ≤ color1. Then, in order to produce colors matching those intended, prior to division and multiplication, the 16-bit colors need to be expanded into 24- or 32-bit color, and each channel must separately be divided by the appropriate amount and multiplied; I have gotten output that slightly differs from BG:EE output, so I'm not sure 100% how the division and multiplication are executed, but this is a very close approximation:


Let us assume that color0 is 18884 and color1 is 0:


So for an R5G6B6 color0, { 9, 14, 4 }, this expands the 5-6-5 bit color into 8-8-8 bit color: { 74, 56, 33 }. Assume color1 would be { 0, 0, 0 } and expands to the same.


In this case of color0 > color1, the yielded color2 would be { ( ( (74/3 => 24) * 2 => 48) + (0/3 => 0) => 48, ( ( (56/3 => 18) * 2 => 36) + (0/3 => 0) => 36, ( ( (33/3 => 11) * 2 => 22) + (0/3 => 0) => 22 ) }, that is { 48, 36, 22 }.


Similarly, color3 would be { ( (74/3 => 24) + ( (0/3 => 0) * 2 => 0 ) => 24, ( (56/3 => 18) + ( (0/3 => 0) * 2 => 0 ) => 18, ( (33/3 => 11) + ( (0/3 => 0) * 2 => 0 ) => 11) }, that is { 24, 18, 11 }.


If anyone has conflicting experience with this algorithm, please speak up.

Edited by Bardez

Share this post

Link to post

Quoting the IESDP concerning PVRZ files:


Width and height of textures are usually a power of 2, up to a maximum of 1024 pixels.

First, I think this wording is somewhat confusing.  When I first read this sentence, I interpreted it as "each PVRZ page is limited to a total of 1024 pixels".  Maybe the following would be a bit more clear?


Width and height of textures are usually a power of 2, up to a maximum of 1024 pixels in each dimension.

Second, looking at the PVR(Z) and IE file formats, I see no reason why textures are limited to 1024x1024 px.  The PVR format doesn't even have a field specifying the filesize, which leads me to believe the theoretical maximum texture dimensions should be the largest DWORDxDWORD (width and height of over 4 billion pixels each).  Is it the engine that limits the dimension, or is there something else I'm missing?

Share this post

Link to post

Pull requests are always welcome. As for the second point, yes, most likely.

Share this post

Link to post
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.