Level Data Format

Pointer Tables

Address	Description	Format
$05E000	Layer 1 data	0x200 levels, 3 bytes each (1,536 bytes)
$05E600	Layer 2 data	0x200 levels, 3* bytes each (1,536 bytes)
$05EC00	Sprite data	0x200 levels, 2** bytes each (1,024 bytes)

* If the long byte of the Layer 2 data is #$FF, it will get replaced by #$0C and the data will be interpreted as a BG tilemap rather than object data.
** All sprite data is located in bank 07.

Primary Level Header

The first five bytes of object data for Layer 1 is the primary level header, which dictates various information about the level. Layer 2 object data also contains this header, but it is skipped over and ignored.

Format
BBBLLLLL	CCCOOOOO	3MMMSSSS	TTPPPFFF	IIVVZZZZ

BBB	BG palette
LLLLL	Length of level (number of screens, -1)
CCC	Back area color
OOOOO	Level mode
3	Layer 3 priority
MMM	Music
SSSS	Sprite GFX setting
TT	Timer setting
PPP	Sprite palette
FFF	FG palette
II	Item memory setting
VV	Vertical scroll setting
ZZZZ	FG/BG GFX setting

Secondary Level Header

The secondary level header consists of four bytes, spread across four seperate tables with one byte per level.

Format
$05F000	$05F200	$05F400	$05F600
SSSSYYYY	33AAAXXX	MMMMFFBB	IUVEEEEE

SSSS	Layer 2 scroll setting
YYYY	Level entrance Y position
33	Layer 3 setting
AAA	Level entrance Mario action
XXX	Level entrance X position
MMMM	Midway entrance screen number
FF	FG initial position
BB	BG initial position
I	Disable No-Yoshi Intro flag
U	Unknown/unused vertical position flag
V	Vertical positioning flag
EEEEE	Level entrance screen number

Sprite Header

The first byte of sprite data is the sprite header, which handles some miscellaneous sprite-related information.

Format
SBMMMMMM

S	Sprite buoyancy
B	Sprite buoyancy (disable sprite-Layer 2 interaction)
MMMMMM	Sprite memory*

* Although values up to #$3F are possible, only up to #$12 are actually intended for use.

Object Data

Object data is used to define Layer 1 and Layer 2 foreground data. The Z order of the objects is determined by the order they're written; an object earlier in the data, for instance, will appear below an object written later.

The data consists of a five byte header, followed by a list of all the objects. If the first byte of an object is #$FF, it indicates the end of the data has been reached.

The "new screen" flag described in most of the below formats increases the high X position of all following objects by one. In order to decrease it or increase it by a larger amount, a screen jump must be used.

Standard Objects

Standard objects are 3 bytes long. The 'settings byte' usage varies depending on the object, but generally specifies the height and width of the object.

Format
NBBYYYYY	bbbbXXXX	SSSSSSSS

N	New Screen flag
BBbbbb	Object number
YYYYY	Y position
XXXX	X position
SSSSSSSS	Settings

In vertical levels, the X and Y position values are swapped.

Extended Objects

Extended objects function as standard object 00, and are also 3 bytes long.

Format
N00YYYYY	0000XXXX	BBBBBBBB

N	New Screen flag
YYYYY	Y position
XXXX	X position
BBBBBBBB	Extended object number

In vertical levels, the X and Y position values are swapped.

Screen Exits

Screen exits function as extended object 00. Unlike the rest of object data, they're 4 bytes long rather than 3.

Format
000PPPPP	0000WUSH	00000000	DDDDDDDD

PPPPP	Screen number
W	Water flag* (secondary exit)
U	LM-modified flag**
S	Secondary exit flag
H	High bit of destination level / secondary exit ID*
DDDDDDDD	Low byte of destination level / secondary exit ID

* Added by Lunar Magic; not used in the original game.
** Indicates the screen exit uses the secondary exit flag added by LM rather than SMW's default functionality.

In an unmodified SMW, if the last screen exit in the data has the secondary exit flag set, all screen exits in the level will be interpreted as secondary exits.
In an unmodified SMW, the high bit of the current level is used as the high bit of the destination level / secondary exit ID.

Screen Jump

Screen jumps function as extended object 01, and change the high X position of proceding objects to a specified screen. They can be used to skip over screens if no objects exit on them, or to move back a screen to change the Z ordering of an object crossing over a screen boundary. Like standard and extended objects, they consist of three bytes.

Format
000PPPPP	0000----	00000001

PPPPP	Screen number
----	Currently unused

Lunar Magic Objects

Lunar Magic adds some additional objects under standard IDs 22-28, with 29-2C additionally reserved for future use, and object 2D reserved for user-defined objects.

Object 22/23

Object 22 and 23 are used for direct tiles from Map16 pages 0 and 1 respectively. They're four bytes long rather than three.

Format
N10YYYYY	001BXXXX	HHHHWWWW	bbbbbbbb

N	New Screen flag
Bbbbbbbbb	Map16 tile number
YYYYY	Y position
XXXX	X position
HHHH	Height
WWWW	Width

In vertical levels, the X and Y position values are swapped.

Object 24/25

Objects 24 and 25 seem to be related to loading graphics files. Object 24 seems to involve FG/BG/SP files, while object 25 seems to involve the AN2 file. They don't seem to be used by the Super GFX Bypass, however, so it's not clear how they function or when they're used.

Format
Object 24	N10-DDDD	0100dddd	CCCCCCCC
Object 25	N10-AAAA	0101aaaa	BBBBBBBB

N	New Screen flag
DDDDdddd	Stored to $FD
CCCCCCCC	Stored to $FC
AAAAaaaa	Stored to $FA
BBBBBBBB	Stored to $FB Seems to be the ExGFX file to write to AN2, plus one.
-	Currently unused

Object 26

Object 26 handles the music bypass.

Format
N10-UUUU	0101uuuu	MMMMMMMM

N	New Screen flag
MMMMMMMM	Song ID to use, plus one.
UUUUuuuu	Unused? Functions identical to the M bits.
-	Currently unused

Object 27

Object 27 handles Map16 objects other than those handled by object 22/23. There are four different forms of the object, depending on how the tiles are selected and stretched.

Format
Single-screen, single tile	N10YYYYY	0111XXXX	HHHHWWWW	00BBBBBB	bbbbbbbb
Multiple tiles unstretched	N10YYYYY	0111XXXX	hhhhwwww	01BBBBBB	bbbbbbbb
Single-screen, multiple tiles	N10YYYYY	0111XXXX	HHHHWWWW	10BBBBBB	bbbbbbbb	hhhhwwww
Multi-screen	N10YYYYY	0111XXXX	WWWWWWWW	11BBBBBB	bbbbbbbb	hhhhwwww	HHHHHHHH

N	New Screen flag
BBBBBBbbbbbbbb	Base Map16 tile number
YYYYY	Y position
XXXX	X position
HHHH(HHHH)	Height*
WWWW(WWWW)	Width*
hhhh	Height of Map16 selection
wwww	Width of Map16 selection

In vertical levels, the X and Y position values are swapped.

* Although the height and width of multi-screen objects are 8-bit, only values up to #$80 are valid due to the way their routine is coded.

Object 28

Object 28 handles the time limit bypass.

Format
N10-BBBB	0001CCCC	R---AAAA

N	New Screen flag
AAAA	Ones
BBBB	Tens
CCCC	Hundreds
R	Force timer reset flag
----	Currently unused

Object 2D

Object 2D is reserved by Lunar Magic for 5-byte custom user-defined objects. Although it's parsed by LM's hijacks, it's not actually tied to any routines normally.

Format
N10YYYYY 1101XXXX SSSSSSSS AAAAAAAA BBBBBBBB

N	New Screen flag
YYYYY	Y position
XXXX	X position
SSSSSSSS	Settings
AAAAAAAA	Extension byte A
BBBBBBBB	Extension byte B

ObjecTool uses extension byte A as the custom object number, while byte B is left free for use.

Background Data

When Layer 2 is stored as a background tilemap (see the note on the pointer table), it's written as a raw tilemap with no header, compressed in the LC_RLE1 format.

Format
RLLLLLLL	...

R	RLE flag
LLLLLLL	Length
...	If the RLE flag is clear, the following (length + 1) bytes are intepreted as direct tile data. If the RLE flag is set, the following byte is repeated (length + 1) times.

The entire left half of the BG is stored first, then the right half. A command of FF FF indicates the end of the data.

Sprite Data

Sprite data consists of a single-byte header, followed by a list of all the sprites. If the first byte of a sprite is #$FF, it indicates the end of the data has been reached.

Format
yyyyEESY	XXXXssss	NNNNNNNN

Yyyyy	Y position
EE	Extra bits
XXXX	X position
Sssss	Screen number
NNNNNNNN	Sprite ID

In vertical levels, the X and Y position values are swapped.

Secondary Entrances

Secondary entrance data consists of four bytes, spread across four seperate 512-byte tables with one byte per secondary exit ID.

Format
$05F800	$05FA00	$05FC00	$05FE00
DDDDDDDD	BBFFYYYY	XXXSSSSS	L---HAAA

DDDDDDDD	Low byte of destination level
BB	BG initial position
FF	FG initial position
YYYY	Entrance Y position
XXX	Entrance X position
SSSSS	Entrance screen number
L	Slippery level flag*
---	Currently unused
H	High bit of destination level*
AAA	Entrance Mario action

* Added by Lunar Magic; not used in the original game.