![]() |
Advanced Over World Sprite Editing: Part 2
After some discoveries, I asked Darthatron if I could finish his old tutorial on Advanced OW Sprite Editing and he said yes. I recently fully discovered how the routine works which controls how many OWs you can have and I plan on sharing with you how to increase this limit.
However, first, here is the original tutorial who's thread was closed a while back with a little updated commentary from me. I will also include the offsets for the main english roms Ruby and Emerald. If you need more offsets and you can't find them on your own, just let me know. Quote:
http://i1322.photobucket.com/albums/u563/karatekid552/0a64141c92eb4b52523365e88120d5ed_zps7f7d54de.jpg [I would like to apologize for this being an image. I wanted code it as a table, but it appears the table system for PC has a few bugs, so I couldn't.] I would also like to note that to use the increased OWs with an OW editor, I would suggest using NSE Classic since it reads from the table we just repointed, and not the secondary sprite table that OWERE uses. To use your new sprites, create an .ini file (instructions for this are in the NSE readme file) and point it to your new table. Then, open NSE and under options choose "Advanced Mode". From there, go back under options and turn the boundaries off. This was a major feature lacking from OWERE. Instead of this, it just gave the "subscript out of range" error. Part 2. Now that you know how to increase the amount of overworlds by repointing that nice big table, we need to take a look at what I like to call "OW limiters". In all Advance Gen games, there is a special routine that is carried out when an overworld is loaded onto the screen. This routine checks to make sure that the OW is a part of the table. If not, instead of letting the game crash, it just reroutes the loading routine to use OWs from earlier on in the table. For those of you ASM enthusiasts, here is the routine that runs said checks in Ruby and FireRed. they are almost identical but Emerald is a little different, so we will discuss it later on: Ruby Code:
Code:
In Ruby, there is a total of 218 OWs (counting #00). If you notice, the second cmp command checks if the number in r1 (which is the OW number currently being loading loaded onto the screen using the hex equivalents for the numbers in NSE) is less than or equal to 0xD9 or decimal 217. In FireRed, this cmp is to 0x97 or decimal 151 and will branch only if less than or equal. This proves what I commented earlier being that there are 152 OWs because it is comparing to the numbers in NSE, in which the S.S. Anne is #151. So, as you can see, that check was pretty basic. It was just the maximum number of OWs. But what about those other two? They both cmp for 0xEF (240) in both Ruby and FireRed, but what could they possibly do? After a lot of research, I finally understand how these are used. They allow for Dynamic OWs; OWs that can be placed on the map and then later modified to be something different. These checks make it so that OWs #240+ are dynamic in nature. Some main examples of how these are used would be the sprites in the Union Room in FR and how secret bases are done in RSE. I will discuss how we can use these to our advantage in Part 2.5. So, what if you don't know all of this fancy ASM stuff? What do you do? It is actually pretty simple. Open up our trusty Hex editor and change the following three offsets to the hex value of the number of OWs you want to have up to 239. If you want anything higher, you will have to deal with Part 2.5. Ruby(AXVE) •0x5BC28 FireRed(BPRE) •0x5F2E0 *If you need offsets for different versions, just let me know. I will get them. Now you have done it! You've successfully increased the amount of OWs in Ruby and FireRed. Yay! But what if you have Emerald? I never want to leave any hackers in the cold, which is why I try to write my tutorials to support as many games as possible. In Emerald, the routine is fairly the same. However there is an extra ripple I want to make you aware of. Here is the routine: Emerald: Code:
As you have probably noticed by now, this routine has four checks. I can tell you that the 1st, 3rd, and 4th checks match up in the same order that they do in Ruby and FireRed. But what about that second check? After some guessing and playing, I figured it out. It checks specifically for this guy's sprite: http://i1322.photobucket.com/albums/u563/karatekid552/69_0_zpse8bb40f7.png In all of the other games in which he appears, his sprites were kept together. However in Emerald, there is only one usable sprite: #69. The other ones are at the end of the table, above the old limits, and auto default to other sprites when used in game. When you use sprite number 69, it activates a section of the OW loading routine that allows the sprite shown on screen to be changed (to one of his other colors at the end of the table) depending on certain conditions such as his location in the game (bank and map number) and the data of your save file. In theory, this check could be used to create OWs that could be randomized, and ideally, unique, per game save. I don't know if it can be done, but it definitely would be a cool feature. So, when you are expanding your OWs in Emerald, keep this guy in mind and try to leave his sprites in order and when you change one, change them all. He is the only NPC sprite to vary like he does, so it is kind of cool.:) As I said before, the other three checks work exactly as they do in Ruby and FireRed so here are the offsets that need to be changed in Emerald to the number of OWs you want to have. Since Emerald has 246 OWs already, your best bet is to just go straight for 255 and change the main limit locations to 0xFF, but remember, since this goes over 239, you will have to deal with Part 2.5: Emerald(BPEE): •0x8E6C4 Now you know how to get the most OWs possible without having problems with the dynamic ones in the major Advance Gen games.:D Have fun! Part 2.5: Dealing with Dynamic Over Worlds Above you learned that in RSE, OWs 240+ are used for secret bases. If we change their checks, then it prevents your dolls and cusions from being used in your secret bases. So, Darthatron and I worked out a way to fix this. I suggested just checking if you were in a secret base and then running the original routine if that was true. He found where the secret base byte was and I tried writing a nice routine. I failed miserably after 2 hours of hard work, lol. Then, Darth wrote up a routine in 10 minutes to fix it. (I guess I need some more practice, haha) What his routine does is it just skips the checks used for secret bases when you are not in them. After we worked out the bugs in Ruby, I ported it over to Emerald. Simple, but effective. There are only 3 problems (2 of which I provide a fix for): 1) Outside of S.B.s, sprite 240 is the always the opposite gender of the player making it the rival sprite. I don't have a fix for this yet. You can still do it the old fashion way by having two different sprites on the map and only showing the relevant one. 2) A-map loads the OWs by searching for the routine that comes just before the pointer. This fix changes that routine, which means A-map won't be able to load the OWs without a change to the .ini file. I will provide this change attached at the end of this post. My best suggestion is to make a second copy of A-map that will use this .ini so that you won'thave to keep switching them out. 3) This one is really simple; your player's rooms are not secret bases, so the decorations won't be diplayed correctly. Just change the map type in A-map to "Secret Base" for those 2 rooms and you should be fine. With the above mentioned, let's move on to how to apply this hack. If you are decent with ASM, then feel free to do it yourself. Here is the source code: Spoiler:
However, most of you will look at the above and go, "Say what?" So, I will simplify it for you. ~Ruby Fix (AXVE)~ 1) Paste both of these lines of code somewhere in the free space of the rom using a hex editor: Routine prt1: Code:
Code:
3)Now, we shall make these changes: ---------------------------- @5BC12-> change "00 06 01 0E" to "09 49 08 47". @5BC36-> change "02 BC 08 47 00 00" to "00 BD XX XX XX XX" where XX XX XX XX is the pointer to the location where you placed "Routine prt1 + 1". @5BC42-> change "04 1C 60 79" to "18 4C 20 47". @5BCA2-> change "01 BC 00 47 00 00" to "00 BD XX XX XX XX" where XX XX XX XX is the pointer to the location where you placed "Routine prt2 + 1". ---------------------------- ~Emerald Fix (BPEE)~ (yeah, I just copied and pasted the Ruby part and changed the offsets and data;p) 1) Paste both of these lines of code somewhere in the free space of the rom using a hex editor: Routine prt1: Code:
Code:
3)Now, we shall make these changes: ---------------------------- @8E696-> change "00 06 01 0E" to "0F 49 08 47". @8E6D2-> change "02 BC 08 47 00 00" to "00 BD XX XX XX XX" where XX XX XX XX is the pointer to the location where you placed "Routine prt1 + 1". @8E6DE-> change "04 1C 60 79" to "18 4C 20 47". @8E73E-> change "01 BC 00 47 00 00" to "00 BD XX XX XX XX" where XX XX XX XX is the pointer to the location where you placed "Routine prt2 + 1". ---------------------------- And now, you're done! Not so bad huh? Remember to change your A-map .ini (best to just create a second copy of A-map to use it), that the rival sprite won't work (Maybe I'll find a fix:D), and to change your rooms' map type to Secret Base. Dealing with FireRed In FireRed, I mistakenly assumed (you know what they say about assuming:p) that we wouldn't have any problems because we don't have secret bases. I was very wrong. The Union Room definitely uses dynamic OWs and it is most likely also the case when it comes to the trainer tower. So, I have created another port of the Ruby routine for FR. This routine, like the others will only allow the dynamic OWs to be dynamic on maps whose type is 09 (secret base). On any other map, these OWs will act like regular OWs, just showing up like you see them in NSE. Here is the source code: Spoiler:
-Just as a side note, when I was porting this routine, I noticed that, besides offsets, both routines are exactly the same. Just a little bit more proof for the argument that FR is a heavily modified version of Ruby.:p- Once again, I know you probably don't understand much of that fix, so I will dumb it down a lot: ~FireRed Fix (BPRE)~ -Just as a fair warning, I did not test this routine since it was all just offset changes from Ruby. I have double-checked all of the offsets, so it should work. If you have a single problem, be sure to let me know. 1) Paste both of these lines of code somewhere in the free space of the rom using a hex editor: Routine prt1: Code:
Code:
3)Now, we shall make these changes: ---------------------------- @5F2CA-> change "00 06 01 0E" to "09 49 08 47". @5F2EE-> change "02 BC 08 47 00 00" to "00 BD XX XX XX XX" where XX XX XX XX is the pointer to the location where you placed "Routine prt1 + 1". @5F2FA-> chnage "04 1C 60 79" to "18 4C 20 47". @5F35A-> change "01 BC 00 47 00 00" to "00 BD XX XX XX XX" where XX XX XX XX is the pointer to the location where you placed "Routine prt2 + 1". ---------------------------- Also, if you notice any other areas where the sprites do not appear correctly, try changing that map type to 09 (secret base) in A-map. Places like the Battle Tower/Frontier most likely use dynamic OWs. If you find a location not listed here, feel free to comment with it. I will try and make a list of all of the locations. --On a final note, Advance Map was never designed to support expanded OWs, therefore, it is highly likely that your sprites will not show up properly in A-map.-- Well, that should be it, Good Luck! ~Credits:~
Locations that need to be changed to map type Secret Base: Quote:
|
why dont you use the tool overworld changer?
|
Quote:
That being said, I included the original tutorial becuase Part 2 makes a lot more sense when you have Part 1 right in front of you. The is no tool, or even documentation, that people can find on what is covered in Part 2. -------- I would like to say that last night me and Darthatron began working on a branch from the original routine in order to allow the use of OWs over 240 with secret bases. Hopefully we can get it done, and then you can have both.:) |
But the overworld changer tool is much quicker and better to resize the overworld sprites.
|
Quote:
Might I ask why that tool is better? Quicker, sure. But why better? |
Quote:
Finally, this is the biggest kicker. You can't repoint more than one OW at a time, otherwise it just overwrites the image space you used for the last one. This is definitely not good if you need to get a large number of OWs resized at once. Also, did you even read my post???? Daratron's tutorial is in there so that Part 2 fits with Part 1. I know there are tools for it. But his was written before them. It also teaches you how OWs are stored and work, which is extremely important for knowing how to make things go the way you want when you start thinking outside the box, for example making huge OWs like the S.S. Anne which you cannot do in a tool. None of them will let an OW exceed 64x64, but yet some have to be. My tutorial is about changing the number of OWs in total, something that not a single tool can do, (except JPAN's hacked engine, but that is only for FR 1.0). If you think I'm being a jerk, you'll understand when, as Darth stated, you actually dig into the code and do some real hacking. Tools are how you start off, but the best parts of hacking, the ones that take you over the top, there is no tool for. Take this lesson to heart. It is one that took me a while to learn, but it is amazing what can be done once you leave the "blockyness" of tools behind. I love them, don't get me wrong, but if they are all you use, your hack will never excell. Now Darthatron, let's get that secret base routine patched up. First we need to find where the map header is stored. I'm thinking of saving the RAM and searching it for the header that is found in the rom. Good idea? |
you might be right karatekid....i accept that tool is buggy....
|
Quote:
|
bUT Karatekid this turiotial is hard!!!! please try and make a tool as soon as possible
|
Quote:
On a scale of 1-10, my programing skill is a 0.1. I just started. I know it is hard, but real rom hacking is hard. Here are two quotes I really want you to ponder on: Quote:
Quote:
|
Now that that is over, I bring great news!!!!!! Me and Darth (96% Darth actually:p) have solved the problem of secret bases in Ruby. I have a completely running copy with 256 OWs and fully functional secret bases sitting on my desktop right now!!:D As soon as I port it over to Emerald, I will edit the tutorial to teach you how to fix it!
Edit: I finished porting the routine today. I haven't had a chance test it, but once it is confirmed, I will update this tutorial. |
On other news, I am testing the ported routine right now!
Edit: It appears to work well, however, I forgot that you can place decorations in your room...... I wonder if we can just change your room to secret base and have it work fine.... Edit2: yup, that is a fix. But I found one more problem:/. With this hack aplied, A-map gives the error: The position SpriteHeader could not be found! Any ideas? I didn't move the location of the pointer to the sprite bank.... Edit3: Searching through the .ini I found that it appears to search for the routine which I just edited, which allows it to know where to load sprites from:/. I'll find a fix for this, I just hope I don't have to edit the .ini because then clean roms won't work of any kind due to the fact searches for the same SpriteHeader in all of the games, it is just one line in the ini:( |
UPDATED!!!!!
I finally finished part 2.5 which will allow people to fix the Secret Base issue in RSE. Maybe I will get around to looking into a fix for the rival sprite issue, but it isn't a priority. I will see what I can do. Have fun maxing things out! Lastly, in case anyone is wondering, me and HackStar worked everything out. |
I cant seems to understand your part 2.5,...but anyway I will give try at least if I can
|
Quote:
|
Is there a way to add more OW-palettes without JPANs hacked engine?
|
Nice Job Karatekid!!! And I'm glad you figured out the secret bases in r/s/e.
I really love reading advanced tutorials like this, as they help understand things in detail rather than using some tool, in this case OW changer. Hoping for some more tutorials like this (: |
Quote:
Quote:
------ I also just learned, that while FR doesn't have secret bases, it does have the union room, which won't work properly (I think) with my (Darth's, lol) routine as it uses the variable sprites over 240. This needs more research though, and I don't know if anybody really needs the union room... Lol Edit: Due to the above and some more thoughts about the OWs over 240, I am going to need to rework a lot of my tutorial to account for it. Please keep an eye out for it. |
oh!!!then what will happen if i incase dont follow part 2.5
|
Quote:
edit: I am in the proccess of redoing Part 2 and 2.5 in an effort to completely prevent any problems with the dynamic OWs. I just need to finish porting the routine to FR. What could really help me is a list of maps in Ruby, Emerald, and FR that have OWs which use sprites 240+ as these will be dynamic. ~~~~~~~~~~~~~~~ Updated! I redid most of Part 2 to flow better into 2.5 and added a section for FR and a list of possible locations for dynamic OWs in all of the games. I also posted an updated A-Map Ini to support FR. |
Can someone make a tool for adding new OW?
|
Quote:
|
I cant' find NSE's ini file anywhere. I don't exactly know how to tell the table what i repointed
|
Quote:
|
My god.. you're a hex person.
pretty much, I'll try to understand the whole thing before I do everything. |
Quote:
|
I'm so confused. It's gonna take me years before I fully learn Hex Editing.
|
I know that's a really old topic but I think this part should be included in the main post since it's very important to make resized overworlds work correctly.
Quote:
|
When I edit rival's OW (I changed it to a nds style one, bigger), the rival's OW of the introduction is buggy (when we wrote rival's name). It's due to the resize of the OW and it seems to be store differently than a normal OW. Is there someone who know where it is stored?
|
| All times are GMT -8. The time now is 9:02 AM. |
![]()
© 2002 - 2018 The PokéCommunity™, pokecommunity.com.
Pokémon characters and images belong to The Pokémon Company International and Nintendo. This website is in no way affiliated with or endorsed by Nintendo, Creatures, GAMEFREAK, The Pokémon Company or The Pokémon Company International. We just love Pokémon.
All forum styles, their images (unless noted otherwise) and site designs are © 2002 - 2016 The PokéCommunity / PokéCommunity.com.
PokéCommunity™ is a trademark of The PokéCommunity. All rights reserved. Sponsor advertisements do not imply our endorsement of that product or service. User generated content remains the property of its creator.
Acknowledgements
Use of PokéCommunity Assets
vB Optimise by DragonByte Technologies Ltd © 2023.