Just a Heads Up

Well, I decided I'm going to take a break and not really work on project til mid next week. Sorry for the inconvenience, but I just don't want to work on it until school's out.

Another No-News Post

Nothing has happened today. I learned some new stuff that will advance the editor in the future, but I haven't touched one piece of code. Tomorrow being Friday, I will be able to get work done without the trouble of school. Sorry for the short post, but like I said, I wanted to get one every day.

See you tomorrow!

A Bunch of Things

Well, I've finished up pretty much everything on interactions, and now it's time to finish warps. For a full list, you can add new interactions, delete existing ones, or delete the whole map's interactions altogether.

But now some bad news. Jigglysaint, the pioneer of these games, has informed me interactions have different events based on the maps you're on, which is not good for hacking. However, it's not really time to worry. I haven't debugged anything passed basic loading in the overworld, so hopefully I'll figure it out soon.

I spent a bit of time trying to find chest data today, but it was worthless as I couldn't even find it in the memory (This is how I discover the majority of things I find). I also found out even if maps had walkable tiles connecting to the right and bottom edge of the map, you couldn't access them, as the game doesn't even let you exit the other map.

One last thing I want to cover is with this editor, I want to include a graphics and tileset editor. I'm going to most-likely have to once again add an ASM hack, but this is to allow bank indexes to be used, since the uncompressed graphics would be going in the new ROM space. I'm sorry if the fact that there are going to be several ASM hacks in the end, but this just makes the editor more powerful and editing much easier.

So that's all I wanted to cover. School is finally dieing down as I'm taking my finals soon, so once I'm on break there will likely be heavy updates daily. See you tomorrow!

Keeping You Posted On...

Nothing! Today, nothing got added to the editor. The IDE wasn't even opened, and the project wasn't even executed. I've had a long day and it's only going to get more stressful this week. However, next week starting Thursday I will be out of school for the summer (I'm currently in 9th grade if you're wondering). Anyways, see you tomorrow!

Interaction Adding And Removing

Well, this is a small update, but not much work was done on the editor today. I decided to take a break as this is my last full week of school, and as you can imagine, it's stressful. However, the editor now has the capability to add or remove interactions to a map, as there is plenty of space at the end of the bank. The next update will include full warp editing, so wait for tomorrow for the update on it.

Holy Crap! For Real?!

Yep! You heard it here! Click-and-set editing now works for every single map. This means we can now customize hacks to the fullest without a single worry of needing space (*Offer does not apply to interactions and warps. See inside for de... oops!). There are current 3 ASM scripts being written. I have basically kicked out compressed dungeon loading since the game originally did not support fully uncompressed dungeon data. Here's the 2 major scripts (The other one is a modification of an existing one to call one of the scripts).

ROM0:3EF8 D5 push de
ROM0:3EF9 E5 push hl
ROM0:3EFA C5 push bc
ROM0:3EFB 3E 54 ld a,54
ROM0:3EFD EA 22 22 ld (2222),a
ROM0:3F00 21 00 40 ld hl,4000
ROM0:3F03 FA 2D CC ld a,(cc2d)
ROM0:3F06 DF rst 18
ROM0:3F07 2A ldi a,(hl)
ROM0:3F08 66 ld h,(hl)
ROM0:3F09 6F ld l,a
ROM0:3F0A FA 30 CC ld a,(cc30)
ROM0:3F0D 06 00 ld b,00
ROM0:3F0F 4F ld c,a
ROM0:3F10 09 add hl,bc
ROM0:3F11 7E ld a,(hl)
ROM0:3F12 C1 pop bc
ROM0:3F13 E1 pop hl
ROM0:3F14 D1 pop de
ROM0:3F15 5F ld e,a
ROM0:3F16 AF xor a
ROM0:3F17 7C ld a,h
ROM0:3F18 E6 80 and a,80
ROM0:3F1A C8 ret z
ROM0:3F1B 7C ld a,h
ROM0:3F1C D6 40 sub a,40
ROM0:3F1E 67 ld h,a
ROM0:3F1F AF xor a

ROM0:3949 11 00 CF ld de,cf00
ROM0:394C 2A ldi a,(hl)
ROM0:394D 12 ld (de),a
ROM0:394E 1C inc e
ROM0:394F 7B ld a,e
ROM0:3950 FE FF cp a,ff
ROM0:3952 C8 ret z
ROM0:3953 C3 4C 39 jp 394c ;I'm aware this could have been jr, but space was not an issue and BGB doesn't assemble it the way I want it to

So nothing to particular interest, but I thought maybe someone would like to see it. Here's some proof of the dungeon editing:



As usual, thanks for reading and hope to see you tomorrow!

Click-And-Set Overworld Editing

That's right! I've implemented click-and-set overworld editing. After going through a crap load of trial and error to get it all right, the editor now expands the ROM, decompresses all overworld (Small, actually) maps, and makes the maps ready to edit.

However, it wasn't just that simple. I had (Sorry, but it had to be done) to make a custom ASM script and change the way it gets the level data address. Basically, now it writes the bank of where the map data starts, since a region carries over to another bank. The only other thing I have to point out is the editor isn't very efficient with the 64 banks added. Each region gets 2 banks for map data, and there are 2 banks dedicated to map addressing. But, don't worry! You don't have to do anything. The editor will automatically expand the ROM, fix the header, and insert the ASM script.

Here's a test edit.


So as you can see, everything works great. You just click a tile and click where you want it on the map and it appears just like you want it to. Up next I'm working on dungeons. Let's hope they're not too much of a pain!

The News That Will Spice This Editor Up

Well I'm so excited I can hardly type up this post. After giving it some real thought, I realized I could give the editor click-and-set editing! This means no more worrying about compression! However, due to space problems, the ROM will be forced to be expanded up to 2MB, which is adding 64 banks. However, this is way more than needed. The dungeons, which need 176 bytes per room, need 176 * 512 = 90112 (0x16000) bytes, which is only 5 1/2 banks (Excluding some stuff). The rest of the rooms, which need 80 * 1024 = 81920 (0x14000) bytes, which is only 5 banks (Again, excluding some stuff. Don't worry, it's nothing major). This leaves up 54 banks to do what we please.

Sorry, but ROM expansion WILL be forced and applied as soon as you open your ROM, along with the decompression and repointing of each room. It's not like this is a bad thing. It's much better than being stuck with compressed rooms. And besides, dungeons were barely editable the way they are compressed anyway.

So hopefully you're just as excited about this news bit as I am, because this will make hacks 100 times better in the future. Thanks for reading and expect another post tomorrow!

The Final Post On Warps

Well, after about checking this out for maybe 5 hours (You have to keep note that I tend to slack off... a lot...), I've grasped the way side rooms work. The first byte is unchangeable, but doesn't effect how we edit warps. Infact, I don't see its use. Anyhow, the second byte is the source map. There is no source group (I will be calling this region after this post) because side room use virtual group 6 (Note: There is no real group. This saves about 2 bytes in terms of instructions without using bit 5,a). The third byte is a reference to the warp data, like other warps, and the last byte is the same nybble-encoded byte (Will be explained below).

The reference byte (03) refers to data as follows. The first byte is the real destination map, the second byte is the destination location (I still keep my warp-tile theory as it HAS been seen), and the last byte controls the room-enter type. For example, 03 is facing up, 04 is facing right, 05 is falling from above, etc...

Now the last byte is nybble-encoded. The first nybble controls the destination group (region), whereas the second nybble controls how you enter the warp (Or exit the room rather). For example, 03 (If I remember correctly), is a straight-forward switch to the map. 04 will move you up a little bit as if climbing up a ladder.

So my plans and previous interpretations were incorrect. The warp editor will have its second phase started Saturday, May 15th (Some may call it tomorrow, others today, as it's currently 4:54AM here) and hopefully started then too. Thanks for reading and stay tuned for more updates!

Warps - Yes, More About Them!

Good news everyone! I've completely cracked the data format for warps, and found out why rooms with working stairs in dungeons don't have real warp data. You see, to save space (And let's thank Capcom for this wonderful space-saving yet hack-friendly method), dungeon rooms without warp data will take whatever the room you're in and the position of the warping tile and add or subtract 64 (Depending on the tile. For example, if it's a staircase leading up, it will add 64) from the current room. This is great because hackers won't have to worry about space, and if they DO want to make the staircase lead somewhere special, a simple warp can be added.

Side rooms seem to be different, though. They use a separate loading procedure, which means their format is different. However, its format was how I predicted. The data only contains the 4 bytes. One byte is for... well, it seems to have something to do with data at 0xF8, another for the warp-containing map group (With some special formatting, that I'll leave up to the user to figure out. Trial and error is small price to pay, as it's pretty simple), one for the destined map, and then finally a nybble-based byte controlling the destination group and entrance type. So you may be wondering: How does the game know where to place you? Well, to save about 20 bytes total of space (Damn Capcom...), it loops through the level data until it finds a stair tile (Regardless of the direction). If it can't find one, it finds an entrance. If it can't find one of those, well, I haven't gotten there yet, but I'd imagine it finds some other warp spot.

So this blog was kind of crowded. All-in-all, I've figured out warps completely and should start, if not finish, the warp editor by tonight.

Brainstorm, Brainstorm, Brainstorm!

There hasn't been much progress recently, as I've been unsure on how to make a warp editor. As the warps aren't exactly the prettiest thing, it's hard to make a flexible editor that's easy to use. However, thinking about it has gotten the main idea done. You can see in the screenshot here what the main window looks like.



It's not done, but you get the idea. The "Follow and Edit Warp" button will open another window containing the real warp properties, as it would be too crowded and terrible in the same window.

All in all, there's not much to blog about today. Stay tuned until tomorrow to see progress, and expect it done by this Monday as the weekend is coming up!

Warps and More About Interactions

Well, today's update is mainly about warping. But before I get on about warps, I'll be talking about interactions.

Continuing from my progress yesterday, I've finished everything I need for interaction loading. The editor has the ability to edit existing interactions, but you current cannot re-point, add, or delete any. With the aid of a hex editor, I was able to learn more about certain interactions. It turns out, tree seeds depend on tile 34.



The unknown values to seem to be a constant 00 on trees, but since the interaction type is used for the growing grass that spawn seeds, they might control those.

Anywho, I've cracked the format of warps (Has only been testing on overworld maps). Needless to say, the format is just as bad as everything else in the game. Compressed? Almost. However, the ability to on-screen edit them won't be added. Instead, a separate window called a Warp Editor will be. You see, there are 3 types of warps. One type consists of a plain warp point for every warping tile in the room to use. This is why you'll notice using a walk-through-walls code and entering, say, a chimney will take you to the same spot as a door (in some case). On the other hand, there's another type that's a waste of space, yet Capcom insisted on using it. The type starts by defining the current map of the warp. Then there is a pointer that points to a set of data controlling the position the warp point is at, followed by the destined map group, location, and map. Sadly, instead of using pointers for every map, the game must loop through every warp until it finds one matching the current map's properties.

So you may be thinking warps will be a pain to edit. But, like everything else, my editor will deal with them easily. It's just one less feature (on-screen editing) the editor will have, but really just make editing take one more step.

ZOLE - Interaction Loading and a Boost to the Current Stage

Welcome to the first post on my blog. Obviously, this site is primarily directed to (GB/C) Zelda hacking. My current project is a Zelda Oracles (Current vaguely working for Seasons) level editor.

Anywho, level viewing is perfect. It currently loads dungeons (big rooms) and overworld maps (small rooms). There is no saving, but like every other tool, viewing always comes first!

So I finished interaction loading a bit ago. Some might call them sprites, some events, and others NPCs. Interactions is a word I chose to sum up both. Here's some screenshots of what they look like in the rooms.

View the Screenshot (Big Image)
You can view a screenshot showing only 4/16 types of interactions. You might be wondering why they're simple colors, but the opcodes are actually a partial pointer pointing to code in the same bank ($12), which may be followed furthermore. Because actually recreating a Z80 emulator in C# would be out of the picture, the editor just shows the sprites as blocks to show you they're there (These are the 8x8 blocks). The 16x16 blocks actually draw at the position they would appear in-game, as the sprite data contains a position.

This may all seem complicated at first, but you'll see how wonderful this engine is for hacking. We can add trees anywhere, our own dungeon warp points, enemies wherever we want, portals, bosses, events, switches, and many more without a big hassle. For example, here's a small hack I did placing Twin Rova in a regular overworld map.



Flexible enough? To top things off with of good news, sprite sets are nonexistent! This means we can throw whatever we want on any map.

The only real bad news about this game is the compression. The graphics and tileset assembling data is compressed beyond the ability to edit. The level data compression is compressed, but good enough to edit it. Repointing is rather out of the picture (sadly), as the small room's compression type also effects the pointer, but a future feature I will add will allow you to swap rooms to get what you want in a room where you want it. Editing won't be a dream, but flexible enough to make a good hack.

A long post, but you're informed of the project. I hope you readers visit my blog often and catch up on most-likely daily filler info!