# Introduction ## Introduction **If you’re reading this,** you are probably an aspiring rom hacker who thinks it would be **really cool** to make a Fire Emblem game. Maybe you’re a bit intimidated by how much there is to learn, but you’ve decided to **give it a shot** anyway. Lucky for you, you’ve come to the right place. FE hacking is one of the most **enjoyable** and **rewarding** hobbies I’ve come across, and the community is friendly, welcoming, and filled with amazingly talented people. The original **Ultimate Tutorial** by Blazer was and is a fantastic resource for anyone who wants to get into Fire Emblem romhacking. However, it has not been updated since 2013 and is primarily aimed at FE7 hacking. Since then, there have been some **significant advances** in rom hacking. The hacking process is very different from what it used to be, both in terms of tools required and also how projects are managed. This guide aims to be an **all-in-one** tutorial for all steps of the hacking process, with a particular focus on managing a **complete project** rather than making individual changes. Most parts of this guide are applicable to both FE7 and FE8, and to some extent FE6. This guide is a **work in progress**, so for the moment it is assumed that you are hacking FE8. If you have questions that are not covered by this guide or Google, please visit [**Fire Emblem Universe**](http://feuniverse.us). # Getting Started *Note: Many of the tools you will be using are made for Windows. If you have OSX or Linux you may want to consider a VM or Dual Boot setup.* First, you will set up your **project folder**. Create a new folder wherever you want, and name it your project name. **Note: Do not use special characters such as "`[]+-`" in your folder name.** ## For the rest of the tutorial, I will refer to this folder as **Root**. Next, download the latest version of [**Event Assembler**](http://feuniverse.us/t/event-assembler/1749?u=circleseverywhere) from FE Universe, and place the folder in Root. You will also want a **Hex Editor** of some sort installed on your computer. This does not need to be in the Root folder. **HxD** is a good, free hex editor that is more than enough for our purposes. Although you can get away with using plain old Notepad, a good text editor such as Notepad++ or Sublime Text will make your life much easier. Personally, I'm quite partial to Sublime Text thanks to its [syntax highlighting for Event Assembler code](http://feuniverse.us/t/syntax-highlighting-for-event-assembler/2131?u=circleseverywhere). Create a new, empty **text file** in Root. Name it `ROM Buildfile.txt`. This simple text file will become the ***backbone of your entire project.*** Finally, place your **clean ROM** in Root. Mine is called `FE8_clean.gba` but you can substitute whatever yours is. ## Your **folder structure** should look like: > * `Root` > * `Event Assembler` > * `ROM Buildfile.txt` > * `FE8_clean.gba` Now you’re ready to get started! # Aside: Editing a ROM If you've done any ROMhacking before, such as in another community or even by following older FE tutorials, you may be used to the idea that your *Working ROM* is your entire project. In fact, many of the older tools you may see people refer to, such as FEditor or Nightmare are designed to modify a ROM *in-place* -- that is, you change something, hit save, your old ROM is gone and an edited ROM has taken its place. This is akin to how most real file editors work (open file, edit, hit save). This is *not* how our project is going to work. Those of you who've worked with gigantic projects before may have spotted an issue with the old process. Namely, *what if I mess up*? This isn't so much of a concern for, say, word documents, as you can undo, copy-paste, whatever to restore your older version and fix mistakes. This is not so true for ROM hacking, where our ROM can be modified by all sorts of tools, often in more ways than we even realize. Mistakes can go undetected for weeks or even *months* of work, resulting in one of two scenarios: 1. Restore from backup (assuming we even have one), necessitating those weeks and months of work be redone onto the fixed ROM 2. Attempt to fix in-place, requiring possibly hours of research and debugging to even *find* the bug, as well as potentially introducing more errors when a fix is hacked on. Needless to say, this is often a painful experience, and can even cause a project to slow or stop entirely. Instead, we're going to be rebuilding our project from scratch, every time we change anything. ## "Wait, what?" Yeah, you heard me! *Every time we make a change to the project, we're going to be remaking the new ROM from the raw base*. Not by hand, of course. The key to all of this is that *buildfile* you just made. As the name may suggest, this buildfile is a *file* that says how to *build* our project. So if we want to change the project, we just have to change the buildfile! This means we get to take advantage of easy undo operations, human-readable changes and even more advanced things like [Version Control](https://github.com/FireEmblemUniverse/CCB_Round1)! Fixing an old mistake is as simple as changing a few lines in our buildfile (or its `included` files -- we'll get there). Those of you with programming experience may realize that our buildfile is our project's *source code*, and Event Assembler is our *compiler*. This way, the project folder *is* our entire project, *not* the output ROM. # Buildfile Basics ## Baby's First Buildfile Open up `ROM Buildfile.txt` and paste: ``` #include eastdlib.event ORG 0x1000000 ``` *Wow, what a great buildfile!* What does it do? Let's find out with an **example**! ## Hello, World! Create a **new text file** and type: ``` String(Hello World!) ``` Now **save** that in Root as `Hello World.txt`. Go back to your `ROM Buildfile.txt` and add this to the bottom: ``` #include "Hello World.txt" ``` Now it's time to **assemble**. **Save** `ROM Buildfile.txt`, take your clean ROM and **make a copy** of it. We'll edit this copy so that we always have a clean ROM available in case something goes wrong. ![Event Assembler Window](http://puu.sh/ryp0V/59e19685bf.png) In the **Text** field, select `ROM Buildfile.txt`. Set the **ROM** as the copy you made earlier. Make sure Game matches the one you're working on. When that's done, click **Assemble**! You will see a friendly message: > "No errors or warnings. Please continue being awesome." Perfect. But what did it actually do? Open up the ROM in **HxD**, press *Ctrl-G* and type `1000000` as the offset, ensuring that the `hex` option is selected. ![Hex Editor View](http://puu.sh/ryUig/6763a68df3.png) You should see a bunch of numbers, but on the right side you can see that they translate to `Hello World!` **Congratulations, you inserted some data!** But this is just the beginning of what buildfiles can do... ## Understanding #include What does `#include "some/file.txt"` do? Basically, it inserts the entire contents of `some/file.txt` in place. So in our ROM Buildfile, the line `#include "Hello World.txt"` becomes `String(Hello World!)` > ### **The file you #include can #include other files!** ## PUSH and POP Let's take a step back and look at our `ROM Buildfile` again. What does `ORG 0x1000000` mean? **ORG** stands for **Origin** meaning the starting offset of our data. In the previous example, we saw that our data was inserted to the offset 0x1000000. Imagine it as a **cursor** that tells Event Assembler where to insert at. **ORG** lets you move the cursor to a specific position, where you can start "typing", i.e. **inserting data**. > **If we don't put an ORG at all**, Event Assembler just starts at offset 0, or the very beginning of the ROM. ***This breaks the ROM horribly!*** What happens if we `#include "Hello World.txt"` **twice**? ``` #include eastdlib.event ORG 0x1000000 #include "Hello World.txt" #include "Hello World.txt" ``` If you assemble this buildfile, you will see `Hello World!` twice at the end of the data. The "cursor" doesn't stay where you put the ORG, it moves forward as you insert data. After the first Hello World is inserted, the cursor is now at the end of that data, ready to add the second Hello World. Now, let's try something new. Make a new text file containing ``` ORG 0x1000050 String(Hellow Orld!) ``` and save it as `Hellow Orld.txt`. Now `#include` this in your buildfile **between** the two `"Hello World.txt"` lines. ``` #include eastdlib.event ORG 0x1000000 #include "Hello World.txt" #include "Hellow Orld.txt" #include "Hello World.txt" ``` > ### We'll want to start fresh for this, so **delete** the ROM you've been > > assembling to and **make another copy** of the clean ROM. Now assemble the buildfile again, and take a look in HxD. As expected, you have `Hello World!` at 0x1000000, and `Hellow Orld!HelloWorld!` at 0x1000050. But what if we wanted the two Hello Worlds together? **Go back to `Hellow Orld.txt`** and add `PUSH` to the top, and `POP` to the bottom. **PUSH** creates a "bookmark" that remembers your position, and **POP** jumps back to the last bookmark you created. ``` PUSH ORG 0x1000050 String(Hellow Orld!) POP ``` > ### You can **PUSH** multiple times, and each **POP** will take you to the **newest** bookmark you placed. Assemble to a fresh ROM and this time, you'll see two `Hello Worlds` together, and `Hellow Orld` on its own at 0x1000050. ## Definitions, Labels and Macros It's now time to introduce you to one of the simplest, but **most powerful** commands in Event Assembler: `#define`! ``` #define FreeSpace 0x1000000 #include eastdlib.event ORG FreeSpace #include "Hello World.txt" ``` Can you figure it out? That's right, `#define` simply **replaces** one thing with another. Well, that's certainly **simple**. What's **powerful** about it? How about this? ``` #define FreeSpace 0x1000000 #define TestMacro(offset) "ORG FreeSpace + offset; String(Hello World!)" TestMacro(0x10) ``` This is an example of a **macro**. Like a definition, it expands out into the second half. ``` ORG FreeSpace+offset String(Hello World!) ``` However, the difference is that you can **set** the value of `offset` when you write the macro! When you write `TestMacro(0x10)`, you're telling EA that **offset = 0x10**. This expands out into: ``` ORG 0x1000000+0x10 //FreeSpace = 0x1000000, offset = 0x10 String(Hello World!) ``` However, if you had `TestMacro(0x100)`, it would instead become: ``` ORG 0x1000000+0x100 String(Hello World!) ``` You may have noticed that `TestMacro(offset)` looks **very similar** to something we've seen before. Yep, `String(text)` is **also a macro**! One final thing. You now know that definitions are like **shortcuts** that you create with `#define`. There is one more way to create a shortcut: **Labels.** > ### A **Label** is a shortcut for an offset. You can create a label like so: ``` ORG 0x1000000 #include "Hello World.txt" MyLabel: #include "Hellow Orld.txt" MESSAGE Hellow Orld is inserted at MyLabel ``` Assembling this will give you the following output: > Finished.\ > Messages: Hellow Orld is inserted at 0x100000B > > No errors or warnings. Please continue being awesome. As you can see, **a Label is an automatically defined offset**. In this case, it tells you exactly where Hellow Orld begins. We'll be using labels a lot to track where our data is inserted. ## MAKE HACK.cmd You may have noticed that every single time we assemble, we use the **same** text file, the **same** ROM, and the **same** settings. Wouldn't it be nice if we could **save those settings**? > ### Enter **MAKE HACK.cmd**! Create a new text file and paste the following: ``` cd %~dp0 copy "FE8_clean.gba" "FE_Hack.gba" cd "%~dp0Event Assembler" Core A FE8 "-output:%~dp0FE_Hack.gba" "-input:%~dp0ROM Buildfile.txt" pause ``` (replace "FE8\_clean.gba" with your clean ROM, **both** instances of "FE\_Hack.gba" with your edited ROM, FE8 to FE7 if you're hacking that, and "ROM Buildfile.txt" with the name of your buildfile) Save this as `MAKE HACK.cmd` in Root. When you open this script, it will first **copy** and rename your clean rom. Then it will **assemble** the buildfile to the ROM. Finally it will **pause** when it's done so you can see the output and any error messages. > ### In other words, **you can now build an entire hack from scratch in one click.** # Baby's First Buildfile # Hello, World! # Understanding #include # PUSH and POP # Definitions, Labels and Macros # MAKE\_HACK.cmd # Nightmare You may have heard of a program called **Nightmare**, which can be used to make changes to things like character stats, item properties, and so on. Fortunately for you, **you won't need to worry about it!** You do need to download the appropriate set of **Nightmare Modules** for your game, but you won't need the actual Nightmare program. ## How Tables Work Nightmare modules essentially describe **data tables** in the ROM. They say **where** the table is, how many **columns**, how many **rows**, and so on. Using this information, we are able to understand what each bit of data in the table **represents** and change it accordingly. ## Using NMM2CSV When you download **NMM2CSV** you'll see that it is in fact made up of two programs: N2C.exe and C2EA.exe. ### N2C.exe This program creates **.csv spreadsheets** from a ROM using Nightmare Modules as a template. Essentially you simply place N2C.exe in the **same folder** as your Nightmare Modules, and then **drag and drop** the rom you want to rip from onto it. ### C2EA.exe This program **converts the spreadsheets** you got in the previous step into Event Assembler compatible format, and also **generates an installer** so that you can `#include` all of your spreadsheets in one go. So the way to make changes is to first create your CSV spreadsheets using N2C.exe. **You should only have to do this once!** Once you have the spreadsheets, you can edit them using Microsoft Excel, LibreOffice, Google Sheets... any spreadsheet program will do. > #### **Put your Nightmare Modules, N2C and C2EA into a new folder called Root\Tables.** Next, you make the changes you want. In this example, I am going to give Eirika a base Strength of 10. First, I open up `FE8 Character Editor.csv`: ![Table screenshot](http://puu.sh/rIHg9/3e88b7e1f3.png) As you can see, each character is a **row** of the table, and each row is split into **columns** for the properties we can edit. We are editing Eirika's Base Strength, so we click that cell and type 10. ![Table screenshot](http://puu.sh/rIHmG/35ac32eaf0.png) Then **save**, and run C2EA.exe. You don't need to drag or drop anything, just run the program and it will process your Nightmare Modules and create a file called `Table Installer.txt`. Add this file to your **ROM Buildfile** and the next time you run `MAKE HACK.CMD`, the changes will be saved! > ### **You *****MUST***** run C2EA again every time you make changes to the modules.** > > You can add C2EA into your MAKEHACK.cmd batch file using `cd "%~dp0Tables"` (or whatever subfolder c2ea is in) `c2ea "%~dp0FE8_clean.gba"` (the path to the clean rom is only needed if you are repointing a table) ## Using Definitions NMM2CSV comes with a file called `Table Definitions.txt`. This comes with a few useful definitions like weapon and character abilities. You can also add your own, depending on what you're doing. The best part of this is that you can actually **use definitions** in your spreadsheets! For example, let's take Eirika's Rapier and make it an **indestructible, brave weapon**. Just for the sake of learning, of course. This time, we open up `FE8 Item Editor.csv`. ![Table Screenshot](http://puu.sh/rIHGt/0e233961a2.png) We find the row with Rapier, and find the `Weapon Ability 1` column. In this case, we need to expand out the column width so that the full name is visible. Then we click on the **cell** we need to edit, and enter the abilities we want to have, added together. (You can also use `|`(bitwise OR) instead of `+`.) > **Tip:** Use **View>Freeze Panes** to keep the first row or column visible at all times. This is very helpful when you edit larger tables. ![Table Screenshot](http://puu.sh/rIHSm/4bb86393dd.png) Once again, we can **save and run C2EA,** and the changes will be inserted the next time we assemble. ## Repointing and Expanding (#inctext) You can expand a table simply by adding some rows to the bottom. You can put `INLINE LabelName` in the first cell to have the table inserted into free space and labeled `LabelName`. Event Assembler comes with a tool called `PFinder.exe` which can be used to find and replace pointers in the ROM. When you run C2EA with a table that needs repointing, you can either drag a clean rom onto the exe OR select the clean rom when prompted. > Alternatively, you can add C2EA into your MAKEHACK.cmd and provide the clean rom as an argument like this: `cd "%~dp0Tables` (the folder where C2EA.exe is stored) `c2ea "%~dp0FE8_clean.gba` (the location of the clean rom) # How Tables Work # Using NMM2CSV # Using Definitions # Repointing and Expanding with #inctext # Appendix: Nightmare Module Format NMM format: # at line\[0] means comment, ignore it. blank lines are ignored also. decimal is assumed, 0x for hex, 0 for octal (0b for binary?) ``` Line 1: file version, ignore it. Line 2: file description, ignore it. Line 3: address of table, no 0800:0000h Line 4: number of entries Line 5: length of each entry Line 6: text file of entry names, might be useful. Default to numbers if not found Line 7: tbl file for text, ignore it. ``` Entry format: ``` Line 1: Description (use as header row?) Line 2: Offset Line 3: Length in bytes Line 4: Type of data (Only care about H or DU/DS imo) Line 5: Text file for descriptions, ignore it for now. NEHU: Numeric Editbox Hexadecimal Unsigned NEDU: Numeric Editbox Decimal Unsigned NEDS: Numeric Editbox Decimal Signed NDHU: Numeric Dropdown Hexadecimal Unsigned NDDU: Numeric Dropdown Decimal Unsigned ``` # Text Each piece of text in GBAFE is tied to a **text ID** up to 0xFFFF. This text contains a number of **control codes** that determine extra data such as loading and moving faces. > ## Important: > > Text editing requires the ***Anti-Huffman Patch*** to be installed. This is included with the **FE8 Essential Fixes**, or as part of the **FEditor Autopatches for EA** if you are using FE7. ## Formatting Text Text is converted into binary data using a **text parser**. We will be using the parser included with **Event Assembler**, but we will make the process much simpler by using **textprocess.exe** to do all the hard work for us. Here is a very simple example of a text file called `UnitNames.txt`: ``` # 0x212 RubyName Ruby[X] ``` There are three parts to each text entry. First, `# 0x212` is a **text ID**. It happens to be the text ID that refers to Eirika's name. The second part is an optional **definition**. In other words, when I need to refer to this text ID later on, I can use `RubyName` and Event Assembler will understand that to mean this text ID. If you leave out the definition, you can still refer to it by the number `0x212`. The final part is the actual text. You can see that we are changing Eirika's name to Ruby. Finally we end the text with the control code `[X]`. This is a special code that tells the game where the text stops. Now, let's look at something a little more complicated. ``` # 0x903 [OpenFarLeft][LoadFace][0x02][0x01] Hello, how are you?[A] As for me, I'm talking[NL] words at you![A][X] ``` > ### The positions from left (flip for the right side): > > `[FarFarLeft]`(offscreen) > `[FarLeft]` > `[Midleft]` > `[Left]` `[LoadFace][0x02][0x01]` is used to load up portrait number 0x02. If you have more than 0xFF portraits, the **higher digit carries over** to the \[0x01], e.g. portrait 0x17F would be `[LoadFace][0x7F][0x02]`. You only need `[LoadFace]` if a portrait is actually being **loaded**. Otherwise, you can simply use \[Open(position)] to make the face at that position **active**. ## Inserting Text Textprocess.exe works by dragging a text file onto the exe. It then converts this text file for EA insertion and generates an **installer file** that you can `#include` in your buildfile. This textfile contains **all of the text changes** you want to make. For example, we can take the two previous text changes and put them in a single document, which I've called `text_buildfile.txt`. ``` # 0x212 RubyName Ruby[X] # 0x903 [OpenFarLeft][LoadFace][0x02][0x01] Hello, how are you?[A] As for me, I'm talking[NL] words at you![A][X] ``` > ### But wait, why is it called a **buildfile**? You guessed it, you can `#include` other text files! Let's take a look at one of the text buildfiles I used for a simple one chapter hack: ``` #include "DQText.txt" #include "PrologueText.txt" #include "MiscText.txt" ``` You'll notice there aren't any actual text entries here, those are all split into separate text files for organization. Peeking at PrologueText.txt, we can see things like: ``` #0x664 BrownBoxPrologue 1 year ago[X] #0x665 BrownBoxPrologue2 Present day[X] # 0x1a2 Prologue_Objective_Long Survive[X] #0x19d Prologue_Goal_Window Survive[X] ``` Now you may have noticed something else this has in common with an event buildfile - whenever we process the text, it's **always the same file**. Know what that means? **We can add it to MAKEHACK.cmd!** Here's an example from my own: ``` cd %~dp0 copy FE8_clean.gba FE_Hack.gba cd "%~dp0Tables" c2ea "%~dp0FE8_clean.gba" cd "%~dp0Text" textprocess_v2 text_buildfile.txt cd "%~dp0Event Assembler" Core A FE8 "-output:%~dp0FE_Hack.gba" "-input:%~dp0ROM Buildfile.event" pause ``` # Inserting Text # Graphics When a **graphic** is inserted in the GBA, it is broken up into 8x8 pixel blocks called **tiles**. These tiles work together with **palettes** and **TSA** in order to be displayed properly. Additionally, graphics come in two main varieties, **sprites**, which are also called **objects**, and **background** images. The differences between the two will be covered later on. Finally, **graphics** can be **compressed** (such as the frames of a battle animation) or **uncompressed** (item and weapon icons). **Graphics** are, essentially, large grids, whereas each cell in the grid is a pixel. Each pixel is given a number to represent which colour in the **palette** it uses. Sometimes, **graphics** appear on screen just as the tiles are laid out in the original image. Other times they make use of **TSA**. **TSA** functions like a map that tells the GBA which **tile** goes where. **Palettes** are sets of halfwords (two bytes per colour) that denote the colour of a pixel. Most, if not all **palettes** encountered will have 16 colours in them, taking up 32 (0x20) bytes of space. The first colour in a **palette** is usually used as a transparent colour, meaning that pixels using that colour are not displayed. Finally, some **tiles** in the graphic might be the same, or different images might be made from a single set of **tiles**. To save space in the ROM, only one copy of the tile will be saved. Therefore, we need something called **TSA** that allows the game to put the tiles back together in the correct order, similar to assembling a puzzle. Multiple sets of **TSA** allow for a variety of images to be stitched together. ## Sprites & Backgrounds The GBA has two ways to display graphics, as mentioned previously. They are **Background** images and **Sprites**. Both have limitations and uses, so understanding the difference is vital for any kind of graphical work. Larger images are almost guaranteed to be **background** images. Dynamic images, like map sprites or battle animation frames, are **sprites**. ### Background Images There are 4 **background layers** (or **BG layers**) that the GBA has to work with. Naturally, these are labeled **BG0**-**BG3**. Each one has different abilities and uses. ![What you see](http://puu.sh/rGX81/7903256b06.png) Here's a screenshot from FE8's prologue. What you see is a combination of **background layers** and **sprites**, but let's worry about the **background layers** for now. The layers are stacked on top of each other to form a cohesive screen. We call the order in which the **BG layers** are placed the **priority** of the layer. A higher **priority** means that it will be covered by things with a lower **priority**. Let's take a look at the **BG layers** you see here. ![0, 1, 3](http://puu.sh/rGXRG/6bdf9eb8c1.png) You might be thinking to yourself, *"Wait! You're missing a layer! There are three here, not four,"* and you're right. These are, in order, **BG0**, **BG1**, and **BG3**. I didn't include **BG2** because it was blank. Here, the **BG layers** are layered with **BG0** on top, followed by **BG1**, and then **BG3**. **Background layers** are built using three parts: **tilesets**, **TSA**, and **BG palettes**. Both the **tileset** and **TSA** are written to the `0x06000000` (**Video RAM** or **VRAM**) section of memory. Specifically, **tilesets** are written to `0x06000000-0x06006000` and `0x06008000-0x06010000`. **TSA** is written to `0x06006000-0x06008000`. In the GBA Fire Emblem games, the `0x06008000-0x06010000` segment is usually reserved for the game's map tilesets or scrolling menu backgrounds, while `0x06000000-0x06006000` is used for general images. **BG Palettes** are written to the `0x05000000` (**Palette RAM** or **PalRAM**) section of memory. More info on them in the next section. **BG images** can be large and are not suited for moving quickly, although their individual tiles can be edited easily. There are settings for rotation, alpha blending, scrolling, and other settings, but they are better left to be covered by the links in the next paragraph. Menus, windows, cutscene backgrounds, and many other images are all **BG images**. Documents such as [Tonc](http://www.coranac.com/tonc/text/toc.htm) or [GBATek](http://problemkaputt.de/gbatek.htm) are a fantastic resource for understanding how to use and manipulate **BG layers** and **BG images**. Both also refer to both **sprites** and **BG layers** differently. For the purposes of this tutorial, terms you may have heard before, or may hear later, have been used, such as **TSA**. ### Sprites **Sprites** have nearly the opposite characteristics: they're mobile, usually small, and lack **TSA**. **Sprites**, or **objects**, are written to `0x06010000-0x06018000` (**OVRAM** or **ObjRAM**). **Objects** are also referred to as **OAM**, which stands for **Object Attribute Memory**, although **OAM** is more correctly defined as the section of memory that control data for **objects** is written. This section of memory is `0x07000000-0x07000400`. **Sprites**, like **backgrounds**, can have effects applied to them, such as alpha blending or rotation, but these are too advanced to cover in this basic guide. If you'd like to learn more, give this section of [Tonc](http://www.coranac.com/tonc/text/regobj.htm) a read. Individually, **Sprites** are small, generally restrained to rectangles that are 8x8 pixels to 64x64 pixels in size. Like **background images**, however, you can have many sprites seem connected. One major difference between **sprites** and **background images** is that **sprites** are not confined to a tile grid. > ### The positions of sprites are in pixels, not tiles! This allows **sprites** to do complex things much more easily than **background images**. The control data, or **attributes**, of **sprites** control all of the features of the **sprite**. There are four **attributes**, aptly named **attr0-3**. Each **attribute** is a **halfword**, or two **bytes**. For a detailed breakdown of **attributes**, see **Tonc**. ## Palettes ***Battle Sprite Palettes*** **Do FE7/FE6 version \*soon\*** (remind me to do the FE7/FE6 instructions later) \~ Tera ***FOR FE8*** There is a nightmare module for setting the palettes in FE8 called the battle palette association editor. it comes in two parts; the first part is for setting the class and the second part is for choosing the palette. If the character is not in a class listed in their class list, the game uses the default palette. ![Battle Palettes Window](http://feuniverse.us/uploads/default/original/2X/5/58ea14b5a8feaf581fb85d6166ee103fbce64073.png) In FE7 it was 2 palettes per character, but in FE8 its 1 palette per class and 7 classes per character. Basically, you go to the character's slot andset one of the seven class slots to the desired class, and then go to the other part and set the palette (trainee palette is used by the trainee class and etc.) ## TSA or Tile Maps Nintenlord's compressor and/or grit ## Compression Link to wiki article on LZ77 # Sprites and Backgrounds # Palettes # TSA or Tilemaps # Compression # GBA Graphics Editor GBA Graphics Editor, or GBAGE, is the gold standard for viewing images within a ROM. Easy to use and very powerful, this tool by Nintenlord is going to be your best friend. Go ahead and download it if you have not already, and run the application. ![GBAGE Main Window](http://puu.sh/rFBza/69cd98b1be.png) This is GBAGE's main window. Here is a breakdown of its functions: > * **File** - Standard file opening and saving. > * Open ROM - *Opens a specified ROM.* > * Load a .nlz file - *Loads a special file containing compressed graphics and offsets.* > * Load a palette file - *Loads a .pal file created by VBA.* > * Re Scan - *Scans through the ROM again and updates .nlz files.* > * Deep Scan - \*Performs a scan that can pick up things that are less likely > > to be graphics.\* > * Save - *Saves the current ROM.* > * Save As - *Saves the current ROM into a new file.* > * Exit - *Exit the program.* After opening a ROM, you gain access to the **Windows** and **Rotate/flip image** tabs. > * **Windows** - Open other windows for specialized functions. > * Image Control - *Window for viewing and changing images.* > * Palette Control - *Window for viewing palette settings.* > * Colour Control - *Window for editing colours within a palette.* > * Tile Control - *Window for viewing and editing TSA.* > * **Rotate/flip image** - Choose to rotate or flip an image > * Rotate - *View an image rotated based on angle chosen.* > * Flip - *View an image flipped either horizontally and/or vertically.* The **File** window has three unusual options--**Re Scan**, **Deep Scan**, and **Load a .nlz file**--that you may be unfamiliar with. When you open a ROM with GBAGE it scans the contents of the ROM for compressed images and saves their offsets and palettes to a special .nlz file. **Re Scan** looks through the ROM again and updates the .nlz file. **Deep Scan** picks up smaller data sets that are less likely to be images but still could be identified as a compressed image. **Load a .nlz file** loads a premade .nlz file. ## Image Control Go ahead and load up a ROM and open the **Image Control** window. ![GBAGE Image Control](http://puu.sh/rFFQw/5888345685.png) This is what the **Image Control** window looks like with a ROM opened. This window is the most important window, as it allows the user to look through the ROM's images. Once again, there are multiple options: > * **Compressed Graphics** - Denotes whether an image is lz77 compressed or not. > * **Offset** - Gives the position in the ROM that GBAGE is looking at. > * **+Block** and **-Block** - Changes the viewed offset by 32 (0x20), which is one tile. > * **+Line** and **-Line** - Changes the viewed offset by one row of tiles. See the size options for more information. > * **Save as bitmap** - Saves the currently-viewed image in the chosen format. These formats are: > * Bitmaps (.bmp) > * Portable Network Graphics (.png) > * Graphics Interchange Format (.gif) > * **Import a bitmap** - Loads and inserts a graphic into the ROM. More info below. > * **Raw dump** - Saves the currently-viewed image in the chosen raw format. More on this later. These formats are: > * GBA files (.gba) > * Binary files (.bin) > * **Load Raw** - Loads and inserts a raw graphic into the ROM. Once again, details below. > * **+Screen** and **-Screen** - Changes the viewed offset by one screen. > * **Compressed controls** and **Size** - See their respective sections. ### Compressed Graphics GBAGE determines what is and is not an image by looking for a specific set of bytes at the beginning of a **compressed image**. When viewing a **compressed image** in GBAGE, the box denoting a compressed image is checked. When navigating images within a ROM, such as by pressing **+Line** or **+Block**, you may notice that the box becomes unchecked and the image turns into a jumbled mess. When you change the **Offset**, GBAGE is not seeing the image header, and does not know the image is compressed. For uncompressed images, such as item icons, the **-Block** and **+Block** options are useful. ### Compressed Controls The **Image Control** window has a box in its lower-left corner that has two things in it: **Image** and **Amount of blocks added**. When you open a ROM in GBAGE, it counts the number of images it finds, and assigns each one a number based on the order in which the images are found. In the image above, notice that the image box displays that the image in numbered "0". Use the up and down buttons to quickly navigate compressed images within the ROM. You can also enter a known image number into the box and hit enter to immediately go to that image. Deleting or adding images to the ROM may change these numbers, so be careful. Furthermore, this box only applies to compressed images. The **Amount of blocks added** note shows how many pixels or tiles needed to be added to the image to display a rectangle. ### Size This box on the **Image Control** window dictates how many tiles wide or tall to display the image. This setting is useful for images that may be seen in-game in a different format than how they are inserted. For example: ![FE8 Items Default](http://puu.sh/rFJTC/4a1d0198e7.png) These weapon icons are a mess! How about we make them look a bit better? ![Formated GBAGE Orientation](http://puu.sh/rFK3Q/41179ddec5.png%20%22FE8%20Items%20Formatted) Much better! Now, using **+Line** twice will move to the next weapon icon. The best part about changing the size like this is that you can insert your icons as an image formatted vertically, like these icons. ## Saving Graphics from GBAGE GBAGE has two methods of saving graphics: **Save as bitmap** and **Raw dump**. **Save as bitmap** outputs files that are edited with conventional graphic editing tools, while **Raw dump** saves images as binary data. GBAGE is also slick because it outputs files using the specified palette and other settings. ## Inserting Graphics with GBAGE To insert graphics using GBAGE, select either **Import a bitmap** or **Load raw**, depending on what type of image you are inserting. Clicking **Import a bitmap** displays: ![Import a bitmap](http://puu.sh/rFOPu/a57016f09f.png) This window allows you to import .gif, .png, and .bmp images. The **Graphics** section is where you specify the offset to write to. You have the option of specifying whether or not to abort if the image is larger than what you are replacing, but that only matters if you are importing an image over an existing one. When inserting images into free space, uncheck the box. Also, there is an option to repoint existing pointers to the offset given by the **Image Control** window to point to the new graphic. When importing a graphic, having the **Compressed graphics** box checked will insert the graphic using lz77 compression. Leaving it unchecked will insert the graphic as uncompressed. The **Palette** section is the same as the **Graphics** section, but for palettes. In many cases, this section is optional, such as when replacing graphics that use the same palette as the original. You could also choose to only import an image's palette without any graphics, if you so choose. **Load raw** has a similar interface to the **Graphics** section of **Import a bitmap** and functions the same way. ## Palette Control Remember those weapon icons shown earlier? Navigating to them normally should give you something like this: ![What happened?!](http://puu.sh/rFPZD/b781eb297a.png) Whoah! Definitely not what we want. Time to open up the **Palette Control** window. ![Aha!](http://puu.sh/rFQqy/33d692871e.png) So, GBAGE does not know where the palette for these icons is by default. Just like the **Image Control** window, here is a breakdown of the features: > * **Graphics mode** - This determines how colour data is saved. More on this later. > * **Gray scale** - Display the image as a grayscale image. Useful for finding graphics with unknown palettes. > * **Use palettes from PAL file** - If you load a .pal file, you can choose palettes from it. > * **Compressed ROMpalette** - Just like compressed images, GBAGE can determine if the palette at the indicated offset seems to be compressed. > * **ROM Palette(s) offset** - Location of the palette you want to display. > * **Palette index** - Displays an alternate palette, which is the next 32 (0x20) bytes after the previous one. Before explaining further, how about we set the correct palette? !\[Weapon icons with palette]\( "That's better!") Awesome. Let us keep rolling, shall we? ## Graphics Mode As indicated above, GBAGE can detect images with different **colour depths**. Most images encountered will use 4bit **colour depth**. One such exception is the rotating circle graphic in FE7's main menu. **Colour depth** describes how many bits are used to save colour information in an image. A 4bit image, or 4bbp (bits-per-pixel) uses a 16-colour palette. This is due to the 16 possible combinations of the four bits. For example: ``` 0000 = 0 0001 = 1 1001 = 9 1111 = 15 ``` Notice that the max is 15, but we count colour 0 in our palette. 8bit depth is where an entire byte is used to save a pixel's colour information, so there are ``` 11111111 = 255 ``` Counting 0, that gives an 8bit bitmap 256 colours to choose from. ### Palette Index Sometimes graphics will be able to use different palettes, such as map sprites or windows whose colour is determined by the options menu. Graphics like these have their palettes saved one after the other. Because they are predictably placed, we can advance to the next palette, or the one after that, and so on, quite easily. Since we have already discussed weapon icons, there is a good example of different using a different palette index just up ahead. Continuing onward to the weapon rank icons, you may notice that they do not look quite right. !\[Palette index 0]\( "Something's off here...") A quick change of palette index yields: ![Much better.](http://puu.sh/rFSdk/a7e7407cfd.png) This leads us into the next window: **Colour Control**. ### Colour Control Opening the **Colour Control** window after changing the colour index, you should get something like: ![Colour Control](http://puu.sh/rFSSk/28460c99fe.png) The **Colour Control** window is very simple. On the left, you have your **palette indexes** (numbered 0-15). At the top is the weapon icon palette (index 0), in this example, and just below it is the weapon rank palette (index 1). On the right, you have the red, green, and blue values for the selected colour. On the GBA, each of these is represented by 3 bits for a range of 0-31. To convert to normal colours, multiply these values by 8. Likewise, colours you use must be in steps of 8, converted into 0-31. On the bottom, you may choose which colour you want to edit the values of, but it is much easier to click on a colour instead. Lastly, you can save the palettes as a .png, .gif, or .bmp. Finally, we have the most complex part of GBAGE! ## Tile Control Switching gears, let's look at an image that uses TSA. ![Ooh, world map](http://puu.sh/rFVTO/9bd916f776.png) This is one of the world map images in FE8. Once again: > * **Use TSA** - Checked if the image uses TSA. > * **Compressed** - TSA can be compressed, too. More on that later. > * **Offset** - Where the TSA is located. > * **Amount of bytes to ignore for displaying** - Some TSA has extra data at the beginning. > * **Vertically/Horizontally flip all tiles** - flips image by tiles. > * **Tile index** - Which tile position is currently being edited. > * **Graphics** - Which tile is being placed at that position. > * **Palette** - Images with TSA can use multiple palettes, and each tile can select one to use. > * **Flip** - In addition, tiles can be flipped individually. Notice that the **Graphics**, **Palette**, and **Flips** cannot be edited here. This is because the **Compressed** box is checked. Also note that clicking on the image in the main window will move the **tile index** to the tile you've selected. Also note that I changed the width of the image. This world map, for example, isn't a 32x32 tile square. In fact, it is 32x20 tiles, which equates to 256x160 pixels, or two tiles wider than the GBA screen but just as tall. The extra tiles are not displayed. When viewing **TSA**, you may need to adjust the number of tiles shown. If you need to **raw dump** your TSA, take the **offset** and put it in the **Image Control** window to see it as image data. Then you can raw dump like any other data. Congratulations! You're ready to use GBAGE! # Image Control # Saving Graphics from GBAGE # Inserting Graphics with GBAGE # Palette Control # Graphics Mode # Colour Control # Tile Control # Portraits Here's an example `Portrait Installer.event`: ``` #include "Tools/Tool Helpers.txt" //this file defines the macro: //setMugEntry(number, data, mouth_x, mouth_y, eye_x, eye_y) Sigurd_Mug: #incext PortraitFormatter "sigurd.png" setMugEntry(0x51, Sigurd_Mug, 3, 5, 3, 3) ``` Easy, right? In free space, you simply label the portrait and use #incext PortraitFormatter to convert the PNG for insertion. Then use setMugEntry to set the portrait ID and the tile locations for the eye and mouth frames. ## Formatting Portraits Formatting portraits is the same between buildfiles and FEditor. This is a hackbox. Your portrait should fit in this. ![Hackbox](https://i.imgur.com/2MpEGSA.png) ## Ripping Portraits You can use FEditor to rip portraits and have them formatted ready to go. Alternatively you can download all the GBA portraits [**right here**](https://doc.feuniverse.us/static/resources/mugs.png). # Inserting Portraits Here's an example `Portrait Installer.event`: ``` #include "Tools/Tool Helpers.txt" //this file defines the macro: //setMugEntry(number, data, mouth_x, mouth_y, eye_x, eye_y) Sigurd_Mug: #incext PortraitFormatter "sigurd.png" setMugEntry(0x51, Sigurd_Mug, 3, 5, 3, 3) ``` Easy, right? In free space, you simply label the portrait and use #incext PortraitFormatter to convert the PNG for insertion. Then use setMugEntry to set the portrait ID and the tile locations for the eye and mouth frames. ## Formatting Portraits Formatting portraits is the same between buildfiles and FEditor. This is a hackbox. Your portrait should fit in this. ![Hackbox](https://i.imgur.com/2MpEGSA.png) ## Ripping Portraits You can use FEditor to rip portraits and have them formatted ready to go. Alternatively you can download all the GBA portraits [**right here**](https://doc.feuniverse.us/static/resources/mugs.png). # Ripping Portraits # Animations We're going to take out our handy [Animation Assembler.exe](http://feuniverse.us/t/fe7-8-animation-assembler-convert-feditor-format-for-insertion-with-ea/1880). All we do is drag and drop our FEdidor-formatted animations onto the exe, and a .event file should pop out. Within the .event file, there will be a slot near the top to define which animation slot you are using for this animation. Now go ahead and `#include` it! Also, I suggest using `{ }` with any outputted files. Labels within the .event file are dependant on the file names of the frames, and many frames from different animations have the same name. Next, in a new file... ``` #define SwordAnim(Animation) "BYTE Swords 0x01 ; SHORT Animation" #define SpearAnim(Animation) "BYTE Spears 0x01 ; SHORT Animation" #define AxeAnim(Animation) "BYTE Axes 0x01 ; SHORT Animation" #define HandAxeAnim(Animation) "BYTE HandAxe 0x00 ; SHORT Animation ; BYTE Tomahawk 0x00 ; SHORT Animation" #define BowAnim(Animation) "BYTE Bows 0x01 ; SHORT Animation" #define StaffAnim(Animation) "BYTE Staves 0x01 ; SHORT Animation" #define AnimaAnim(Animation) "BYTE Anima 0x01 ; SHORT Animation" #define LightAnim(Animation) "BYTE Light 0x01 ; SHORT Animation" #define DarkAnim(Animation) "BYTE Dark 0x01 ; SHORT Animation" #define UnarmedAnim(Animation) "BYTE Item 0x01 ; SHORT Animation" #define SpecialAnim(Animation,Weapon) "BYTE Weapon 0x00 ; SHORT Animation" ``` So now we need to tell the game which animation to use for each weapon type. For each class, in this new file, you want to set up something like the following: ``` MarshalAnim: SwordAnim(MarshalSword) SpearAnim(MarshalSpear) AxeAnim(MarshalAxe) HandAxeAnm(MarshalHandAxe) UnarmedAnim(MarshalUnarmed) WORD 0x0 // Seperator ``` I suggest putting all of these for each class in the same file. Note that you need to specify the hand axe animation! If you want to do a special animation, kind of like Hector with Armads, Eliwood with Durandal, or Lyn with Sol Katti, you would add to the list something like... ``` SpecialAnim(MarshalSpecial,UberSpear) ``` Finally, we go into our class editor csv and put MarshalAnim|IsPointer into the Battle Animation Pointer slot, and you should be good to go! ## Inserting existing animations If your animation is already in .event format, just open it up and change `AnimTableEntry(0x0)` to whichever animation slot you are using, then `#include` it in free space. If it is in FEditor format, download Animation Assembler and drag the **extensionless file** onto AA.exe. Wait for it to finish processing, then change AnimTableEntry as outlined above. ## Creating custom animations This is more time consuming than it is difficult. My advice is to block out the motions using stick figures, and then flesh out the animation once you're happy with it. I use Aseprite and Blender to animate, and it works pretty well. ## Battle Palette Editing For the first step of this, you'll need to get a copy of [FE Recolor](http://feuniverse.us/t/fe-recolor/95). You'll also need [Pal2EA](http://feuniverse.us/t/pal2ea-the-buildfile-palette-inserter/2646) for that, so grab that as well. FERecolor is a program used to make palette changes for battle animations. We're doing our recolor and then getting those colors as a hex for later. Open it up and go to Load Image. Open up the image for the class you want to work with. Once that's done, just modify your colors until you like how the unit looks. Just make sure not to meddle with the box below the reset buttons. That's the order which will be needed for the next step. When you've got your palette done, click Copy hex to clipboard and you'll get a hex string. Close the box, we're now moving to Pal2EA. We're going to make a new .txt where we'll create our input to Pal2EA. I'm going to refer to this as Palette Input.txt. This is the file we'll give Pal2EA which will generate the .event's we actually insert. ``` #char{0x6F} "AlanCav" set{0x02,0x1,0x5} 5553FF7FFF5B737FF431AA799E00F8009F26DE0017002A001D4736324E1DA514 auto auto auto auto ``` This will probably be easier to explain with an example, so here it is. `#char{0x6F}` means that we're inserting the palette into 0x6F in that table. You can find the list of slots in the same folder as the Animation nmm's. It's called Palette List.txt. 0x6F is an empty slot, they start from 0x6E. "AlanCav" is something Pal2EA will print so you know it's processed this palette. Not necessary and you can put a string in between the quotes. `set{0x2,0x1,0x5}` is a little more complicated. The first thing is the character ID. In this case, I'm selecting Seth, The second thing is the palette number. I don't think this really pops up elsewhere, but it's important here. Each character has up to 7 classes for palette association. 0x0 is trainee, 0x1 is the unpromoted class, 0x2 is the 2nd unpromoted class for trainee's, 0x3 is the first promotion option for the first unpromoted class, 0x4 is the 2nd for 0x1, etc. In this case, it's going to Seth's normal unpromoted class. The third thing is the actual class ID. 0x5 is the male Cavalier. Get this from a class list or something, this is pretty easy to find. The giant string of hex below that is the palette that we copied from FERecolor and auto will just make Pal2EA associate the first palette in this command with that allegiance. The order goes Player, Enemy, NPC, Arena 4, Arena 1. So you need a slot to insert the palette then you need to define the character, palette number, class and hex for the palette. Once you've done that, drag Palette Input.txt onto Pal2EA and #include Palette Setup.event in your buildfile. There's a bit more to Pal2EA, but you can look into the documentation for that. ## Spell Animations We're going to use [CSA\_Creator.exe](http://feuniverse.us/t/fe6-7-8-circles-spell-animation-creator-updated-to-v1-1/1946?u=circleseverywhere) for this one. Drag and drop your FEditor-formatted spell onto the .exe, and a .event file will be outputted. In the .event file, specify the slot you're inserting the spell into. #include that file in the master spell installer, then #include that in your buildfile. Next we need to use the Spell Association Editor. Find the item that you're replacing in the item slot. If you're adding a new item slot to the Item Editor, just make a new slot to the end of the Spell Association Editor. In the row with your item, specify the animation slot, and the flash color on the map for when animations are off. All the other slots are straight-forward. No need to mess with the Item Editor on this one. Yay. # Inserting Animations We're going to take out our handy [Animation Assembler.exe](http://feuniverse.us/t/fe7-8-animation-assembler-convert-feditor-format-for-insertion-with-ea/1880). All we do is drag and drop our FEdidor-formatted animations onto the exe, and a .event file should pop out. Within the .event file, there will be a slot near the top to define which animation slot you are using for this animation. Now go ahead and `#include` it! Also, I suggest using `{ }` with any outputted files. Labels within the .event file are dependant on the file names of the frames, and many frames from different animations have the same name. Next, in a new file... ``` #define SwordAnim(Animation) "BYTE Swords 0x01 ; SHORT Animation" #define SpearAnim(Animation) "BYTE Spears 0x01 ; SHORT Animation" #define AxeAnim(Animation) "BYTE Axes 0x01 ; SHORT Animation" #define HandAxeAnim(Animation) "BYTE HandAxe 0x00 ; SHORT Animation ; BYTE Tomahawk 0x00 ; SHORT Animation" #define BowAnim(Animation) "BYTE Bows 0x01 ; SHORT Animation" #define StaffAnim(Animation) "BYTE Staves 0x01 ; SHORT Animation" #define AnimaAnim(Animation) "BYTE Anima 0x01 ; SHORT Animation" #define LightAnim(Animation) "BYTE Light 0x01 ; SHORT Animation" #define DarkAnim(Animation) "BYTE Dark 0x01 ; SHORT Animation" #define UnarmedAnim(Animation) "BYTE Item 0x01 ; SHORT Animation" #define SpecialAnim(Animation,Weapon) "BYTE Weapon 0x00 ; SHORT Animation" ``` So now we need to tell the game which animation to use for each weapon type. For each class, in this new file, you want to set up something like the following: ``` MarshalAnim: SwordAnim(MarshalSword) SpearAnim(MarshalSpear) AxeAnim(MarshalAxe) HandAxeAnm(MarshalHandAxe) UnarmedAnim(MarshalUnarmed) WORD 0x0 // Seperator ``` I suggest putting all of these for each class in the same file. Note that you need to specify the hand axe animation! If you want to do a special animation, kind of like Hector with Armads, Eliwood with Durandal, or Lyn with Sol Katti, you would add to the list something like... ``` SpecialAnim(MarshalSpecial,UberSpear) ``` Finally, we go into our class editor csv and put MarshalAnim|IsPointer into the Battle Animation Pointer slot, and you should be good to go! ## Inserting existing animations If your animation is already in .event format, just open it up and change `AnimTableEntry(0x0)` to whichever animation slot you are using, then `#include` it in free space. If it is in FEditor format, download Animation Assembler and drag the **extensionless file** onto AA.exe. Wait for it to finish processing, then change AnimTableEntry as outlined above. ## Creating custom animations This is more time consuming than it is difficult. My advice is to block out the motions using stick figures, and then flesh out the animation once you're happy with it. I use Aseprite and Blender to animate, and it works pretty well. ## Battle Palette Editing For the first step of this, you'll need to get a copy of [FE Recolor](http://feuniverse.us/t/fe-recolor/95). You'll also need [Pal2EA](http://feuniverse.us/t/pal2ea-the-buildfile-palette-inserter/2646) for that, so grab that as well. FERecolor is a program used to make palette changes for battle animations. We're doing our recolor and then getting those colors as a hex for later. Open it up and go to Load Image. Open up the image for the class you want to work with. Once that's done, just modify your colors until you like how the unit looks. Just make sure not to meddle with the box below the reset buttons. That's the order which will be needed for the next step. When you've got your palette done, click Copy hex to clipboard and you'll get a hex string. Close the box, we're now moving to Pal2EA. We're going to make a new .txt where we'll create our input to Pal2EA. I'm going to refer to this as Palette Input.txt. This is the file we'll give Pal2EA which will generate the .event's we actually insert. ``` #char{0x6F} "AlanCav" set{0x02,0x1,0x5} 5553FF7FFF5B737FF431AA799E00F8009F26DE0017002A001D4736324E1DA514 auto auto auto auto ``` This will probably be easier to explain with an example, so here it is. `#char{0x6F}` means that we're inserting the palette into 0x6F in that table. You can find the list of slots in the same folder as the Animation nmm's. It's called Palette List.txt. 0x6F is an empty slot, they start from 0x6E. "AlanCav" is something Pal2EA will print so you know it's processed this palette. Not necessary and you can put a string in between the quotes. `set{0x2,0x1,0x5}` is a little more complicated. The first thing is the character ID. In this case, I'm selecting Seth, The second thing is the palette number. I don't think this really pops up elsewhere, but it's important here. Each character has up to 7 classes for palette association. 0x0 is trainee, 0x1 is the unpromoted class, 0x2 is the 2nd unpromoted class for trainee's, 0x3 is the first promotion option for the first unpromoted class, 0x4 is the 2nd for 0x1, etc. In this case, it's going to Seth's normal unpromoted class. The third thing is the actual class ID. 0x5 is the male Cavalier. Get this from a class list or something, this is pretty easy to find. The giant string of hex below that is the palette that we copied from FERecolor and auto will just make Pal2EA associate the first palette in this command with that allegiance. The order goes Player, Enemy, NPC, Arena 4, Arena 1. So you need a slot to insert the palette then you need to define the character, palette number, class and hex for the palette. Once you've done that, drag Palette Input.txt onto Pal2EA and #include Palette Setup.event in your buildfile. There's a bit more to Pal2EA, but you can look into the documentation for that. ## Spell Animations We're going to use [CSA\_Creator.exe](http://feuniverse.us/t/fe6-7-8-circles-spell-animation-creator-updated-to-v1-1/1946?u=circleseverywhere) for this one. Drag and drop your FEditor-formatted spell onto the .exe, and a .event file will be outputted. In the .event file, specify the slot you're inserting the spell into. #include that file in the master spell installer, then #include that in your buildfile. Next we need to use the Spell Association Editor. Find the item that you're replacing in the item slot. If you're adding a new item slot to the Item Editor, just make a new slot to the end of the Spell Association Editor. In the row with your item, specify the animation slot, and the flash color on the map for when animations are off. All the other slots are straight-forward. No need to mess with the Item Editor on this one. Yay. # Inserting Existing Animations # Creating Custom Animations # Battle Palette Editing # Spell Animations # Miscellaneous Graphics MASSIVE TODO ## Ripping images with GBAGE ## Chapter Name Graphics FE8 uses graphics as chapter names, unlike FE7 which uses text. Luckily for you, [there's a hack for that](http://feuniverse.us/t/fe8-chapter-titles-as-text/2065?u=circleseverywhere). ## Map Sprites As you may already know, there are two types of map sprites: moving and standing. These are treated separately with different graphics and tables. Let's start with standing sprites. First, we want to insert the graphical data simply like this. ``` ChampionSt: #incext Png2Dmp ChampionSt.png --lz77 ``` That --lz77 is very important as map sprites are lz77 compressed, but that's it. Now to let the game know where the graphics are... This is where the Standing Map Sprite Editor comes in. You can add entries to the end of this table for each map sprite you're inserting. Put your label into the Pointer to Graphics Section (for me, ChampionSt|IsPointer). Then, we need to specify the size. Go ahead and use these in the table. ``` #define Large 0x02 // Use for 32x32 frames #define Medium 0x01 // Use for 32x16 frames #define Small 0x00 // Use for 16x16 frames ``` Finally, we need to specify the slot we put the sprite in in the Class Editor in the Map Sprite # (standing) slot. For moving sprites, it works just a bit differently. We're going to insert our raw graphical data in the same way. ``` ChampionMv: #incext Png2Dmp ChampionMv.png --lz77 ``` This is where it gets a little different. In the Moving Map Sprite Table, you see it has 2 pointers we need. They are named a little stupidly in some versions so let me clarify. The first pointer is to the graphics we just inserted. The second pointer is to data that handles its animation (AP pointer). AP pointer? Sounds scary. Don't worry. We barely have to worry about it. So now write your label (ChampionMv|IsPointer) into the first pointer, but this time, the slot number has to match the class number. If you're overwriting the Revenant class, the new moving map sprite has to go in the moving Revenant map sprite slot. Then the AP pointer. The best thing to do is not touch it. If you're copying a sprite that already exists in-game, it's a good idea to copy this pointer. With a new sprite, uf it looks fine, it's good. If it looks weird, then try a different one from a vanilla class that has a similar sprite. I've never seen a moving sprite that doesn't have vanilla animation data that works for it. Then that's it! Your map sprites are good to go. ## Custom CGs ## Battle Backgrounds ## Battle Frames (FE8) Name frames are 7 tiles wide (1 more than fe7): In game is arranged ``` 01 03 05 07 09 11 13 02 04 06 08 10 12 14 ``` Graphic is arranged ``` 01 02 03 04 05 06 07 08 09 10 11 12 13 14 ``` Weapon frames are 8 tiles wide (1 more than fe7): In game is arranged ``` 01 03 05 07 09 11 13 15 02 04 06 08 10 12 14 16 ``` Graphic is arranged ``` 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 ``` Note that you will need separate images for the Enemy side and the Player side, as the edge tiles are different. Convert these images to bin files and compress using lz77 with Wingrit. ### The battle frame itself Build your battle frame like this default layout here: ![battle frame layout example](/files/-M-H1CF-FkjJxSdb8xxe) Once you've made your edits, open your hack in FEBuilder. Go to the "Battle Screen" editor from Advanced Editors and insert your edited frame. Save it, close the Battle Screen editor, save your ROM and re-open the Battle Screen editor. Go to the "Main" tab at the bottom of the editor - you should see a small image containing the tiles from your new battle frame. Click "Export image". In your graphics installer, add the following: ``` PUSH ORG $51f68 POIN BattleFrame POP BattleFrame: MESSAGE Battle frame gfx at currentOffset #incext Png2Dmp "YourExportedBattleframeTiles.png" --lz77 ``` Now run makehack, and in the output, note where the "Battle frame gfx at" offset is - copy it. Open GBAGE and, in the Image Control window, paste that offset where you inserted your battle frame tiles. Make sure "Compressed graphics" is checked, and set width to `15` and height to `68`. If the colors are messed up, open the Palette Control and paste offset `802558` in the offset box. Now open Tile Control and check "Use TSA", and paste offset `80201C` in the offset box there. You can now edit any TSA errors by clicking the tile and scrolling through the "Graphics" scroller in Tile Control until it's the correct graphic. Refer to the Wingrit screenshot below - the first red row and the first blue row are what will be loaded when 2 units are on-screen together (battle/healing), and the final blue row is loaded when 1 unit is on-screen (e.g. promotion). Remember to update the TSA for both. *Make sure that any areas that are the background color in the screenshot (e.g. where the unit names and weapon names are placed) are also blank in your TSA edit.* Save your rom once you've finished editing the TSA. Open the rom in HxD (or other hex editor) and goto address `80201C` - this is where the TSA for the battle frame lives. The palette is located at `802558`. Select from `80201C` to `802557` and copy the data, then make an empty .bin file and paste-insert. Save the new .bin file as "battlescreenTSA.bin". Now, add to your buildfile inside your push-pop: ``` ORG $80201c #incbin "battlescreenTSA.bin" ``` If you changed the palette, open your original battle frame in wingrit and use these settings to export: ![grit settings](https://i.gyazo.com/b153f107d63d24084884ebc715ce4708.png) You can then insert the resulting .pal.bin at offset `802558`. *NOTE: even though you are exporting a .map.bin as well, do not insert this file - it is not TSA data and will only confuse the issue.* With all parts in place your graphics installer should look something like this: ``` //New Battle Frame: ORG $51f68 POIN BattleFrame ORG $51fc8 POIN BF_EN ORG $52088 POIN BF_PN ORG $52028 POIN BF_EW ORG $52164 POIN BF_PW ORG $80201c #incbin "battlescreenTSA.bin" ORG $802558 #incbin "battlescreenTSA.pal.bin" //Put this part in free space BattleFrame: #incext Png2Dmp "YourExportedBattleframeTiles.png" --lz77 BF_EN: #incbin "bin\BF_Enemyname.bin" BF_PN: #incbin "bin\BF_Playername.bin" BF_EW: #incbin "bin\BF_Enemywep.bin" BF_PW: #incbin "bin\BF_Playerwep.bin" ``` You're done! ## Item Icons (Read GBA Graphics Editor first) Using the graphics pointer and the pallete pointer in that chapter, (hopefully) you've found the vanilla item icons. Set the width correctly and the height to 64. Save that image. Next, add 0x1000 to the offset. In other words, change the 2 to a 3. Woah it's at the next batch of items and stuff. Yes. Save that image and repeat until you have 7 sheets. Great! Now make your edits to your item icons. In a new .event file... ``` PUSH ORG $5926F4 #incext Png2Dmp "Sheet 1.png" #incext Png2Dmp "Sheet 2.png" #incext Png2Dmp "Sheet 3.png" #incext Png2Dmp "Sheet 4.png" #incext Png2Dmp "Sheet 5.png" #incext Png2Dmp "Sheet 6.png" #incext Png2Dmp "Sheet 7.png" POP ``` Notice item icons aren't lz77 compressed. If necessary, don't forget to change the icon for the item in the Item Table. # Chapter Name Graphics # Map Sprites # Custom CGs # Battle Backgrounds # Battle Frames # Inserting Music First off, you want to get the Native Instrument Map for your game (FE6 doesn't have one, you'll need some other instrument patch). Then get [Sappy2EA](https://www.dropbox.com/s/nw5w6wqwny0wnrh/Sappy2EA.zip?dl=0), which comes with a music installer and other useful things. ## Converting from MIDI > ### **Make sure your midi has no spaces or +- signs in the file name!** Get yourself Mid2AGB and Sappy2EA. Drag midi onto Mid2AGB, receive .s file. Drag .s file onto S2EA, receive event file. Then include it in your Music Installer and add the macro to set the table entry (the label name should be the same as the file name): ``` SongTable(8,FE4Ch10,MapMusicGroup) #include "FE4Ch10.event" ``` ## Custom SFX ## About Song Groups # Converting from MIDI # Custom Sound Effects # About Song Groups # Inserting Maps ## Inserting Maps [Here's a good map *making* tutorial. I suggest you read it up to insertion. (By Markyjoe)](http://markyjoe.com/Tutorials/Tiled_Tutorial/Tutorial.html) The main helper tool you will use here will be [`tmx2ea`](http://feuniverse.us/t/tmx2ea-v2-0-released-insert-tiled-maps-using-event-assembler/1830). It is a tool that is able to translate `.tmx` files (Tiled map files) into insertable events. In addition to inserting maps, it is also able to insert map changes, and it will also automatically fill up chapter data for you. Now let's assume you have your map ready. Under your main tile layer properties, specify the following if applicable: ``` Name Default Value Notes ----------------------------------------------------------------------------- Main Required when there are multiple layers. ChapterID ChapterID The chapter number/row in the chapter data editor ObjectType1 ObjectType The object set to use. Can also use ObjectType ObjectType2 0 FE7 only PaletteID PaletteID The palette to use TileConfig TileConfig The tile configuration to use MapID map_id The index of the map in the Event Pointer Table MapChangesID map_changes The index of the map changes in the Event Pointer Table Anims1 0 Tile Animation to use. Can also use Anims Anims2 0 FE8 only ``` Next, I suggest you make a new subfolder in your Root folder. This is because you will need to have all your maps located there for `tmx2ea` to work at its best (because, much like `n2ea`, it will scan for map files in the folder it is in). I'll assume you'll call it `Maps`. In your `Maps` folder, put in the `tmx2ea` executable along with you map file(s). Next, *run* `tmx2ea`. It will ask you whether you want to scan all subfolders for `tmx` files: tell it that you want. After it being done, you should be able to see a few new files in your `Maps` folder: One `event` and one `dmp` file for each of your map file, and `Master Map Installer.event`. All you should need to do is to `#include` the master map installer file from your main buildfile, because (as its name implies) the master map installer event file *will* install every map scanned by `tmx2ea`. After generating the master installer, you can use `tmx2ea` to update *specific* maps instead of all of them at once (to gain a little bit of time). To do that, simply drag your `tmx` file onto the `tmx2ea` executable and it should do its thing no problem. ## World Map Editing (FE8) # FEMapCreator # Tiled # Tile Changes # Insertion # World Map Editing # Events Here are a few resources to get started with eventing: * [Arch's "Eventing for Dummies"](http://feuniverse.us/t/eventing-for-dummies/109) (FE7) * [Zim's (unfinished?) "grand eventing wiki/chapter construction guide"](http://feuniverse.us/t/fe8-the-grand-eventing-wiki-chapter-construction-guide-wip/1594) (FE8) * [Blazer's "Ultimate Tutorial"](https://www.dropbox.com/sh/zymc1h221nnxpm9/AACZicftK6SbxlndbmYXCpiua/ToolBox?dl=0\&preview=Ultimate+Tutorial.pdf) (FE7) (starting on page 142) ## How to Read the Doc `Event Assembler/Event assembler language.txt` is a big text file listing all the defined event codes for all three games, and includes a little description for most of them. Alternatively, if you need more details on how different event codes look like, you can simply browse the `Event Assembler/Language Raws` folder. If you're looking for a standard definition/macro, you'll want to look at `Event Assembler/EA Standard Library` instead. ## How to Read the Disassembled Events ## The World Map # How to Read the Doc # How to Read Event Disassembly # The World Map # Engine Hacks ## Inserting ASM hacks In this section we'll go over how one can insert assembly hacks using EA Buildfiles. You're going to need the ASM beginner pack (where is it?). Included is `AssembleARM.bat` and (a very small subset of) DevkitARM (a common development kit for the GBA). Assuming your `.asm` file works properly, all you should have to do is drag and drop your file onto `AssembleARM.bat`, and it should output a `.dmp` file containing your assembled asm. All you need to do is to insert it: `ALIGN 4` (for good measure) and `#incbin` it, and you should be good to go. You're also going to want to put a label to be able to locate your routine(s) from other parts of your buildfile. If this is something you `ASMC` (call through events), don't forget to add `1` to your routine pointer/label. That way, the game knows it's reffering to *Thumb* ASM. Otherwise, you're probably going to want a hook. Check out `Hack Installation.txt` for different ways to hook your ASM. If your hook involves a `BL`, you need to insert your ASM within "`bl` range" (for example, in FE8U, in the free space range starting at 0x1C2270). ## Introduction to Assembly [Try out this neat new tutorial by Tequila](http://feuniverse.us/t/gbafe-assembly-for-dummies-by-dummies/3563)! ## Using the Debugger (this is also covered by Tequila's tutorial) # Inserting ASM hacks # Introduction to Disassembly # Using the Debugger