Jump to content


  • Content Count

  • Joined

  • Last visited

About Bardez

  • Birthday 08/10/1984

Profile Information

  • Gender
  • Location
    Peoria, IL, USA
  • Interests
    To be keeping a secret.
  • Mods Worked On
    Baldur's Gate Trilogy

Contact Methods

  • Website URL
  • AIM
  • ICQ
  • Yahoo
  1. Has anyone figured out what the flavor of SQL being used is? I want to think that it's a custom in-memory database (not SQLite or the ilk) due to non-standard syntax. One such example, from baldur.ini: INSERT INTO options ROWS (...) where the (...) seems to indicate multiple rows, despite the syntax indicating a single very large row in standard SQL implementations. Another example is that in BGEE.sql (from BG:EE), comments are made using the "//" syntax of C-derived languages, not the "--" of standard SQLs. Another example is what appears to be a call into an application function, such as setting globals or playing sound: FUNCTION goto { SELECT .CUIManager_InvalidateRect(''); global( 'currentmenu', menus.name[$1].id ); doscript( %menu, 'onOpen' ); }; FUNCTION sound { SELECT .PlaySound($1); }; So, while it initially appears to be SQL, this almost feels like pseudo-sql that's actually a new scripting language.
  2. Some of this contradicts what is already in IESDP: [Redacted the existing IESDP list to avoid confusion] Has the override folder order changed?
  3. 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.
  4. 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.
  5. In older threads, (here, here) it was mentioned that pvr is not yet documented for IESDP. Since Avenger pointed out a document that, when downloaded, required no NDA to be agreed to, I think I'll post the info here, but in a new thread in case someone wants to close this thread if necessary. It's worth mentioning that this information is readily available (I think) if you register on imgtec's website and download their SDK. Power VR header: In a PVR file, the header is 52 bytes long, or 0x34h long. Offset Size Name Description 0x0000 4 [DWORD] Version Either 0x03525650 is source and destination systems match endianness or 0x50565203 if they do match 0x0004 4 [DWORD] Flags 0x0000 if no flags set 0x0002 if colors within the texture 0x0008 8 [union] Pixel Format This field is somewhat awkward. It can either be one of several predetermined enumerated values (a DWORD) OR a 4-character array and a 4-byte array(8 bytes). If the most significant 4 bytes of the 64-bit (8-byte) value are all 0, then it indicates that it is the enumeration; otherwise it is the character array. Enumerated values are as follows: Value Pixel Type 0 PVRTC 2bpp RGB 1 PVRTC 2bpp RGBA 2 PVRTC 4bpp RGB 3 PVRTC 4bpp RGBA 4 PVRTC-II 2bpp 5 PVRTC-II 4bpp 6 ETC1 7 DXT1 / BC1 8 DXT2 9 DXT3 / BC2 10 DXT4 11 DXT5 / BC3 12 BC4 13 BC5 14 BC6 15 BC7 16 UYVY 17 YUY2 18 BW1bpp 19 R9G9B9E5 Shared Exponent 20 RGBG8888 21 GRGB8888 22 ETC2 RGB 23 ETC2 RGBA 24 ETC2 RGB A1 25 EAC R11 Unsigned 26 EAC R11 Signed 27 EAC RG11 Unsigned 28 EAC RG11 Signed Note that of the above, BG:EE and BG2:EE only appear to use DXT1 and DXT5. OTHERWISE, the 8-byte character array indicates the pixel format as follows: The least significant 4 bytes indicate channel order, such as in this example: { 'b', 'g', 'r', 'a' } or { 'b', 'g', 'r', '\0' } The most significant 4 bytes then indicate the width of each channel in bits, as follows: { 4, 4, 4, 4 } or { 2, 2, 2, 2 }, or {5, 5, 5, 0 } (the most likely values being 8s for full bytes) Quoth Avenger: "pvr files could have a hell of a number of pixel formats" 0x0010 4 [DWORD] Color Space This is an enumerated field, currently two values: Value Color Space 0 Linear RGB 1 Standard RGB 0x0014 4 [DWORD] Channel Type This is another enumerated field: Value Data Type 0 Unsigned Byte Normalized 1 Signed Byte Normalized 2 Unsigned Byte 3 Signed Byte 4 Unsigned Short Normalized 5 Signed Short Normalized 6 Unsigned Short 7 Signed Short 8 Unsigned Integer Normalized 9 Signed Integer Normalized 10 Unsigned Integer 11 Signed Integer 12 Float (no size specified) To be honest, I'm not sure what kind of normalization these values might indicate. I have observed normalized indicators, but data seemed identical to non-normalized data. 0x0018 4 [DWORD] Height Height of the image 0x001C 4 [DWORD] Width Width of the image 0x0020 4 [DWORD] Depth Depth of the image, in pixels Since this format targets 3D as well as 2D, I admit my ignorance of how this would be used. 0x0024 4 [DWORD] Surface Count The number of surfaces to this texture, used for texture arrays 0x0028 4 [DWORD] Face Count The number of faces to this texture, used for cube maps 0x002C 4 [DWORD] MIP-Map Count The number of MIP-Map levels, including a top level (again, I'm ignorant of what this means) 0x0030 4 [DWORD] Metadata Size The size, in bytes, of meta data that immediately follows this header Power VR meta data blocks: Offset Size Name Description 0x0000 4 [DWORD] FourCC Four-character identifier of the type of meta data. The following 255 arrays are reserved of PowerVR use: { 'P', 'V', 'R', 0x00 } { 'P', 'V', 'R', 0x01 } { 'P', 'V', 'R', 0x02 } ... { 'P', 'V', 'R', 0xFF } 0x0004 4 [DWORD] Key A secondary identifier indicating how the data should be interpreted 0x0008 4 [DWORD] Size The length of the meta data's data 0x000C 4 [DWORD] Data The binary data of the meta data These immediately follow the header. The meta data is read in a loop until you hit the meta data size specified in the header. I don't believe that meta data is extensively used for BGs:EE. Power VR data: This is the raw data for the pixels, interpreted dependent on the pixel type, color space, and other options indicated in the header. Pseudo-code for interpreting data is as follows: for (int mip = 0; mip < header.MIP-Map Count; ++mip) { for (int surface = 0; surface < header.Surface Count; ++surface) { for (int face = 0; face < header.Face Count; ++face) { for (int slice = 0; slice < header.Depth; ++slice) { for (int row = 0; row < header.Height; ++row) { for (int pixel = 0; pixel < header.Width; ++pixel) { //read X bytes, dependent on the header's Pixel Format } } } } } }
  6. This is a text format. I'm a bit ignorant, but are these pixel shaders or some OpenGL plugin?
  7. I'm quoting Avenger from the BGEE thread: 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.
  8. Does anyone else think that it is safe to assume, based on the common structure size, that an ARE's variable structure (as clarified by Scott Brooks) can be applied to variables inside a GAM v1.1? The unknowns appear to line up, and I don't think it's an unreasonable conclusion.
  9. "Intensity" is misleading at best, if not outright wrong. While it can display a moderately accurate representation of *.PLT content, if you assign colors to a palette and let 'intensity' modify the palette color (this is what Near Infinity does), they end up displaying too dark and off balance. Instead, color map is a row index into 'MPAL256.BMP', where the row numbers match the gradients stored in creatures. 'Intensity' is actually an index to a column of that row for the color to display. As a point of interest, the 255th value for this gradient is always { R:0 G: 255 B: 0 }, or transparent. Another point is that the shadow (palette channel # 7) is alpha-blended with the background, whereas the rest of the paper-doll is not. Comments on the palettes bitmaps: 'MPAL256.BMP' and 'MPALETTE.BMP' have their columns opposite; MPAL256 ranges dark to bright, whereas MPALETTE ranges bright to dark. Also, while BMPs store the rows bottom-up, their palettes are indexed top-down; index 0 is the first row on top when the image is viewed. This is all probably common knowledge, but I still wasted two days rediscovering this through original research.
  10. IESDP describes a trailing length of 218 padding bytes. All such shipped files are it is actually 240 (22 more bytes than reported).
  11. The Region structure is listed as being 0xB8 bytes long for ARE v. 9.1, when in shipped files their Name fields in the array are distanced 0xC4 bytes apart, just as in the ARE 1.0 structure.
  12. What I have definitely noticed: In the Strref Entries section, offset 0x0004 appears to be a boolean value indicating whether or not text exists. 1 (most cases) indicates that there is text. 0 indicates that there is no associated text. There is an accompanying TOT entry, however. A reproduction case is when editing a character biography, hitting clear, then done. A new strref seems to be created for each character that this is performed on. What I am uncertain of: Has anyone been able to confirm that offset 0x0010 is in fact a WAV/WAVC resref? I've tried inserting a couple custom strref overrides in dialogs with some wav resrefs that did not seem to play. As for offsets 0x0008 and 0x000C, I usually see 0 and 0 both. Often I see 16 and 33, respectively. Other pairs I've seen (signed values): * 33 and 32, * 1441817 and 1279655936 * 48 and 33 * 64 and 33 * 11250944 and 0 * 1966263 and -65536 * 145 and 32 * 96 and 33 I want to think of these as flags fields, but in some of my save games I've seen added map notes in a single area with different 'flags'. It almost makes me think it was junk data from memcpy, similar to some junk data seen trailing resrefs in CRE files.
  13. Offset 0x0004 is a back-link offset. In the case of larger strings, longer than 512, this offset it back references to the previous string block. It does not reference the first string block, which can be proven with blocks larger than 1572 characters. Usually, with strings < 512 in length, it is -1.
  14. The unknown at offset 0x0208 in TOT entries is an offset to the next entry, in case the string was larger than 512 bytes. In the case of IWD2 sorcerer biography: offset 0x0208, in my case (default.tot.zip), is 524, the second entry: Text displayed in-game is: Magic flows in your veins, always ready to be shaped by your will into some new arcane feat. But while you have learned to harness your inner strength over the past many years, now your spirit craves a challenge of a different sort - adventure. Discouraged by the prospects for excitement within the town of Luskan, a posting for adventurers in Targos caught your eye in the marketplace - and with it, a strange feeling of destiny. This feeling drew you to book passage on the Wicked Wench, across the lake Maer Dualdon to the besieged town of Targos, where you plan to stand with the town's defenders and carve a name on the field of battle." I am looking into the first two fields also.
  • Create New...