Show Posts
46
Maps In Progress / Re: Troy's Junk and Stuff
« on: June 07, 2012, 09:14:53 pm »
The Sword of Mana maps have been bugging me since they were finished. The main point of irritation comes from the scenes being incomplete. Some games restrict camera movement while others have the camera follow the actor no matter what. Games that restrict the camera have to have a way to tell when the camera should stop scrolling, right? Games will usually store this in an easy to find location where the value is the minimum or maximum coordinate allowed for the camera. Sword of Mana was just a bit different.
How Sword of Mana Is Different
Sword of Mana doesn't use a simple system for restricting camera movement, or at least that's what I thought after hours of perusing it's memory. For the life of me I could not find the values for the restrictive camera coordinates. Then, I noticed a pointer at 0201C98C. The problem with this pointer was that it pointed to the ROM portion of the memory. For those that don't know, if you change a value in the ROM portion of memory you actually change the ROM itself. If you are not careful you can permanently damage or corrupt your ROM. So, I quickly made a copy of my ROM and headed to the address being pointed to.
Upon arrival, I immediately noticed the pattern of bytes presented to me. The pattern told me that each "block" of code was 24 bytes in length. The blocks weren't too complicated looking, as some of the bytes were zeroes, meaning they didn't do anything. My brain being the way it is, I noticed another pattern in this specific block. There were two bytes, one was 0F and the other was 03. These values stood out because of the following: the scene I was looking at had minimum camera coordinates of 120 on the x-axis and 24 on the y-axis. See the correlation yet?
0F, of course, equals 15 in decimal. 15 multiplied by 8 equals... 120. Omg. Did I just find the location of the camera restriction? Let's check the other one. 3 multiplied by 8 equals... 24! Yes! I found it! Oddly, I had to edit the ROM directly but I'll take what I can get. By the way, the 8 from earlier is a very basic value in most things. I just it because the size of tiles in most games is 8 pixels by 8 pixels. So, in essence, 0F means 15 tiles from 0.
So, now that I found that I went in to capture the rest of the scenes. I set both values from earlier (0F and 03) to 00 so that the camera will be able to go to the very minimum point. When I reloaded the area, I could indeed move the camera past the previous restrictions (YES!) but another problem arose. The camera could now no longer move south as far as it could before. Weird. I took another look at the block in the ROM and checked out the next two values past 0F 03. They were 2C and 20. Using the method from before, I multiplied both values by 8 and came up with 352 and 256, respectively.
From this, I deciphered that the first set of values (0F and 03) determined the minimum tile the camera can move to. The second set of values, 2C and 20, determined the size of the area. Added together like so: 352 + 120 = 472, 256 + 24 = 280, these values determine the maximum tile the camera can move to.
Now, I already knew the total size of the area was 480 by 288 from before. The values I calculated seem to be 8 pixels off on each axis. For the second set of values, I figure if I set them to 00 it would mean one tile and not zero tiles. That actually gives me another tile (or 8 pixels) to add on the totals. Finally, I arrived at 480 by 288.
This is fantastic! I can now capture all the missing areas in each scene.
Here are some screens that show the values:
Example of the difference:
How Sword of Mana Is Different
Sword of Mana doesn't use a simple system for restricting camera movement, or at least that's what I thought after hours of perusing it's memory. For the life of me I could not find the values for the restrictive camera coordinates. Then, I noticed a pointer at 0201C98C. The problem with this pointer was that it pointed to the ROM portion of the memory. For those that don't know, if you change a value in the ROM portion of memory you actually change the ROM itself. If you are not careful you can permanently damage or corrupt your ROM. So, I quickly made a copy of my ROM and headed to the address being pointed to.
Upon arrival, I immediately noticed the pattern of bytes presented to me. The pattern told me that each "block" of code was 24 bytes in length. The blocks weren't too complicated looking, as some of the bytes were zeroes, meaning they didn't do anything. My brain being the way it is, I noticed another pattern in this specific block. There were two bytes, one was 0F and the other was 03. These values stood out because of the following: the scene I was looking at had minimum camera coordinates of 120 on the x-axis and 24 on the y-axis. See the correlation yet?
0F, of course, equals 15 in decimal. 15 multiplied by 8 equals... 120. Omg. Did I just find the location of the camera restriction? Let's check the other one. 3 multiplied by 8 equals... 24! Yes! I found it! Oddly, I had to edit the ROM directly but I'll take what I can get. By the way, the 8 from earlier is a very basic value in most things. I just it because the size of tiles in most games is 8 pixels by 8 pixels. So, in essence, 0F means 15 tiles from 0.
So, now that I found that I went in to capture the rest of the scenes. I set both values from earlier (0F and 03) to 00 so that the camera will be able to go to the very minimum point. When I reloaded the area, I could indeed move the camera past the previous restrictions (YES!) but another problem arose. The camera could now no longer move south as far as it could before. Weird. I took another look at the block in the ROM and checked out the next two values past 0F 03. They were 2C and 20. Using the method from before, I multiplied both values by 8 and came up with 352 and 256, respectively.
From this, I deciphered that the first set of values (0F and 03) determined the minimum tile the camera can move to. The second set of values, 2C and 20, determined the size of the area. Added together like so: 352 + 120 = 472, 256 + 24 = 280, these values determine the maximum tile the camera can move to.
Now, I already knew the total size of the area was 480 by 288 from before. The values I calculated seem to be 8 pixels off on each axis. For the second set of values, I figure if I set them to 00 it would mean one tile and not zero tiles. That actually gives me another tile (or 8 pixels) to add on the totals. Finally, I arrived at 480 by 288.
This is fantastic! I can now capture all the missing areas in each scene.
Here are some screens that show the values:
Example of the difference:
