Banon's Donkey Farm > General Discussion
State of the Sketcher
13375K31C43R:
Hi everyone! Time for a bit of a serious discussion.
It's now 2018, which means this year will see my third anniversary of FF6 hacking! I don't know yet whether I will release a new Anniversary Pack as I have done the past two anniversaries, mainly because I've only released four new patches since my most recent anniversary (five if you include Count Monsters for FF5). But I'm not here to anticipate or look ahead; this is instead a time for reflection. My FF6 hacking portfolio shows that I have made a total of 70 patches, and out of those all 70 are applicable to the SNES version, 68 are applicable to the SFC version, 26 to the GBA version and 14 to the PS1 version! I have to say I'm very proud of myself for all the work I've done so far and I am so grateful to my supporters and contributors for all the help you've given me! Thank you all very much! :childish:
On a more serious note, however, I anticipate that I will be much less active this year because I have to focus hard on school and work, and I will have little to no time available for hacking. To give some context, I just finished making a small but important update to Dead in the Air, which in turn affected Soul Saved, and I decided that it would be a convenient opportunity to port those two patches to GBA as well. It ended up being a successful and positive accomplishment, but far from convenient. I wanted to have the ports finished before New Year's, but it took me two weeks longer than I expected.
GBA hacking is much different than SNES hacking when it comes to this game. While the GBA version does its best to align its RAM in the same manner as the SNES version to maintain some semblance of recognition and similarity, the ARM Thumb assembly language that makes up the code of the GBA version is entirely different than the SNES assembly language. It requires multiple ARM instructions to simulate one SNES instruction, making GBA hacking much more arduous and time-consuming. To give some perspective, the non-headered SNES fix patch for Dead in the Air is 504 bytes; its US GBA equivalent is a staggering 2.43 kilobytes!
I would love to port as many of my patches to GBA as possible this year, but unfortunately I can only do as much as my busy schedule will allow. Don't be surprised this year to experience gaps between updates that are several months long. If a flaw exists in one of my already-existing patches, you may still feel free to send me a message and I will fix it ASAP, but as far as my own agenda goes, it's going to be a long and slow climb to that higher peak. Here are some of my patches that I would most love to port as soon as I get the opportunity:
* Caravaggio
* Game Over
* Half Knife
* Imp's Call
* Imp's Retort
* Item/Magic Counter
* Stone Zombie
* Throwback
* Ultimate Damage Fix
If anyone feels like helping me out with these ports, I will be so thankful to you and I will continue to appreciate every bit of support and assistance that comes my way! Here's to a successful and enjoyable 2018!
Squall:
--- Quote from: 13375K31C43R on January 16, 2018, 01:59:04 AM ---My FF6 hacking portfolio shows that I have made a total of 70 patches, and out of those all 70 are applicable to the SNES version, 68 are applicable to the SFC version, 26 to the GBA version and 14 to the PS1 version!
--- End quote ---
:whoa: That is quite some patching!!! Congratulation and Respect!!!
May I ask you what tools you used to do all this work? I'm mainly interesting in what compiler& editor you use for SNES, but whatever make the life easier will be very welcome too. Also doing whatever patch would require a good source of info for SNES hardware and FF6 internals (structures, addresses,...) could you share that too? (lets say the primary sources of info)
Since, this is a time for reflection, my personal goal is to add Scene (event), Spells and Attack Animations to my Viewer. Imagine, you could watch Galuf and Bratz learn that Faris is a women. Or how Blizzaga animation looks like. Or how Excalibur swings. Similar to you, I don't restrict myself to specific version (SNES), rather seeing it in all worth mentioning versions (GBA). Unfortunately that is vast uncharted area in FF5. Since FF5 is close to FF6 (as internals) maybe learning about FF6 will help me in FF5 ...
P.S.
--- Quote ---If anyone feels like helping me out with these ports, I will be so thankful to you and I will continue to appreciate every bit of support and assistance that comes my way!
--- End quote ---
Maybe asking for specific needs will help :D
13375K31C43R:
--- Quote from: Squall on January 16, 2018, 04:45:43 AM ---May I ask you what tools you used to do all this work? I'm mainly interesting in what compiler& editor you use for SNES, but whatever make the life easier will be very welcome too. Also doing whatever patch would require a good source of info for SNES hardware and FF6 internals (structures, addresses,...) could you share that too? (lets say the primary sources of info)
--- End quote ---
For editing, I've found nothing to be more effective then simply using a hex editor to hack the snot out of the ROM. I use the disassembly docs hosted on Slick as a reference for the code that is there that needs fixing. For addresses and such, there are ROM maps and RAM maps posted in various places that you can find easily with a quick Google search. The most useful ROM map for me is Terii Senshi's; it's available to view on his website, which I am linking here.
The only patch I think I've made that required more in-depth knowledge of the hardware is Map Mishap because that includes editing values used by the graphics processor. I use this site as reference for all my knowledge about how the graphics registers work. The Super Famicom dev wiki also has a lot of useful information.
GBA hacking is much more of a pain. There aren't disassembly docs I can find like there are for SNES, so instead I use NO$GBA, which is an emulator/debugger/disassembler. The code is disassembled in 16-bit ARM Thumb, so I have an instruction reference handy that I found online via Google.
--- Quote from: Squall on January 16, 2018, 04:45:43 AM ---P.S.
--- Quote ---If anyone feels like helping me out with these ports, I will be so thankful to you and I will continue to appreciate every bit of support and assistance that comes my way!
--- End quote ---
Maybe asking for specific needs will help :D
--- End quote ---
Ah, yes. Sorry about that. :isuck:
One thing that would really help is if someone could confirm if Game Over actually needs a GBA port, i.e. if the bug that it fixes is also in the GBA version. When I debugged and died on the overworld map, it looked like the event pointer stack was indeed filling up, but even after 52 deaths there didn't seem to be any adverse effects on the game, unlike when I was testing on the SNES version and it froze.
:edit: Same thing goes for the other patches on the above list.
Squall:
--- Quote from: 13375K31C43R on February 02, 2018, 09:33:34 AM ---For editing, I've found nothing to be more effective then simply using a hex editor to hack the snot out of the ROM. I use the disassembly docs hosted on Slick as a reference for the code that is there that needs fixing. ...
--- End quote ---
O boy, you are second person that have done extensive hack work and I respect, BUT is using just hex editor ... was that a trend or a guru told you that is the way :laugh:
C'mon guys that is so obvious low productive ... that is even hard to explain. Its like you have to move weight from floor 1 to floor ... lets say 5. Obviously you can move the weight by hand. Or use a specialized tool created for that job like winch, windlass or lift. When it comes to move just few kilos/pounds by hand is ok, but what about when you have to move 100? or 1000? Obviously you still can do it BUT its HIGHLY inefficient - it will cost you so much effort, so much time.
Exactly the same is doing it with a hex editor. Sure you can still do the job, but the cost, the time, the probability to make error is more then 100%. Instead of focusing on the real thing like algorithm, you have to keep track for trivial things like: did I enter the right opcode? Did I used the right addressing? And when you want to insert a few bytes you have to manually reevaluate all relative branches ...
13375K31C43R:
--- Quote from: Squall on February 21, 2018, 06:49:37 AM ---C'mon guys that is so obvious low productive ... that is even hard to explain.
...
Exactly the same is doing it with a hex editor. Sure you can still do the job, but the cost, the time, the probability to make error is more then 100%. Instead of focusing on the real thing like algorithm, you have to keep track for trivial things like: did I enter the right opcode? Did I used the right addressing? And when you want to insert a few bytes you have to manually reevaluate all relative branches ...
--- End quote ---
You're probably referring to assembly code, because for everything else I don't have much of a choice. And even for assembly code, I find it best to devise a working algorithm before I start editing, and by working, I mean it does the job the way it's meant to AND fits within the allowed space, or if free space is needed, uses as little as possible. That means I actually write the code in an accompanying text file, including the bytes that make up the commands, before I even start editing. That way I can visualize all the bytes that are there and make sure that the algorithm doesn't use too much space.
I just find that better than writing just an assembly file and using that to make a patch (I'm aware that there's a program out there that's written specifically for that purpose) because A) that means I have to learn the right/best way to write the assembly file to make it work as intended and B) I can't be entirely sure how big the fix is compared to how much space is allowed. Yes, counting and re-counting bytes may be tedious, but it's worth it to make sure it's done right. In most cases I even find it easier to follow, believe it or not, which is important when I manually step through it to check all possible routes that could be taken through the logic.
Navigation
[0] Message Index
[#] Next page
Go to full version