OBD talk:TXMP: Difference between revisions

OBD talk:TXMP (view source)

Revision as of 03:05, 6 March 2007

4,896 bytes added , 6 March 2007

Just another little effort...

Geyser

Administrators

5,389

edits

@@ Line 63: / Line 63: @@
 |}
 ==Bitsets or indices==
-;Store type
+;Store type (0x90)
 :probably an index
-;MIP mapping
+;MIP mapping (0x88)
 :not sure
 :maybe they are not ''only'' MIP mapping options
 ::(in that case almost certainly a set of flags)
-;Color depth
+;Color depth (0x89)
 :It's not just the color depth
 :(actually, quite little to do with ''color'' depth)
 :so almost certainly a bitset.
-==MIP mapping==
+==MIP mapping (0x88)==
+Bitset
 ;0x01
 :This one "just" turns mip mapping on and off.
@@ Line 99: / Line 100: @@
 :A bitset ''does'' make some sense because both 1 and 17 use MIP mapping...
 :Well, IMO they're bitsets. I fixed that a long time ago. [[User:Ssg|Ssg]] 10:59, 13 February 2007 (CET)
+:You "fixed that" ''where''? I can't see it detailed on OS... [[User:Geyser|geyser]] 04:05, 6 March 2007 (CET)
 ==Color depth==
@@ Line 150: / Line 152: @@
 :rgb555, rgb565, rgba5551, argb1555, argb4444, rgba4444, rgba8888, s3, compressed, i8, i1, i4a4
 :(r=red, g=green, b=blue, a=alpha, i=intensity; see http://www.cg.tuwien.ac.at/~wimmer/view3dx/TEXUS.html too)
+----
+----
+==Reloaded==
+Woohoo, nice clean list for accurate knowledge! Over here!!!
+===0x88===
+Bitset (rather large: 18 bits at least)
+;0x01000000
+:MIP mapping enabled (generations stored in RAW/SEP, used at runtime)
+:Q: Anything special about MIP mapping of DXT1-compressed pixels?
+;0x02000000
+:Q: (sorry) ever used? effect? ^^ [[User:Geyser|geyser]]
+;0x04000000
+:U wrapping disabled
+;0x08000000
+:V wrapping disabled
+;0x10000000
+:Enabled for env-mapped textures and env maps themselves.
+:Q: Also enabled for skyboxes? Exact effect? [[User:Geyser|geyser]]
+;0x20000000
+: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]]
+;0x40000000
+:unknown - animation related [[User:Neo|Neo]]
+:Q: (sorry) exact effect? ^^ [[User:Geyser|geyser]]
+;0x80000000
+:unknown - animation related, only used by an "electric arc" texture, could mean to play frames of the animation in random order [[User:Neo|Neo]]
+;0x00010000
+:Q: Ever used? Effect? ^^ [[User:Geyser|geyser]]
+;0x00020000
+: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?
+;0x00040000
+: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?
+;0x00080000
+:Q: Ever used? Effect? ^^ [[User:Geyser|geyser]]
+;0x00100000
+: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]]
+;0x00200000
+: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]]
+;0x00400000
+:Looks like TXAN looping ON/OFF. Somebody please check somehow ^^ [[User:Geyser|geyser]]
+:Q: (sorry) did anybody "please check somehow"? ^^ [[User:Geyser|geyser]]
+;0x00800000
+:16 bit blue (?) - only SHIELD uses it [[User:Ssg|Ssg]] 11:06, 13 February 2007 (CET)
+:Q: ??? [[User:Geyser|geyser]]
+;0x00001000
+:16 bit alpha (?) - only INVIS uses it [[User:Ssg|Ssg]] 11:06, 13 February 2007 (CET)
+:Q: ??? [[User:Geyser|geyser]]
+;0x00002000
+:16 bit red (?) - only DAODAN_SHIELD uses it [[User:Ssg|Ssg]] 11:06, 13 February 2007 (CET)
+:Q: ??? [[User:Geyser|geyser]]
+----
+===0x90===
+Integer ID. Defines the ''RGB'' color depth of texels (is that correct?)
+;0
+:(4,4,4) RGB, 4 bits extra (interpreted as alpha or env map blending)
+::equivalent to GL_RGBA4 OpenGL image format
+:Q: Does the interpretation of the high bits depend on the 0x88 settings? [[User:Geyser|geyser]]
+;1
+:(5,5,5) RGB and 1 bit extra
+::the extra bit is simply ignored, equivalent to GL_RGB5 OpenGL image format
+:Q: Is the extra bit ''always'' ignored, regardless of the 0x88 settings? [[User:Geyser|geyser]]
+;2
+:(5,5,5) RGB, 1 bit extra (interpreted as alpha or env map blending)
+::equivalent to GL_RGB5_A1 OpenGL image format
+:Q: Does the interpretation of the high bits depend on the 0x88 settings? [[User:Geyser|geyser]]
+;8
+:(8,8,8) RGB, 8 bits extra
+::extra bits are ignored, equivalent to GL_RGB OpenGL image format
+:Q: (sorry) are the extra bit ''always'' ignored, regardless of the 0x88 settings? [[User:Geyser|geyser]]
+;9
+:compressed (four times) (algorithm detailed elsewhere)
+::equivalent to [http://www.oldunreal.com/editing/s3tc/ARB_texture_compression.pdf GL_COMPRESSED_RGB_S3TC_DXT1_EXT] OpenGL compressed image format
+:::(note: ARB stands for Architecture Review Board, not Alpha Red Blue ^^)
+:Q: Aha, "dxt1". Any more ideas looking at [[OSL:Preset#Only_on_Mac_beta_4|THESE]]? [[User:Geyser|geyser]]
+;Anything else?
+:Q: (sorry) nothing else, ever ever? ^^ [[User:Geyser|geyser]]