News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Lin

Pages: [1] 2 3
How have I not seen this? It's been an idea I've had flowing my mind for a good while now but I never actually thought it would be practical. The features you have listed so far sound great and and I'm a bit disappointed to see it's over a year old. Keep up the good work anyway.

Well, from a ROM-hacking standpoint, the Oracles are much more free and editable. They're way more organized in regards to tilesets and all forms of data, and the "interactions" and other pointer tables allow any script or assembly procedure to happen safely without any actual original assembly edits. LA hardcodes a lot of map-specific events that you're stuck with unless you know Gameboy assembly (PS If you do get into that stuff I'd recommend my assembler. Despite GUI and some disassembler issues, it's unfortunately the only assembler to support dynamic addressing).

But enough that. I'd be happy to beta test and I'm pretty sure Fatories too would if he's not too busy. We know specific things to look for just because of how much we've worked with the games. I could try and get in contact with Jigglysaint too if you'd like.

I'm glad to see people are taking advantage of LALE and actually making hacks (*cough* why you'd choose LA over the Oracles is beyond me though...) When I get the chance, I'll be sure to check it out.

Also, LALE should include some sort of documentation on how to visit its forum/irc channel if you ever need help with stuff.

Personal Projects / Re: Zelda Minish Cap Level Editor
« on: January 01, 2013, 11:21:35 pm »
This would be really nice! Are you planning to allow the user to re-arrange properties related to Kinstone fusion events? (i.e. the locations of monsters and treasure chests that appear as a result of fusing)
Oh yeah, I forgot about those. More than likely yes, although it all depends on how they work.

Personal Projects / Zelda Minish Cap Level Editor
« on: January 01, 2013, 10:02:29 pm »
Recently I played Zelda Minish Cap for the first time and after getting through the first dungeon I realized the game was just like the Oracles and needed a level editor. I've only attempted GBA hacking once before but regardless I dove right in and now it's a project that's made decent progress. Right now it only has map viewing, which I'm pretty sure is flawless but I'm not entirely sure since I haven't even beaten the game yet! Here's a screenshot.

The layout isn't official or anything but to actually get the maps displaying took a few days. The compression used is the regular GBA LZ77 for everything. Before releasing it, I plan on having the basic stuff for a hack - character editing, warp editing, map property editing (I already have this data figured out), connection editing, level editing (obviously), chest editing, and anything else I feel is necessary.


ROM Hacking Discussion / Re: So, what would it take to make this a reality?
« on: November 11, 2012, 10:51:20 pm »
The only oracle editor I can think of would be ZOLE, but it's still under development and robably won't be released until finished.

The pertinent link is:

You might want to ask them just what's feasible or coerce them into a prerelease copy.
Alright. Lots to say here. First off, ZOLE has been released and periodically updated over the past couple of years. You can get it and other tools like a script editor and text editor at the official forums for it (don't get the build on this site since it's outdated) - (I'm sorry if it's not okay to advertise it). Second, you will need assembly knowledge if you want to make a decent and unique hack. A good amount of knowledge about the games, like memory addresses is highly recommended, since if you don't want to do a lot of assembly hacking, you can at least do cheap hardcoding hacks using ZOSE as long as you have the appropriate memory addresses.

Third, a guy named Luigi has been working on an Oracle of Hours hack for a while. It's not very good with attention to detail, but he's had a lot of help from Jigglysaint so a lot of out-of-ZOLE work has been done. The project page for it is here:

Now for ZOLE stuff - You can make a full-fledged hack using all of my tools (but you'd be limited to how unique things are), but you'll have to learn to look at how the game does stuff since me and other people never really wrote tutorials. It applies a lot of assembly hacks to allow things like uncompressed maps, uncompressed graphics and tilesets, 3-byte pointer jumps for scripts, special script commands, and other cheap hacks to make work for me and other people easier. Most of the features only work for Oracle of Ages because I never wanted to write the assembly patches for Seasons. That might change soon.

There's a great deal of knowledge I and Fatories know about the games but keep to ourselves, so if you ever have questions, please don't hesitate to hop onto ZOLE's IRC channel ( #ZOLE). I almost want to say the only other people who know as much or more than us are Jigglysaint and maybe Dwedit, so please feel free to ask us for help.

Also, yes, Oracle of Nature has been abandoned. Lots of stuff to explain but I'll just leave it at that. If you want anything of the sort that it had, lots of scripting and assembly hacks will need to be done, since the scripting engine in the games is only so powerful.

So in conclusion, this is totally doable right now (at least in Ages) by using ZOLE and the other tools I've made. It might be hard to make the weapons and custom blocks, but other than that it's definitely possible. Like I said, join the IRC channel for any questions.

EDIT: Oh and I forgot to mention - I've spoken to Jonathan Leung quite a bit and he's okay with people making fan games for it. He doesn't remember the storyline or much about it so you're on your own for that sort of stuff.

EDIT 2: If you're interesting in a community project, you'd definitely be interested in ZOLE Live - It's basically a Google Docs version of ZOLE 4, where multiple people can work on the same ROM at once while their edits appear to others in real time. The public build is outdated and buggy so ask me for the latest build if you're interested.

Programming / Re: Preferred Lauguage to code a RPG
« on: July 14, 2012, 06:21:10 am »
I recommend C#/XNA from experience. Excellent performance, great flexibility, and it's very easy to use and distribute.

Personal Projects / Re: Gameboy Assembler Plus [Released]
« on: July 04, 2012, 07:22:50 pm »
Actually, on an unrelated note, I'm thinking of improving the assembling stuff I tacked onto my own disassembler. Haven't had much time to work on it, though I ended up learning a lot from the process. Good luck with making your program the best :)
Awesome, and thanks!

I have finally finished this. It's got everything I want (Except a toolbar, which I might add) and should be ready for release very soon. I'll be sure to post a reply if possible or edit the topic when I've uploaded it to the site.

Edit: This has been released. Check the OP for details.

Programming / Re: A Plugin-Based Level Editor
« on: June 14, 2012, 11:08:25 pm »
Well, things would be easier to program, other people could develop plugins or change things they don't like, ZOLE would be neater, and all the other Zelda Oracles tools I've made would be inside ZOLE and wouldn't require reloading the ROM. At this point, I think I'll be making a new version of ZOLE from scratch and this is the system I want to implement.

Programming / A Plugin-Based Level Editor
« on: June 14, 2012, 07:43:42 pm »
Recently, I've been wanting to work on my level editor for the Zelda Oracles games, ZOLE, but because there's two versions of it, adding features is quite the pain. I've had an idea to create a new version of ZOLE that runs completely off of plugins, with some core stuff for showing the map and other additional information. That way, once I integrate the core for the other version, they both would use the same plugin (Plugins could be things like a chest editor, a text editor, or even something that launches a hex editor and automatically notes the changes). I would make the cores of each version override-able, so if someone wanted to, for example, hardcode sprite loading for certain interactions, they could. That said, anybody would be able to add something to the program and either keep it for themselves or share it. It's much more easily modified than just editing the source for ZOLE.

I want some feedback on this. My friend says it's quite useless, as nobody else would develop plugins but me, but I still see it as a big shortcut in the future and the idea just seems cool. What do you guys think?


News Submissions / Re: ROM Hacks: New Hacks Added to the Database
« on: June 14, 2012, 01:14:43 am »
Oh? They're different engines? That's interesting; I was always under the impression (from magazines, I suppose) that it was the same engine. Maybe I got it confused with Majora's Mask/Ocarina of Time? I don't know.

It is good to know that LA's graphics are uncompressed... although, what do you mean they're limited in the overworld?
Yeah, there's a lot you can read on it. Very interesting.

I mean there aren't very many unique tiles in the overworld compared to the Oracles, although that really has nothing to do with what you accomplish... :P

News Submissions / Re: ROM Hacks: New Hacks Added to the Database
« on: June 13, 2012, 03:13:20 pm »
Hmm. Interesting. I was expecting it to look similar, but it only has a passing resemblance. It's interesting how two games with the same engine, with nearly identical graphics, can look this different.

Nuts, now I'm interested in seeing Oracles graphics completely ported over to Link's Awakening. I don't remember if LA's tile sets are compressed or not. I could do it myself with TLP...
Oh, believe me, they don't have the same engine at all. On the inside, they're like two totally different games. LA's graphics are uncompressed, but they're very limited in the overworld. ZOLE has a tileset editor for Ages, which shows the tileset's original tiles if you wish to give it a try. I'd recommend changing the palettes as well, because they make a big difference.

News Submissions / Re: ROM Hacks: New Hacks Added to the Database
« on: June 12, 2012, 11:51:31 pm »
I never realized that the Link's Awakening font was that bad. I played that game over twenty times, I love it to death... yet, I didn't notice the font was bad.

Yet, now I see that I actually like Oracle's font in Link's Awakening. Maybe it's because it makes the game look a bit more modern?

Now I wonder how Link's Awakening would look like with Oracle's tilesets... (and yeah, they ARE different!)
Early on when I was working on ZOLE, one of the first things I did was make a few LA maps in Ages. Here's how it turned out:

Personal Projects / Re: Wario Land 3 level editor
« on: June 11, 2012, 11:03:06 pm »
Awesome! You beat me in terms of progress. A long time ago I decided to take a shot at it, even though I've never played the game, but I managed to get somewhat far: I couldn't really figured out the mess of tiles or room order, so it's nice to see someone else could!

Personal Projects / Re: Gameboy Assembler Plus
« on: June 04, 2012, 05:42:21 pm »
Well that 10 seconds is for over 2000 lines. This tool is mostly to edit existing procedures, which would never span more than a few hundred lines anyway. The only reason the disassembled procedure was over 2000 lines was because of how the disassembler traces addresses in the 4000-7FFF range, and I set it to disassemble from 0x0100 - the start point of a game. It doesn't handle banks unless the code executing it is outside bank 0. I'm probably going to add some sort of emulation with bank-switching instructions and see how it works, or add the option for a user to specify the bank and such. I'm not going to change the color coding again though, because I want to concentrate on disassembly and assembly features.

EDIT: Making some decent progress on assembler features. I also redid the bottom box to show every single error and where they're located.

Read-Only Zones
Procedure Rewrites

EDIT2: I'm aware the commas are red when they shouldn't be. The coloring issues are now fixed.

Personal Projects / Re: Gameboy Assembler Plus
« on: June 04, 2012, 04:27:54 pm »
I can't imagine why it would take long to colorize. How did you implement the feature?
It was a method I wrote a very long time ago. I just finished changing a lot of it and now it colors large procedures almost instantly. I made a lot of mistakes originally and they really impacted performance. For example, that Ages code I posted took like 8 seconds to color. Now, 2514 lines takes about 10 seconds to color and the 296 Ages lines are instant.

Looking good! :)

Are you coloring the entire file at the moment? You may try thinking about coloring only the code in-view, or building a dictionary of symbol <> color mappings that's built as you scroll rather than parsing the entire script, that should provide a big speed boost.
Yes, I color the entire file. I'd rather have it color the entire file once so the rest of the time it's completely smooth.

Personal Projects / Re: Gameboy Assembler Plus
« on: June 04, 2012, 04:48:59 am »
Thanks for the support! I have finished the disassembler (took forever). It's capable of tracing procedures, as in keep on disassembling until the procedure ends or the call stack becomes empty. It also has full label jumping and filling, as you can see in This Screenshot (The entire Megaman Xtreme graphic decompression routine). All of the code reassembles perfectly, and it also works with jumps to not-immediate code (poor choice of words) as you can see Here (A big chunk of Oracle of Ages's graphic decompression routine), and like before it all reassembles. While writing this I found a couple tiny assembler bugs but they're all fixed, so hopefully this entire thing is bug-free now. I really want to work on faster code coloring because it takes a slightly long time to color large procedures even though they take less than a second to disassemble.

Personal Projects / Gameboy Assembler Plus [Released]
« on: May 31, 2012, 07:55:22 pm »
This has been released. As of the date this is being edited, it hasn't been added to the site utilities yet.

This program was written to be the best GameBoy assembler out there. It also features a disassembler capable of some advanced methods. Here's a full unique feature list:

-Dynamic addressing (AKA label support, and the ability to call and jump to them)
-Code highlighting
-White space can be ignored, so instructions like "  ld  a     ,     5F" will assemble successfully. It should be noted that spaces and other characters act the same as commas, so don't feel like you need a comma just because it's proper
-Error checking on-the-spot and highlighting
-Support for just assembling code right away without opening a ROM
-Read-only zones that prevent code from being written in certain areas
-Rewrite zones, which fill a specified area with 00s so you can safely rewrite a chunk of code
-Code previewing, which shows where your code will be written line-by-line
-Safe file IO (warnings when you would lose your code if it was unsaved)
-Code insertion - "This generates code compatible with any language that uses curcly-bracket array assigning in the case you might want to make software automatically insert your assembly into a ROM. This only generates the code containing the values, so you still have to write them to the proper addresses yourself."
-Trace disassembling - the disassembler will start at a certain point and follow jumps, calls, and returns until the call stack is empty
-Bank-changing emulation - this is very weak and only emulates LD A,# and LD (####),A instructions, but when the accumulator is written to 2000-2FFF, the program will attempt to change the current bank if possible. Perhaps full emulation will come in the future

Finally, here's the download:

My site


I think it's pretty easy to tell what games were and weren't written in assembly. For example, a majority of the Oracles games probably wasn't, because even though the both Ages and Seasons use the exact same engine, memory addresses for stuff like map and tileset information is different when they don't need to me. Perhaps they just had a fancy assembler that accounted for variables, I don't know. I also think the code is just too space-efficient to be done by humans in a reasonable amount of time (Perhaps I'm thinking the exact opposite of what it really is). Plus, look at games like Megaman Xtreme 1/2. The constant popping and pushing and seemingly-unnecessary storing in HRAM is ridiculous and incredibly hard to follow. No human in his/her right mind would do what those games did. Honestly, I have no real answer. This is just my guess.

This is incredibly awesome. Wow!

Pages: [1] 2 3