| User | Post |
Mega-Dog
Posts: 74/139 |
Originally posted by BMF54123
OK, I figured out the level data format. It's really easy, but please forgive any errors or wacky grammar, as it's really, really late.  Also note that this data only applies to Niagara Falls; I haven't found the pointers to the other levels yet, though everything's stored within the same bank.
Level header: $10010, the second two bytes point to the "screen order table," the rest are probably related to the block mappings (See Coby's post). Everything from $10012-$10025 is copied to $4B-$5E in RAM.
Level layout: The first screen (01) of Niagara Falls starts at $11D5A (note: this is NOT the first screen you start on, that's actually at $120DA). Each screen is comprised of 64 (8 rows x 8 columns) 4x4-tile blocks, similar (IIRC) to Castlevania. The first row is completely obscured by the status bar, the second row is half-visible, and the last row is just barely visible at the bottom of the screen (only 1 row of tiles is shown). Each screen's blocks are stored sequentially, starting from the top-left corner of the screen and ending at the bottom-right corner, running left to right. There is no break between each room's data, and there is no compression.
The "screen order table" starts at $11C3A. Niagara Falls is 8 screens wide x 6 screens tall (this is probably defined in the level header). Each individual screen is assigned a number from 01 to 1F, and this table determines which screen will be loaded where. A visual aid should be more helpful (0F is the starting position, and 0D is the boss room):
This table also defines the level's scrolling boundaries; a value of 00 will stop horizontal scrolling in the current direction. The edges of the level are treated as 00s as well.
I believe there is another table of some kind, separate from the screen order table, that affects how the status bar is handled during vertical scrolling; adding a vertical scroll where there wasn't one before will mess up the status bar (but nothing else). Should be relatively simple to figure out.
There is 2 tables if I remember right...the 21 byte table should be for layout of each screen in chuncks of blocks or something and then there is another table which will have TSA in it. It confused me after awhile that is why I discontinued MWOD which was going to edit this game. |
Darth Coby
Posts: 1088/1371 |
BMF: Woah :o Now, how did you find that? :O Because now I didn't really learn a lot :o But still thanks! 
Dan: Oh so there's a new version? Your site showed 0.1.1 as the latest version and that's also the version I seem to be having. Oh well.
*Coby redownloads |
dan
Posts: 383/782 |
Originally posted by Coby
Hmm, looks like Sapros is pretty buggy, even when I restore a ROM it curropts the old area again when I try to curropt other areas, can anyone recommend any curropter?
Yeah, the restore ROM function doesn't reload the ROM in the memory of Sapros. A stupid logic bug. That's been fixed now.  |
BMF98567
Posts: 619/1261 |
OK, I figured out the level data format. It's really easy, but please forgive any errors or wacky grammar, as it's really, really late. Also note that this data only applies to Niagara Falls; I haven't found the pointers to the other levels yet, though everything's stored within the same bank.
Level header: $10010, the second two bytes point to the "screen order table," the rest are probably related to the block mappings (See Coby's post). Everything from $10012-$10025 is copied to $4B-$5E in RAM.
Level layout: The first screen (01) of Niagara Falls starts at $11D5A (note: this is NOT the first screen you start on, that's actually at $120DA). Each screen is comprised of 64 (8 rows x 8 columns) 4x4-tile blocks, similar (IIRC) to Castlevania. The first row is completely obscured by the status bar, the second row is half-visible, and the last row is just barely visible at the bottom of the screen (only 1 row of tiles is shown). Each screen's blocks are stored sequentially, starting from the top-left corner of the screen and ending at the bottom-right corner, running left to right. There is no break between each room's data, and there is no compression.
The "screen order table" starts at $11C3A. Niagara Falls is 8 screens wide x 6 screens tall (this is probably defined in the level header). Each individual screen is assigned a number from 01 to 1F, and this table determines which screen will be loaded where. A visual aid should be more helpful (0F is the starting position, and 0D is the boss room):
This table also defines the level's scrolling boundaries; a value of 00 will stop horizontal scrolling in the current direction. The edges of the level are treated as 00s as well.
I believe there is another table of some kind, separate from the screen order table, that affects how the status bar is handled during vertical scrolling; adding a vertical scroll where there wasn't one before will mess up the status bar (but nothing else). Should be relatively simple to figure out. |
Jigglysaint
Posts: 150/215 |
Corruptster. I swear by it. |
Darth Coby
Posts: 1087/1371 |
Hmm, looks like Sapros is pretty buggy, even when I restore a ROM it curropts the old area again when I try to curropt other areas, can anyone recommend any curropter? |
Jigglysaint
Posts: 149/215 |
The levels can't be compressed into 21 bytes. It is just not possible to store than amount of information that way. My guess is that it's just the level headers. Perhaps you need to check the beginning of the ROM for the actual data. I know that some games, level data is stored from the very first offset. |
Darth Coby
Posts: 1075/1371 |
Hmm, sorry for the big bump (hey it's not older than 1 month! )
You say the data is not compressed, but it looks like the level exists out of 21 bytes or something. Because only 21 bytes seemed to have an effect when edited.
This is all I have up until now, I put this project aside for a while now.
Title screen (Press start): 0x00F567
Copyright screen: 0x00F4FE
Status bar: 0x00F9C3
Niagara falls: 0x10010 - 10025
Starting lives: 0x01C118
Starting energy: 0x01C109
$ amount from small diamonds: 0x01D3D9 (amount x 1000)
Data at 0x010010:
0A 1D 2A 9C 3A 8D 09 8E D8 8E A7 8F 7A 80 7A 81 7A 82 7A 83 7A
1st byte: Vertical position of screen (higher value = higher floor)
2nd byte: Number of screen on vertical axis(?? | 1A<->21)
3rd byte: Number of screen on horizontal axis (?? | 2A<->31)
4rd byte: Also screen number O_o; (?? | 9A<->9C)
5th byte: Graphical glitches (16x16 blocks)
6th byte: Graphical glitches (16x16 blocks)
7th byte: Graphical glitches (16x16 blocks)
8th byte: Graphical glitches (16x16 blocks)
9th byte: Graphical glitches (16x16 blocks)
10th byte: Graphical glitches (8x8 blocks)
11th byte: Graphical glitches (8x8 blocks)
12th byte: Graphical glitches (8x8 blocks)
13th byte: Graphical glitches (8x8 blocks)
14th byte: Graphical glitches (8x8 blocks)
15th byte: Still untested and so is the rest because of lack of motivation.
EDIT: I also got the tables if anyone is interested :p (For the title screen and the ingame text, including the dictionary) |
Mega-Dog
Posts: 71/139 |
Sorry to post in an old thread but I havn't been here in a while. As far as I know the data is not Compressed. I did start working on an editor for this game and gave up after a while. The tile data was too scrambled around for me to make sense.
If you did work hard enough you will find it all... |
Darth Coby
Posts: 1007/1371 |
Well, they seem to be pointers, because:
0A 1D
2A 9C
3A 8D
09 8E
D8 8E
Now, I'm very unfamiliar with NES pointers and all the documents I've found about NES pointers err.. Suck. :\ So, if anyone could explain NES pointers or point me to a *good* document about NES pointers.
Extra note: All the offsets I've posted are for the unheadered ROM. |
Jigglysaint
Posts: 135/215 |
Did you check to see if they are pointers? It looks so, but I am unsure. I might try somthing later to see what I find. |
Darth Coby
Posts: 1005/1371 |
Sorry, I thought I had already posted the offset
It's $10010 and I have no idea where it ends as of now. |
Jigglysaint
Posts: 134/215 |
Offsets? Perhaps I might be able to help. |
Darth Coby
Posts: 1003/1371 |
Commando125: As stated before, I'm doing this just to see what I can do and learn from it, it might someday expand to a full hack, but until then I'm doing this on my own.
Skateboarder11: IF (Note boldness and caps) this becomes a full hack (wich is perfectly possible) then I guess there will be some new graphics, yes 
BMF54123: Do you have any idea if the first duck tales used compression? Because if so then I guess they'd probably reuse it, no? I'll check into that more tonight, home sweet home
Edit:
Ok, after poking around a bit with the first three bytes of the Niagara falls I'm 100% sure the levels are compressed, try adding $01 to the first byte (making it $0B) you'll see what I mean. All sorts of parts of the level are changed. Now, how would I go and figure out how to compress/decompress them? |
Xkeeper 2.0
Posts: 189/1091 |
Interesting, Coby... If this becomes a full hack, will you be doing any graphics editing? |
BMF98567
Posts: 551/1261 |
The level data could very well be compressed. The ROM is only 128K, the same size as the first game, yet it has more/bigger levels. |
Commando125
Posts: 22/40 |
Keep up the good work. Maybe I can help  |
Kario
Posts: 1023/2082 |
Oh....in that case. Good job Coby. Looks real cool. Keep up the good work. |
dan
Posts: 302/782 |
Yeah, basically. It's similar to the TSA in SMB3, I believe. (at least with the world maps) |
Jigglysaint
Posts: 133/215 |
Odd, so basically all the upper left pieces of the block are together, then the upper right, then the lower left, ect? |
| This is a long thread. Click here to view it. |
hukka
