 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
1 user currently in Rom Hacking:  hukka |
| Acmlm's Board - I2 Archive - Rom Hacking - Gee, might as well as post it here too(nothing new unless you care about the Oracle Series) |
 |  |  |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| User | Post | ||
Jigglysaint Red Cheep-cheep Level: 24 Posts: 120/215 EXP: 76907 For next: 1218 Since: 03-17-04 Since last post: 7 days Last activity: 3 days |
| ||
| Basically, the dungeon data has been fully decoded. At first, there were problems because some bytes didn't seem to match up. that's been figured out now. Basically, the structure of each room in the rom is that each room is made from a mixture of 2 byte pairs that reference pre-defined horizontal macros, only their length can be adjusted. With the first byte, the first part is half of a pointer that leads to a row of data. The second part is how many bytes into the row the data starts. The second byte has a part that determines the length of the row. If the row exceeds the edge of the screen, either the remainder of the data will be drawn, or it will start to draw the next macro that's below it. The last part is the second pointer. So the byte pair 20 D2 means that at 60220 In the first byte, the 2 is the 10's digit in the offset(20), and the 0 means the row starts on the first byte. In the second byte, the D means that the row goes for 13 bytes, plus 2(which is always added). The other 2 is the 100's digit in the offset(200). Now, each room starts off with a unique byte. This byte is a bitflag, and most rooms are set it as FF. For each bit, starting from the right, each bit represents 2 bit pairs. If the game encounters a 0, then on that byte the game will draw a single tile from the tile index. So lets say for example that the room starts with F7. This means that there will be 3 byte pairs, and then a single tile drawn. After there will be 4 byte pairs, and then another length byte. Some rooms seem to only have the FF, and the rest are all byte pairs. It's also interesting to note that a lot of rooms have either 24 bytes(with a second one of these length bytes), or 27 bytes(wthout a second one). My guess is that if the game detects the size of the room to be a certain size, then it reads the other bytes or somthing. BTW, the pointers are all relitive or somthing. They look local, but the pointer list and the room data arn't in the same bank. I though I'd mention my breakthrough in case somebody want's to make a level editor. Using this data it's possible, although it would still require a little bit extra hand work unless the pointers are able to be re-adjusted. |
|||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 2206/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| I'm going to assume this is for the Zelda Oracle games? Anyway, sounds like a crazy combination of two different types of LZ77 compression. One type, which I often refer to as MIO0 (since the first time I saw it was in N64 games, which have that in the compression header), has 3 elements. Raw data, compressed data, and bit flags. For each byte, if the flag is a 1, it reads a length/position pair from the compressed data, and outputs the raw data. (Ex: Length = 4, position = 2, means output 4 bytes from raw data starting at #2.) If the flag is a zero, it simply outputs a byte from the raw data. (Of course, these can be reversed.) The second type is the more traditional LZ77 seen in GBA games, in which the raw and compressed data are mixed together. It simply copies the raw data, but if it finds a certain byte, that means there's a length/position pair after it. (Though this means you have to do extra coding to be able to use that byte.) Now what it sounds like this game is doing is mixing those methods together. The raw and compressed data are mixed, but all of it is considered compressed. If the flag bit is a 1, it's assumed that whatever is at the current position is a length/position pair, otherwise it's a single tile number. (I assume that for the actual LZ77 part, it uses the already-decompressed data as the raw data. It doesn't make a lot of sense to reference forward anyway.  A lot of normal LZ77 implementations do this too.))So I hope that makes it even clearer (not that your post was unclear, but best to have as much info from as many sources as possible) for anyone who intends to work on this. (The only thing I don't get is only having one flag byte.  ) |
|||
jman2050 Red Koopa Level: 19 Posts: 26/123 EXP: 33172 For next: 2605 Since: 03-21-04 Since last post: 10 days Last activity: 103 days |
| ||
| Unfortunately, as I've mentioned to Jiggly before, it would be a major pain to write a level editor for this. Not to mention, if I remember correctly, there's very little free space left in the rom (which is probably why they had to resort to such a wacky compression scheme) | |||
|
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 2248/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
| Well if it's programmed anything like Link's Awakening, I wouldn't be surprised. So much crap in there. French text and stuff. Hell if you change anything it breaks on GBC. |
|||
|
Jigglysaint Red Cheep-cheep Level: 24 Posts: 121/215 EXP: 76907 For next: 1218 Since: 03-17-04 Since last post: 7 days Last activity: 3 days |
| ||
| Link's Awakening isn't compressed, in fact it's very easy to figure out. Making an editor would work, it just means the levels might not be as flexable as other games, but in LA you were limited to objects, here you can use any of the 256 pre-defined rows, using as little as 3 tiles and as much as 19 or so. One of the features could be a checking systemt to make sure the rom fits, and would discard the changes if it causes a massive room corruption. Most rooms can be rendered in 24 bytes, which is pretty good. If not, a great tool could be a row viewer that allows you to view all the rows, and maybe a row arranger where you can arrange the rows to get a good picture. Part of the problem with the game is that since the game grabs data from several places and in several sizes, figuring what row is what can be hard. |
|||
|
jman2050 Red Koopa Level: 19 Posts: 30/123 EXP: 33172 For next: 2605 Since: 03-21-04 Since last post: 10 days Last activity: 103 days |
| ||
| Or you could take the easy way out: copy MetEdit. If I recall, Metroid consisted of a very similar system of predefined pieces you place in the level instead of going tile-by-tile, although from the sounds of it the levels for the Oracle games wouldn't be as flexible, although at least you don't have to reuse screens.... do you? | |||
|
Jigglysaint Red Cheep-cheep Level: 24 Posts: 122/215 EXP: 76907 For next: 1218 Since: 03-17-04 Since last post: 7 days Last activity: 3 days |
| ||
| No, all the screens are unique. In fact, for such a system, it does get the job done. Many times it re-uses rows, but only small pieces of it. For example, in Oracle of Ages, there are many areas in the game that actually use just one piece of a row of data. As long as you can get more than 2 bytes in per byte pair, its still going to be smaller than if it was one byte-one tile. Each room has 15x11 rows, which is more than 100 bytes per room each. This way, the most common rows can be compressed and used for the same rooms. for example, the top half of a standard room with 4 walls is used in most rooms, while the lower part of the room has to be made up of 2 rows, or one row plus one stand alone tile, since unlike the top half, the bottom is never found to be complete. It's kind of hard to explain. |
| Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
| Acmlm's Board - I2 Archive - Rom Hacking - Gee, might as well as post it here too(nothing new unless you care about the Oracle Series) |
| | |
