Retro Modding Wiki - User contributions [en]

ANIM (Metroid Prime 3)

2016-05-08T16:42:15Z

Bearborg:

''This article is for the ANIM format used in ''Metroid Prime 3''. See [[ANIM (File Format)]] for the other revisions of this format.''

The '''ANIM format''' is used in conjunction with [[CINF]] + [[CSKR]]
rigging to animate [[CMDL (Metroid Prime)|CMDL meshes]].

There are two versions of the ANIM format in ''Metroid Prime 3'' (indicated by the file's first u32 value):

{| class="wikitable"
!Version
!Description
|-
|0x0
|[[#Quaternion Array Format|Quaternion Array Format]]
|-
|0x1
|[[#Bitstream Format|Bitstream Format]]
|}

== Quaternion Array Format ==

{{main|ANIM (Metroid Prime)}}

This format is identical to [[ANIM (Metroid Prime)#Quaternion Array Format (Uncompressed)|Metroid Prime 2's Version 0]]
'''except for an unknown u16 value inserted at the beginning'''.

== Bitstream Format ==

The '''Bitstream Format''' (0x1) version of ANIM is a significant departure from Version 0x2 used in MP1/2.
It's still based on a [[wikipedia:Bitstream|bitstream]] with
[[wikipedia:Delta encoding|delta encoding]] and [[wikipedia:Quantization (signal processing)|quantization]],
but the quaternion encoding is simpler to decode and the key-layout is slightly different.

There is no longer a frame interval value for defining a consistent frame-rate; each keyed-frame's time position
is explicitly defined as a floating-point value in seconds.

Additionally, [[CINF]] bone-IDs are no longer explicitly defined; the indexing
position of the bone channel serves as the bone-ID (beginning at 0 for the root bone).

=== Key Values ===

Each keyed-frame begins with 1-bit in the stream; its purpose is unknown.

Each channel attribute is initialized iteratively using the ''init_block''
values. For every frame of every bone channel, the key value in the bitstream is ''added''
with the previous key value (to resolve the delta encoding).

Once resolved, rotation imaginary components and scale components are divided by 0x7FFF, resulting
in normalized floats.

Rotation channels consist of 4-components per-bone. The first expresses the quaternion W-sign
in the least-significant bit. The remaining 3 express quaternion imaginary (XYZ) values.
The W value itself is calculated using normalized-difference:

<pre>
q = 1.0 / 0x7FFF
X = rx * q
Y = ry * q
Z = rz * q
W = sqrt(MAX((1.0 - (X*X + Y*Y + Z*Z)), 0.0))
W = (rw & 0x1) ? -W : W
</pre>

Translation components are multiplied by ''translation_multiplier'', yielding world units.

=== Layout ===

{| class="wikitable"
!Data Type
!Element Count
!Identifier
!Notes
|-
|[[#Header1|Header1]]
|1
|header
|
|-
|float
|header.key_count
|key_times
|Array of time positions in seconds
|-
|u8
|1
|channel_flag_count
|
|-
|u8
|channel_flag_count
|channel_flags
|Field of 3-bits for enabling channel attributes
* 0x1: Rotation
* 0x2: Translation
* 0x4: Scale
|-
|s16
|header.init_block_size / 2
|init_block
|Initial values for each channel-attribute animated by this ANIM (bone-major)
|-
|u32
|1
|channel_q_count
|
|-
|u32
|1
|{{unknown|unknown0}}
|
|-
|u32
|1
|{{unknown|unknown1}}
|
|-
|u8
|1
|channel_q_block
|Quantized bit-count for each channel-attribute animated by this ANIM (bone-major)
|-
|
|<remainder-of-stream-block>
|key_bitstream
|Word-packed bitstream laid out as described by the tables above. The bitstream is unpacked least-significant to most-significant bit for each word.
Key values are tightly-packed, quantized integers whose bit-depth is specified by the values in the ''channel_q_block''.

The key integers are signed using [[wikipedia:Two's complement|Two's complement]] representation.
|-
|u32
|1
|unknown_bool_count
|Seems to match the bone count
|-
|u8
|unknown_bool_count
|{{unknown|unknown_bools}}
|
|}

=== Header1 ===

{| class="wikitable"
!Offset
!Length
!Data Type
!Identifier
!Notes
|-
|0x0
|2
|u16
|{{unknown|unknown0}}
|
|-
|0x2
|1
|u8
|{{unknown|unknown1}}
|
|-
|0x3
|4
|u32
|{{unknown|unknown2}}
|
|-
|0x7
|3
|u8[3]
|{{unknown|unknown3}}
|
|-
|0xA
|4
|float
|translation_multiplier
|Translation vectors are multiplied by this value before being applied
|-
|0xE
|4
|u32
|{{unknown|unknown4}}
|
|-
|0x12
|4
|u32
|{{unknown|unknown5}}
|
|-
|0x16
|4
|float
|{{unknown|unknown6}}
|
|-
|0x1A
|4
|float
|{{unknown|unknown7}}
|
|-
|0x1E
|4
|float
|duration
|Time in seconds that the animation plays for
|-
|0x22
|2
|u16
|key_count
|Count of keyed-frames in animation (including initializer keys)
|-
|0x24
|4
|u32
|data_blob_size
|Count of bytes after header
|-
|0x28
|1
|u8
|{{unknown|unknown8}}
|
|-
|0x29
|4
|u32
|key_times_size
|Count of bytes in key times array
|-
|0x2D
|4
|u32
|channel_flags_size
|Count of bytes in channel flags array
|-
|0x31
|4
|u32
|init_block_size
|Count of bytes in init block
|-
|0x35
|4
|u32
|stream_block_size
|Count of bytes in bitstream block (everything after init_block)
|-
|0x39
|4
|u32
|{{unknown|unknown9}}
|
|-
|0x3D
|4
|u32
|bone_count
|Count of bone channels in this ANIM
|}

[[Category:File Formats]]
[[Category:Metroid Prime 3: Corruption]]

File:ATEX example crunchy.gif

2016-02-29T01:36:16Z

Bearborg: Bearborg uploaded a new version of File:ATEX example crunchy.gif

MAPA (File Format)

2015-04-11T13:51:40Z

Bearborg: /* Point of Interest */

The '''.MAPA file format''' defines the minimap models used in the Metroid Prime series. MAPA or '''MAP A'''rea consists of several sections: The header, Point Of Interest entries, Vertices, Primitive Headers, and the primitives.

{{research|2|A few things are unknown in the header and POI Entries}}

__TOC__
== Format ==
=== Header ===
The header is very straight forward, and has some minor differences depending on version, the unknown values don't seem to do anything, however not much research has been put into them.

{| class="wikitable"
!Type
!Description
!MP1
!MP2
!MP3
|-
|u32
|'''Magic'''; Always 0xDEADD00D
|{{check}}
|{{check}}
|{{check}}
|-
|u32
|'''Version'''; See below
|{{check}}
|{{check}}
|{{check}}
|-
|CAABox
|'''Bounding Box'''
|{{check}}
|{{check}}
|{{check}}
|-
|u32
|{{unknown|Unknown}}
|{{check}}
|{{check}}
|{{check}}
|-
|u32
|{{unknown|Unknown}}
|{{check}}
|{{check}}
|{{check}}
|-
|u32
|{{unknown|Unknown}}
|{{nocheck}}
|{{check}}
|{{check}}
|-
|u32
|{{unknown|Unknown}}
|{{nocheck}}
|{{check}}
|{{check}}
|-
|u32
|{{unknown|Unknown}}
|{{nocheck}}
|{{check}}
|{{check}}
|-
|u32
|{{unknown|Unknown}}
|{{nocheck}}
|{{nocheck}}
|{{check}}
|-
|u32
|'''POI Count'''
|{{check}}
|{{check}}
|{{check}}
|-
|u32
|'''Vertex Count'''
|{{check}}
|{{check}}
|{{check}}
|-
|u32
|'''Primitive Count'''
|{{check}}
|{{check}}
|{{check}}
|}

==== Version ====
The version value listed above can have the following values:
{|class="wikitable"
!Game
!Value
|-
|Metroid Prime 1
|2
|-
|Metroid Prime 2: Echoes
|3
|-
|Metroid Prime 3: Corruption
|5
|}

=== Point of Interest ===
A Point of Interest in the Metroid Prime series can include: Mission Objectives, Elevators, Doors, Map Stations, and Missile Stations. Each Point of Interest entry consists of the following struct:
{|class="wikitable"
!Type
!Description
!MP1 & MP2
!MP3
|-
|u32
|{{unknown|Unknown}}
|{{nocheck}}
|{{check}}
|-
|u32
|'''Type'''; All valid values are not currently known
|{{check}}
|{{check}}
|-
|u32
|{{unknown|Unknown}}
|{{check}}
|{{check}}
|-
|u16
|{{unknown|Unknown}}
|{{check}}
|{{nocheck}}
|-
|u16
|'''ID'''; Which door, elevator etc.
|{{check}}
|{{nocheck}}
|-
|CVector4f
|{{unknown|Unknown}}
|{{nocheck}}
|{{check}}
|-
|u32
|'''Padding'''; always -1
|{{check}}
|{{check}}
|-
|CTransform4f
|'''Tranform Matrix''' The Point of Interest's position in '''world''' space.
|{{check}}
|{{check}}
|-
|u32 * 4
|'''Padding'''; four values of -1
|{{check}}
|{{check}}
|}

=== Vertices ===

Vertices are a simple array of CVector3f. Geometry in MAPAs is, almost always, centered around the origin (0, 0, 0) and are simplified, full sized, versions of the map they replicate. Each vertex is referenced at least twice: once for the primitive, once for the line border.

=== Primitive Headers ===

The Primitive headers are extremely simple, they merely have a bounding box followed by the primitive table start and end point, relative to the end of the current primitive header. In other words: read in the header, seek to the start of the table from the '''current''' position, then read the primitives tables.

{|class="wikitable"
!Type
!Description
|-
|CAABox
|'''Bounding Box'''
|-
|u32
|'''Primitive Table Start'''; relative to the end of this header
|-
|u32
|'''Primitive Table End'''; relative to the end of this header
|}

=== Primitive Table ===

The Primitive is also fairly simple, each one consists of two parts: The GX Primitive list, and the Border list.
{|class="wikitable"
!Type
!Description
|-
|u32
|'''Primitive Count (PC)'''
|-
|Primitive * PC
|'''Primitives'''
|-
|u32
|'''Border Count (BC)'''
|-
|Border * (BC)
|'''Borders'''
|}

=== Primitive ===

A primitive in a MAPA is a simple 4 byte aligned list of indices into the vertex list, starting with the GX Primitive type, a count, then an array of indices, each index taking up one byte.

=== Border ===

A border in a MAPA is a simple count followed by a 4 byte aligned list indices into the vertex list, each index taking up one byte. A border is simply drawn using GX_LINESTRIP.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

Materials (Metroid Prime)

2015-03-17T20:54:00Z

Bearborg: /* Color Channels */

The format for '''materials''' is seen in both the [[CMDL (Metroid Prime)|CMDL]] and [[MREA (File Format)|MREA]] formats and is identical in both. This particular material format appears in both Metroid Prime and Metroid Prime 2 with minor differences.

{{research|minor|There are two unknown values left in the MP1 material format, and there might be some unknown flag settings. Also, everything that was introduced in Echoes (two general settings and a vertex attribute) is unknown.}}

__TOC__

== GX Overview ==

The materials system in Metroid Prime is heavily dependent on the GameCube and Wii's graphics system, GX. GX is a fixed-function graphics pipeline, similar to old versions of OpenGL. In GX, rendering is done through a series of steps called '''T'''exture '''E'''n'''V'''ironment Stages, or or TEV stages for short.

Lighting calculations and tex coord generation are done per-vertex and passed along to TEV; the results of the lighting calculations are saved into up to two color channels that can be used as TEV inputs (as the rasterized vertex color). Each TEV stage takes in four color inputs and four alpha inputs, from one of eight sources. Then these four input colors are combined into one output color, and the output is saved into one of four registers, which can subsequently be used as input in the next TEV stages. The final stage must always save its output into the "previous TEV stage" register; that register is used as the final pixel color that gets displayed onscreen.

== Material Set Format ==

Materials come as part of a set; often there will only be one set per file, but many CMDLs can have more than one. The set begins with a short header before the actual material data begins.

{| class="wikitable"
!Type
!Count
!Description
|-
| long
| 1
| '''Texture count''' (TC)
|-
| long
| TC
| '''Texture file IDs'''
|-
| long
| 1
| '''Material count''' (MC)
|-
| long
| MC
| '''Material end offsets''' (relative to the start of the first material)
|-
| colspan=3 | Materials begin
|}

== Material Format ==

=== General Settings ===

Each material begins with a flags value, followed by a list of texture indices:

{| class="wikitable"
!Type
!Count
!Description
|-
| long
| 1
| '''Flags'''
|-
| long
| 1
| '''Texture count''' (TC)
|-
| long
| TC
| '''Texture indices''' (these are indices into the material set texture array)
|-
| long
| 1
| '''Vertex attribute flags'''
|-
| long
| 1
| {{unknown|'''Unknown''' ''(note: only in Echoes)''}}
|-
| long
| 1
| {{unknown|'''Unknown''' ''(note: only in Echoes)''}}
|-
| long
| 1
| {{unknown|'''Unknown'''}}
|-
| long
| 1
| '''Konst count''' (KC); max setting is 4. ''(note: only present if flag 0x8 is set!)''
|-
| long
| KC
| '''Konst colors''' - 32-bit RGBA colors ''(note: not present if the Konst count isn't)''
|-
| short
| 1
| '''Blend destination factor'''
|-
| short
| 1
| '''Blend source factor'''
|-
| long
| 1
| {{unknown|'''Unknown''' ''(note: only present if flag 0x400 is set!)''}}
|-
| long
| 1
| '''Color channel count''' (CC)
|-
| long
| CC
| '''Color channel flags''' ''(note: only one flag value, but you must advance 4*CC bytes instead of 4 for some reason)''
|-
| long
| 1
| '''TEV stage count'''
|}

==== Flags ====

These are the known flag settings:

{| class="wikitable"
! Bit
! Hex
! Description
|-
| 0
| 0x1
| Appears unused, but always set
|-
| 1
| 0x2
| Appears unused, but always set
|-
| 2
| 0x4
| Appears unused, but always unset
|-
| 3
| 0x8
| Enable Konstant values
|-
| 4
| 0x10
| Mark transparent material
|-
| 5
| 0x20
| Enable punchthrough alpha
|-
| 6
| 0x40
| Enable Samus's reflection
|-
| 7
| 0x80
| Enable depth writing
|-
| 8
| 0x100
| {{unknown|Unknown}}
|-
| 9
| 0x200
| Don't draw
|-
| 10
| 0x400
| Enable second unknown value
|-
| 11
| 0x800
| {{unknown|Unknown}}
|-
| 12
| 0x1000
| {{unknown|Unknown}}
|-
| 13
| 0x2000
| Enable lightmaps; first UV coordinate uses short array instead of float array
|-
| 14
| 0x4000
| {{unknown|Unknown}}
|-
| 15
| 0x8000
| {{unknown|Unknown}}
|-
| 16
| 0x10000
| {{unknown|Unknown}}
|-
| 17
| 0x20000
| {{unknown|Unknown}}
|-
| 18
| 0x40000
| {{unknown|Unknown}}
|-
| 19
| 0x80000
| {{unknown|Unknown}}
|-
| 20+
| 0x100000+
| Unused; never set
|}

==== Vertex Attribute Flags ====

These flags are generally toggled in pairs, with each pair corresponding to a vertex attribute; if a pair is set, then vertices using this material will have the corresponding attribute. This is vital for reading geometry.

An important note is that while the leftmost byte is not used in Prime 1, in Echoes there's occasionally a value there that toggles an extra vertex attribute preceding position. This needs research to determine what the new attribute actually is. Also, GX supports up to 8 texture coords per vertex, but the game doesn't seem to allow you to assign more than 7 (though this could do with some double-checking).

These are the possible attributes:

{| class="wikitable"
! Bit pair
! Attribute
|-
| 0x3
| Position
|-
| 0xC
| Normal
|-
| 0x30
| Color 0
|-
| 0xC0
| Color 1
|-
| 0x300
| Tex 0
|-
| 0xC00
| Tex 1
|-
| 0x3000
| Tex 2
|-
| 0xC000
| Tex 3
|-
| 0x30000
| Tex 4
|-
| 0xC0000
| Tex 5
|-
| 0x300000
| Tex 6
|}

==== Konst Colors ====

These values are only present when flag 0x8 is enabled. These allow you to set Konstant values, which can subsequently be used as inputs in TEV stages. The maximum number of Konst values you can set on one material is 4. The colors themselves are simply 32-bit RGBA values.

==== Blend Mode ====

The two blend factors set the blending mode used. The most common values you'll see are 0/1, which is used on opaque materials; transparent materials will usually have either 1/1, for additive blending, or 5/4, for alpha blending. Here's the full range of possible settings for each value:

{| class="wikitable"
! Value
! Blend factor
|-
| 0
| GX_BL_ZERO
|-
| 1
| GX_BL_ONE
|-
| 2
| GX_BL_SRCCLR / GX_BL_DSTCLR
|-
| 3
| GX_BL_INVSRCCLR / GX_BL_INVSRCCLR
|-
| 4
| GX_BL_SRCALPHA
|-
| 5
| GX_BL_INVSRCALPHA
|-
| 6
| GX_BL_DSTALPHA
|-
| 7
| GX_BL_INVDSTALPHA
|}

==== Color Channels ====

The color channels data consists of a count value indicating the number of color channels, and then one set of flags that controls the COLOR0 channel. The flags correspond to arguments passed to [http://libogc.devkitpro.org/gx_8h.html#a87d79cf2375217d06237c887ba027cc2 GX_SetChanCtrl()]. These are the settings:

{| class="wikitable"
! Bits
! Hex
! Description
|-
| 0
| 0x1
| '''Enable lighting''' (enable)
|-
| 1
| 0x2
| '''Ambient color source''' (ambsrc)
|-
| 2
| 0x4
| '''Material color source''' (matsrc)
|-
| 3-10
| 0x7F8
| '''Light mask'''; always 0, filled in at runtime ([http://libogc.devkitpro.org/group__lightid.html litmask])
|-
| 11-12
| 0x1800
| '''Diffuse function''' ([http://libogc.devkitpro.org/group__difffn.html diff_fn])
|-
| 13-14
| 0x6000
| '''Attenuation function''' ([http://libogc.devkitpro.org/group__attenfunc.html attn_fn])
|}

There's only one set of flags, which operates on COLOR0. COLOR1 is reserved for dynamic shadows (terrain casting shadows on actors), so its settings can't be directly modified. Here's how the other color channel settings work.

COLOR1A1's settings vary depending on whether shadowmaps are enabled:

* No processing will be done if the count value is 0. Otherwise, the count value is ignored; the game will always set up both color channels.
* COLOR1A1's ambient color is black, and its material color is white.
* COLOR1 will use the diffuse function GX_DF_CLAMP and the attenuation function GX_AF_SPOT. It will have lighting disabled entirely if there are no lights in range

If shadowmaps are disabled:

* COLOR1 is disabled if the count value is not 2. If it is 2, then its ambient color will be black and its material color will be white.

COLOR0 is set up the same way either way:

* COLOR0 will use the flags from the material, with the light mask merged in. It will also have lighting disabled if there are no lights in range.
* If there are no lights in range, COLOR0A0 will have its material color set to match its ambient color. Otherwise, its material color will be set to white.

Finally, an important note is that the formatting of the color channel info is bugged. There is always a color channel count and a single set of flags; 8 bytes total. However, for some reason the game is expecting one set of flags per color channel. To reach the TEV stages, you need to advance (4 * count) bytes past the count value, rather than 4. A likely explanation is that there was one set of flags per channel earlier in development, and the material loading code wasn't fully updated when this was changed. It's not normally an issue because the count is always 1 in every file the game uses, but beware for experimentation/custom materials.

=== TEV Stages ===

There'll be one of these structures per TEV stage:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Color Input Flags'''
|-
| 0x4
| 4
| '''Alpha Input Flags'''
|-
| 0x8
| 4
| '''Color Combine Flags'''
|-
| 0xC
| 4
| '''Alpha Combine Flags'''
|-
| 0x10
| 1
| '''Padding'''
|-
| 0x11
| 1
| '''Konst Alpha Input''' ([http://libogc.devkitpro.org/group__tevkalphasel.html possible values])
|-
| 0x12
| 1
| '''Konst Color Input''' ([http://libogc.devkitpro.org/group__tevkcolorsel.html possible values])
|-
| 0x13
| 1
| '''Rasterized Color Input''' ([http://libogc.devkitpro.org/group__channelid.html possible values])
|-
| 0x14
| colspan=2 {{unknown|End of TEV stage}}
|}

After looping through each TEV stage, there will be one of these structures per stage:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| '''Padding'''
|-
| 0x2
| 1
| '''Texture TEV Input'''
|-
| 0x3
| 1
| '''Tex Coord TEV Input'''
|-
| 0x4
| colspan=2 {{unknown|End of structure}}
|}

==== Color Input Flags ====

These flags set the four color inputs that are used by the TEV stage. Each color is allocated 5 bits, even though only 4 are actually used; the lower bits correspond to the lower input numbers (eg. the bottom 5 bits refer to the first input).

There are 16 possible color sources:

{| class="wikitable"
! Binary
! Hex
! Color Source
|-
| 00000
| 0x0
| Previous stage RGB
|-
| 00001
| 0x1
| Previous stage AAA
|-
| 00010
| 0x2
| Color 0 RGB
|-
| 00011
| 0x3
| Color 0 AAA
|-
| 00100
| 0x4
| Color 1 RGB
|-
| 00101
| 0x5
| Color 1 AAA
|-
| 00110
| 0x6
| Color 2 RGB
|-
| 00111
| 0x7
| Color 2 AAA
|-
| 01000
| 0x8
| Texture RGB
|-
| 01001
| 0x9
| Texture AAA
|-
| 01010
| 0xA
| Rasterized RGB
|-
| 01011
| 0xB
| Rasterized AAA
|-
| 01100
| 0xC
| One
|-
| 01101
| 0xD
| Half
|-
| 01110
| 0xE
| Konstant RGB
|-
| 01111
| 0xF
| Zero
|}

==== Alpha Input Flags ====

Similar to the color input flags, these set the four alpha inputs used by the TEV stage. Each value is allocated 5 bits, although only 3 are used. The main difference with alpha is that there are only 8 possible sources instead of 16:

{| class="wikitable"
! Binary
! Hex
! Alpha Source
|-
| 00000
| 0x0
| Previous stage alpha
|-
| 00001
| 0x1
| Color 0 alpha
|-
| 00010
| 0x2
| Color 1 alpha
|-
| 00011
| 0x3
| Color 2 alpha
|-
| 00100
| 0x4
| Texture alpha
|-
| 00101
| 0x5
| Rasterized alpha
|-
| 00110
| 0x6
| Konstant alpha
|-
| 00111
| 0x7
| Zero
|}

==== Color Combine Flags ====

These flags specify how the operation that combines the four input colors into one output color is performed.

This is the combiner function:

<pre>tevrigid = (d (tevop) ((1.0-c)*a + c*b) + tevbias) * tevscale;</pre>

The values set in the color operation flags correspond to the parameters passed to [http://libogc.devkitpro.org/gx_8h.html#a067b875ff1e3e6760d0d7d7838c6c4c2 GX_SetTevColorOp()]. These are the settings:

{| class="wikitable"
! Bits
! Hex
! Description
|-
| 0-3
| 0xF
| '''Combiner operator''' ([http://libogc.devkitpro.org/group__tevop.html tevop])
|-
| 4-5
| 0x30
| '''Bias''' ([http://libogc.devkitpro.org/group__tevbias.html tevbias]); 00 does nothing; 01 adds 0.5; 10 subtracts 0.5; 11 does nothing.
|-
| 6-7
| 0xC0
| '''Scale''' ([http://libogc.devkitpro.org/group__tevscale.html tevscale]); 00 does nothing; 01 multiples by 2; 10 multiplies by 4; 11 divides by 2.
|-
| 8
| 0x100
| '''Clamp flag'''; enabling this will clamp the output color between 0 and 1.
|-
| 9-10
| 0x600
| '''Output register''' ([http://libogc.devkitpro.org/group__tevcoloutreg.html tevrigid]); can be Previous Stage or Color 0/1/2
|-
| 11+
| 0xFFFFF800
| Unused.
|}

Note that the vast majority of materials in the game, if not all of them, don't really bother with any of this; they enable clamping, set an output register, and leave everything else at their defaults of 0.

==== Alpha Combine Flags ====

This is exactly the same as the color combine flags; the only difference is it operates on alpha instead of color.

=== Texgen ===

After the TEV stages comes a sequence of flags determining how texgen is executed. Texgen is the process of taking input values and using them to generate texture coordinates (or UV coordinates), which can then be used by the TEV stages. It's important to note that any vertex attribute can be used as a texgen input; in fact, it's rather common for materials to use the vertex normal as an input to simulate reflections. That means ''the number of texture coords present on each vertex is not the same as the number of texture coords available to TEV''.

{| class="wikitable"
! Type
! Count
! Description
|-
| long
| 1
| '''Texgen count''' (TC)
|-
| long
| TC
| '''Texgen flags'''
|}

The flags correspond to arguments passed to [http://libogc.devkitpro.org/gx_8h.html#a55a426a3ff796db584302bddd829f002 GX_SetTexCoordGen2()]. These are the settings:

{| class="wikitable"
! Bits
! Hex
! Description
|-
| 0-3
| 0xF
| '''Texture coord generation type''' ([http://libogc.devkitpro.org/group__texgentyp.html tgen_typ])
|-
| 4-8
| 0x1F0
| '''Texture coord source''' ([http://libogc.devkitpro.org/group__texgensrc.html tgen_src])
|-
| 9-13
| 0x3E00
| '''Texture matrix index''' ([http://libogc.devkitpro.org/group__texmtx.html mtxsrc] - add 30)
|-
| 14
| 0x4000
| '''Normalize flag''' - normalizes texture coord after it's multiplied by the texture matrix (normalize)
|-
| 15-20
| 0x1F8000
| '''Post-transform texture matrix index''' ([http://libogc.devkitpro.org/group__dttmtx.html postmtx] - add 64)
|-
| 21+
| 0xFFE00000
| Unused
|}

=== UV Animations ===

The UV animations section immediately follows the texgen flags. Its purpose is to generate texture matrices and post-transform matrices, which are then used to transform UV coordinates. This is commonly used to animate textures via simple UV scrolls, but it's also often used to simulate reflective surfaces that move with the camera. Materials can have multiple UV animations; in that case, each animation generates a separate texture/post-transform matrix and are loaded into GX sequentially. Texgen is used to set which matrices are used by which UV coordinates (if any).

The section starts with this short header:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Material animations section size''' (includes animation count, so will be 4 at minimum)
|-
| 0x4
| 4
| '''Animation count'''
|}

The structure of the animations themselves is somewhat simple. Each animation has a 32-bit ''mode'' setting, followed by a number of float parameters. The number and usage of these float parameters varies depending on what mode is set. There are 8 possible modes.

For all of the following modes, ''s'' refers to ''seconds mod 900''.

==== Mode 0: Inverse ModelView Matrix (No Translation) ====

This mode is commonly used with vertex normals to simulate reflective surfaces using spheremaps that move with the camera. It takes no parameters, and will generate both a texture matrix and a post-transform matrix. Translation is ignored.

The texture matrix is calculated like this. Note that the multiplication of the view matrix by the model matrix should be modified slightly rather than being a straight multiplication to ignore translation on the model matrix. (The game uses a function called MultiplyIgnoreTranslation for this.)

<pre>texmtx = inverse(ViewMatrix) * ModelMatrix;
texmtx[0][3] = texmtx[1][3] = texmtx[2][3] = 0;</pre>

The post-transform matrix is a constant value. [1][1] and [1][2] may need to be swapped around for correct playback.

<pre>0.5, 0.0, 0.0, 0.5,
0.0, 0.0, 0.5, 0.5,
0.0, 0.0, 0.0, 1.0</pre>

==== Mode 1: Inverse ModelView Matrix ====

This mode is nearly identical to mode 0; the only difference is that translation is left as-is. The multiplication of the view matrix by the model matrix actually is a straight multiplication in this mode, and the translation values on the texture matrix aren't set to 0.

==== Mode 2: UV Scroll ====

This mode is used to scroll both U and V at the same time. It will only generate a texture matrix. It has four float parameters: ''offsetA'', ''offsetB'', ''scaleA'', and ''scaleB''.

<pre>uOffset = (s * scaleA) + offsetA;
vOffset = (s * scaleB) + offsetB;</pre>

==== Mode 3: Rotation ====

This mode rotates the texture. It will only generate a texture matrix. It has two float parameters: ''offset'' and ''scale''.

<pre>float angle = (s * scale) + offset;
float acos = cos(angle);
float asin = sin(angle);
float translateX = (1.0 - (acos - asin)) * 0.5;
float translateY = (1.0 - (asin + acos)) * 0.5;</pre>

The resulting texture matrix is laid out as:

<pre>acos, -asin, 0.0, translateX,
asin, acos, 0.0, translateY,
0.0, 0.0, 1.0, 0.0</pre>

==== Mode 4/5: Horizontal/Vertical Filmstrip ====

These modes can be used to create a filmstrip-like effect. The texture steps a set distance each animation frame, rather than the scroll being smoothly interpolated every game frame. The same calculation is done for both modes, with the only difference being whether the calculated offset is applied to the U or V coordinate. It will only generate a texture matrix. There are four float parameters: ''scale'', ''numFrames'', ''step'', and ''offset''.

The animation is made up of a number of pseudo-frames, where ''step'' controls the amount that the texture scrolls by each frame, and ''numFrames'' sets how many frames are iterated through before resetting back to 0. ''scale'' roughly controls animation playback speed, and ''offset'' modifies the time input value.

<pre>float value = step * scale * (offset + s);
float uv_offset = (float)(short)(float)(numFrames * fmod(value, 1.0f)) * step;</pre>

==== Mode 6: Model Matrix ====

This mode is similar to modes 0 and 1 in that it simulates reflective surfaces, but it only takes the model matrix into account, which means camera movement doesn't affect the reflection. It takes no parameters and it generates both a texture matrix and a post-transform matrix.

The texture matrix is simply the model matrix, with the translation values set to 0. The post-transform matrix is set to the following:

<pre>0.5, 0.0, 0.0, ModelMatrix[0][3] * 0.50000001,
0.0, 0.0, 0.5, ModelMatrix[1][3] * 0.50000001,
0.0, 0.0, 0.0, 1.0</pre>

==== Mode 7: Mode-Who-Must-Not-Be-Named ====

Mode 7 takes two parameters and generates both a texture matrix and a post-transform matrix. We don't know what to name it.

The texture matrix is generated the same way as in mode 0; translation is ignored.

<pre>texmtx = inverse(ViewMatrix) * ModelMatrix;
texmtx[0][3] = texmtx[1][3] = texmtx[2][3] = 0;</pre>

The post-transform matrix is where it gets a little complicated. A little math is required to calculate some values:

<pre>float xy = ((ViewMatrix[0][3] + ViewMatrix[1][3]) * 0.025f * ParamB;
xy = (xy - (int) xy); // This truncates the integer portion of the value, leaving only the fractional part (mantissa).

float z = ViewMatrix[2][3] * 0.05f * ParamB;
z = (z - (int) z);

float halfA = ParamA * 0.5f;</pre>

The post-transform matrix is then constructed as:

<pre>halfA, 0.0f, 0.0f, xy,
0.0f, 0.0f, halfA, z,
0.0f, 0.0f, 0.0f, 1.0f</pre>

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]

Metroid Prime 2: Echoes

2015-02-27T05:51:49Z

Bearborg: Pretty sure there are no CTWK files in MP2.

'''Metroid Prime 2: Echoes''' is the sequel to the critically acclaimed [[Metroid Prime]], and the second game developed by Retro.

== Formats ==

* [[AFSM (File Format)|AFSM]]: AI finite state machine
* [[AGSC (File Format)|AGSC]]: Sound effects
* [[ANCS (File Format)|ANCS]]: Character
* [[ANIM (File Format)|ANIM]]: Animation data
* [[ATBL (File Format)|ATBL]]: Audio table
* [[CINF (File Format)|CINF]]: Skeletons
* [[CMDL (Metroid Prime)|CMDL]]: Models
* [[CRSC (File Format)|CRSC]]: Collision response data
* [[CSKR (File Format)|CSKR]]: Skin bindings
* [[CSNG (File Format)|CSNG]]: MIDI data
* [[DCLN (File Format)|DCLN]]: Collision OBB tree group
* [[DGRP (File Format)|DGRP]]: Dependency groups
* [[DPSC (File Format)|DPSC]]: Decal data
* [[DSP (File Format)|DSP]]: Music
* [[DUMB (File Format)|DUMB]]: Raw data
* [[EGMC (File Format)|EGMC]]: Unknown
* [[ELSC (File Format)|ELSC]]: Particle electric data
* [[EVNT (File Format)|EVNT]]: Animation POI data
* [[FSM2 (File Format)|FSM2]]: Another finite state machine format
* [[FONT (File Format)|FONT]]: Font
* [[FRME (File Format)|FRME]]: GUI frames
* [[HINT (File Format)|HINT]]: Hint system manager
* [[MAPA (File Format)|MAPA]]: Area map
* [[MAPW (File Format)|MAPW]]: World map
* [[MAPU (File Format)|MAPU]]: Universe map
* [[MLVL (File Format)|MLVL]]: World
* [[MREA (File Format)|MREA]]: Area (room geometry, collision, objects, lights, etc)
* [[NTWK (File Format)|NTWK]]: Tweak data
* [[PAK (Metroid Prime)|PAK]]: Packfile
* [[PART (File Format)|PART]]: Particles
* [[PATH (File Format)|PATH]]: Pathfinding data
* [[SAVW (File Format)|SAVW]]: World save info
* [[SCAN (Metroid Prime 2)|SCAN]]: Scannable object info
* [[STLC (File Format)|STLC]]: Audio name lookup
* [[STRG (File Format)|STRG]]: String tables
* [[SWHC (File Format)|SWHC]]: Particle swoosh data
* [[THP (File Format)|THP]]: Videos
* [[TXTR (Metroid Prime)|TXTR]]: Textures
* [[WPSC (File Format)|WPSC]]: Weapon projectile data

[[Category:Metroid Prime 2: Echoes]]

Template:Mainpagelinks

2015-02-14T20:32:39Z

Bearborg:

{|cellpadding="5" cellspacing="3" align="center" style="text-align:center; margin-bottom:20px; float:center; border:1px solid; box-shadow: 0 0 5px #6DBACD; border-radius:6px; border-color:#6dbacd;" ! width="45%"
|[[File:Powercannon_render3.png|200px]]
|'''Help us research and document!'''
'''Join the discussion: [https://m2k2.taigaforum.com/post/metroid_prime_hacking_research.html Metroid Prime Hacking Research thread]'''
{|align="center" style="text-align:center;"
|[[File:Morphball_wire.png|50px|link=Category:Major research needed]]
|[[File:Morphball_wirerender.png|50px|link=Category:Moderate research needed]]
|[[File:Morphball_render.png|50px|link=Category:Minor research needed]]
|-
|<small>[[:Category:Major research needed|'''File formats that need major research''']]</small>
|<small>[[:Category:Moderate research needed|'''File formats that need moderate research''']]</small>
|<small>[[:Category:Minor research needed|'''File formats that need minor research''']]</small>
|}
|}

[[Category:Templates]]

Retro Modding Wiki

2015-02-14T20:31:37Z

Bearborg: I'm guessing {{ZWheader}} is something they have on ZeldaWiki.

<br>
<div style="overflow-x:auto;">
{| cellspacing="3" style="padding:0px; margin:0px; width:100%; background-color: #{{ZWheader}}; white-space:nowrap;"
|colspan=2|
{| width=100% style="padding:0px; background-color: transparent;"
|style="width:40%; text-align:center; white-space:nowrap;"|
<div style="font-size:162%">Welcome to the [[Retro Modding Wiki:About|Retro Modding Wiki]]</div>
<div style="font-size: 95%">an encyclopedia about modding and hacking games from Retro Studios.</div>
<div style="font-size: 75%">With [[Special:Statistics|{{NUMBEROFARTICLES}}]] articles and counting.</div>
|style="width:16%"|
*[[Metroid Prime]]
*[[Metroid Prime 2: Echoes]]
*[[:Category:Metroid Prime 3: Corruption‏‎|Metroid Prime 3: Corruption‏‎]]
|style="width:16%"|
*[[:Category:Donkey Kong Country Returns|Donkey Kong Country Returns]]
*[[Donkey Kong Country: Tropical Freeze‏‎]]
|style="width:16%"|
*[[:Category:File Formats‏‎|File Formats‏‎]]
*'''[[Special:Categories|All categories]]'''
|}
|}
</div>
<br>
{{Mainpagelinks}}
<noinclude>[[Category:Retro Modding Wiki]]</noinclude>

User:Bearborg/vector.css

2015-02-14T20:25:14Z

Bearborg:

#mw-panel {
font-weight: bold !important;
}

#mw-panel li {
border: 1px solid transparent !important;
}

#mw-panel li :link {
margin-left: 3px;
}

#mw-panel li:hover {
background: #30558a;
background: linear-gradient(#30558a, #7baef1);
border: 1px solid white !important;
box-shadow: 1px 1px 2px rgba(0,0,0,0.2);
border-radius: 3px !important;
}

#mw-panel li:hover :link {
color: white !important;
text-decoration: none !important;
}

#mw-panel li:hover :link, #mw-panel li:hover :visited {
color: white !important;
text-decoration: none !important;
}

.vectorTabs li.selected > span > :link {
color: #333333 !important;
}

:link:not(.new) {
color: #2f66ad !important;
}

:link.new, .new *:link {
color: #a63829 !important;
}

:visited {
color: #7b569d !important;
}

.mw-body h1, .mw-body h2, .mw-body #firstHeading {
font-family: sans-serif !important;
}

/*This is the CSS for prepending morph ball images to article names. Needs custom classes, or else it'll just put morph balls in front of everything.
table li a::before {
content: url(http://www.metroid2002.com/retromodding/images/thumb/8/85/Morphball_render.png/20px-Morphball_render.png);
margin-right: 6px;
position: relative;
top: 5px;
}*/

Category:Templates

2015-02-05T16:29:55Z

Bearborg:

This is the root of a category tree, and relevant subcategories should be categorized here. Templates typically do not belong in this category.

[[Category:Retro Modding Wiki]]

Category:Research needed

2015-02-05T16:29:06Z

Bearborg:

[[Category:File Formats by Completion]]

Category:Documented File Formats

2015-02-05T16:28:56Z

Bearborg:

[[Category:File Formats by Completion]]

Category:File Formats by Completion

2015-02-05T16:28:25Z

Bearborg: Created page with "Category:File Formats"

[[Category:File Formats]]

Category:Template/Table Status

2015-02-05T16:25:31Z

Bearborg:

[[Category:Formatting Templates]]

Category:Template/Table Status

2015-02-05T16:24:50Z

Bearborg:

[[Category:Templates]]

Category:Moderate research needed

2015-02-05T16:23:26Z

Bearborg:

[[Category:Research needed]]

Category:Minor research needed

2015-02-05T16:23:17Z

Bearborg:

[[Category:Research needed]]

Category:Major research needed

2015-02-05T16:23:03Z

Bearborg:

[[Category:Research needed]]

Materials

2015-02-05T16:13:06Z

Bearborg: Adding categories.

'''Materials''' are etc etc expand on this later

* [[Materials (Metroid Prime)]]
* [[Materials (Metroid Prime 3)]]
* [[Materials (Tropical Freeze)]]

[[Category:File Formats]]

CMDL (File Format)

2015-02-05T16:07:23Z

Bearborg: Adding categories.

The '''CMDL format''' is the Retro Studios model format. It embeds one or more sets of materials, and a single mesh. The format largely stayed the same through the Prime series, with only changes to the material format being made, before being changed significantly in Donkey Kong Country Returns, and then being overhauled completely in Tropical Freeze.

* [[CMDL (Metroid Prime)]] is used in the Metroid Prime series.
* [[CMDL (Donkey Kong Country Returns)]] is used in DKCR.
* [[CMDL (Tropical Freeze)]] is used in Tropical Freeze. Note that Tropical Freeze actually has three model formats - CMDL, SMDL, and WMDL - which are all very similar to each other and covered in the same article.

[[Category:File Formats]]

SCAN (File Format)

2015-02-05T16:07:05Z

Bearborg: Adding categories.

The '''.SCAN file format''' describes SCAN POI data in the Metroid Prime series, there are two variations of this format:

* [[SCAN (Metroid Prime)]] is used in Metroid Prime.
* [[SCAN (Metroid Prime 2)]] is used in both Metroid Prime 2: Echoes and Metroid Prime 3: Corruption.

[[Category:File Formats]]

PAK (File Format)

2015-02-05T16:06:39Z

Bearborg: Adding categories.

The '''.pak format''' is a packfile format; some variation of it is used in every Retro Studios game to contain the bulk of the game's assets. The only assets in a pak that are directly accessed by the games are the named resources; the rest are dependencies. There are three pak formats:

* [[PAK (Metroid Prime)]] is used in Metroid Prime and Metroid Prime 2.
* [[PAK (Metroid Prime 3)]] is used in Metroid Prime 3 and Donkey Kong Country Returns.
* [[PAK (Tropical Freeze)]] is used in Donkey Kong Country: Tropical Freeze.

[[Category:File Formats]]

SAVW (File Format)

2015-02-05T16:06:04Z

Bearborg: Adding categories.

The '''SAVW format''' determines what data gets saved to the memory card. It's used to save information on non-hardcoded parts of the game, like whether you've collected a certain pickup, whether you've scanned a given object, etc.

{{todo|Document the rest of this format.}}

__TOC__

== Format ==

{| class="wikitable"
! ID
! Category
|-
| 0
| Generic
|-
| 1
| Space Pirate Data
|-
| 2
| Chozo Lore
|-
| 3
| Morphology
|-
| 4
| Research
|}

[[Category:File Formats]]

MREA (Metroid Prime 2)

2015-02-05T16:05:21Z

Bearborg: Adding categories.

''See [[MREA (File Format)]] for the other revisions of this format.''

The '''MREA format''' defines areas (rooms) in Metroid Prime 2. It serves the same purpose as the MREA files from Prime 1, but in Echoes it was updated with new features, including some new data sections and the ability to compress most of the data in the file.

{{todo|Rest of the article needs to be written. There's a lot known about this format that should be documented.}}

__TOC__

== Format ==

Like CMDL, MREA files are split up into a number of 32-byte aligned sections. Every section both starts and ends on a 32-byte boundary. These are used to separate different parts of the file; different types of sections typically indicate different sets of data. The header declares the section count and the size of each one; using these is the only way to navigate the file.

=== Header ===

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Magic'''; always 0xDEADBEEF
|-
| 0x4
| 4
| '''Version'''; see [[MREA (File Format)|hub article]]
|-
| 0x8
| 4 × 12
| '''Transform matrix'''
|-
| 0x38
| 4
| '''Mesh count'''
|-
| 0x3C
| 4
| '''SCLY layer count'''
|-
| 0x40
| 4
| '''Section count''' (SC)
|-
| 0x44
| 4
| '''Geometry section number''' (starts on materials)
|-
| 0x48
| 4
| '''SCLY section number'''
|-
| 0x4C
| 4
| '''SCGN section number'''
|-
| 0x50
| 4
| '''Collision section number'''
|-
| 0x54
| 4
| '''Unknown section number'''
|-
| 0x58
| 4
| '''Lights section number'''
|-
| 0x5C
| 4
| '''Empty section number'''
|-
| 0x60
| 4
| '''PATH section number'''
|-
| 0x64
| 4
| '''FFFFFFFF section number'''
|-
| 0x68
| 4
| '''Unknown section 2 number'''
|-
| 0x6C
| 4
| '''EGMC section number'''
|-
| 0x70
| 4
| '''Compressed cluster count'''
|-
| 0x74
| 0xC
| '''Padding'''
|-
| 0x80
| 4 × SC
| '''Section sizes'''
|-
| colspan=3 {{unknown|Pad to 32 bytes before compressed cluster definitions begins}}
|}

Following the section sizes comes an array defining the file's compressed cluster. Each definition is 0x10 bytes and is formatted like this:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Buffer size''' (usually 0x120 bytes bigger than uncompressed size)
|-
| 0x4
| 4
| '''Uncompressed size'''
|-
| 0x8
| 4
| '''Compressed size''' (if 0, that indicates an uncompressed cluster)
|-
| 0xC
| 4
| '''Section count''' (the number of regular sections contained in this cluster)
|-
| 0x10
| colspan=2 {{unknown|Cluster definition end}}
|}

[[Category:File Formats]]
[[Category:Metroid Prime 2: Echoes]]

MAPW (File Format)

2015-02-04T15:22:05Z

Bearborg:

The '''MAPW format''' defines the map for a world.

== Format ==

MAPW is an extremely simple format; it's essentially just an array of MAPA IDs. There's always one MAPA per area. The MAPW format has never been updated; every Prime game uses the same version of the format, version 1. The only difference is that Prime 1/2 has 32-bit file IDs, while Prime 3 has 64-bit ones.

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| '''Magic'''; always 0xDEADF00D
|-
| 0x4
| u32
| 4
| '''Version'''; always 1
|-
| 0x8
| u32
| 4
| '''MAPA count''' (AC)
|-
| 0xC
| [[MAPA (File Format)|MAPA]]
| 4 × AC
| '''MAPA array'''
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

Template:Research

2015-01-30T05:14:50Z

Bearborg: Fixing category names.

{{Box
|gradient1=cce8ff
|gradient2=64b8ff
|image={{#switch:{{{1|}}}|1|minor|Minor=File:Morphball render.png|2|moderate|Moderate=File:Morphball_wirerender.png|3|major|Major=File:Morphball_wire.png}}
|text={{#switch:{{{1|}}}|1|minor|Minor='''This file format is almost completely documented'''|2|moderate|Moderate='''This file format needs more research'''|3|major|Major='''This file format needs a lot of research'''}} <br /> {{{2|}}}
}}
<includeonly>{{#switch:{{{1|}}}|1|minor|Minor=[[Category:Minor research needed]]|2|moderate|Moderate=[[Category:Moderate research needed]]|3|major|Major=[[Category:Major research needed]]}}</includeonly>
<noinclude>

==Usage==
This template can be used to indicate the degree of research required on a file type or article and categorize it accordingly. Use the following code.

<nowiki>{{Research |</nowiki> ''Degree'' <nowiki>|</nowiki> ''Supplementary text'' <nowiki>}}</nowiki>

''Degree'': Three available options, designated by Minor, Moderate, or Major (or 1, 2, or 3).<br />
''Supplementary text'': Optional additional text to specify required research.

[[Category:Notice Templates]]
</noinclude>

User:Bearborg/vector.css

2015-01-28T01:54:42Z

Bearborg: I'm dumb.

#mw-panel {
font-weight: bold !important;
}

#mw-panel li {
border: 1px solid transparent !important;
}

#mw-panel li :link {
margin-left: 3px;
}

#mw-panel li:hover {
background: #30558a;
background: linear-gradient(#30558a, #7baef1);
border: 1px solid white !important;
box-shadow: 1px 1px 2px rgba(0,0,0,0.2);
border-radius: 3px !important;
}

#mw-panel li:hover :link {
color: white !important;
text-decoration: none !important;
}

#mw-panel li:hover :link, #mw-panel li:hover :visited {
color: white !important;
text-decoration: none !important;
}

.vectorTabs li.selected > span > :link {
color: #333333 !important;
}

:link:not(.new) {
color: #2f66ad !important;
}

:link.new {
color: #a63829 !important;
}

:visited {
color: #7b569d !important;
}

.mw-body h1, .mw-body h2, .mw-body #firstHeading {
font-family: sans-serif !important;
}

/*This is the CSS for prepending morph ball images to article names. Needs custom classes, or else it'll just put morph balls in front of everything.
table li a::before {
content: url(http://www.metroid2002.com/retromodding/images/thumb/8/85/Morphball_render.png/20px-Morphball_render.png);
margin-right: 6px;
position: relative;
top: 5px;
}*/

User:Bearborg/vector.css

2015-01-28T01:46:42Z

Bearborg:

#mw-panel {
font-weight: bold !important;
}

#mw-panel li {
border: 1px solid transparent !important;
}

#mw-panel li :link {
margin-left: 3px;
}

#mw-panel li:hover {
background: #30558a;
background: linear-gradient(#30558a, #7baef1);
border: 1px solid white !important;
box-shadow: 1px 1px 2px rgba(0,0,0,0.2);
border-radius: 3px !important;
}

#mw-panel li:hover :link {
color: white !important;
text-decoration: none !important;
}

#mw-panel li:hover :link, #mw-panel li:hover :visited {
color: white !important;
text-decoration: none !important;
}

.vectorTabs li.selected > span > :link {
color: #333333 !important;
}

:link:not(.new) {
color: #2f66ad !important;
}

:link.new {
color: #a63829 !important;
}

:visited {
color: #7b569d
}

.mw-body h1, .mw-body h2, .mw-body #firstHeading {
font-family: sans-serif !important;
}

/*This is the CSS for prepending morph ball images to article names. Needs custom classes, or else it'll just put morph balls in front of everything.
table li a::before {
content: url(http://www.metroid2002.com/retromodding/images/thumb/8/85/Morphball_render.png/20px-Morphball_render.png);
margin-right: 6px;
position: relative;
top: 5px;
}*/

User talk:Bearborg

2015-01-27T19:28:13Z

Bearborg: /* Breaking Tables with Style Transclusions */

==Breaking Tables with Style Transclusions==
Hey Bearborg, I was wondering if you could take a look at [[:Template:RMWBorder]]. It's just a string of numbers (a hex color code), but whenever I try to use it in a style tag my tables explode ([[User:Embyr_75/Sandbox|example]]). It's an extremely simple template so I don't get what would cause it to do that. Same thing happens with [[:Template:Border]]. Could it be a MediaWiki issue? I need a fresh set of eyes (or just a better brain); care to take a look? [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 22:41, 26 January 2015 (CST)

:Well, I did take a look, but I don't think I can really help much- I'm not too proficient with wiki markup, and it all looks to me like it should work. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 13:28, 27 January 2015 (CST)

User:Aruki/Sandbox

2015-01-27T19:24:22Z

Bearborg: /* Common */

Dumping script object structures here for now. Miles is the one who figured out most of this stuff.

Note: Whenever a struct is used, it's preceded by a value indicating the number of properties contained in that struct. Therefore, you need to add 4 to the size of its members to get an accurate size.

== Types ==

{| class="wikitable"
|+ vec3
! Offset
! Type
! Size
! Description
|-
| 0x0
| float
| 4
| '''X'''
|-
| 0x4
| float
| 4
| '''Y'''
|-
| 0x8
| float
| 4
| '''Z'''
|-
| 0xC
| colspan=3 {{unknown|End}}
|}

{| class="wikitable"
|+ vec4
! Offset
! Type
! Size
! Description
|-
| 0x0
| float
| 4
| '''X'''
|-
| 0x4
| float
| 4
| '''Y'''
|-
| 0x8
| float
| 4
| '''Z'''
|-
| 0xC
| float
| 4
| '''W'''
|-
| 0x10
| colspan=3 {{unknown|End}}
|}

{| class="wikitable"
|+ ANCS
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| '''ANCS file ID'''
|-
| 0x4
| u32
| 4
| '''Selected node index'''
|-
| 0x8
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xC
| colspan=3 {{unknown|End}}
|}

== Script Objects ==

Like how structs are preceded by a property count, entire objects' property sets are each considered to be their own struct, and so are also preceded by a property count. Also, every object except Area Attributes (0x4E) begins with a string instance name. Excluding because variable-length data is yucky for the offset column.

=== Actor (0x0) ===

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| vec3
| 0xC
| '''Position'''
|-
| 0xC
| vec3
| 0xC
| '''Rotation'''
|-
| 0x18
| vec3
| 0xC
| '''Scale'''
|-
| 0x24
| vec3
| 0xC
| {{unknown|'''Unknown'''}}
|-
| 0x30
| vec3
| 0xC
| '''Scan Offset'''
|-
| 0x3C
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x40
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x44
| struct
| 0xC
| [[#Health|Health]]
|-
| 0x50
| struct
| 0x74
| [[#Vulnerabilities|Vulnerabilities]]
|-
| 0xC4
| [[CMDL (Metroid Prime)|CMDL]]
| 4
| '''Model'''
|-
| 0xC8
| [[ANCS (File Format)|ANCS]]
| 0xC
| '''Char Set'''
|-
| 0xD4
| struct
| 0x7D
| [[#Common|'''Common''']]
|-
| 0x151
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x152
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x153
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x154
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x155
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x156
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x15A
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x15B
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x15C
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x15D
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x15E
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x15F
| colspan=3 {{unknown|End}}
|}

== Structs ==

=== Patterned ===

0x12D bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| float
| 4
| '''Mass'''
|-
| 0x4
| float
| 4
| '''Speed'''
|-
| 0x8
| float
| 4
| '''Turn Speed'''
|-
| 0xC
| float
| 4
| '''Detection Range'''
|-
| 0x10
| float
| 4
| '''Detection Height Range'''
|-
| 0x14
| float
| 4
| '''Detection Angle'''
|-
| 0x18
| float
| 4
| '''Min Attack Range'''
|-
| 0x1C
| float
| 4
| '''Max Attack Range'''
|-
| 0x20
| float
| 4
| '''Average Attack Time'''
|-
| 0x24
| float
| 4
| '''Attack Time Variation'''
|-
| 0x28
| float
| 4
| '''Leash Radius'''
|-
| 0x2C
| float
| 4
| '''Player Leash Radius'''
|-
| 0x30
| float
| 4
| '''Player Leash Time'''
|-
| 0x34
| struct
| 0x14
| [[#Contact Damage|'''Contact Damage''']]
|-
| 0x48
| float
| 4
| '''Damage Wait Time'''
|-
| 0x4C
| struct
| 0xC
| [[#Health|'''Health''']]
|-
| 0x50
| struct
| 0x74
| [[#Vulnerabilities|'''Vulnerabilities''']]
|-
| 0xC4
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xC8
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xCC
| vec3
| 0xC
| {{unknown|'''Unknown'''}}
|-
| 0xD8
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xDC
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xE0
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xE4
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xE8
| u32
| 4
| {{unknown|'''Sound?'''}}
|-
| 0xEC
| [[ANCS (File Format)|ANCS]]
| 0xC
| '''Char Set'''
|-
| 0xF0
| bool
| 1
| '''Active'''
|-
| 0xF1
| [[AFSM (File Format)|AFSM]]
| 4
| '''FSM'''
|-
| 0xF5
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xF9
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xFD
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x101
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x105
| vec3
| 0xC
| {{unknown|'''Unknown'''}}
|-
| 0x111
| [[PART (File Format)|PART]]
| 4
| '''Particle'''
|-
| 0x115
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x119
| vec3
| 0xC
| {{unknown|'''Unknown'''}}
|-
| 0x125
| [[PART (File Format)|PART]]
| 4
| '''Particle'''
|-
| 0x129
| u32
| 4
| '''Sound?'''
|-
| 0x12D
| colspan=3 {{unknown|End}}
|}

=== Contact Damage ===

0x10 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| '''Weapon Type'''
|-
| 0x4
| float
| 4
| '''Damage'''
|-
| 0x8
| float
| 4
| '''Radius'''
|-
| 0xC
| float
| 4
| '''Knockback Power'''
|-
| 0x10
| colspan=3 {{unknown|End}}
|}

=== Health ===

0x8 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| float
| 4
| '''Health'''
|-
| 0x4
| float
| 4
| '''Knockback Resistance'''
|-
| 0x8
| colspan=3 {{unknown|End}}
|}

=== Vulnerabilities ===

0x70 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| '''Power Beam'''
|-
| 0x4
| u32
| 4
| '''Ice Beam'''
|-
| 0x8
| u32
| 4
| '''Wave Beam'''
|-
| 0xC
| u32
| 4
| '''Plasma Beam'''
|-
| 0x10
| u32
| 4
| '''Morph Ball Bomb'''
|-
| 0x14
| u32
| 4
| '''Power Bomb'''
|-
| 0x18
| u32
| 4
| '''Missile'''
|-
| 0x1C
| u32
| 4
| '''Boost Ball'''
|-
| 0x20
| u32
| 4
| '''Phazon Beam'''
|-
| 0x24
| u32
| 4
| '''Enemy Weapon 1'''
|-
| 0x28
| u32
| 4
| '''Enemy Weapon 2 (Poison)'''
|-
| 0x2C
| u32
| 4
| '''Enemy Weapon 3 (Lava)'''
|-
| 0x30
| u32
| 4
| '''Enemy Weapon 4'''
|-
| 0x34
| u32
| 4
| {{unknown|'''Unknown Weapon 1'''}}
|-
| 0x38
| u32
| 4
| {{unknown|'''Unknown Weapon 2'''}}
|-
| 0x3C
| u32
| 4
| {{unknown|'''Unknown Weapon 3'''}}
|-
| 0x40
| struct
| 0x18
| [[#Charged Beams|'''Charged Beams''']]
|-
| 0x58
| struct
| 0x18
| [[#Beam Combos|'''Beam Combos''']]
|-
| 0x70
| colspan=3 {{unknown|End}}
|}

==== Charged Beams ====

0x14 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| '''Charged Power Beam'''
|-
| 0x4
| u32
| 4
| '''Charged Ice Beam'''
|-
| 0x8
| u32
| 4
| '''Charged Wave Beam'''
|-
| 0xC
| u32
| 4
| '''Charged Plasma Beam'''
|-
| 0x10
| u32
| 4
| '''Charged Phazon Beam'''
|-
| 0x14
| colspan=3 {{unknown|End}}
|}

==== Beam Combos ====

0x14 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| '''Super Missile'''
|-
| 0x4
| u32
| 4
| '''Ice Spreader'''
|-
| 0x8
| u32
| 4
| '''Wavebuster'''
|-
| 0xC
| u32
| 4
| '''Flamethrower'''
|-
| 0x10
| u32
| 4
| '''Phazon Combo'''
|-
| 0x14
| colspan=3 {{unknown|End}}
|}

=== Common ===

0x79 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| struct
| 0x47
| [[#Inside Common|Inside Common]]
|-
| 0x47
| struct
| 8
| [[#Scan|Scan]]
|-
| 0x4F
| [[CMDL (Metroid Prime)|CMDL]]
| 4
| '''X-Ray Model'''
|-
| 0x53
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x57
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x5B
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x5F
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x60
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x64
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x68
| struct
| 0xA
| [[#Maybe Thermal-Related|Maybe Thermal-Related]]
|-
| 0x72
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x73
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x74
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x75
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x79
| colspan=3 {{unknown|End}}
|}

==== Inside Common ====

0x43 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x1
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x5
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x9
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xD
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x11
| vec4
| 0x10
| {{unknown|'''Unknown'''}}
|-
| 0x21
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x22
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x26
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x2A
| vec3
| 0xC
| {{unknown|'''Unknown'''}}
|-
| 0x36
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x3A
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x3E
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x3F
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x43
| colspan=3 {{unknown|End}}
|}

=== Scan ===

0x4 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| [[SCAN (Metroid Prime)|SCAN]]
| 4
| '''SCAN file'''
|-
| 0x4
| colspan=3 {{unknown|End}}
|}

=== Maybe Thermal-Related ===

0x6 bytes

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x1
| bool
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x2
| u32
| 4
| {{unknown|'''Unknown''' (possibly bit flags)}}
|-
| 0x6
| colspan=3 {{unknown|End}}
|}

Template talk:Todo

2015-01-27T02:50:30Z

Bearborg:

I can whip up some Varia suit colors for this template and icon later today. --[[User:MrSinistar|MrSinistar]] ([[User talk:MrSinistar|talk]]) 09:33, 26 January 2015 (CST)

:Well, there's a Varia icon already uploaded. The only real work to be done is finding two good shades of orange. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 09:38, 26 January 2015 (CST)

::Sounds good to me. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 09:42, 26 January 2015 (CST)

:::How's this? [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 20:50, 26 January 2015 (CST)
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#eb752f, #ffd78a); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:VariaSuitIcon.png|50px|link=]]
|'''To do:''' <br/> Finalize this template.
|}

Template talk:Todo

2015-01-26T15:39:01Z

Bearborg:

User:Bearborg/vector.css

2015-01-26T10:41:20Z

Bearborg:

#mw-panel {
font-weight: bold !important;
}

#mw-panel li {
border: 1px solid transparent !important;
}

#mw-panel li :link {
margin-left: 3px;
}

#mw-panel li:hover {
background: #30558a;
background: linear-gradient(#30558a, #7baef1);
border: 1px solid white !important;
box-shadow: 1px 1px 2px rgba(0,0,0,0.2);
border-radius: 3px !important;
}

#mw-panel li:hover :link {
color: white !important;
text-decoration: none !important;
}

.vectorTabs li.new > span > :link {
color: #a63829 !important;
}

.vectorTabs li.selected > span > :link {
color: #333333 !important;
}

:link:not(.new) {
color: #2f66ad !important;
}

:link.new {
color: #a63829 !important;
}

.mw-body h1, .mw-body h2, .mw-body #firstHeading {
font-family: sans-serif !important;
}

/*This is the CSS for prepending morph ball images to article names. Needs custom classes, or else it'll just put morph balls in front of everything.
table li a::before {
content: url(http://www.metroid2002.com/retromodding/images/thumb/8/85/Morphball_render.png/20px-Morphball_render.png);
margin-right: 6px;
position: relative;
top: 5px;
}*/

Retro Modding Wiki:About

2015-01-26T06:28:40Z

Bearborg: This sentence seemed a little weird.

[[File:RetroModding.png|right|300px]]'''Retro Modding Wiki''' is the definitive resource containing all of the information gathered on formats used throughout Retro Studios' games. These games are, of course, the critically-acclaimed Metroid Prime Trilogy and the Donkey Kong Country Returns games. Our goal is to have a complete understanding of every file format and function in Retro Studio's games so that we can build level editors, import brand new assets, and create mods.

If you want to contribute and help us research these game files, [[Special:UserLogin|create an account]] and be a part of the largest community devoted to modding Metroid Prime and Donkey Kong Country Returns. [https://m2k2.taigaforum.com/post/metroid_prime_hacking_research.html Be sure to also check out our forum posts as well!]

==History==

RMW started out as a [https://m2k2.taigaforum.com/post/metroid_prime_hacking_research.html forum post about hacking and modding Metroid Prime] created by [[User:Parax0|Paraxade]]. Over the course of the thread, more progress has been made than ever before on hacking and modifying the Metroid Prime series; many file formats were able to be read and edited for the very first time since Metroid Prime's release in 2002.

Several months after the forum post, so much progress had been made, it had become rather difficult to find information and collaborate on hacking files, so it was decided that a repository or a central hub of information would be needed to track down all the file formats and progress made. Since Retro Studios, the team behind the Metroid Prime Trilogy and Donkey Kong Country Returns series, utilizes the same game engine for all of their games, we chose Retro Modding Wiki to name our resource as all this information encompasses all of their games.

On January 22rd, [[User:Nate|Nate]], owner of Metroid2002.com, was gracious enough to host this wiki on his website. Several contributors from the original forum including [[User:Antidote|Antidote]], [[User:Bearborg|Bearborg]], [[User:MrSinistar|MrSinistar]], [[User:Embyr 75|Embyr 75]] and several others soon joined to further support this challenging hacking endeavor.

Retro Modding Wiki:About

2015-01-26T06:22:55Z

Bearborg:

[[File:RetroModding.png|right|300px]]'''Retro Modding Wiki''' is the definitive resource containing all of the information gathered on formats used throughout Retro Studios' games. These games are, of course, the critically-acclaimed Metroid Prime Trilogy and the Donkey Kong Country Returns games. Our goal is to have a complete understanding of every file format and function in Retro Studio's games so that we can build level editors, import brand new assets, and create mods.

If you want to contribute and help us research these game files, [[Special:UserLogin|create an account]] and be a part of the largest community devoted to modding Metroid Prime and Donkey Kong Country Returns. [https://m2k2.taigaforum.com/post/metroid_prime_hacking_research.html Be sure to also check out our forum posts as well!]

==History==

RMW started out as a [https://m2k2.taigaforum.com/post/metroid_prime_hacking_research.html forum post about hacking and modding Metroid Prime] created by [[User:Parax0|Paraxade]]. For the very first time since Metroid Prime's release in 2002, more progress has been made than ever before on hacking and modifying the Metroid Prime series.

Several months after the forum post, so much progress had been made, it had become rather difficult to find information and collaborate on hacking files, so it was decided that a repository or a central hub of information would be needed to track down all the file formats and progress made. Since Retro Studios, the team behind the Metroid Prime Trilogy and Donkey Kong Country Returns series, utilizes the same game engine for all of their games, we chose Retro Modding Wiki to name our resource as all this information encompasses all of their games.

On January 22rd, [[User:Nate|Nate]], owner of Metroid2002.com, was gracious enough to host this wiki on his website. Several contributors from the original forum including [[User:Antidote|Antidote]], [[User:Bearborg|Bearborg]], [[User:MrSinistar|MrSinistar]], [[User:Embyr 75|Embyr 75]] and several others soon joined to further support this challenging hacking endeavor.

TXTR (Metroid Prime)

2015-01-26T04:52:28Z

Bearborg: /* External links */

''Note: The Tropical Freeze TXTR format is completely different, but doesn't have a page yet.''

'''TXTR''' is, as the name suggests, the Retro Studios texture format. The format remains completely unchanged from Metroid Prime all the way up to Donkey Kong Country Returns.

{{todo|Could possibly use some more information on how the formats work and how to decode them, but then again the Custom Mario Kart Wiiki has this covered pretty nicely already.}}

__TOC__

== Format ==

TXTR files contain a very short 12-byte header, followed by the image data.

=== Header ===

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Image format'''. Possible values range from 0x0 to 0xA; see below for more details.
|-
| 0x4
| 2
| '''Width'''
|-
| 0x6
| 2
| '''Height'''
|-
| 0x8
| 4
| '''Mipmap count'''
|-
| 0xC
| colspan=2 {{unknown|End of header}}
|}

=== Palettes ===

The C4 and C8 image formats contain a palette table after the header, before the image data begins.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Palette format'''. Possible values range from 0 to 2.
|-
| 0x4
| 2
| {{unknown|'''Unknown'''; always 0x1 in C4, 0x100 in C8}}
|-
| 0x6
| 2
| {{unknown|'''Unknown'''; always 0x10 in C4, 0x1 in C8}}
|-
| 0x8
| Varies
| '''Palette colors'''. 16-bit color values; 16 colors in C4, 256 in C8.
|-
| colspan=3 {{unknown|End of palette table; image data begins immediately after}}
|}

== Image Formats ==

There are 11 different image formats; these are built directly into GX, so they remain the same across all GameCube and Wii games. Rather than storing pixels in a linear left-to-right order, GX textures encode pixels in large blocks. The size of the block varies depending on the image format.

For example, suppose you have a format that stores 4x4 blocks. Pixels 1-4 of the image will make up the first row of the first block; pixels 5-8 will make up the second row; 9-12 will make up the third row; 13-16 will make up the fourth row, completing the block; and the 17-20 will begin the first row of the second block, appearing directly to the right of the first row of the first block.

{| class="wikitable"
! ID
! Name
! Bits per pixel
! Block size
! Description
|-
| 0x0
| I4
| 4
| 8x8
| 4-bit greyscale intensity values. Two pixels per byte.
|-
| 0x1
| I8
| 8
| 8x4
| 8-bit greyscale intensity values.
|-
| 0x2
| IA4
| 8
| 8x4
| 4-bit greyscale intensity values with an additional 4-bit alpha channel.
|-
| 0x3
| IA8
| 16
| 4x4
| 8-bit greyscale intensity values with an additional 8-bit alpha channel.
|-
| 0x4
| C4
| 4
| 8x8
| 4-bit palette indices.
|-
| 0x5
| C8
| 8
| 8x4
| 8-bit palette indices.
|-
| 0x6
| C14x2
| 16
| 4x4
| Another palette format. Not used by any official textures.
|-
| 0x7
| RGB565
| 16
| 4x4
| 16-bit colors without alpha.
|-
| 0x8
| RGB5A3
| 16
| 4x4
| 16-bit colors with alpha.
|-
| 0x9
| RGBA8
| 32
| 4x4
| Uncompressed 32-bit colors with alpha.
|-
| 0xA
| CMPR
| 4
| 8x8
| DXT1-compressed textures.
|}

== External links ==

* [http://wiki.tockdom.com/wiki/Image_Formats Custom Mario Kart Wiki]: More detailed information on each format, and how to decode them.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]

Materials (Metroid Prime)

2015-01-26T01:20:19Z

Bearborg: /* Alpha Input Flags */

The format for '''materials''' is seen in both the [[CMDL (Metroid Prime)|CMDL]] and [[MREA (File Format)|MREA]] formats, and is identical in both. This particular material format appears in both Metroid Prime and Metroid Prime 2, with minor differences.

{{researchmoderate|reason=There are a few unknown values, and some unknown settings in known values; there are also a few unknown material animation modes. Also, basically everything that was introduced in Echoes is unknown.}}

__TOC__

== GX Explanation ==

The materials system in Metroid Prime is heavily dependent on the GameCube and Wii's graphics system, GX. GX is a fixed-function graphics pipeline, similar to old versions of OpenGL. In GX, rendering is done through a series of steps called '''T'''exture '''E'''n'''V'''ironment Stages, or or TEV stages for short.

Prior to TEV stages, per-vertex calculations are performed, including lighting calculation and texture coord generation (texgen), and passed to GX. Then some parameters are passed that specify TEV order; namely, a set of values that describe which texture, UV coordinate, and rasterized color is available to each respective TEV stage.

How TEV stages actually work: Each TEV stage takes in four color (RGB) inputs, and four alpha inputs, from one of eight sources. Then these four input colors are combined into one output color, and the output is saved into one of four registers, which can subsequently be used as input in the next TEV stages. The final stage must always save its output into the "previous TEV stage" register; that register is used as the final pixel color that gets displayed onscreen.

== Material Set Format ==

Materials come as part of a set; often there will only be one set per file, but many CMDLs can have more than one. The set begins with a short header before the actual material data begins.

{| class="wikitable"
!Type
!Count
!Description
|-
| long
| 1
| '''Texture count''' (TC)
|-
| long
| TC
| '''Texture file IDs'''
|-
| long
| 1
| '''Material count''' (MC)
|-
| long
| MC
| '''Material end offsets''' (relative to the start of the first material)
|-
| colspan=3 | Materials begin
|}

== Material Format ==

=== General Settings ===

Each material begins with a flags value, followed by a list of texture indices:

{| class="wikitable"
!Type
!Count
!Description
|-
| long
| 1
| '''Flags'''
|-
| long
| 1
| '''Texture count''' (TC)
|-
| long
| TC
| '''Texture indices''' (these are indices into the material set texture array)
|-
| long
| 1
| '''Vertex attribute flags'''
|-
| long
| 1
| Unknown ''(note: only in Echoes)''
|-
| long
| 1
| Unknown ''(note: only in Echoes)''
|-
| long
| 1
| Unknown
|-
| long
| 1
| '''Konst count''' (KC); max setting is 4. ''(note: only present if flag 0x8 is set!)''
|-
| long
| KC
| '''Konst colors''' - 32-bit RGBA colors ''(note: not present if the Konst count isn't)''
|-
| short
| 1
| '''Blend destination factor'''
|-
| short
| 1
| '''Blend source factor'''
|-
| long
| 1
| Unknown ''(note: only present if flag 0x400 is set!)''
|-
| long
| 1
| '''Color channel flag count''' (CC)
|-
| long
| CC
| '''Color channel flags'''
|-
| long
| 1
| '''TEV stage count'''
|}

==== Flags ====

These are the known flag settings:

{| class="wikitable"
! Bit
! Hex
! Description
|-
| 0
| 0x1
| Appears unused, but always set
|-
| 1
| 0x2
| Appears unused, but always set
|-
| 2
| 0x4
| Appears unused, but always unset
|-
| 3
| 0x8
| Enable Konstant values
|-
| 4
| 0x10
| Mark transparent material
|-
| 5
| 0x20
| Enable punchthrough alpha
|-
| 6
| 0x40
| Enable Samus's reflection
|-
| 7
| 0x80
| Enable depth writing
|-
| 8
| 0x100
| Unknown
|-
| 9
| 0x200
| Don't draw
|-
| 10
| 0x400
| Enable second unknown value
|-
| 11
| 0x800
| Unknown
|-
| 12
| 0x1000
| Unknown
|-
| 13
| 0x2000
| Enable lightmaps; first UV coordinate uses short array instead of float array
|-
| 14
| 0x4000
| Appears to do the same thing as bit 14
|-
| 15
| 0x8000
| Unknown
|-
| 16
| 0x10000
| Unknown
|-
| 17
| 0x20000
| Unknown
|-
| 18
| 0x40000
| Unknown
|-
| 19
| 0x80000
| Unknown
|-
| 20+
| 0x100000+
| Unused; never set
|}

==== Vertex Attribute Flags ====

These flags are generally toggled in pairs, with each pair corresponding to a vertex attribute; if a pair is set, then vertices using this material will have the corresponding attribute. This is vital for reading geometry.

An important note is that while the leftmost byte is not used in Prime 1, in Echoes there's occasionally a value there that toggles an extra vertex attribute preceding position. This needs research to determine what the new attribute actually is. Also, GX supports up to 8 texture coords per vertex, but the game doesn't seem to allow you to assign more than 7 (though this could do with some double-checking).

These are the possible attributes:

{| class="wikitable"
! Bit pair
! Attribute
|-
| 0x3
| Position
|-
| 0xC
| Normal
|-
| 0x30
| Color 0
|-
| 0xC0
| Color 1
|-
| 0x300
| Tex 0
|-
| 0xC00
| Tex 1
|-
| 0x3000
| Tex 2
|-
| 0xC0000
| Tex 3
|-
| 0x300000
| Tex 4
|-
| 0xC00000
| Tex 5
|-
| 0x3000000
| Tex 6
|}

==== Konst Colors ====

These values are only present when flag 0x8 is enabled. These allow you to set Konstant values, which can subsequently be used as inputs in TEV stages. The maximum number of Konst values you can set on one material is 4. The colors themselves are simply 32-bit RGBA values.

==== Blend Mode ====

The two blend factors set the blending mode used. The most common values you'll see are 0/1, which is used on opaque materials; transparent materials will usually have either 1/1, for additive blending, or 5/4, for alpha blending. Here's the full range of possible settings for each value:

{| class="wikitable"
! Value
! Blend factor
|-
| 0
| GX_BL_ZERO
|-
| 1
| GX_BL_ONE
|-
| 2
| GX_BL_SRCCLR / GX_BL_DSTCLR
|-
| 3
| GX_BL_INVSRCCLR / GX_BL_INVSRCCLR
|-
| 4
| GX_BL_SRCALPHA
|-
| 5
| GX_BL_INVSRCALPHA
|-
| 6
| GX_BL_DSTALPHA
|-
| 7
| GX_BL_INVDSTALPHA
|}

==== Color Channels ====

There's an odd quirk with how these values work; although there's a count value listed, the game will only actually read the first value listed, and then skip the rest. There's no reason to ever have more than one flag value. Aside from that, how this works is unknown and needs research.

=== TEV Stages ===

There'll be one of these structures per TEV stage:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Color Input Flags'''
|-
| 0x4
| 4
| '''Alpha Input Flags'''
|-
| 0x8
| 4
| '''Color Combine Flags'''
|-
| 0xC
| 4
| '''Alpha Combine Flags'''
|-
| 0x10
| 1
| '''Padding'''
|-
| 0x11
| 1
| '''Konst Alpha Input'''
|-
| 0x12
| 1
| '''Konst Color Input'''
|-
| 0x13
| 1
| '''Rasterized Color Input'''
|-
| 0x14
| colspan=2 | End of TEV stage
|}

After looping through each TEV stage, there will be one of these structures per stage:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| '''Padding'''
|-
| 0x2
| 1
| '''Texture TEV Input'''
|-
| 0x3
| 1
| '''Tex Coord TEV Input'''
|-
| 0x4
| colspan=2 | End of structure
|}

==== Color Input Flags ====

These flags set the four color inputs that are used by the TEV stage. Each color is allocated 5 bits, even though only 4 are actually used; the lower bits correspond to the lower input numbers (eg. the bottom 5 bits refer to the first input).

There are 16 possible color sources:

{| class="wikitable"
! Binary
! Hex
! Color Source
|-
| 00000
| 0x0
| Previous stage RGB
|-
| 00001
| 0x1
| Previous stage AAA
|-
| 00010
| 0x2
| Color 0 RGB
|-
| 00011
| 0x3
| Color 0 AAA
|-
| 00100
| 0x4
| Color 1 RGB
|-
| 00101
| 0x5
| Color 1 AAA
|-
| 00110
| 0x6
| Color 2 RGB
|-
| 00111
| 0x7
| Color 2 AAA
|-
| 01000
| 0x8
| Texture RGB
|-
| 01001
| 0x9
| Texture AAA
|-
| 01010
| 0xA
| Rasterized RGB
|-
| 01011
| 0xB
| Rasterized AAA
|-
| 01100
| 0xC
| One
|-
| 01101
| 0xD
| Half
|-
| 01110
| 0xE
| Konstant RGB
|-
| 01111
| 0xF
| Zero
|}

==== Alpha Input Flags ====

Similar to the color input flags, these set the four alpha inputs used by the TEV stage. Each value is allocated 5 bits, although only 3 are used. The main difference with alpha is there's only 8 possible sources instead of 16:

{| class="wikitable"
! Binary
! Hex
! Alpha Source
|-
| 00000
| 0x0
| Previous stage alpha
|-
| 00001
| 0x1
| Color 0 alpha
|-
| 00010
| 0x2
| Color 1 alpha
|-
| 00011
| 0x3
| Color 2 alpha
|-
| 00100
| 0x4
| Texture alpha
|-
| 00101
| 0x5
| Rasterized alpha
|-
| 00110
| 0x6
| Konstant alpha
|-
| 00111
| 0x7
| Zero
|}

==== Color Combine Flags ====

These flags specify how the operation that combines the four input colors into one output color is performed.

This is the combiner function:

<pre>tevrigid = (d (tevop) ((1.0-c)*a + c*b) + tevbias) * tevscale;</pre>

The values set in the color operation flags correspond to the parameters passed to [http://libogc.devkitpro.org/gx_8h.html#a067b875ff1e3e6760d0d7d7838c6c4c2 GX_SetTevColorOp()]. These are the settings:

{| class="wikitable"
! Bits
! Hex
! Description
|-
| 0-3
| 0xF
| tevop; [http://libogc.devkitpro.org/group__tevop.html there are ten accepted values.]
|-
| 4-5
| 0x30
| tevbias. 00 does nothing; 01 adds 0.5; 10 subtracts 0.5; 11 does nothing.
|-
| 6-7
| 0xC0
| tevscale. 00 does nothing; 01 multiples by 2; 10 multiplies by 4; 11 divides by 2.
|-
| 8
| 0x100
| clamp; enabling this will clamp the output color between 0 and 1.
|-
| 9-10
| 0x600
| tevrigid; this sets the register that the output color is saved into. 00 is the previous stage register; 01 is Color 0; 10 is Color 1; 11 is Color 2.
|-
| 11+
| 0xFFFFF800
| Unused.
|}

Note that the vast majority of materials in the game, if not all of them, don't really bother with any of this; they enable clamping, set an output register, and leave everything else at their defaults of 0.

==== Alpha Combine Flags ====

This is exactly the same as the color combine flags; the only difference is it operates on alpha instead of color.

=== Texgen ===

After the TEV stages comes a sequence of flags determining how texgen is executed. Texgen is the process of taking input values and using them to generate texture coordinates (or UV coordinates), which can then be used by the TEV stages. It's important to note that any vertex attribute can be used as a texgen input; in fact, it's rather common for materials to use the vertex normal as an input to simulate reflections. That means ''the number of texture coords present on each vertex is not the same as the number of texture coords available to TEV''.

{| class="wikitable"
! Type
! Count
! Description
|-
| long
| 1
| '''Texgen count''' (TC)
|-
| long
| TC
| '''Texgen flags'''
|}

The flags largely correspond to arguments passed to [http://libogc.devkitpro.org/gx_8h.html#a55a426a3ff796db584302bddd829f002 GX_SetTexCoordGen2()]. These are the settings:

{| class="wikitable"
! Bits
! Hex
! Description
|-
| 0-3
| 0xF
| Unknown
|-
| 4-8
| 0x1F0
| Attribute input. [http://libogc.devkitpro.org/group__texgensrc.html These are the accepted inputs.]
|-
| 9-13
| 0x3E00
| Unknown; appear to be unused?
|-
| 14
| 0x4000
| Toggle whether the coordinate is normalized after being multiplied by the texture matrix.
|-
| 15-20
| 0x1F8000
| This sets the index into the post-transform matrix used for the final calculations.
|-
| 21+
| 0xFFE00000
| Unused
|}

=== Material Animations ===

The material animations section immediately follows the texgen flags. It starts with this short header:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Material animations section size''' (includes animation count, so will be 4 at minimum)
|-
| 0x4
| 4
| '''Animation count'''
|}

The structure of the animations themselves is somewhat simple. Each animation has a 32-bit ''mode'' setting, followed by a number of float parameters. The number and usage of these float parameters varies depending on what mode is set. There are 7 possible modes, but only 2-5 are known.

For all of the following modes, let ''s'' be equal to ''seconds mod 900''.

==== Mode 2: UV Offset ====

This mode is used to scroll both U and V at the same time. It has four float parameters: ''offsetA'', ''offsetB'', ''scaleA'', and ''scaleB''.

<pre>uOffset = (s * scaleA) + offsetA;
vOffset = (s * scaleB) + offsetB;</pre>

==== Mode 3: Rotation ====

This mode rotates the material. It has two float parameters: ''offset'' and ''scale''.

<pre>angle = (s * scale) + offset;</pre>

The material is then rotated by ''angle'' degrees.

==== Mode 4/5: U/V Offset ====

This mode can be used to scroll U and V independently from each other. It has four float parameters. The offset calculation for these modes is unknown; however, the same code is used for both modes, with the only difference being whether the calculated offset is applied to U or V.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]

User talk:Embyr 75/Sandbox

2015-01-25T21:51:41Z

Bearborg: /* Gradient Colors */

==Gradient Colors==
Adding gradient colors for backgrounds for these templates, hope to eventually make a universal "box" template that can be used to create new Notice Templates, with the gradient-color-functionality built in. Colors can be chosen and changed later, more concerned with if people like the gradient function right now. We could probably discuss the progression here, so others can input their opinions. [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 12:37, 25 January 2015 (CST)

: To have it out in the open, my two cents are mainly that I like the light colors, and the gradient is nice but I'm split on whether I prefer the flat color or the gradient; gradient's definitely nice but I like the simplicity and uniformity of the flat colors. Interested to hear other peoples' input. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 12:46, 25 January 2015 (CST)

: Personally, I prefer the gradients. Sweeping up to white looks particularly good, but if you want something more eyecatching, maybe go from one shade of purple to another? IMO, going straight from purple to white looks a little weird. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 12:55, 25 January 2015 (CST)

::I also prefer the gradients, and sweeping up to white. The colors are flexible, I just think they should match the icon for each template. I don't mind the purple pixels I pulled but I also see the appeal of the lighter, more subtle colors. [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 13:10, 25 January 2015 (CST)

::I kinda agree with purple to white being a little weird. I'd be curious to see what a purple-to-purple gradient might look like. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 13:19, 25 January 2015 (CST)

:::Kinda meh on the purple to purple one. The darker purple doesn't really work IMO, especially since it starts to clash with the black text. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 14:36, 25 January 2015 (CST)

::::Maybe something like this? [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 14:44, 25 January 2015 (CST)
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#f5e0fc, #c68cd9); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' <br/> Light purple to lighter purple.
|}

:::::Definitely like the lighter to darker purple gradient more than the purple to white. I made some morphball images that I thought would work great for noticed that pertain to showing the file format progress. For example:

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball_wire.png|50px|link=]]
|'''This file format is not documented''' <br/> This file format has either no or very little documentation. More research is needed.
|}
<br>
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball_model.png|50px|link=]]
|'''This file format is partially documented''' <br/> This file format may have some functionality but is still not completely understood and still needs further research.
|}
<br>
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball render.png|50px|link=]]
|'''This file format has been completely documented''' <br/> This file format has been completely understood and no further research is needed.
|}

:::::Note how the ball goes from wireframe, to untextured, to fully rendered, to denote the progress of the file. Hope you guys like it! --[[User:MrSinistar|MrSinistar]] ([[User talk:MrSinistar|talk]]) 15:06, 25 January 2015 (CST)

::::::Oh wow, those look excellent. I'd definitely support implementing them ASAP. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 15:09, 25 January 2015 (CST)

:::::::Ooh that's actually a really neat concept. I like it. Also liking the gradients a lot. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:11, 25 January 2015 (CST)

:::::::The only issue I have with the purple gradient is I feel like once it starts getting to be darker it starts clashing with the black text a little bit. It's still completely readable, but makes me feel like even that shade of purple is just a bit too dark.

:::::::I wonder if we could expand on MrSinistar's idea with the morph ball a little to display smaller versions of that on the category pages. That way someone could go take a look at the Metroid Prime category, for instance, and quickly see the status for every format right from the category page. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:15, 25 January 2015 (CST)

::::::::Thanks everyone! I'll go and make the templates for the file formats notices, if that's cool with everyone. As for the purple gradient, how about inverting it like this?

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#c68cd9, #f5e0fc); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' <br/> Light purple to lighter purple.
|}

::::::::I'll look into see if we can add small icons like that to the article names in the categories. Just to make sure we're on the same page, something like this?

[[File:Forum_idea.png|center]]

::::::::If so, I think that requires a fair amount of CSS and extra programming. But I think it's doable. --[[User:MrSinistar|MrSinistar]] ([[User talk:MrSinistar|talk]]) 15:26, 25 January 2015 (CST)

:::::::::I was thinking of having it before the link instead of after, but yeah, basically that. Also, I think I like sweeping down to the darker color better. Go ahead and implement the templates, would like to start sticking these on some pages. I think embyr was going to make a universal box template for this kind of thing though, and I'm not sure if she's done with that, so we might need to remake it later? --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:30, 25 January 2015 (CST)

::::::::::Hey MrSinistar, I think it'd be nice to have one or two more intermediate notices. Can you think of what could be used as icons for that? Maybe vertices? Like in the pak format, for example, the structure is 100% known; it's just file ordering that needs a slight bit more research. But it's small enough that I don't think it's really accurate to say we only have a partial understanding of it. Also, I don't think we should ever really say no more research is needed. No matter how much we know about a given format, there's always the chance that there's something we missed about it. Also also, I'd kind of like to try changing the names of the templates if that's alright with you :P --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:48, 25 January 2015 (CST)

::::::::::Actually come to think of it, that's not the only thing - it'd be helpful to write directly into the message box what specifically needs research. That doesn't really mesh with the icon idea, though. Any idea how we could do that? --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:50, 25 January 2015 (CST)

:::::::::The CSS side of that would actually be pretty simple, I've [http://i.imgur.com/nKm5btY.png already written it]. The hard part would be the code that determines which image to show. Maybe Parax or someone who knows more than me could implement custom CSS classes for the file progress? [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 15:51, 25 January 2015 (CST)

User talk:Embyr 75/Sandbox

2015-01-25T21:09:04Z

Bearborg: /* Gradient Colors */

User talk:Embyr 75/Sandbox

2015-01-25T20:44:28Z

Bearborg:

File:PhazonSuitIcon.png

2015-01-25T20:36:16Z

Bearborg: Bearborg uploaded a new version of File:PhazonSuitIcon.png

Custom Phazon Suit graphic made for the Randomizer, in case anyone wants to use it

File:GravitySuitIcon.png

2015-01-25T20:34:40Z

Bearborg: Bearborg uploaded a new version of File:GravitySuitIcon.png

File:VariaSuitIcon.png

2015-01-25T20:34:30Z

Bearborg: Bearborg uploaded a new version of File:VariaSuitIcon.png

File:DarkSuitIcon.png

2015-01-25T20:33:29Z

Bearborg: Bearborg uploaded a new version of File:DarkSuitIcon.png

Dark Suit icon, in case anyone wants to use it

File:LightSuitIcon.png

2015-01-25T20:32:45Z

Bearborg: Bearborg uploaded a new version of File:LightSuitIcon.png

Light Suit icon; looks like crap because apparently it uses a color modulation ingame

User:Bearborg/vector.css

2015-01-25T20:30:33Z

Bearborg: Slightly darker color for links.

Talk:Retro Modding Wiki

2015-01-25T20:24:07Z

Bearborg:

__TOC__
==License==
CC-BY-SA logo is broken [[User:Antidote|Antidote]] ([[User talk:Antidote|talk]])
:Fixed --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]])

==Logo==
Sorry for reverting your change, MrSinistar. Your logo looks nice, but I think we should try to mostly keep the logo consistent between the corner and the front page, though, and the one we have currently works a little better with the square shape than yours would. I'd actually be down for another revision of the logo, though, if you wanted to try to tweak yours a bit; it'd be cool to have it say "Retro Modding Wiki" instead of just "Retro Modding" (you could try making a more vertical layout for the corner and a more horizontal one for the front page if you want), and having the space inside the letters being transparent would be nice, since as embyr pointed out [http://www.metroid2002.com/retromodding/wiki/User:Embyr_75/Sandbox it doesn't look great on non-white backgrounds].--[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 05:32, 25 January 2015 (CST)

:Funny, I actually did a second revision of my logo that changed almost all the things you mentioned. Wasn't sure if I should post it since you guys seemed satisfied with the current one. Here's [https://i.imgur.com/fdXpkmH.png that], and here's [https://i.imgur.com/3RhPoro.png a version with the spaces empty]. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 12:14, 25 January 2015 (CST)

:: Oh that's nice! Will put that up. I'd still want to consider using MrSinistar's if he tweaks the things I mentioned though, since I like what he did with the subtext; it looks a little cleaner/nicer. Guess the best thing to do would be to put it up to a vote in the forum thread? :P In any case they're both awesome, thanks for the effort from both of you. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]])

::: Something that actually fills out the entire square would be ideal for the corner IMO but I realize that's kinda hard to do with the Retro logo since it's so horizontally-oriented. Not a big deal either way though. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 12:20, 25 January 2015 (CST)

::::Yeah, I would have liked to get a perfect square too, but I couldn't think of a better way to orient things to make that work. BTW, I noticed those suit pickup icons you made were a little off-color, especially, the Light Suit- don't know if you mind that much, but I made [https://imgur.com/a/iEp1O a set of icons] a while back from direct texture rips, and they seem to have come out better in that regard. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 12:38, 25 January 2015 (CST)

:::::Did you replace the logo in the sidebar? I'm still seeing the old one, even after clearing my cache. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 14:24, 25 January 2015 (CST)

User:Bearborg/vector.css

2015-01-25T20:23:42Z

Bearborg:

#mw-panel {
font-weight: bold !important;
}

#mw-panel li {
border: 1px solid transparent !important;
}

#mw-panel li :link {
/*color: #446fa7 !important;*/
margin-left: 3px;
}

#mw-panel li:hover {
background: #30558a; /* Old browsers */
background: linear-gradient(#30558a, #7baef1);
border: 1px solid white !important;
box-shadow: 1px 1px 2px rgba(0,0,0,0.2);
border-radius: 3px !important;
}

#mw-panel li:hover :link {
color: white !important;
text-decoration: none !important;
}

.vectorTabs li.new > span > :link {
color: #a63829 !important;
}

.vectorTabs li.selected > span > :link {
color: black !important;
}

:link:not(.new) {
color: #446fa7 !important;
}

:link.new {
color: #a63829 !important;
}

User:Bearborg/vector.css

2015-01-25T20:19:03Z

Bearborg:

#mw-panel {
font-weight: bold !important;
}

#mw-panel li {
border: 1px solid transparent !important;
}

#mw-panel li :link {
/*color: #446fa7 !important;*/
margin-left: 3px;
}

#mw-panel li:hover {
background: #30558a; /* Old browsers */
background: linear-gradient(#30558a, #7baef1);
border: 1px solid white !important;
box-shadow: 1px 1px 2px rgba(0,0,0,0.2);
border-radius: 3px !important;
}

#mw-panel li:hover :link {
color: white !important;
text-decoration: none !important;
}

.vectorTabs li.new > span > :link {
color: #ba0000 !important;
}

.vectorTabs li.selected > span > :link {
color: black !important;
}

:link:not(.new) {
color: #446fa7 !important;
}

User:Bearborg

2015-01-25T20:00:00Z

Bearborg: Created page with "A guy from [http://metroid.wikia.com/wiki/User:AmorphousBlob Wikitroid] who's clueless about modding, and only slightly less clueless about CSS. Not actually a bear or a cyborg."

A guy from [http://metroid.wikia.com/wiki/User:AmorphousBlob Wikitroid] who's clueless about modding, and only slightly less clueless about CSS. Not actually a bear or a cyborg.

User talk:Embyr 75/Sandbox

2015-01-25T18:55:03Z

Bearborg: