Mother 3/SOB block: Difference between revisions

From Data Crystal
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{subpage|game=Mother 3}}
==Overview==
==Overview==
SOB blocks are used for storing sprite arrangement data. They're organized of tables that are two levels deep. They need to be manually associated with a valid tileset and palette group.
SOB blocks are used for storing sprite arrangement data. They're organized of tables that are two levels deep. They need to be manually associated with a valid tileset and palette group.
Line 12: Line 13:


===Offset table===
===Offset table===
The offset table contains offsets for both the primary and secondary entries. The secondary entry offsets immediately succeed the primary entry offsets. Each offset is 16 bits, and is calculated relative to the start of the table (including the header).
The offset table contains offsets for both the primary and secondary entries. The secondary entry offsets immediately succeed the primary entry offsets. Each offset is 16 bits (unsigned), and is calculated relative to the start of the table (including the header).


==Primary entries==
==Primary entries==
Line 18: Line 19:


===Primary entry format===
===Primary entry format===
* <tt>00-01 (02)</tt> = ''Unclassified data''
* <tt>02 bytes</tt> = Preamble count; let '''x1 = (preamble count * 8)'''
* <tt>02-03 (02)</tt> = Number of OAM sprites in this entry
* <tt>x1 bytes</tt> = Preamble
* <tt>04-.. (..)</tt> = OAM entries
* <tt>02 bytes</tt> = Number of OAM sprites in this entry; let '''x2 = (sprite count * 8)'''
* <tt>x2 bytes</tt> = OAM entries


The OAM entries follow the same format as the standard [http://nocash.emubase.de/gbatek.htm#lcdobjoamattributes GBA OAM data]. Each entry uses 8 bytes.
The preamble is ''usually'' not present, but the game does still check for it (e.g. $808866A when showing an OAM-based battle animation) and adjust the starting offset of the OAM data accordingly. The format of the preamble is currently unknown.
 
The OAM entries follow the same format as the standard [http://problemkaputt.de/gbatek.htm#lcdobjoamattributes GBA OAM data]. Each entry uses 8 bytes.


Typically in MOTHER 3, a picture will be composed of many sprites; for example, the NK Cyborg picture is composed of six large sprites, so its primary entry will have 6 OAM sprites. Since the OAM entries store coordinate information, one can easily piece together a full picture from the OAM data, tileset and palette data alone.
Typically in MOTHER 3, a picture will be composed of many sprites; for example, the NK Cyborg picture is composed of six large sprites, so its primary entry will have 6 OAM sprites. Since the OAM entries store coordinate information, one can easily piece together a full picture from the OAM data, tileset and palette data alone.
Line 29: Line 33:
It is not known how secondary entries function. There are typically much fewer secondary entries than primary entries.
It is not known how secondary entries function. There are typically much fewer secondary entries than primary entries.


[[Category:MOTHER_3_named_data_blocks|SOB]]
===Secondary entry format===
[[Category:MOTHER_3]]
* <tt>02 bytes</tt> = Byte count; let '''x1 = Byte count'''
* <tt>02 bytes</tt> = Entry count
* <tt>x1 bytes</tt> = Effective secondary entries. They seem to be 4 bytes long
 
[[Category:Mother 3 named data structures|SOB]]
[[Category:Mother 3|SOB]]

Latest revision as of 02:21, 20 May 2024

This is a sub-page of Mother 3.

Overview

SOB blocks are used for storing sprite arrangement data. They're organized of tables that are two levels deep. They need to be manually associated with a valid tileset and palette group.

Format

  • 00-03 (04) = "sob " header
  • 04-05 (02) = Number of primary entries
  • 06-07 (02) = Number of secondary entries
  • 08-.. (..) = Offset table
  • ..-.. (..) = Primary entries
  • ..-.. (..) = Secondary entries
  • ..-.. (04) = "~sob" footer

Offset table

The offset table contains offsets for both the primary and secondary entries. The secondary entry offsets immediately succeed the primary entry offsets. Each offset is 16 bits (unsigned), and is calculated relative to the start of the table (including the header).

Primary entries

The primary entries contain sprite arrangement data.

Primary entry format

  • 02 bytes = Preamble count; let x1 = (preamble count * 8)
  • x1 bytes = Preamble
  • 02 bytes = Number of OAM sprites in this entry; let x2 = (sprite count * 8)
  • x2 bytes = OAM entries

The preamble is usually not present, but the game does still check for it (e.g. $808866A when showing an OAM-based battle animation) and adjust the starting offset of the OAM data accordingly. The format of the preamble is currently unknown.

The OAM entries follow the same format as the standard GBA OAM data. Each entry uses 8 bytes.

Typically in MOTHER 3, a picture will be composed of many sprites; for example, the NK Cyborg picture is composed of six large sprites, so its primary entry will have 6 OAM sprites. Since the OAM entries store coordinate information, one can easily piece together a full picture from the OAM data, tileset and palette data alone.

Secondary entries

It is not known how secondary entries function. There are typically much fewer secondary entries than primary entries.

Secondary entry format

  • 02 bytes = Byte count; let x1 = Byte count
  • 02 bytes = Entry count
  • x1 bytes = Effective secondary entries. They seem to be 4 bytes long