OBD talk:TXMP: Difference between revisions

OBD talk:TXMP (view source)

Revision as of 00:34, 7 March 2007

2,058 bytes added , 7 March 2007

→‎0x88

Neo

708

edits

@@ Line 165: / Line 165: @@
 :MIP mapping enabled (generations stored in RAW/SEP, used at runtime)
 :Q: Anything special about MIP mapping of DXT1-compressed pixels?
+:A: Not really, only the fact that a DXT1-compressed texture must be at least 4x4 pixels in size unlike an uncompressed image that goes down to 1x1 for mipmaps. [[User:Neo|Neo]]
 ;0x 02 00 00 00
 :Q: (sorry) ever used? effect? ^^ [[User:Geyser|geyser]]
+:A: There is no texture in any level that uses it. If it is of any use that's only at runtime. [[User:Neo|Neo]]
 ;0x 04 00 00 00
 :U wrapping disabled
@@ Line 177: / Line 179: @@
 :used a runtime (marks if a texture name has been allocated for this TXMP or not) [[User:Neo|Neo]]
 :Q: same question as below for 0x00200000: does the whole bitset get copied "elsewhere" at runtime? [[User:Geyser|geyser]]
+:A: See below [[User:Neo|Neo]]
 ;0x 40 00 00 00
 :unknown - animation related [[User:Neo|Neo]]
 :Q: (sorry) exact effect? ^^ [[User:Geyser|geyser]]
+:A: Play animation back to back - frames 0 to n then n-1 to 0 [[User:Neo|Neo]]
 ;0x 80 00 00 00
-:unknown - animation related, only used by an "electric arc" texture, could mean to play frames of the animation in random order [[User:Neo|Neo]]
+:Play animation in random order, only used by an "electric arc" texture [[User:Neo|Neo]]
 ;0x 00 01 00 00
 :Q: Ever used? Effect? ^^ [[User:Geyser|geyser]]
+:A: Animation related again, seems to change the time reference for animation. I've seen it used by w1_case texture in level0 which makes sense because you don't want to see 10 falling bullet cases playing the same animation frame. [[User:Neo|Neo]]
 ;0x 00 02 00 00
 :Reads the high byte as env map (0x00 is "little", 0xFF is "much")
 :Q: Sometimes used in conjunction with store type 1 or 2. 5x5x5 color, 1 bit extra, i.e., if it ''really'' reads the whole high byte, the 3 lower bits are ''garbage'' then?
+:A: Not sure about what "lower 3 bits" are you talking about. Probably you are asking if for a GL_RGBA4 texture all the 4 bits of the alpha channel are used. Yes, they are used. For env maps the alpha channel is sort of a "how much reflective is the surface" so it can be more or less reflective. [[User:Neo|Neo]]
 ;0x 00 04 00 00
 :Reads the high byte as alpha (0x00 is transparent, 0xFF is opaque)
 :Q: Same as above: what if the store type is 1 or 2?
+:A: The above explanation sounds strange. Most of the textures that use it are GL_RGB5 so there is no alpha channel. However, all the textures (most of them are animations) that use it have a black bakground which becomes transparent at runtime. [[User:Neo|Neo]]
 ;0x 00 08 00 00
 :Q: Ever used? Effect? ^^ [[User:Geyser|geyser]]
+:A: There is no texture in any level that uses it. If it is of any use that's only at runtime. [[User:Neo|Neo]]
 ;0x 00 10 00 00
 :On if there are 16 bits per uncompressed pixel (color depth etc may vary) ==> no changes ==> Oni reads it directly from the raw file [[User:Ssg|Ssg]] 11:06, 13 February 2007 (CET)
 :It appears to me that this bit means that the byte order of texture raw data must be swapped, it does not have anything to do with the number of bits which is encoded in the texture format anyway. [[User:Neo|Neo]]
 :Q: Whom is the swapped data relevant to, then? "Texture format" = "store type"? "Number of bits" = RGB color depth = "store type"? [[User:Geyser|geyser]]
+:A: The data from raw file is byte swapped. This is independent of texture format (= store type) which also includes the number of bits used. The raw data needs to be byte swapped because Open GL uses a RGBA format usually and the data is BGRA.  [[User:Neo|Neo]]
 ;0x 00 20 00 00
 :IIRC, that bit is never used in Oni. If you use it, Oni chrashes. [[User:Ssg|Ssg]] 11:06, 13 February 2007 (CET)
 :This one appears to be used only at runtime to mark if the texture has been loaded or not (loading basically means to convert the offset to texture data in the raw file to a memory address, that's why Oni crashes if you set this bit, it thinks that the texture is already loaded and it uses the file offset as a memory pointer which is not valid) [[User:Neo|Neo]]
 :Q: Neo, are you saying Oni ''writes to the memory-mapped DAT-part'' of every loaded TXMP? Or is that particular bitset copied "elsewhere"? [[User:Geyser|geyser]]
+:A: Yes, it writes to this bitset and in many other places of the DAT file. Links to files are replaced with pointers, offset in the raw data file are replaced with pointers, bitsets are written, "dead" fields or fields that are always 0 and appear to be unused are written to. [[User:Neo|Neo]]
 ;0x 00 40 00 00
 :Looks like TXAN looping ON/OFF. Somebody please check somehow ^^ [[User:Geyser|geyser]]
@@ Line 215: / Line 225: @@
 :To the last 3 entries: F.e. the SHIELD in ONI is blue. If you disable the "blue bit" and enable the "red bit" you'll get a red shield. If you disable the "blue bit" and enable no other "colour bit", you'll get a white shield, because IIRC, the hex data of the texture is fully FFFF. [[User:Ssg|Ssg]] 12:35, 6 March 2007 (CET)
 :Neo, what say you? Ssg: thanks a lot, but... no "green" bit? [[User:Geyser|geyser]] 13:44, 6 March 2007 (CET)
+:A: I haven't looked at this but from your story it seems correct. I can add that Open GL has 4 texture formats GL_RED, GL_GREEN, GL_BLUE and GL_ALPHA which can be used to implement the above behavior. [[User:Neo|Neo]]
 ----