Actions

Difference between revisions of "Sonic Advance 3/Technical information"

From Sonic Retro

(...and the other half. Will probably pare this down and split around some info soon.)
 
(14 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{inuse}}
+
{{back}}
This is the [[Sonic Community Hacking Guide]] for ''[[Sonic Advance 3]]''. Guide based on [[Erik JS]]' Sonic Advance 3 Hacking Guide.
+
{{cleanup}}
 +
 
 +
{{SCHG SAdv3}}
 +
__TOC__
 +
This is the '''[[Sonic Community Hacking Guide]] for ''[[Sonic Advance 3]]'''''. The guide is based on [[Erik JS]]' Sonic Advance 3 Hacking Guide.
  
==Introduction==
 
 
In this page I'll show you the most important aspects of SA3 ROM. Read carefully before going into RAM and ROM sections.
 
In this page I'll show you the most important aspects of SA3 ROM. Read carefully before going into RAM and ROM sections.
  
Line 11: Line 14:
 
Now, the palette. GBA supports 32768 colors, and the cubic root of this number is 32, which means that each color level (red, green and blue) has 32 variations. In order to represent a color, GBA uses 2 bytes. Black is 0000 and white is 7FFF. But don't forget what I said about how the ROM stores values, in Little Endian ordering (white would be found as FF7F) If you want to know how to edit the palette, I have a proper page for that. Click here to open it in another window. And remember that VBA has a palette viewer (Tools-> Palette viewer).
 
Now, the palette. GBA supports 32768 colors, and the cubic root of this number is 32, which means that each color level (red, green and blue) has 32 variations. In order to represent a color, GBA uses 2 bytes. Black is 0000 and white is 7FFF. But don't forget what I said about how the ROM stores values, in Little Endian ordering (white would be found as FF7F) If you want to know how to edit the palette, I have a proper page for that. Click here to open it in another window. And remember that VBA has a palette viewer (Tools-> Palette viewer).
  
Time to talk about texts. Majority of them are sprites, and can be edited through Tile Layer Pro. That includes: "press start", copyright info at title screen and the main menu options, for instance. On VBA, go to Tools-> OAM viewer, and slide the bar. If the text isn't "letter by letter" then it's a sprite. Text that is "letter by letter" are coded, like the level select text from Sonic 1 for Genesis.
+
Time to talk about texts. Majority of them are sprites, and can be edited through Tile Layer Pro. That includes: "press start", copyright info at title screen and the main menu options, for instance. On VBA, go to Tools-> OAM viewer, and slide the bar. If the text isn't "letter by letter" then it's a sprite. Text that is "letter by letter" are coded, like the level select text from Sonic 1 for Mega Drive.
  
 
Last, I want to talk about the monoblock technique that is used in the game. As I said before, sprite palette is at 0x353CCC. If you check out, you'll figure that it's Sonic palette. And it has a pointer. Now, where's the pointer for Cream's, Tails',  Knuckles', Amy's and the rest??? Answer: it's the same for all the sprites! What happens is that all the palettes are in one big group (what I call monoblock), and if you alter the palette pointer you'll notice the "effect" in all of game's sprites. That pattern is followed by sprites, palettes and their mappings. About mappings, they give hints where to find sprites. For instance, the first mapping is for Sonic standing on foot, sprite state 0, second is Sonic looking up, sprite state 1... that'll be explained better at the proper section.
 
Last, I want to talk about the monoblock technique that is used in the game. As I said before, sprite palette is at 0x353CCC. If you check out, you'll figure that it's Sonic palette. And it has a pointer. Now, where's the pointer for Cream's, Tails',  Knuckles', Amy's and the rest??? Answer: it's the same for all the sprites! What happens is that all the palettes are in one big group (what I call monoblock), and if you alter the palette pointer you'll notice the "effect" in all of game's sprites. That pattern is followed by sprites, palettes and their mappings. About mappings, they give hints where to find sprites. For instance, the first mapping is for Sonic standing on foot, sprite state 0, second is Sonic looking up, sprite state 1... that'll be explained better at the proper section.
  
==ROM Hacking==
+
==Underwater-related things==
===Sprites===
+
First off, in my research on Sonic Advance 3, I found that underwater areas have a global ripple attached to them. For example, removing BG1 and BG2 in Sunset Hill Act 1 will give you a ripple. The reason they never showed it was that firstly, it's on a cliff, so if it showed in the background it wouldn't make any sense; secondly, the ripple would also not affect the palm trees; and thirdly, the ripple shows beyond BG 3, so it would look glitchy.
Huh! Don't you know what is sprite? [[Sprites]] are all visible objects that stay over a background. That includes certain texts (level titles, copyright info at title screen) and some "bars". Anything that appears at VBA's OAM Viewer should be treated as sprite. Though changing a sprite doesn't basically mean changing colors. An image is made of colors in a certain order - sprite data is the order. ||||||| That bunch of lines can have multiple or no meaning for you, but + these two line crossed you know perfectly that they are an add signal. What sprite data does is reference colors in a palette.
 
  
:Main Sprite Pointer: 0x00000404
+
Palettes are simple to edit. There are no custom underwater palettes. Editing the above-water palettes will result in converting the underwater palette.
  
The pointer above points to 0x003314F0, where there are five pointers. In SA3, a sprite is made of five parts: three mappings, palette and its data. After these five pointers, you'll see two more, but I don't know what they handle.
+
==References==
 +
<references/>
  
====Sprite data====
+
{{SAdv3Omni}}
 
+
{{SCHGuides}}
The GBA sprite data format is very simple. It uses 1 byte for every 2 pixels. Each [[nybble]] (half-byte) points to a color on palette (from 0 to F, the palette has 16 colors). Just for the hell of it the pixels are reversed! So F0 must be treated as 0F for visualisation purposes. That is, before mounting an image, reverse the nybbles. Images are formed by a bunch of tiles, and tiles are nothing more than a block of 8x8 pixels. If you're good at math you'll soon find out that each tile occupies 32 (20h) bytes. For 1-tile (8x8) images, you won't have too much work to edit them. But for 2 tiles or more you can never tell if the next 32 bytes are from the upper or lower part of the image, and that's for what mappings exist. You can see tiles using Tile Layer Pro. And before I forget it, references to the first color (0) of the palette result in transparency.
 
 
 
:Location: 0x0076CB1C
 
:Pointer: 0x00331500
 
 
 
In TLP, put the location address in Go To dialog, so you will be able to see the tiles correctly.
 
 
 
====Sprite mappings====
 
 
 
Do you remember what I said above about mounting images with more than 1 tile? Well, the part that handles the tile arrangement is called mapping. Sprite mappings indicate which, how many and where the tiles appear, and which palette to use.
 
 
 
:Location 0: 0x0032FD20
 
:Location 1: 0x00E2C3A8
 
:Location 2: 0x003524FC
 
:Pointer 0: 0x003314F0
 
:Pointer 1: 0x003314F4
 
:Pointer 2: 0x003314F8
 
 
 
There are three kinds of mappings. If you look at their locations, you'll find more pointers! They refer to the sprite states, and follow the respective topic at RAM section. The first pointer is Sonic standing on foot (sprite state 0), the second is Sonic looking up (sprite state 1)... maybe I change the name of this topic to "Animation mapping". Mapping 0 is directly linked to the sprite that is shown. There, I figured how to change the palette index used, which sprite to use and the time of frames, but there are more things to figure out. You can use SA3 Pointer Reader (Downloads) to get pointers from any sprite state.
 
Palettes
 
 
 
Palettes are sets of colors that are used by a certain sprite state. They are "called" through hidden flags (indexing), which change in groups of 16 colors. In mapping 0, it's possible to load more or less than 16 colors, but the first color to load will be the first color of the palette that corresponds to the index requested, due to the programming style that is used in the game. According to my calculations, there's a total of 551 palette indexes  (0 to 226h).
 
 
 
:Location: 0x00353CCC
 
:Pointer: 0x003314FC
 
 
 
Each color is formed with 2 bytes, and each index has 16 colors, which means that the difference from an index to the next is 32 (20h) bytes. That is, index 0 means to load starting at 0x00353CCC; index 1, start at 0x00353CEC... and so. Click here to know how to edit GBA palette.
 
 
 
You may have noticed that different char states from Sonic use different palette indexes, and all of them are equal! Sonic Team seems to have never noticed it before. This "feature" is annoying while editing Sonic palette to something else... but, hey! Games weren't supposed to be hacked! ;).
 
 
 
===Sound Test===
 
====General sprite selections====
 
 
 
:0x000D729C: selection for Play button - 8 bytes for each language.
 
:0x000D72CC: selection for Back/Stop button - 8/8 bytes.
 
:0x000D7334: selection for Sound Test title for each language - 8 bytes.
 
:0x000D7364: selection for numbers - 8 bytes.
 
:0x000D73B4: selection for double arrows - 8 bytes. (btw, the sprite is doubled here, there's no double arrow sprite state)
 
 
 
:8 bytes format: XXXX YYYY ZZZZ ZZZZ
 
:XXXX: sprite state (see Sprites)
 
:YYYY: sprite sub-state - determines which part of sprite state is used. All the sprites are stored (programmed) in form of states, hence it can contain various frames.
 
:ZZZZ ZZZZ: unknown function.
 
 
 
The double arrow is a perfect guinea pig for seeing which animation a sprite state does.
 
 
 
====Music titles====
 
 
 
:0x000D73BC: beginning of music titles - ASCII.
 
 
 
Let's start with the first one. Before "OPENING", there's a byte which its value is 7. As you may already guessed, this byte tells the game how many letters must be read.
 
 
 
To edit a title, you can use ASCII chars, with some rules:
 
 
 
Characters that appear correctly:
 
* Upper/Lower case letters;
 
* Numbers from 1 to 9;
 
* !@#$%&*()?.:-/_[]{} (these are the ones I've tested);
 
 
 
Special notes:
 
* Using 0 (30h) results in space;
 
* Char ] (5Dh) appears with wrong palette, probably it's from an error at its mapping. The beta version also has this bug.
 
 
 
====Music assignments====
 
 
 
:Location: 0x000D71A4
 
 
 
2 bytes per title. The value corresponds to music pointer order. See Musics section for more details.
 
 
 
===Dynamic text===
 
 
 
Dynamic text is nothing more than the kind of text that is shown in order to send a message to the player. The most common source of that are the Omochaos. This includes the beginning text ("The evil scientist, Dr. Eggman!..") and that one from Nonaggression ("Sonic! Use your tag action..."). Here's a sample:
 
 
 
[[Image:sa3_dynamictext.gif|center]]
 
 
 
Well, "dynamic text" could be the incorrect designation, but who discovered how to edit this shit anyway? Get used to my terminology and don't argue! ;)
 
 
 
:0x00E7E6E8: Pointer to Japanese set
 
:0x00E7E6EC: Pointer to English set
 
:0x00E7E6F0: Pointer to German set
 
:0x00E7E6F4: Pointer to French set
 
:0x00E7E6F8: Pointer to Spanish set
 
:0x00E7E6FC: Pointer to Italian set
 
 
 
Theoretically, each language has 256 dynamic texts. That means in the location given by the language pointer there are 256 pointers, one after other, which belong to text data. However only 1/4 (64) of them points to "real" data. The remaining 192 pointers can be used to assemble new texts, because there is a space of 1,5 MB at the end of the file that Sonic Team kindly left for us! :)
 
 
 
====Text format====
 
 
 
It isn't that hard to understand. Each character uses 2 bytes. Its value minus 92h is equal to its ASCII value. Be aware when you come across the following values:
 
 
 
:0151h: Spacer. The next 2 bytes tell the size of the space.
 
:0152h: Timer. The next 2 bytes tell the speed which letters appear.
 
:0153h: Line break (lik when you press ENTER in a text editor).
 
:0154h: Button request. Player must press A button to see the rest of the text.
 
:0155h: EOT (end of text).
 
 
 
The useless pointers do nothing more than point to a bunch of 0155h. Numbers follow a different pattern. If x (char value) is >= C8h and <= D1h, the formula should be: '''ASCII = x - 98h instead of ASCII = x- 92h'''.
 
 
 
===Zones===
 
 
 
In this page you will find information on how to change the zones of the game. Whenever I use the expression "scene" (with quotation marks), I will be referring to the value that Chao's Playground, Sonic Factory, Route 99 Map, etc, uses as scene flag. Go to RAM section to know more.
 
 
 
====Main zone pointers====
 
 
 
:Group 1: 0x000D0624 - artwork
 
:Group 2: 0x000D0D78 - collision
 
 
 
Each pointer of Group 2 corresponds to a "scene" of the game, according to its flags. On the side of Group 1, there are four pointers per "scene". First, I will explain how Group 1 works. We will use "scene" 03 (Zone 1 Act 1) as example:
 
 
 
[[Image:Romzonedemo1.gif|center]]
 
 
 
The selected part corresponds to the pointers of that "scene". The first pointer (0838B590) is for BG1. The second is for BG2 (0838B5B4). Each one of them points to a sequence of 36 (24h) bytes, that contain the information about layout and palette for those BG's. The last two pointers (085DC428 and 085DEA24) point each one to a sequence of 28 (1Ch) bytes, that have to do with the image of 256 colors that is exhibited in BG's 0 and 3. If you still don't know why I call everything like BG, go into the menu Tools->Map Viewer of VBA and guess it :P.
 
 
 
Let's see how are the 36 bytes pointed by the first two pointers:
 
 
 
[[Image:Romzonedemo2.gif|center]]
 
 
 
The byte marked with black is the beginning of the block. The pointer marked with blue tells where are the tiles. A tile is a block of 64 pixels (8x8). The pointer marked with yellow says where is the palette. There are 256 colors (512 bytes). In this case, only the second pointer (from BG2) is relevant, because, somehow, it overwrites the first. The pointer marked in red refers to the mappings of 96x96 blocks that form the layout. Last, the green pointer indicates where is the layout (1 byte per block).
 
 
 
Now let's see the 28 bytes from BG0 of this same "scene" to know how he game handles images of 256 colors:
 
 
 
[[Image:Romzonedemo3.gif|center]]
 
 
 
Did you notice that I used the same colors of the previous picture? What is marked with black, blue and yellow has the same function that was attributed to those colors previously. The pointer in red, however, has the function of mapping and layout. The format of BG3 is the same.
 
 
 
Time to talk about Group 2, collision. Again from "scene" 03, it's at 0x0038B5D8. 6 pointers, plus 12 bytes.
 
 
 
[[Image:Romzonedemo4.gif|center]]
 
 
 
I didn't mess a lot with the pointers, for now I cannot give more details on how they work.
 
 
 
:Pointers for background movement and deformation : 0x000D0344. Two pointers per "scene".
 
:Character starting position: 0x000D13C8. One pointer per "scene". Each one points to 4 bytes: 2 bytes for horizontal position and 2 for vertical.
 
:Ring layout pointers: 0x000CEBD0.  One pointer per "scene". The format wasn't figured out yet.
 
:Object layout pointers: 0x000D0E9C. One pointer per "scene".
 
 
 
===Musics===
 
 
 
This section is about musics and sound effects in game, how to handle them and other things. I discovered the playlist for maps and acts. But first you need to know how musics are ordered. The Sound Test list has nothing to do with the real order. They are referenced by their order at sound pointer list. Well, let's find out what is this...
 
 
 
====Sound pointer list====
 
 
 
Believe it or not, I found this by chance. It starts at 0x000EB420. Each sound uses 4 bytes for the location, plus 4 more bytes for unknown function. Any pointer that points to 0x000ECE08 (080ECE08) results in no sound. Fortunately SA1 and SA2 uses the same system, so music importing/exporting is possible. However, copy & paste isn't enough. The music itself has pointers at the end of its blocks that need to be changed to fit in the new game (only "loopable" musics).
 
 
 
Musics and sound effects are in this list.
 
 
 
====Music structure====
 
 
 
The location given by the sound pointer holds a header made of 8 bytes. The first 2 bytes tells how many parts the music is formed, and consequently, how many pointers must be read after the header. The next 2 bytes have unknown function. The last 4 are the pointer for instrument definition, something like a sound driver maybe, it's essential however. Let's take music 01 (title) as example. It's at 0x00264A9C. At the header, you'll fin the following bytes, in this order: 06 00 14 80 F8 51 0E 08. The first 2 bytes indicate that there are 6 blocks used to form this music. So, after the last byte of the header, the game should read 6 groups of 4 bytes (6 pointers). Notice that those block pointers point to data behind the header. As the first block pointer is which points to the far away data (pointer with smaller value), then when you want to copy the whole music to other ROM or other place, begin to copy starting from the location of that pointer until the last byte of the last block pointer. After that, change the block pointers in accordance where the music is now. Example: the header was in CE0h, and now it is in 33450h. What you should have to do is to add 32770h (the difference between 33450h and CE0h) to the value of the block pointers.
 
 
 
In the case of music that loops, it has other pointers that are in the end of each block. Those pointers should also be adjusted as the block pointers.
 
 
 
But that is not everything that forms the music. When passing from a game to other, it is necessary to modify the pointer of the instrument definition, or the sound won't play, the game will crash, that kind of thing. Importing instrument definition from a game to another is what I have yet to discover.
 
 
 
====Normal zones playlist====
 
 
 
:Location: 0x000CE1A4
 
:Pointer: 0x00002638
 
 
 
1 byte per act. Zone 1 - Map; Zone 1 Act 1; Zone 1 Act 2... and then until Zone 7 Act 3. The byte value follows the order which musics have at sound pointer list. 00 = opening, 01 = title and so.
 
 
 
===Hidden level select menu===
 
 
 
First of all, you won't learn here how to access this menu, simply because neither I don't know how! Second, I decided to create this subsection because there are evidences of this being a "working" menu, so I'll put everything I discovered about it here.
 
 
 
====Texts====
 
 
 
:0x000D6B98: Text 1: SELECT STAGE
 
:0x000D6BA8: Text 2: ZONE %d ACT %d
 
:0x000D6BB8: Text 3: PRESS A BTN
 
:0x000D6BC4: Text 4: PLEASE WAIT
 
:0x0008E8E8: Pointer to Text 1
 
:0x0008E8F0: Pointer to Text 2
 
:0x0008E8F4: Pointer to Text 3
 
:0x0008E928: Pointer to Text 4
 
 
 
These texts are in the beta, and there are more! Those "extra" texts from beta refer to the ability of choosing between tag and single play. Why did they changed something that doesn't work? Well, that could mean that it works!
 
 
 
====Level pointers====
 
 
 
:Location: 0x000D6B80
 
:Pointer: 0x0008E724
 
 
 
Each byte corresponds to an act. Zone 1 Act 1, Zone 1 Act 2... until Zone 7 Act 3. Those are the values used by the scene flag. Read about scene flag at RAM section.
 
 
 
===Special Stages===
 
 
 
This section concerns about editing things in Special Stages.
 
 
 
====Rings for checkpoints====
 
 
 
:Location: 0x000DBAF6
 
 
 
2 bytes Little-Endian values. SS1 - first checkpoint, SS1 - last checkpoint, SS2 - first checkpoint... and then until SS7 - last checkpoint. Change these values to make the stages easier/harder to pass.
 
 
 
==RAM Hacking==
 
Here you'll find some interesting  RAM locations which values can be altered in order to get a certain thing. This is like changing a byte in a savestate. These locations can be used in Memory Viewer and Cheat List from VBA
 
 
 
I'll list the addresses, how bytes they use and a brief description. Numbers between parenthesis refer to partner character. Example: 030015EA(173A) means that the address that changes the partner character is 0300173A.
 
 
 
{| border="1"
 
!Location||Size||Description
 
|-
 
| 0300094C
 
| 2 bytes
 
| Rings
 
|-
 
| 030015EA(173A)
 
| 1 byte
 
| Character
 
|-
 
| 030015EB(173B)
 
| 1 byte
 
| Character flag
 
|-
 
| 030015F0(1740)
 
| 2 bytes
 
| Character state
 
|-
 
| 030015F2(1742)
 
| 2 bytes
 
| Character state
 
|-
 
| 030015F4(1744)
 
| 2 bytes
 
| Sprite state
 
|-
 
| 03001612(1762)
 
| 2 bytes
 
| Time until going into &quot;wait state&quot;
 
|-
 
| 03001D38
 
| 4 bytes
 
| Pos X (horizontal)
 
|-
 
| 03001D3C
 
| 4 bytes
 
| Pos Y (vertical)
 
|-
 
| 03000552
 
| 7 bytes
 
| SP keys (1 byte per zone)
 
|-
 
| 030008A9
 
| 1 byte
 
| Zone
 
|-
 
| 030008AA
 
| 1 byte
 
| Act
 
|-
 
| 030008AE
 
| 1 byte
 
| Scene flag
 
|-
 
| 030008B4
 
| 2 bytes
 
| Button flag - A
 
|-
 
| 030008B6
 
| 2 bytes
 
| Button flag - B
 
|-
 
| 030008B8
 
| 2 bytes
 
| Button flag - R
 
|-
 
| 0300094E
 
| 2 bytes
 
| Timer (units in 1/100th of second)
 
|-
 
| 03000954
 
| 1 byte
 
| Lives
 
|-
 
| 03004532
 
| 1 byte
 
| Level title (bottom right corner)
 
|-
 
| 03004874
 
| 2 bytes
 
| Rings in special stage
 
|-
 
| 030008C8
 
| 2 bytes
 
| Restarting position X
 
|-
 
| 030008CC
 
| 2 bytes
 
| Restarting position Y
 
|-
 
| 03000541
 
| 1 byte
 
| Zone access flag
 
|-
 
| 03000559
 
| 7 bytes
 
| Zone completion flags (1 byte per zone)
 
|-
 
| 03000562
 
| 1 byte
 
| Emerald flag
 
|-
 
| 03000927
 
| 1 byte
 
| SP key flag
 
|}
 
 
 
===Rings and time==
 
 
 
Two bytes. In the side of the timer, it increases 1 at every 1/100 of second, until reaching the maximum value of 8C9Fh, that is equal to 9:59:99. The timer is present even in the map scene, Sonic Factory and Chao's Playground, but with the difference to a normal act that it's invisible and death is disabled. In the time until going into "wait state", it decreases instead of increasing. When it reaches zero, the character enters into "waiting" animation.
 
 
 
===Character===
 
 
 
Just a single byte. Sonic=00, Cream=01, Tails=02, Knuckles=03 and Amy=04. The same order from SA2. Changing its value will give the result instantly. If you put the same char as main and partner then you're going to have problems using tag action, mostly the game will lock up, with exception of Cream & Cream and Sonic & Sonic. The lock up is due to the fact that a character hasn't a programmed state that is supposed to be used when performing a tag action with himself/herself.
 
 
 
===Character & sprite state===
 
 
 
State means an sprite (or sprites) that appears performing some animation. If you know MUGEN (how CNS and AIR files work) then you know what I'm talking about. Character states indicate which animation the char is doing (standing, looking up, looking down, running, etc). Sprite states indicate which animation the game must show in order to fit the char state (and the current char, because it's pretty stupid/pointless having Knuckles appear when you try to jump with Cream, for instance :P). Char state 0 is standing on foot. For Sonic, both states (char & sprite) are the same. But with Cream,  sprite state for char state 0 is A3h. Every single object in the game that belongs to GBA's OBJ layer has a sprite state. And in case you're wondering, yes,  you can force an object to appear in place of your character with VBA's cheat mode, simulating debug mode, and release a screenshot in order to have about 1 billion stupid kiddies bumping your topic in a forum. So everything that appears in VBA's OAM viewer and uses sprite palette has a sprite state. With Sonic and the cheat, using the attack with B will "force" the sprite to appear. Here comes a cool cheat: 030015F4:0516. You'll turn into G-mel and then turn back to normal. Only few states allow you to come back to normal, otherwise game crashes. There is a total of 1524 sprite states, from 0 to 1523. Some doesn't have data, but 1524 is the max number of states that is actually supported by SA3. Do you remember what I said above about using the same char as main and partner? Let's use Tails & Tails as example. The "jumping-over-Tails" char state is 5Bh. When Tails performs that, sprite state is set to 1A1h(417), and if you check this out in the ROM the pointers for that state will be empty (zero) in all of its mappings. Attempting to read data beyond range and  pointing to invalid data are the two things that make games crash.
 
 
 
===Character flag===
 
 
 
It's a single flag that tells the game how a character must act. With this, you can freeze your main character and even control the partner character. I guess this flag is widely used in multiplayer mode for obvious reasons. When 05 (main char), gameplay is normal. You can "control" the partner by setting his/hers flag to 07.
 
 
 
===Pos X / Y===
 
 
 
4 bytes. Hex view is highly recomended. But surprise, surprise! The corner of the screen isn't 00000000! It's FFFF... something, that is, lower than zero. PosX increases from left to right and PosY increases from above to below. Forcing a position with cheats doesn't work, and I don't know why. I bet nobody has found a use for this.
 
 
 
===Zone and act, level title===
 
 
 
Zone: starts at 00 - Route 99 and ends in 06 - Chaos Angel. 07 is Altar Emerald and 08 is Nonaggression. If you're in a zone and you change its byte to another zone, the next part will be based on the new zone. For instance, being in Route 99, changing map byte to 04 and jumping at act 1 ring. You'll be at Twinkle Snow Act 1. The expression "next part" includes map, Chao's Playground, Sonic Factory, acts, bosses and Special Stages. The act byte just says which "part" of the zone you are. Altar Emerald causes a bunch of problems when accessed through "unofficial" methods. About the level title, it changes instantly, without need of going to another "part".
 
 
 
===Scene flag===
 
 
 
This is really a useful flag! It makes more than give you the current zone and act. It also handles which kind of "scene" you are. 01 is Sonic Factory (precisely from Route 99), and that results in disabling of tag action. 48h is Nonaggression. Example: if you clear an act and then change the scene flag to 48h, the ending sequence with all emeralds will appear. Another example: if you enter Sonic Factory and change scene flag to 02 (Route 99 Map) then you'll be able to use tag action. One more: turn on the timer and ring counter in Sonic Factory, Chao's and map scene by changing scene flag to a value that belongs to an act.
 
 
 
===Button flag===
 
 
 
It's just about what action is attributed to a button.
 
 
 
:0001: jump
 
:0002: attack
 
:0100: partner
 
 
 
Other values will likely result in nothing. "Duplications" don't work - i.e. you can't have two buttons to do the same thing. I wonder how or when it'll be possible to use L button...
 
 
 
===Restarting position===
 
 
 
2 bytes for X/Y position. It's used to place your character somewhere after you lose a life. The values used here are "compatible" with the starting pos values from Zones subsection at ROM section.
 
 
 
===Zone access flag===
 
 
 
This 8-bit flag tells the game how many zones are available through Sonic Factory. 00 means that no zones will be available and 07 means that all zones will be available. Example: if the flag value is 05, all zones up to Zone 5 will be available. In other words: if you're at Sonic Factory from Zone 3, the teleport boxes for Zones 1, 2, 4 and 5 will be active.
 
 
 
===Zone completion flags===
 
 
 
These flags tell the game which acts are complete or not. When playing a completed act, the pause thing will change and an option to go back will be available. I know this can be explained at binary level, but right now I can't think anything better than this:
 
 
 
{|  border="1" width="100%"
 
| FLAG VALUE
 
| ACT 1
 
| ACT 2
 
| ACT 3
 
|-
 
| 00 - 08
 
| Incomplete
 
| Incomplete
 
| Incomplete
 
|-
 
| 01 - 09
 
| Passed
 
| Incomplete
 
| Incomplete
 
|-
 
| 02 - 0A
 
| Incomplete
 
| Passed
 
| Incomplete
 
|-
 
| 03 - 0B
 
| Passed
 
| Passed
 
| Incomplete
 
|-
 
| 04 - 0C
 
| Incomplete
 
| Incomplete
 
| Passed
 
|-
 
| 05 - 0D
 
| Passed
 
| Incomplete
 
| Passed
 
|-
 
| 06 - 0E
 
| Incomplete
 
| Passed
 
| Passed
 
|-
 
| 07 - 0F
 
| Passed
 
| Passed
 
| Passed
 
|}
 
 
 
Values from 00 to 07 mean Boss Arena incomplete. Values from 08 to 0F mean otherwise. However the Boss Arena can only be accessed when all three acts are complete (07 or 0F).
 
 
 
===Emerald flag===
 
  
At least, I figured the "binary spirit" embed in this one. In order to check how many emeralds you have, convert the flag value to binary and read it from right to left, as if it would be from Zone 1 to Zone 7. All emeralds is 7Fh (01111111) and no emeralds is 0 (00000000). Let's say the current flag value is 47h. Converting it to binary (01000111) and then checking out will reveal that emeralds from Zone 1, 2, 3 and 7 were gotten. This flag works in Chao's Playground regardless how many Chaos you found.
+
[[Category:Technical information]]
 
 
===SP key flag===
 
 
 
Very simple. It's set to 1 when you collect a SP key in an act. The end-of-level results thing checks this flag to add 1 SP key to your count.
 
 
 
{{SCHGuides}}
 
[[Category:Sonic Community Hacking Guide]]
 

Latest revision as of 14:13, 1 October 2020

Back to: Sonic Advance 3.
Sonicretro-round.svg This article needs cleanup.

This article needs to be edited to conform to a higher standard of article quality.
After the article has been cleaned up, you may remove this message. See How to Edit a Page for help.

Sonic Advance 3
Technical information
Main article
ROM Portion
Editing the ROM
Sprites
Sound Test
Sound and Music List
Dynamic Text
Zones
Music
Hidden Level Select Menu
Special Stages
RAM Portion
RAM Editing
See Also
SCHG How-to topics
Sonic Advance PalTool
Sonic Advance 3 Tools
VBASDL

This is the Sonic Community Hacking Guide for Sonic Advance 3. The guide is based on Erik JS' Sonic Advance 3 Hacking Guide.

In this page I'll show you the most important aspects of SA3 ROM. Read carefully before going into RAM and ROM sections.

Let's start with the header. The game title is a string that starts at 0x0000A0. Its max size is no more than 11 bytes. At 0x0000AC, there's the serial string (4 bytes). In American SA3, it's B3SE. That "E" belongs to USA region. J is for Japan and P for Europe. At 0x0000BD is the checksum byte. On VBA, go to File-> ROM information. The value outside parenthesis is the right checksum for the game. If the inside value (actual checksum) isn't equal, and the ROM doesn't work, just change it to the correct and it should work. This method is valid for any GBA ROM (specially the intro'ed ones).

Let's go to the pointers. Pointers are nothing more than a group of four bytes that indicates a location at ROM that contains certain data. When something needs to be read from ROM, the pointer points to a ROM location + 08000000h. It's like that because the area reserved for games in GBA starts at 0x08000000 - you can see that at VBA, going to Tools-> Memory viewer. For instance, sprite palettes are at 0x353CCC. In ROM, their respective pointer will be like CC 3C 35 08 (this byte order is called Little Endian). If you are using Visual C++, then you don't need to reverse the order of the bytes when searching for a pointer. VC++ automatically searches reversed values - just search for 08353CCC. Also, note that in ROM and RAM section everything is treated as Little Endian, unless stated otherwise.

Now, the palette. GBA supports 32768 colors, and the cubic root of this number is 32, which means that each color level (red, green and blue) has 32 variations. In order to represent a color, GBA uses 2 bytes. Black is 0000 and white is 7FFF. But don't forget what I said about how the ROM stores values, in Little Endian ordering (white would be found as FF7F) If you want to know how to edit the palette, I have a proper page for that. Click here to open it in another window. And remember that VBA has a palette viewer (Tools-> Palette viewer).

Time to talk about texts. Majority of them are sprites, and can be edited through Tile Layer Pro. That includes: "press start", copyright info at title screen and the main menu options, for instance. On VBA, go to Tools-> OAM viewer, and slide the bar. If the text isn't "letter by letter" then it's a sprite. Text that is "letter by letter" are coded, like the level select text from Sonic 1 for Mega Drive.

Last, I want to talk about the monoblock technique that is used in the game. As I said before, sprite palette is at 0x353CCC. If you check out, you'll figure that it's Sonic palette. And it has a pointer. Now, where's the pointer for Cream's, Tails', Knuckles', Amy's and the rest??? Answer: it's the same for all the sprites! What happens is that all the palettes are in one big group (what I call monoblock), and if you alter the palette pointer you'll notice the "effect" in all of game's sprites. That pattern is followed by sprites, palettes and their mappings. About mappings, they give hints where to find sprites. For instance, the first mapping is for Sonic standing on foot, sprite state 0, second is Sonic looking up, sprite state 1... that'll be explained better at the proper section.

Underwater-related things

First off, in my research on Sonic Advance 3, I found that underwater areas have a global ripple attached to them. For example, removing BG1 and BG2 in Sunset Hill Act 1 will give you a ripple. The reason they never showed it was that firstly, it's on a cliff, so if it showed in the background it wouldn't make any sense; secondly, the ripple would also not affect the palm trees; and thirdly, the ripple shows beyond BG 3, so it would look glitchy.

Palettes are simple to edit. There are no custom underwater palettes. Editing the above-water palettes will result in converting the underwater palette.

References


Sonic Advance 3
SonicAdvance3 title.png

Main page
Comparisons
Maps
Credits


Manuals
Promotional material
Magazine articles
Reception


Development
Hidden content
Bugs
Technical information

Sonic Community Hacking Guide
General
SonED2 Manual | Subroutine Equivalency List
Game-Specific
Sonic the Hedgehog (16-bit) | Sonic the Hedgehog (8-bit) | Sonic CD (prototype 510) | Sonic CD | Sonic CD (PC) | Sonic CD (2011) | Sonic 2 (Simon Wai prototype) | Sonic 2 (16-bit) | Sonic 2 (Master System) | Sonic 3 | Sonic 3 & Knuckles | Chaotix | Sonic Jam | Sonic Jam 6 | Sonic Adventure | Sonic Adventure DX: Director's Cut | Sonic Adventure DX: PC | Sonic Adventure (2010) | Sonic Adventure 2 | Sonic Adventure 2: Battle | Sonic Adventure 2 (PC) | Sonic Heroes | Sonic Riders | Sonic the Hedgehog (2006) | Sonic & Sega All-Stars Racing | Sonic Unleashed (Xbox 360/PS3) | Sonic Colours | Sonic Generations | Sonic Forces
Technical information
Sonic Eraser | Sonic 2 (Nick Arcade prototype) | Sonic CD (prototype; 1992-12-04) | Dr. Robotnik's Mean Bean Machine | Sonic Triple Trouble | Tails Adventures | Sonic Crackers | Sonic 3D: Flickies' Island | Sonic & Knuckles Collection | Sonic R | Sonic Shuffle | Sonic Advance | Sonic Advance 3 | Sonic Battle | Shadow the Hedgehog | Sonic Rush | Sonic Classic Collection | Sonic Free Riders | Sonic Lost World
Legacy Guides
The Nemesis Hacking Guides The Esrael Hacking Guides
ROM: Sonic 1 | Sonic 2 | Sonic 2 Beta | Sonic 3

Savestate: Sonic 1 | Sonic 2 Beta/Final | Sonic 3

Sonic 1 (English / Portuguese) | Sonic 2 Beta (English / Portuguese) | Sonic 2 and Knuckles (English / Portuguese)
Move to Sega Retro
Number Systems (or scrap) | Assembly Hacking Guide | 68000 Instruction Set | 68000 ASM-to-Hex Code Reference | SMPS Music Hacking Guide | Mega Drive technical information