------------------------------------------------------------------------------------------------------------------------------------------- ~CHAPTER 1: Maps~ ------------------------------------------------------------------------------------------------------------------------------------------- I might as well have started this thing with a load of theoretical stuff, but I instead chose for a more practical approach. In fact, you'll be able to create a (almost) completely custom chapter at the end of Chapter 3. The first thing you need for a chapter is obviously a map, and that's why this first chapter will be about maps and how to code them. Map Data First off, for those who didn't know, all FE maps consist of tiles, which are squares of (in this case) 16x16 pixels. The game draws these tiles from tilesets (also called object sets) which are collections of tiles around a certain theme. The colours are only applied to the tiles afterwards, so a particular tileset could look completely different in different maps, depending on the used palette. However, each map can only use tiles from one tileset, and can only use one palette. Before coding your own map data, you'll need to know how the data is built up. To see an example of what map data looks like, use your hex editor to look at offset 0036AF00. This is the starting byte of the Prologue's map data. Before the information about the actual tiles starts, there are 7 other bytes. In the case of the Prologue, these are 10 2E 01 00 00 0F 0A. The 2nd, 3rd, 6th and 7th of these bytes differ from chapter to chapter. The 6th and 7th ones are respectively the horizontal and vertical dimensions of the map, measured in tiles. The 2nd and 3rd bytes actually store a single value, so you'll have to reverse them to read it: 012E. This value tells the game something about how many tiles should be loaded in total for the map, but I don't know exactly how it works. Anyway, the general formula to find this value for your own maps is: length * width * 2 + 2. You might want to use a hex calculator for this. (Shouldn't be difficult to find an online one.) After this, the tiles that are on the map are listed. There's no reference to their location on the map whatsoever, they're just listed from left to right moving from top to bottom on the map. Each tile's reference is just its number in the tileset, and it takes up two bytes (which are, as usually, in reversed order). Note that only numbers ending in 00, 04, 08 and 0C refer to valid tiles, the rest isn't usable in a map. There's a good reason for this, but I won't be explaining it here in order not to overcomplicate things. Additionaly, there's a 00 added in after the first 3 tiles' references, and beyond that after every fourth tile. As a really random example, a very small map's data could look like this: (the seperation 00's are in bold print) (note that a map as small as this can't exist; every map must at least be large enough to fill the screen) 10 2A 00 00 00 04 05 10 05 14 06 2C 01 00 7C 0D 48 09 2C 0F 64 08 00 A8 04 38 00 08 03 94 0A 00 50 07 90 08 A8 01 A8 01 00 74 05 C8 02 D0 09 D4 09 00 30 0B By now, you might have noticed that the map data of the Prologue, which we were looking at earlier, doesn't quite match this format. In fact, none of the actual game maps do, since they're compressed. Because of that, we can't just go ahead and change existing maps; instead we'll have to create our original maps to replace them, but seeing that we were going to do that anyway, that's not really a problem. You might also be wondering how you could possibly know which actual tiles the numbers refer to. For that, you could try ripping all the tiles of the tileset you want to use and collecting them into a table like I did with this one... but looking up every single tile of a custom map you want to code in a table like that would require extremely much time, so I'm going to explain a simpler method to you in a minute. If you prefer just to go ahead and code a map manually, you should be able to do that knowing what you know at this point, but I advise you not to overwrite the existing map data, and to expand the ROM so that you have empty space to put your map code in instead. Repointing the pointers to map data to point to your new map is something that will be discussed later. I strongly advise you though, to just read on and learn a far easier way. An all-powerful shortcut... The easy way I was referring to, involves designing your map in Mappy Map Editor, using the FE7 tilesets the link to which is in the prologue of this guide. How to use Mappy to design a custom map should be fairly clear, but here are a few advices that'll definitely make life easier: - Adjust the tileset window's size in such a way that tiles like castle's or villages align in so that you can easily see how to use each tile. - First pick a tileset, then start a 'new map' and load the tileset again. If you don't, a tileset might load incorrectly if you load it after loading another one first. It's not unlikely that you'll only notice this once you first see your map in-game and realise it doesn't look at all like what it should've been, so I strongly suggest that you pay attention to this. - Always remember to set tile size to 16x16 pxls in the 'new map' window. - Never create maps with dimensions exceeding 43 x 36 tiles, as the game might not be able to load them if you do. - Remember exactly which tileset file you used as you'll need that information later. In fact, you should probably write it down somewhere. - Don't use layers. If you want to use doors that can be opened or walls that can be broken, just make it look the way it should at the start of the chapter, and you'll learn the rest later. If you want to use removable roofs, I can't tell you how to do those, since I don't know it myself. =P - Ignore the fact that the animated tiles don't perfectly connect, since I didn't rip all of them when they were at the same animation frame. Once you've finished creating a map, export it as a .mar (map array) file. If you now get an error message telling you there are more than 1024 tiles in the tileset, you'll know that you haven't been paying attention to my second advice above. Now, we'll manually convert this .mar file into the format Rekka can understand. I'll describe this process step by step to avoid confusion. I'll use Cygnus here, since I don't know the exact functions to use in other editors. 1. Open the file in Cygnus 2. Choose the 'Tools->Modify' function 3. Set the 'number of items to modify' to something high enough so that the entire file is highlighted, set the item type to 'Word (2 bytes)', set the action to divide, the action value to 8 and make sure Big Endian is not checked. 4. Press OK. The hex editor will now divide the value of each pair of bytes by 8. (if it asks whether it should extend the file because your 'number of items to modify' was greater than the total file, choose 'no') 5. Insert a '00' byte after the first 6 bytes, and another after every 8th byte beyond that (not counting the 00 bytes you inserted as one of the 8) 6. Insert 10 XX XX 00 00 YY YY at the start of the file, with YY YY being the map dimensions (in hex!) and XX XX being length * width * 2 + 2 (all in hex). Remember to reverse the bytes! At this point, your file is ready to be inserted into the ROM. To keep things nice and clean, we'll just expand the ROM and insert this in the newly created open space. Inserting it can be done by just using the copy/paste functions of your hex editor. Obviously, the game won't be able to use your map now, since it has no way of knowing it's there. That's why we're going to need to make a pointer to it. Remember how there's a 'map used' byte in the chapter data? (you could use my NM module to find it) Clearly, this byte is not an actual pointer to the map itself; it's a reference to a pointer in the pointer table starting at 00C9C9CC. You'll learn to remember this table's offset, as a lot of important pointers, including those to tilesets, map palettes and event data are in there. Let's say you wanted your map to replace the prologue's map. As the 'map' byte in the chapter data says 04, the fourth pointer in the table is the one you'll need to change. Make it point to the location of your own map intead of to 0036AF00 like it does right now. Note that a pointer to an expanded area of the ROM will end in 09, since the address starts with 01 instead of the usual 00 (and you have to add 08 to it). If you hadn't realised it already, know that replacing the prologue's map pointer with yours won't mean that your map has to be used for the prologue. If you want to, you can change the map reference bytes of various chapters' chapter data around to change which map is used by each chapter. Finally, change the Object Set, Palette, Tile Configuration and Tile Animations settings in the chapter data to correspond with the tileset you used for your map. (Again, I advise using my chapter data editor). If you're not sure which tileset or palette it is, check its (=the tileset's) file name; it matches the values you need to enter. Changing tiles - about chests, doors and more Your map is now in the ROM, but if there are chests, doors, villages, snags or walls in it, you'll have to do some extra things in order for it to work properly. We'll have to edit, or rather, replace a bit of data that describes which tiles of the map can change to other tiles (like a closed chest changing to an opened chest). It allows you not only to make the door/chest/wall/snag tiles themselves change, you can also change the surrounding tiles, if you want to. You might have noticed the chapter data byte labeled 'Triggerable Map Changes' in my editor. Like a lot of values in the chapter data, this refers to a pointer in the table at 00C9C9CC. This pointer points to the data we're going to edit now. If the chapter you want to use your map for has a 00 at this byte, just take a reference number from another chapter. Remember though, that if you're going to make more than one custom chapter, you can't use the same number twice. (Or... in fact it could be done if you very carefully chose which ones to combine, but I advise against it) Anyways, let's take a look at the data these pointers point to. I'll use the data for chapter 2 as an example here, which is at 00CE1D20 (since the byte in the Chapter Data says 0E, which means the 14th pointer of the table, which points to 00CE1D20). The data looks like this: Offset ---- Data 00CE1D00 -- -------- -------- -------- 80072C0D 00CE1D10 -- B40D280D 30090000 240C0000 300D240D 00CE1D20 -- 000D0001 02000000 0C1DCE08 010D0001 00CE1D30 -- 02000000 101DCE08 02080102 03000000 00CE1D40 -- 141DCE08 FF000000 00000000 00000000 The underlined byte is the byte that the pointer points to. It's the start of what is essentially a list of all the changes the map could possibly undergo during the chapter. Each element of the list consists of 12 bytes in this format: GGHHJJKK LL000000 PPPPPPPP In which: GG = Identification number (as in, the first element of the list is 00, the second is 01, the third is 02, etc.) HH = Horizontal coordinate of the top lef tile of the part of the map that changes JJ = Vertical coordinate (note that coordinates are counted from the very top left tile of the map being ( 0, 0 )) KK = Horizontal size of the part of the map that changes (measured in tiles) LL = Vertical size P = Pointer to the tile references of the tiles the defined part of the map needs to be filled with if it changes The bold-printed bytes are the starting bytes of each element of the list for the chapter 2 map-change-data. As you can see, the list ends with 'FF000000 00000000 00000000'. So should yours. If you read the pointers in the example, you'll also see that the tile data is right before the list. Although this is always the case in Rekka, it doesn't need to be so. For your custom map, you might just as well first do the list and add the tiles after that. Remember though, that in any case, the pointer in the pointer table points to the first byte of the list. Making your own list like this shouldn't be too difficult, and I advise you to make one in the expansion part at the end of the ROM (if your map already took up all the new space, expand it further =P). Note that the game doesn't need to know what triggers the tile changes, it just executes any change it can find in the list that includes the tile a chest/door/pick/attack/visit command is used on, at the moment that command is used in the game. This means that the areas of the map that can change cannot normally overlap eachother, or things will go wrong. The only exception to this rule would be a situation in which the same tiles are changed multiple times throughout the chapter, which is the case in the cutscenes of chapter 2, where the door at the top right of the map is closed at one point and opened at another point. This is why that part of the map is listed twice in the example data above. Using this for a cutscene is rather tricky though, so I recommend against doing that, but there is another kind of situation in which you will need to include a certain part of the map twice no matter what. I'm talking about villages. Since they can either be visited (so the gate closes), or destroyed, they must be listed twice. The first one is the change that takes place if the village is destroyed, and the element listed immediately after that should be the change that happens if the village is visited. Also, the 'destruction map-change' must cover the whole village, whereas the change executed upon visiting only replaces the open village gate for a closed one. Getting the right tile numbers can take a bit more time than the list, even though it works in the same way as the tile numbers in the map data itself: the tiles are listed in order of appearance from the top left to the bottom right tile of the indicated part of the map that will change. There are no seperator 00's at all, as the list already tells the game how many tiles to 'read'. Anyways, to find out the tile numbers of the change-able tiles after their change, you'll need to either consult a table like the one I showed you before (I haven't made tables like that for every tileset, so don't ask me for them >_>), or just use Mappy to export another .MAR with the tiles you need to know the numbers of all in one row, and then convert the byte pairs by dividing them by 8 (in hex!) to find out. Oh, and if a certain tile within the area you indicated in the list doesn't need to change, you can just put 00 00 in its place. Once you've finished your tile data and the list, repoint the pointer to it (the one in the pointer table, remember?), and your map should now be playable. Unfortunately, your chapter isn't, so you'll need to have a bit of patience and wait for the next two chapters before you'll be able to actually enjoy your custom chapter. =P -------------------------------------------------------------- END OF CHAPTER 1 ----------------------------------------------------------