+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Oracle of ages
Pages: 1 [2] 3 4 ... 6
Author Topic: Oracle of ages  (Read 3 times)
Wareya
Guest
« Reply #15 on: March 11, 2009, 10:44:36 pm »

I have for mat information I've collected over a long period of time if you want it. It might be way different, and useless due to the face that it's from Link's Awakening, but it's still the same format unless I'm wrong.
Jigglysaint
Guest
« Reply #16 on: March 11, 2009, 11:30:17 pm »

Quote from: Wareya on March 11, 2009, 10:44:36 pm
I have for mat information I've collected over a long period of time if you want it. It might be way different, and useless due to the face that it's from Link's Awakening, but it's still the same format unless I'm wrong.

Link's Awakening is completely different in terms of structure.  LA uses objects combined with templates wheras the Oracle series uses compressed tile data as well as macro usage.  Even things like chests are coded differently.  Besides, I am pretty much the Gameboy Zelda expert.  There is little that I do not know about all 3 of those games.

BTW, what kind of data did you find?  I'm curious to see what you have collected.
Tauwasser
Guest
« Reply #17 on: March 12, 2009, 03:47:01 am »

Hey guys, maybe putting up a proper document might be the cool thing to do?
I actually tried to find all the stuff for OoS and OoA some (long) time ago (in a galaxy far far away), but didn't get very far due to time restraints...


cYa,

Tauwasser
« Last Edit: March 12, 2009, 07:46:05 am by Tauwasser »
Wareya
Guest
« Reply #18 on: March 12, 2009, 06:05:35 am »

Quote from: Jigglysaint on March 11, 2009, 11:30:17 pm
Link's Awakening is completely different in terms of structure.  LA uses objects combined with templates wheras the Oracle series uses compressed tile data as well as macro usage.  Even things like chests are coded differently.  Besides, I am pretty much the Gameboy Zelda expert.  There is little that I do not know about all 3 of those games.

BTW, what kind of data did you find?  I'm curious to see what you have collected.

A scoffable amount of data on some chests and a few hints at the exits, if I simplify.  Embarrassed You really do know what you're talking about, and I'll have to say that with what you've been saying, the LA documents here ARE morbidly outdated.

@Tauwasser: You meant OoS?
Dwedit
Guest
« Reply #19 on: March 12, 2009, 06:41:12 am »

Trying to figure out how the 16x16 tiles are encoded.
They appear to be around 60000.  The first few bytes seem like a pointer, messing with them messes up every tile in the game.
After that, each tile appears to be represented by 3 bytes, but these three bytes do not appear to encode a tile, not sure how they work yet.
Jigglysaint
Guest
« Reply #20 on: March 12, 2009, 11:32:34 am »

Exact location?  If it's 3 bytes, I will bet you anything that it's a 3 byte pointer to data all around the rom.  The enemy pointers in Link's Awakeing are 3 byte pointers, and they work the same as ones on the SNES.  I'll go take a look now.
Dwedit
Guest
« Reply #21 on: March 12, 2009, 02:41:47 pm »

edit:
There appear to be 3 different map formats for overworld maps:
Compressed using the "16 bits and a tile" method
Compressed using "8 bits and a tile" method
Uncompressed

The "8 bits and a tile" method is just like the "16 bits and a tile" method, except it checks for a zero on the bits to compress, and immediately copies 8 literals if it is zero.

The two upper bits of each entry of the map pointer tables indicate which type of compression is used.
00xxxxxx = uncompressed
01xxxxxx = 8 bits and a tile
1xxxxxxx = 16 bits and a tile


So yeah, a summary of the Overworld:
For the Present overworld, the pointer table is at:
0x5E6E3
The 16-bit address is ANDed with 3FFF to mask off the "compression mode" bits.
Then you add 0x67E3 (a hardcoded value) to get a ROM address
Also add 0x88000 if you are interested in a file address
Maps are on the page 0x90000



This map viewer currently cheats by using a hardcoded bitmap for the tileset, it's not doing anything to figure out the correct tiles to display for any area
« Last Edit: March 13, 2009, 03:31:30 am by Dwedit »
Jigglysaint
Guest
« Reply #22 on: March 12, 2009, 07:10:41 pm »

You know I missed that part about the last 2 bits being the compression switch.  What happens then if neither or both are set?

Overworld editing should be easier to do then.  It's dungeon editing that's going to be the hard part.  Of course one could always just re-code the dungeons to use the overworld sized screens, but of course that would mean a complete re-write of the dungeon data.  As for dungeon editing, I was thinking that what could be done, is you have a list of the macros on the right, and what you do is you drag the mouse and highlight the tiles you want to use, keeping in mind that the next row down is used when there is an overflow.  Then individual tiles could be selected as well.  Then it's compressed.  The problem is that what would end up happening is that the pointers, which are relative, need to be auto adjusted after each successful edit.  What could happen is that the data is loaded into a buffer and edited, then when it's re-inserted, it checks how many bytes are needed, then checks to see if it crosses the boundries of the next room(by taking the next pointer, and checking if it points before the previous room ends).  If extra bytes are needed, then all rooms before it are offset by X amount of bytes, and the pointers re-ajusted.  I don't know if it's possible to program such a system but it seems to be the most optimal way to doing things.  Otherwise, editing could be limited by editing the macros and tiles, but not the control code(since that's what makes the maps messed up).

BTW I have a small document that actually credits The Fake God as the one who discovered the format.  Funny thing is that he used the exact same screen that the above pic as an example.
Dwedit
Guest
« Reply #23 on: March 13, 2009, 08:52:10 am »


I managed to find the master overworld table, which includes the address of the pointer table (512 bytes large), and the "zero" address which is added to each address read from the table.
Now I can view all 4 overworlds.

Now I just need to figure out how the game decides what to draw.  How it picks which graphics to include in VRAM, how it selects what metatiles appear, how it builds the metatiles in the VRAM map, how it selects the palette, etc.  I'm still using some hardcoded BMP tilemap for now.

Edit: here's the 4 overworlds drawn as one small image:

Still using the wrong tileset, you can see the lovely black vines around the area before restoration hall.
« Last Edit: March 13, 2009, 09:32:03 am by Dwedit »
Jigglysaint
Guest
« Reply #24 on: March 13, 2009, 11:30:52 pm »

At 10F9C, there is a table that's about 8 bytes each.  This is what I call the area header.  What it is, is it's what defines an area.  You see, all the rooms in the game can belong to a specific area.  An area is defined as a group of rooms that share the same attribute table.  A good example would be level 1.  Any room that is designed to appear in level 1's map is given an area value of 36.  If you scroll down from the area header data, you will see a small list of 7 pointers.  These lead to the data that tells what room belongs in what area.  If you notice, the last 2 pointers are repeats of the two pointers that came before it.  That is because things such as side view areas, and massive dungeon changes are placed into those two maps.  A good example would be the turnstle in Moonlight Grotto that gets knocked down to the next level.  I need to explore this more.

Anyway, each area contains important data, such as the attributes of the tiles(overworld, dungeon), pallete(I'm listing them out of order), area flags that include if the area is underwater, a dungeon, or toggles between present and past style treasure chests.  Also is the bank number to use, tileset graphics, and also some individual tile modifiers which I have not explored in depth.  That last part is why tiles look different in different overworld areas.  For example, the walls of the Black Tower are considered to be part of this extra tile data.  Note that it is the actual tile plus tile attributes that are swapped in and out, not just graphics.  Changing that byte(this is the first area on the list, and it's for the present town), will turn the walls surrounding the tower from it's usual tiles, to red blank tiles.  This also appears in dungeons too, like 4 and 8.

What else?  Level numbers are also included as well.  Also a note about the banks.  Bank 0 is the present overworld.  Bank 01 is present underwater overworld.  Bank 02 is past overworld, and bank 03 is it's underwater map.  04 and 05 are the two dungeon banks, and I already explained that 06 and 07 are copies that hold vital dungeon changes.  Also an interesting note is that even though dungeons and overworld screens are coded slightly different, they will be uncompressed properly, although dungeon screens are chopped off unless they appear in maps 4-7.  I think I even found the code that makes the decision, which means it's possible to extend the overworld or shorten the dungeon rooms.
Dwedit
Guest
« Reply #25 on: March 15, 2009, 08:07:38 pm »

Yes, I'm still working at this...
Trying to figure out what the 8 bytes in that header actually do.
I've mapped out several of the first 16 bits, but not the rest.

In the mean time, I found a couple of other tables:
* The Song table (what song is played at each room)
-- 4:495C has the pointers to 8 tables:
-- 496C, 4A6C, 4B6C, 4C6C, 4D6C, 4E6C, 4D6C, 4E6C (all on page 4)
* A worthless table which is either 01 for normal rooms, 7F for Nuun highlands, or 80 for the maku tree
* The "RAM Flags" table, which indicates visiting maps, using plane+2 temporarily, collectibles collected, and more flags indicating an event has happened on the map
* Some code which does a linear search to see which room you're in

It appears that the "area header" also determines which plane the map is loaded from in the end.

-------------------------

New post:
I'm figuring out the compression method used by the background tiles.
Looks like a simple LZ-style compression.
« Last Edit: March 16, 2009, 04:50:12 pm by Dwedit »
Jigglysaint
Guest
« Reply #26 on: March 16, 2009, 09:43:50 pm »

Okay I've got answers for you.  First of all, the pointer table you found with 8 values was kind of read wrong by you.  Instead they point to the values below where they are, and it's the screen music data.  Second of all, the small table you saw with the worthless 01's, 7f's, and 80 is actually some important stuff.  01 is normal.  7F is used to denote the area that changes depending on what animal you have.  Dimitri's overworld is by default, and the changes happen if the other two are your companion instead.  Also changing a screen not coded to change seems to lead to one of the nul rooms with an I in the middle.  Also, the 80 is what makes the screen fade out instead of scroll you exit the screen.  Two maps count, the present overworld, and the past overworld.  With some tweaking and ASM hacking, you could make other areas change on whatever conditions you want.

Remember, there is no such thing as a worthless table.  Every little bit counts.

Edit:  At 10F6C, which is right above the area header, there are some 3 byte pointers that are actually pointers to the banks where the maps are stored.  Each bank seems to contain two 3 byte pointers, with an 01 at the beginning.  So for the overworld(both past and present seem to be included), the value is 01 17 E3 66 23 E3 67.  I am not sure about the first pointer for the overwolds, but for dungeons, that first pointer leads to the list of macros used in that bank.  The second pointer leads to the map data proper.  Hmm, wait a sec.  01 seems to be for overworld, and 00 seems to be for dungeons.  Perhaps it has to do with how the data is compressed?
« Last Edit: March 16, 2009, 10:38:48 pm by Jigglysaint »
Dwedit
Guest
« Reply #27 on: March 17, 2009, 06:58:47 pm »

I figured out the compression for the game's tile graphics, and how it loads tile graphics.
Now to figure out how it loads map tiles, and palettes, then I can have a proper map viewer.
Jigglysaint
Guest
« Reply #28 on: March 17, 2009, 08:44:00 pm »

...and then, a working map editor, right?  This is still turing out to be pretty good.  It's even got me fiddling with the game again to find new goodies.  Oh yeah, BRB, going to figure out how Symmatry Village works.
Dwedit
Guest
« Reply #29 on: March 17, 2009, 09:08:48 pm »

There are flags in RAM associated with each map (these are also stored in the save file after you save)

For each of the 8 planes, there is a table in RAM at C700, C800, C700, C800, C900, CA00, C900, CA00.

Values
01 = plane = plane OR 2
02 = flags, used for when you life a rock or burn a bush that stays gone
04 = flags???
08 = flags???
10 = Map has been visited
20 = Have collected a collectable
40 = Flag for the map (may indicate a map has changed, or may indicate a cutscene has completed)
80 = flags, this one is used on the map above Level 2 and possibly elsewhere

Symmetry Village sets bit 01 to indicate it wants to use data from the other plane.
So if you look at C702-C704 and C712-C714, you'll see bit 01 set after you have fixed up the town.
The mountain area where you divert the river also works the same way.
I'm sure the dropping rotating thing from Level 2 also works this way.

(and the sideview areas inside dungeons have absolutely nothing to do with the extra planes, they are just regular rooms)
« Last Edit: March 17, 2009, 09:20:32 pm by Dwedit »
Pages: 1 [2] 3 4 ... 6  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC