skip to main |
skip to sidebar
January 29, 2010. A great day in history. By which I mean, one of the main obstacles to my creation of a Link's Awakening editor (which I have decided to call Zledit) had been conquered. I have discovered a way to edit the ROM byte by byte.
Actually, it was easier than I had thought. I was about halfway through the forger's WinAPI tutorial, when I decided to skip to the section about edit controls and skip to the part about editing files.
Now I had tried file input and output with file streams with C++ Standard Library streams, but I never was able to write single bytes. Even if I had, the file stream method would be all but incompatible with my plan for a WinAPI interface.
However. Through the discovery of the BYTE data type, the use of the & operator to pass a pointer value (and thus a greater understanding of pointers), and new knowledge of the SetFilePointer and WriteFile functions, I was able to win the battle.
But obviously, the war is not over yet, nor will it be for a long time. I still need to figure out how to (1) actually display things in the window, (2) load 2BPP graphics from the rom to the screen, and (3) set up functions and classes to make it work. We'll get there.
What I learned:
-How to get byte by byte access to the rom file.
What's next:
-2BPP graphics. Hopefully.
I come to you today with sad news from the Link's Awakening Hacking community (which, mind you, is like, ten people total). ZLADE, the Zelda Link's Awakening Dx Editor, as of the 24th, is now defunct, and will not be updated anymore.
This is bad, because ZLADE was the leading ZLA editor out there. Now, I have downloaded the last version of ZLADE, and obviously there is room for improvement, but it works, so I am sad to see it go.
HOWEVER. After taking a look at what ZLADE did wrong and right, I have ideas for my own editor. It will operate on a sophisticated class library. It will include editing dungeon objects and not be able to add more than the capacity of objects for each room without repointing, which is what ZLADE did that made one of my roms crash.
It will include warp editors, event editors, room sequence editors, pallette transition editors. It will have an option to export hex code for each room, so that people who knows whats going on with the actual code will have a better time. It will have an option to edit the overworld objects and tile data together with ease. It will have functions to erase EVERYTHING and start completely over with a new game.This I intend to do.
There are two logistic things standing in my way.
1. I do not know how to operate on a byte by byte basis with C++ and the Windows API. I am sure it is possible, but I have no idea what is consists of.
2. I do not know how to load 2 bit per pixel graphics from the rom into an editor. This is a big one. Fortunately, I have learned a way to display hex values on screen and work with them in the code.
So, today marks the death of ZLADE, but it also marks the time before the birth of another great editor.
After a week of finals, and consequently learning more about rotational dynamics than I will ever need to know, I was finally able to get back to hacking and programming. Great, right? Of course, no one ever knew I left, but what the hell.
Anyway, I had a revelation today. Look at Jigglysaint's hacking documents with a HEX EDITOR OPEN. When I read them for the first time, frankly I could not make any sense of anything he said. But at any rate, I understand now that the entire level data for dungeons and the overworld is referenced by room pointers. And all the sprite placement data is referenced by room pointers too! Crazy, right?
So I took off. I edited the raw hex data with nothing but notepad. And check out the first room of the tail cave: I think it actually looks pretty good.
So that's that. But this week is a double whammy, because I also learned a ton about Windows API programming.
Not only did I learn how to create, populate, and apply menus, I learned to use resource scripts to add in icons and dialog boxes. I downloaded a great free resource editor called ResEdit which actually worked great, seeing as MS VC++EE has no resource editor included...
You can see to the left my progress on the "editor" so far. I'm actually apprehensive of how I'm going to be able to apply this to a real editor. With Windows API, can I open any file and write hex code to a certain offset? Can I export graphics? Can I move controls at runtime? Argh. There is a long road ahead children.
What I learned:
-A whole hell of a lot about how the level data works
-How to use resources to create a whole hell of a lot of windows controls
-when editing images, using two hands on the touchpad of a laptop saves a lot of time
What's next:
-Windows: reading, writing files, and custom dialogs, etc.
-Overworld editing, dungeon and overworld pallette data, etc.
-Packing for a sub zero camping trip this weekend. URGH.
And just like that, the first step toward a fully complete and functional Link's Awakening editor has been taken.
That's right, kiddos, I have official performed (and it WAS a performance) the creation my first ever Windows API program. That program, of course, being an empty window.
I feel pretty proud of myself. Let's detail how it happened, eh?
About four hours ago I went to the Microsoft website and downloaded the Windows SDK. Actually, I downloaded one of many of them, but I just went with the defaults anyway. Screw instructions.
While it was downloading I checked facebook, watched some TV, went and had dinner, and by the time I got back it was done. Great.
Anyway. I copied and pasted The Forger's Hello World message box program into VC++, and it worked. Thus began a three hour long journey of copying, pasting, looking in the help files, writing the code for myself (which I figured I should do to help me retain it, but with the Window Class Properties I just could not bring myself to do it), and finally building. After I thought I had it all done, I compiled and ran it.
There were 38 errors.
But, I pushed through. Most of the errors were simple syntax, or idiotic capitalization of variables, and I realized that I had never learned to handle strings in c++ without string objects, so needless to say I needed a refresher. Anyway, it finally worked, and what you see at the top it the result.
I still don't know how Window Procedure functions are referenced in the main body of code, so if anyone is reading this who knows, I'd appreciate it.
Speaking of, a note on people reading this blog (whom at the present I am sure are 0):
I created the blog primarily to document my progress and to give myself a sense of accomplishment that would drive my hard work. I never expected anyone to read it. But, maybe after a few more posts, I'll spam Mystery Google with it or something. (I wrote a Greasemonkey script for that.)
What I learned:
-Losing Windows API virginity should always be done with the condom of the Microsoft SDK and extensive help files.
-What handles are, how windows behave, and the basic structure of the Windows API.
-Ham and cheese omelets for dinner are delicious.
Up next:
-Minimap Pallete and Behavior Data editing.
Goodnight, all, and I wish you good hacking dreams.
...okay sorry, that was creepy.
Well let me tell you, this is certainly going a lot better than the last time.
I started off with a simple task: edit the graphics of the minimap. It seemed simple enough: there was a mention of it in linscape99's notes, and I figured it would be pretty easy. So I found the offset, edited a few numbers, and saw what happened.
Once the game loaded up, and I figured out the the backspace button on my laptop corresponds to select to open the minimap, I realized that in order to test my data, I would have to actually "defog" it to see the whole thing.
Luckily, I'm lazy. After twenty minutes of messing around with the SRAM editor in VBA, I managed to set the map to all defogged, and to spawn myself in the upper left corner. (I had messed around with the SRAM last time also, so it came back quickly.)
I change the first three bytes of the offset where the data is supposed to be, reload the ROM, and BANG!! IT CHANGED!! Needless to say, I did a huge fist pump.
See, this was really a big turning point for me, as I hadn't accomplished anything before this. This was the maiden hack, if you will.
Anyway. I copied 64 bytes from the hex code into notepad and formatted them into a map. I closed VBA and found an image of the minimap online. Then, I set off to write down all the codes for all the squares with a "YES! IT WORKED!!!!!! Time to document." (THAT is a direct quote from my personal notes.)
An hour later, and it was done. I copied the hex map I'd made in notepad and started editing away, and the image at the top of this post is what I have to show for twenty minutes worth. As you can see, I've added a second castle with another Windfish Egg at the top of it, as well as replaced the forest with a witch's hut, and vice versa. A working storyline? Link goes into the future, clones the Windfish and brings back another Egg, but only to find a society raging with civil war between the extremist policies of two conflicting monarchs? I THINK SO.
What I learned:
-Where the minimap data is in the ROM!
-How to make a hex map in notepad
-How long it takes to make a table file for tile graphics
-How frustrating it is to edit image files in MS Paint with a touchpad laptop.
Up next:
-Minimap behavior editing
-Hello World with Windows API
Time for bed after a successful day.
Today is January 10, 2010, and I am going to attempt a ROM hack of The Legend of Zelda: Link's Awakening.
Now, mind you, this is a big deal, because I have attempted something like this in the past. A year ago, I failed, but this time, building on my experience, I'll see if I can't succeed. To the best of my knowledge, there is no complete hack of this game as of yet. There will be.
The challenge is this: Hack the Zelda ROM and create, using Windows API, a fully functional editor program. Then use the program to create a full Zelda hack and release it to the public.
What I will learn: First, how to ROM hack. I am really interested in this and also the experience it will give me with computer programming and file manipulation.
Second, how to use the Window API. I have learned a little bit of C++, but I grew tired of making only black and white console applications. The Zelda editor will be coded in pure C++ using the Windows API (and also SDK). The big challenge here, obviously, is learning WinAPI, so I will be using The Forger's tutorial to start and the references that the SDK provides for more complete functionality.
Third, a basic knowledge of the assembly language. That's right. Assembly, the motherload, the king of ROM hacking languages. With assembly, I've been told, it is possible to directly edit the game's engine, create new AI, new enemies, new bosses, new everything. This is going to be the BIG ONE. It's time to finally find out how much the legend can do.
What I will be using:
The ROM: a clean version of the ROM for LoZ:LA that I used a year ago. I donwloaded it from the internet previously.
The Hex Editor: HxD, a free hex editor that i have heard, based on reviews, is very good. I used Hex Workshop the last time, and I am hoping to improve.
The C++ Compiler: Microsoft Visual C++ Express Edition 2008. I used Dev-C++ last time, but I think that VC++ has a better IDE and will suit my interests as far as learning the Windows API nicely.
The Emulator: Visual Boy Advance. I have used this previously, and it is the best one.
Hacking Documents: Both my extensive (read: wordy) notes from last time, Jigglysaint's hacking documents for this game that I found on Romhacking.net, and Linscape99's notes that he sent me after I commented on his Youtube video. He has also written an editor called ZLADE. You could say I'm following in some footsteps here. But also I'm not, because I plan to hack LA with assembly. And, if possible, have a direct asm editor in my editor.
Those are the goals. Those are the challenges. Without further ado, let's get to it.
