• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Our weekly protagonist poll is now up! Vote for your favorite Kanto protagonist in the poll by clicking here.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register

Inserting Battle Backgrounds

DrFuji

DrFuji

[I]Heiki Hecchara‌‌[/I]
    • 1,691
    Posts
    15
    Years
    Hey everybody, this thread is collaboration between myself and karatekid552 that seeks to help people with the many facets of battle backgrounds in Fire Red. In this section I will walkthrough how to insert new backgrounds over already existing ones. In the next half karatekid552 will go into further detail about how the background table is structured and present a way to allow you to expand the table and change the active background through a single variable. We hope that you can learn a lot from this and will be able to insert and do all sorts of wondrous things with battle backgrounds afterwards.


    Tools Needed:
    • Nameless TileMap Editor (NTME)
    • Old version of Paint/ Photoshop/ GIMP/ An image-editing program of some kind that can work with indexed images
    • unLZ.GBA
    • A Hex Editor
    • Free Space Finder
    • An Emulator with a Fire Red ROM


    Starting off, make a back up of you ROM, it is very possible that things may not come out as originally intended.

    Firstly, we need to create a mock-up of the background we want to insert in Paint. In this instance I've decided to make a background for a generic grass battle. Here's what I want to insert in the ROM:

    Spoiler:

    The dimensions of this background are 240x112 pixels if you're interested. Some of you keen-eyed people may have noticed that I have more than the standard 15 colours plus a transparent colour as per usual in an indexed image. This is the case because I'll be taking advantage of a second palette that can be used when we are in battle – I will go further into this later.

    If you don't know whow to index an image then there are many other tutorials that cover this. For the sake of laziness length I would advise you to find another graphics tutorial that includes indexing.

    Anyway, now that we know what we want to insert, we need to make it more compact for the next step. We will need to remove as many 8x8 pixel tiles that have been repeated as possible. If we were to insert something the size of our mock-up above it would take up quite a lot of unnecessary space and possibly overwrite/ be overwritten by other graphics loaded in the RAM. Here's the tileset that I've compacted our background down to:

    Spoiler:

    While this tileset isn't optimalas there are still a number of repeated tiles it is close enough and has already significantly shrunken the filesize that will be inserted. There also appears to be an anomaly on the right hand side of the tileset, this is to do with the second palette that I mentioned earlier. I've lined up the colours in the tiles so they will directly match their places in the second palette. As this particular picture can only be made with fifteen colours (plus transparency) it has to look out of place for the time being. Nevertheless, this is what we're going to be working with.

    Now we're going to need to extract some things via unLZ.GBA (It is possible to insert a background without doing this step, but it makes everything easier). Open your ROM in unLZ and head to picture number 3. There you should see the tileset for the current grass background. Click 'Save As' and put it somewhere on your computer. Click 'Next' to arrive at picture number 4 which just appears to be a big jumble of random lines resembling television static. This is the tilemap for the grass background, it essentially tell our tileset how to arrange itself in-game to give us a full blown battlefield. To save it click 'RAW Dump' and then proceed to open up NTME.

    Spoiler:

    NTME is a program that allows you to create your own tilemaps to be inserted along with tilesets. For now just open up the two files you saved from unLZ and you should be able to be able to recreate the default grass background. To make it look like it should in-game select the dropdown menu underneath 'Size (Keep Ratio)' and select 32x64.

    Spoiler:

    But this isn't what we want – We want to aim higher and greater. Now we should open up the combination of our own tileset as well as the default grass tilemap. 99% of the time a message will pop up asking about whether some tiles should be replaced with the first tile in your tileset. Just say yes to this and move on. The result may look random, but that's only because we're working with old data (the default tilemap) so now we need to remake our mock-up from the beginning of the tutorial. Load your tileset and start painting! It is easiest to just follow what has already been done by mirroring the original tilemap which is why it is open now. After some work these are the before and after screenshots:

    Spoiler:

    But we've only got half the story in this screenshot, there's a lot more that has gone unseen here - NTME's viewing window can only show a fraction of what needs to be done. This actually what we have to make by manipulating the up/ down and right/ left scroll bars:

    Spoiler:

    Yup, it's just like an iceberg: most of the image's size lies beneath the water. A handy image that briefly covers what each part of the tilemap represents has also been included for your convenience.

    Once you've recreated your battle background we need to make sure it is using the correct palette. Select the 'PaletteMap' tab at the bottom of NTME and the viewing window should change to a series of numbers overlaying your background. These numbers indicate which palette the tiles will be loaded from when being played in-game. The only two numbers which we are interested in are two and three as they are what the game uses in its original backgrounds.

    This is the point where if you prepared ahead of time you will be able to add more than fifteen colours (plus transparency) to your background. In this background I have a large strip of background that isn't supposed to use the same palette as the majority of the background. There is a catch when it comes to adding a second palette though – It can only have a maximum of seven new colours. You will be able to see why this is the case later on, but for now know that you are restricting in how much you can add. Anyway, this is how my palette map will look, where palette two applies the full fifteen colour palette while palette three will only apply the restricted seven colour palette.

    Spoiler:

    And with that, we're finished making the tilemap for our background – Now it is time to insert both it and the tileset into the ROM. Reopen unLZ.GBA and head to the background of your choice. Once you're at your background's position select 'Import' and open your tileset. Select 'Write to ROM' and a second smaller window should pop-up; this is where we shall decide where the tileset will be inserted in the ROM. I'm going to be inserting the tileset at 0x720000 in the FR ROM as there is quite a lot of free space from there so I know nothing will be accidentally overwritten.

    Spoiler:

    Don't try to insert the palette accompanying the tileset at this point. Unlike other compressed images like Pokemon sprites, the proper palette isn't attached to the tileset in unLZ – We need to change it manually later. Now let's enter a battle and see how it's looking.

    Spoiler:

    Eww. To avoid seeing something Picasso vomited out during a hazy Friday night we have to insert the tilemap. Click 'Next' in unLZ and you should have returned to the tilemap from earlier. Rather than simply importing the tilemap like the tileset there is a slightly different method as it is not an image file (though unLZ is able to translate it into one). Select 'File > Load RAW' and select your custom tilemap. Now we just have to write it to the ROM in the exact same manner we did with the tileset. I've chosen to insert it directly after my tileset which means it will be located at 0x720400 according to HackMew's Free Space Finder.

    With both our tileset and tilemap inserted the background should be shaping up far better than before. This is what we get when we enter a battle now:

    Spoiler:

    Alright, that's looking much better – Our background actually has a recognisable structure now. We are now up to the final part of our insertion method, altering the palette. As you must have noted several times throughout this tutorial I have deferred talking about the background palettes for one reason or another. This was because it would have been quite jarring to interrupt with notes on how the palettes are structured as they differ from ordinary compressed and uncompressed palettes.

    The palettes which are assigned to battle backgrounds are made from two palettes, palettes 0x2 and 0x3 in your emulator's background palette viewer. Both of these palettes are highly interlinked as 0x3 borrows most of its data from 0x2 to save some space. This has caused them to appear fractured with a byte jutting out after every fourth word. For example, here's a screenshot of the original grass background palette in a HEX editor with each stray byte indicated:

    Spoiler:

    Thanks to this interlinking we cannot simply open up palettes in a palette editing program such as APE, even if it is instructed to uncompress the palette.

    There is one main way to find your palette. Search for the first string of four words of your background's 0x2 palette (I'll discuss palette 0x3 shortly). You can do this by entering a battle with your chosen background, opening the palette viewer and reversing the colour values (e.g 0x1234 becomes 34 12). In the last screenshot you can see this as the string '00 00 FC 73 D4 3F 90 3F' in front of the first marked byte. At this point you can just calculate the HEX values of your new palette and overwrite the current words but keep in mind the stray bytes - Leave them as they are.

    Now when we check our background in-game:

    Spoiler:

    Awesome, we're almost done. This part of the tutorial is only needed if you have chosen to utilise palette 0x3 in conjunction with 0x2. Since palette 0x3 is interwoven with palette 0x2 it is generally more garbled and difficult to find if you don't know what to do. Once you have found palette 0x2's location, palette 0x3 should be somewhere nearby, but you should only search for the NEW values that are present in 0x3. In my case, when I searched for the grass background's first two new values in palette 0x3 (92 37 4E 37) I found them at 0x24842B. Changes these values (once again looking out for any stray bytes) and save your ROM.

    Spoiler:

    Let's check out our final result:

    Spoiler:

    Congratulations, you have just inserted your first battle background!


    There are also some lesser know things you have to be aware of when inserting particular backgrounds.
    • The grass background also doubles as the background for when your Pokemon evolves. Be sure to not have an extra-large battle platform that stretches out into the centre of your tilemap in NTME otherwise it will be visible during the cutscene.
    • The Gym battle background is linked to the field and three other backgrounds. Their palettes are incredibly garbled and you would be lucky to get more than 7-8 colours out of them.
     
    Last edited:
    The Data Behind Battle Backgrounds


    Now that DrFuji has taught you how to edit Battle Backgrounds, I am going to take you into the data aspect. For right now, this lesson will just be for FireRed. If you do want it for another game and you are actually going to use it, I will attempt to do my best to help you.

    To start off with, apply the patch at the bottom of this post to your rom. What it does is move the battle BG table to 0xF10000 where we can work with and expand it, and it also hacks the BG loading routine with branches placed 0xF00000 (I will completely explain this later).

    The Table

    To be honest, the table is quite simple. To start off, it has 20 backgrounds already in it designated by Game Freak. They are as follows:

    1. Grass
    2. Grass2
    3. Sand
    4. Field
    5. Pond Sea
    6. Sea Pond
    7. Craggy
    8. Cave
    9. Multi/Indoor- White & Grey & some Yellow in the Palette (Normal Trainer Battle)
    10. Multi/Indoor- Green & a little Yellow (Rival Trainer Battle)
    11. Multi/Indoor- White & Grey ()
    12. Multi/Indoor- White & Grey & some Tan in the Palette ("Gym" Trainer Battles (that option in A-Map))
    13. Multi/Indoor- White & Grey & some Tan in the Palette (2) ("Gym" Gym Leader battle (yes the Leaders have different BG))
    14. Multi2/Indoor2- White & Grey
    15. Multi2/Indoor2- White & Grey & some Purple in the Palette
    16. Multi2/Indoor2- Blue & some Tan in the Palette
    17. Multi2/Indoor2- Yellow & Tan
    18. Multi2/Indoor2- Purple & some Tan in the Palette
    19. Multi2/Indoor2- Turquoise & some Tan in the Palette
    20. Multi2/Indoor2- White & Grey & some Purple in the Palette

    For each background, there are 5 pointers in order with this format:


    Code: 
    [CENTER]VV VV VV 08  WW WW WW 08  XX XX XX 08  YY YY YY 08  ZZ ZZ ZZ 08
 
VV = Image Offset
WW = TileMap Offset
XX = Entry Image 
(Ex. The Grass that moves in front of the screen at the beginning of a grass battle.)
YY = Entry Image Tilemap
ZZ = Palette[/CENTER]
    Here is the documentation of each background and their pointers in the original table:

    Spoiler:


    So, expanding this is really quite simple. Just follow the setup of the table and add on to the end. Don't delete any of them if you are not going to replace them. This may sound obvious, but you never know what people will do:p.


    So, I expanded it... Now what?

    This is probably what you are thinking after completing the above. This is where the hack of the loading routine that comes in. What it does is allows you to very easily change the battle background to whatever you wish.

    If you remember, all of the backgrounds are in order. If the first grass is 0, then numbering from there will give you the number of background, which means that background slots from 0 to 19 are already filled. So, let's say we add 4 more backgrounds to the end of the table: Fire, Snow, Storm, and Metal, respectively.

    The games coding does not directly allow access to these backgrounds, which is what the hacked routine does. Basically, it branches to a section of ASM that checks var 0x40F7. If this var is set to 0, it will automatically return to the regular routine and continue as normal. However, if it is set to any other number, the routine will operate from there and load the battle background of that number instead.

    So, if you set var 0x40F7 to 20, then the Fire background will be loaded. If you set it to 22, then the Storm bg will be loaded, and so on. This will stay until you change it to something else. In order to return to the normal background for that map, then you simply set the var to 0.

    Please note that this routine overrides every type of battle. This means you can change trainer battles, sea battles, grass battles, cave battles, etc, all by setting that one var. Also, the routine loads a half-word, not a byte, which means that you can have up to 0xFFFF backgrounds in the table, which is a little over 65,000. Granted, there isn't enough space in the rom to have unique backgrounds in each slot, but don't worry about over expanding the table. You won't have a problem there.:)

    Well, that about wraps this up. Originally I had planned to give you the ASM routines and explain how to use them, but that got overly complicated with the branches, so I made it really simple with the patch.






    Also, I did my best to make this compatible with both JPAN's engine and Jambo51's 649 patch. I haven't tested it on either, but I asked Jambo if there would be any complications or things I should avoid and the only thing he gave me was which var to use since he had used a few. For JPAN's, I avoided using any RAM that he used (which didn't matter in the end because Jambo had me switch to a var) and I don't think he had any routines and such that would affect this.


    In order to make this even better for people, on case you have already used the free space at 0xF00000, I have included the source code here:


    You can do as you wish with this code.

    EDIT: Courtesy of Zeturic, here's the source code designed to work with armrips.


    If there are complications, please let me know!



    ~Credits!

    Driver - Driver was an old-time German hacker whom originally accomplished this for his own hack. Instead of using a var, he freed up some RAM and used that. About two months ago, I received a rom and some notes of his from Narutoactor via Tajaros. It took me a while to make heads or tails of them, but once I did, I set out to port it over to English FireRed and this was the result! So, most of the credit goes to him!

    Jambo51 - A HUGE help in making this. He taught me how to access vars and answered a lot of questions. I know he hates people bugging him with questions, so I really appreciate him not ignoring me!

    Darthatron - For being a really good friend and giving me a lot of help. When I was stuck and didn't have access to the var_access routine due to being on the go, but I still wanted to write up the ASM for it, he Pastied it me and I got a lot done. As usual, he also answered a lot of questions and was really helpful.

    Mat - While I didn't end up using it because I switched to a var, Mat spent over an hour helping me try to find some free save-able RAM for this project. I really appreciated the time he gave me as we explored the save blocks and got almost nowhere, but he stuck with me until he had to go, so I have to give him a huge thanks!

    Tajaros (Not Shadowraze, this was before the switch:p) - For starting this whole project by sending me all of Drivers stuff and asking for my help in deciphering it. He also decoded a lot of the table and documented the first 9 backgrounds before I even started working, which was a huge help.

    Narutoactor - For sharing all of Driver's research, and attempting to help me contact Driver which, unfortunately, never happened:(.

    Lastly, DrFuji - For digging into the archives and redoing his old private bg editing tutorial and completely rewriting it to go along with this research to make this ultimate guide to hacking battle backgrounds.


    Well, that is all for now! On to the next project.... !

    ~karatekid552
     
    Last edited by a moderator:
    Congratulation! If I can learn this,I am sure will give credit to both of them.This is what the thing I wanted to know.Well many people will find this useful for sure.
     
    Wow, this is great! I was just wondering how to change that stuff lol.

    Question though: you mentioned that there was an offset for the grass that moves across the screen before a battle begins. Is there any way to edit this?
     
    Is there right now anyway for the tilemap autoinserted from a tile map? Or is it going to be tedious?
     
    NarutoActor said:
    Oh wow I never knew the research came into fruition, that is really awesome. I have so many backgrounds I will love to try and insert, good job guys! :D
    Click to expand...

    Did I REALLY forget to tell you?!?! I told Taj... i mean ShadowrazeXD, but I can't believe I forgot you. I'm sorry man.:( but anyways, yeah, thanks!!!
     
    L96 said:
    How can I change it through Pokemon Ruby?
    Click to expand...

    SWI 0x12 is LZ Decompression. Using the logging feature in VBA, log that as the battle starts. You will get a list of all calls to an SWI. Some will be LZ decompression with an offset after. That offset is for an image. Go there in a graphics editor until you find the right one.

    BGs are the same on all advance gen games, just in different locations, so use the logging feature to find one in ruby, then search for its pointer in the rom and you will find the table I talk about in my post. This table will tell you all you need to know about palettes, bgs, raws, EVERYTHING.:)
     
    karatekid552 said:
    SWI 0x12 is LZ Decompression. Using the logging feature in VBA, log that as the battle starts. You will get a list of all calls to an SWI. Some will be LZ decompression with an offset after. That offset is for an image. Go there in a graphics editor until you find the right one.

    BGs are the same on all advance gen games, just in different locations, so use the logging feature to find one in ruby, then search for its pointer in the rom and you will find the table I talk about in my post. This table will tell you all you need to know about palettes, bgs, raws, EVERYTHING.:)
    Click to expand...


    I'm confused e_e can you make a tutorial for ruby? please!
     
    L96 said:
    I'm confused e_e can you make a tutorial for ruby? please!
    Click to expand...

    Everything is the same, just the offsets are different.

    How to find offsets:


    1) Go into tall grass in VBA-M.

    2) BEFORE the battle, go into Tools-> Logging.

    3) Check the box "SWI" and then click "Start".

    4) Close that window.

    5) Enter a battle.

    6) Once the battle bg has loaded, go into the logger and save all of the junk that was there to a txt file.

    7) Open that txt file in Notepad.

    8) Hit "CTRL+F" and type this:

    If you see a lot of CPUSets: type "LZ" in the box.

    If you see a lot of SWI 0x8, type "SWI 0x12" in the box.


    9) Click "Find".

    You should now be brought to either an SWI 0x12 or an lz decompression (same thing, just different ways of writing it.)

    10) Now, look for an 4 byte hex number that looks like 0x08XXXXXX just to the right of the text we found. This is the offset of an image that was decompressed.

    11) Go into an image viewer like NSE 2.X or GBA Graphics editor and go to that offset.

    12) Is this a bg???? If no, repeat steps 8 -> 12 until it is. If it is, continue:

    13) Take that offset, and reverse it:

    So, 08XAYBZC -> 08 XA YB ZC -> ZC YB XA 08.

    Ex. 08 12 34 56 becomes 56 34 12 08.

    Search that in a hex editor. Now you have found the table I talk about in my post. Cool.

    That is
     
    Is there a byte somewhere in the map header which dictates what battle background is being used? I would like to know which background will show up in a trainer battle or something :)
     
    kearnseyboy6 said:
    Is there a byte somewhere in the map header which dictates what battle background is being used? I would like to know which background will show up in a trainer battle or something :)
    Click to expand...

    Ummmm, I believe it is dictated by the tile you are standing on. Also, why not just test it? Go into a trainer battle and see which bg is being used.
     
    I'm sure folks have probably asked about this somewhere, or it's covered it in a tutorial, but thanks to my brain damage and dodgy eyesight I'm having trouble finding the solution to my problem.

    The problem:
    I have inserted the Yellow version Pokemon sprites into my EEVEELUTION hack (uses Fire Red as its base) and the fronts, for the most part, are fine; however, the transparency of the back sprites clash with the battle fields... resulting in them being visible through the sprites.

    It's really off-putting when you're having a battle and you see grass etc. through your Pokemon; I was wondering if there were any way to remove the battle fields altogether, or change all of them to the indoor field type used in Oak's lab etc.?

    Also, I have absolutely no idea how to hex edit roms; so if I have to do that some advice, or directions to a hex editing tutorial, would be greatly appreciated too.
     
    KosmoF said:
    I'm sure folks have probably asked about this somewhere, or it's covered it in a tutorial, but thanks to my brain damage and dodgy eyesight I'm having trouble finding the solution to my problem.

    The problem:
    I have inserted the Yellow version Pokemon sprites into my EEVEELUTION hack (uses Fire Red as its base) and the fronts, for the most part, are fine; however, the transparency of the back sprites clash with the battle fields... resulting in them being visible through the sprites.

    It's really off-putting when you're having a battle and you see grass etc. through your Pokemon; I was wondering if there were any way to remove the battle fields altogether, or change all of them to the indoor field type used in Oak's lab etc.?

    Also, I have absolutely no idea how to hex edit roms; so if I have to do that some advice, or directions to a hex editing tutorial, would be greatly appreciated too.
    Click to expand...

    The second part of this tutorial deals with controlling battle backgrounds.....

    theRiolvile2 said:
    I did everything you did and mine turned out like this:


    [PokeCommunity.com] Inserting Battle Backgrounds
    Click to expand...

    Never saw this post, but I can't see the image either way. Could you post it again?
     
    Last edited:
    You must log in or register to reply here.
    Back
    Top