|
BASIC HEX EDITING
Enough to get'cha switchin' bytes
If you're very new but very willing to learn hex or ROM hacking in general, then read this whole page - multiple times if necessary. You'll be setting yourself up to make full use of all resources on this website and, if you're creative enough, come up with some quality material of your own later on. Most of what you learn here can be applied to other SNES games and perhaps beyond if you're motivated and resourceful enough. How to edit hex bytes Types of hex edits Long hex edits Variable hex edits Sound hex edits Counting in hex/frames/pixels HOW TO EDIT HEX BYTES
1. Download the HxD hex editor (it's free). 2. Make a back-up copy of the Super Metroid ROM you want to edit (right-click on the ROM file > "Copy" > "Paste"). 3. Make sure the ROM has no header! SMILE can check for a header and remove it if there is one (in SMILE: "Tools" > "Header" > "Remove Header"). 4. For this example, we're gonna make all of Samus' beams travel slower by applying this particular hex tweak: 83968 - 22 97 B1 90 to EA EA EA EA (these will make sense later if you want them to). 5. Open the ROM in HxD, then click "Search" > "Goto..." and make sure that only the "hex" and "begin" circles are checked. Type 83968 into the "Offset:" box and click "OK."  6. Look for the blinking | that lets you know where you will be typing if you press any keys. It can be a little tricky to spot if it's near the very top or bottom of the window.  7. Notice that the | is sitting right in front of the values 22 97 B1 90. 8. Type EA EA EA EA and click on "File" > "Save" to finish. There you have it. You're all done. Test the ROM now, and you'll see that Samus' beams do indeed go slower. To undo the change, you'd simply go back to 83968, then replace EA EA EA EA with 22 97 B1 90 and save again. That's the gist of it. Easy stuff. Slowing down Samus' beams was a 4-byte static edit, which means it's a cut-and-dry "change this to this and go about your day" type of modification. There are others that are very long or are up to you to determine what the new values are. Let's go into those next. TYPES OF HEX EDITS
Static edits: ##### - ## to ## The most straightforward kind of edit and the best one to learn how to do first if you've never touched a hex editor before. These clearly mark where the bytes are, what the bytes are, and what they should be changed to for that particular edit to take effect in the game. They can be done in seconds after you memorize the routine, which is very easy. Variable edits: ##### - ## Exactly like static edits, except the new value is up to you - only the current value is given. There's no 'to' telling you what it should be. Most variables apply to how fast enemies, colors or other things in the game animate, but they can be just about anything else. Knowing how to count in hex and knowing what pixels and frames are is recommended for getting the most out of these. Long edits: #####-##### Mostly static, but I'm sure there are variables too. The idea behind long edits is the same, except making the actual hex edit is done a bit differently. Usually used for edits that are more than around 8 bytes long. Instead of giving an address+bytes like the above 2 examples, long edits tell you the beginning address+ending address of the bytes that you'll be changing. Sound edits: ##### - ## A combination of static and variable edits. Not much to explain here since you just pick the new sound from a set of lists that are included on the sound editing page. LONG HEX EDITS
Changes to the game can't always be made with just a few bytes. Some are well over 100 bytes or more. In the case of these, I list them with a beginning-to-end address instead of just the beginning address and a few bytes after it. The idea behind editing these is the same, but actually doing it is handled slightly different. Let's take a long edit and break down how to change it. This is a hex edit for Kraid that stops him from using those belly spike platforms during the fight: 13B832-13B867 - all to EA That looks a lot better than... 13B832 - BD 86 0F 29 FF FE 29 FF FB 9D 86 0F AD 7A 0F 18 7D AC 0F 38 FD AA 0F 9D 7A 0F BD AA 0F 18 69 01 00 9D AA 0F C9 20 00 30 0C A9 68 B8 9D A8 0F A9 1E 00 9D B2 0F 6B all to EA. So, how to go about making this change? Easy. All you need to do is select everything in the beginning-to-end address given so that "Block:" at the bottom of HxD says the same thing that our hex edit does:  Now just right click and pick "Fill Selection..." from the menu. In the "Hex-values:" box, type EA, then click OK. Now click on File > Save (or Ctrl+S) to save the ROM. This replaces all selected bytes with EA. Long edit complete. To undo a long edit, you can copy the selected bytes before filling them with EA (or copy the bytes from an unedited ROM) and paste them back in. SOUND HEX EDITS
These are simple. On the sound hex editing page near the bottom, you'll see 3 lists called library 1, library 2 and library 3. All you have to do is pick a new sound from one of these lists and replace the value as necessary. If the sound you wanna use isn't on the list that the sound you're wanting to change goes for, you can change the JSL to use another library. More on this later when I update that page. VARIABLE HEX EDITS
A huge majority of edits that we find are variables. These work exactly like static edits, except the values that you're changing can be one of different options in the description to pick from, or in the case of things like frames or pixels, the decision is totally up to you. Variables might seem confusing, but all you have to do is memorize a couple of little things and you'll have them mastered. Those things are mainly scales of reference. There can be an infinite number of different types. They can do anything from set how fast something animates, how fast something moves, how high something jumps, how many times a specific action is repeated, damage, X/Y-coordinates... you name it. Descriptions are your friend, but counting in hex is your lover. To take full advantage of everyvariable, soak in this next section. COUNTING IN HEX/FRAMES/PIXELS
Counting in hexadecimal I won't go into why numbers have to be dealt with in hex, so just roll with it. Hexadecimal is also known as base16, and decimal (which is what we normally count things in) is base10. The reason they're called that is because that's how high they can count before their numbers reach double digits. So, how does hexadecimal go all the way to 16 using a single digit? Letters, buddy. And zero. Here's what going from 1 to 32 looks like in decimal (dec) and hexadecimal (hex): Dec: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Hex: 0 1 2 3 4 5 6 7 8 9 A B C D E F Dec: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Hex: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F You don't have to memorize this if you don't want to. Not many are able to convert numbers larger than 2 digits in their head quickly (including me). Thankfully, Windows Calculator is able to convert between decimal and hexadecimal in a snap. When you run Windows Calculator, click View > Scientific. Now just check the "Hex" or "Dec" box, enter a number, then check the other box (hex or dec) to see what it becomes. If you don't have Windows Calculator, it shouldn't be hard finding a hex calculator somewhere else. A note on byte reversal for 3 and 4-digit values By this point going between decimal/hex should be no problem for you, but before this becomes an issue in the future, I'll take a second to mention byte reversal. Most of the time when you're given a variable, the value will be something like 06 00. It's actually read as 00 06, or 0006, or just plain ol' 6. For just about all animations, the 00 will be ignored. Even changing it to 01 is going to result in, for example 06 01 = 01 06 = 0106 = 106(hex) = 262(dec). This comes out to around 3 or 4 seconds, or 262 frames. I'll explain this in more detail a bit later. For now, since we can convert decimal/hex, let's look at frames and pixels. PAY ATTENTION INSECT, because almost all variables are determined by frames or pixels. Frames 'Frame' can have 2 different meanings, so I'll do my best at differenciating them right now because both frame types are often used and talked about together. There are animation frames and hardware frames. Animation frames make up the different graphics used for just about everything in the game that moves (Samus, enemies, bosses and others). Hardware frames are how many times (AKA how fast) the SNES is able to show something different in a second (AKA animate), which is 60, or better known as 60 Frames Per Second (FPS). Hardware frames are used for determining how long to show an animation frame before switching to the next one. If we take a common animation frame value like 08 00, that's 1 animation frame being shown for 8 hardware frames. This gives you a good basis of comparison on deciding new values for certain variables. 60 in decimal is 3C in hex (which is 1 second), so if you see a value somewhere that's 1C 00, you know right away that it's 20 less than 3C if you're counting in hex, which comes out to 32 less in decimal. 32 frames is almost exactly half a second (2/60ths of a second longer). Most enemies animate at about 05-0C hardware frames, which are the same as 5/60th and 12/60th of a second. This means each animation frame of their graphics will be seen for X number of hardware frames before switching to the next animation frame. If an enemy has 4 different animation frames which are each displayed for 05 hardware frames, then changing all of the 05 bytes to 03 will make them animate faster, and 02 would be even faster. 01 is the lowest value that can be used (1/60th of a second), and thus is the fastest you can make something animate. Using 00 will just freeze the animation. I explained all of that the best I could, I'm sorry. I put examples and stuff below to make it more clear. Pixels Pixels are the building block of everything you're seeing on the screen right now. The period at the end of this sentence is about 2 pixels in size. Every graphic you see on the screen while playing Super Metroid is also made from pixels. More specifically, drawn with pixel art, which involves zooming way in and making drawings with tiny squares. Pretty cool stuff. You'd be doing yourself a favor to get a good comprehension of how large pixels are, because they're also used as a way of measuring the distance and size of many things. Even outside of ROM hacking, pixels are commonplace. Here, have some perspective:  That's nice and all, but what's that have to do with hex? Lots of things. The distance from Skree that Samus must be within for it to drop from the ceiling is one of many ways pixel usage can apply. For pixel-related hex tweaks, you're not really gonna be seeing any actual pixels. Instead, they're mostly used as a way of measuring something. This next bit should explain the rest of it well enough. The edit for Skree is: 11C6E6 - 30 00 (Distance from either side of Skree (in pixels) until it flies down at Samus). From this you should already know that 30 00 = 00 30 = 0030 = 30(hex) = 48 pixels in decimal. Here's a visual:  If you wanted Samus to be twice as far away before Skree drops from the ceiling, you'd only have to multiply the value by 2 to have what you should change the value to, in this case 60 (96 pixels in decimal). If you wanted to halve the distance, then 18 (24 pixels in decimal) would be the value to use. Not every single value that handles distance will use pixels as a way of measuring it, but most will. If you're unsure, the best thing to do is just experiment by giving it a noticably higher value to see what happens. If the description doesn't mention pixels, but says that a distance is 10 00, bump it up to 60 00, save, test it and see what happens in the game, adjust the value as necessary based on what the results were in the game, save again, test the game again, etc. I try to give quick examples in the descriptions when I can, but they aren't always there. Pixels and frames often work together. Most variables are given to you in 2-byte pairs with 00 as the second byte (remember, you rarely need to mess with 00). A common example would be "0A 00." Skree's animation frame delays will work nicely as a way to explain this. 11C65E - 0A 00 [idle] 11C662 - 0A 00 [idle] 11C666 - 0A 00 [idle] 11C66A - 0A 00 [idle] 11C672 - 10 00 [about to dive] 11C676 - 08 00 [about to dive] Each value will almost always go to its own animation frame. Skree loops through 4 animation frames while it's hanging from the ceiling, and each animation frame has a hardware frame timer (or 'delay') of 0A, which means 10 frames in decimal. When Samus gets within range for it to dive down at her (which we went over earlier), Skree displays 2 new animation frames a single time for a delay of 10 and 08 hardware frames before it actually drops down. The animation of Skree hanging from the ceiling loops exactly 3 times in 2 seconds (SNES = 60FPS and 0A(hex) = 10(dec), meaning 4 animation frames @ 10 hardware frames each = 40 frames per loop x 3 loops = 120 hardware frames, which is 2 seconds). 1 second = 3C in hex, and 2 seconds = 78. You don't have to bother with calculating how long animations are playing like I just did, but understanding how to will probably help you with more advanced things later. So, if you wanted the Skree's animation to play slower, a reasonable change would be to replace all 4 0A bytes with something in the range 10-14 or a bit higher. A good estimate for a faster animation would be about 03-06, give or take. Deviation is encouraged whenever possible. Something like 03, 06, 08, 0D in place of 0A, 0A, 0A, 0A might animate nicely (or terribly, depending on preference), same with 27, 10 in place of 10, 08. No harm in playing around until something works. That wasn't so bad, right? |