Bardez Posted January 7, 2014 Share Posted January 7, 2014 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. Quote Link to comment
argent77 Posted January 7, 2014 Share Posted January 7, 2014 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. Quote Link to comment
Bardez Posted January 15, 2014 Author Share Posted January 15, 2014 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. Quote Link to comment
Bardez Posted January 15, 2014 Author Share Posted January 15, 2014 (edited) 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 January 15, 2014 by Bardez Quote Link to comment
Sam. Posted May 2, 2019 Share Posted May 2, 2019 Quoting the IESDP concerning PVRZ files: Quote 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? Quote 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? Quote Link to comment
lynx Posted May 2, 2019 Share Posted May 2, 2019 Pull requests are always welcome. As for the second point, yes, most likely. Quote Link to comment
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.