Does anyone know how he was able to create the moving ocean/stream/ and apparently lava tiles?
This ultimately is a programming problem. You have to write assembly code which will perform the animation, and inject it into your hack.
As far as assembly hacks go, if you have no prior programming experience, this probably isn't the best one to start with, but it also isn't the worst. There's already a disassembly available that has all the out-of-combat code commented and organized, so hopefully that softens the difficulty a bit:http://www.romhacking.net/documents/401/
But there's no getting around it. To do this yourself you'll have to learn 6502 assembly and some basics about NES architecture. You'll be writing code.
I did a hack like this way back when... it basically worked like this:
The game is in different areas of code for different sections. So when you're on the overworld, the game is running one set of code, and when you're in standard maps, it's running another set. What I did (since i just wanted to animate overworld water), was I got into the overworld game code, and at the start of every frame, had it JMP to some free space, where I would insert my animation routine.
The animation routine basically just read the pixel data from the PPU (via $2007 register reads), shifted them over, and wrote them back. Conceptually it's very simple, it's just getting the details with PPU interaction right that's tricky.
I can get into more details if you want. But I don't want to get ahead of myself. If this didn't scare you away and you're willing to try it, then I'm certainly willing to help. Just let me know.
I would REALLY like to make the chests reflect that they have been opened. Is there ANY way to somehow do a type of if:then code where the closed lid sprites are automatically redirected to different open lid sprites when the chest has been opened?
That is absolutely possible. And as with the other question... the relevant code is all commented and explained how it all works in the above linked disassembly.
Normally when drawing tiles, the game just looks at the tile ID and draws it appropriately. You'll have to change that so instead it:
1) Checks the tile properties. If it's not a treasure chest, draw it normally
2) If it is a treasure check, check to see if that particular chest has been opened. If not, draw it normally
3) If it has been opened, draw a different tile.
It'd probably be easiest to dedicate a tile for each tileset to be the "open chest" -- much like the game does now with open doors.
And in fact... the open door code might be similar to what you want to do -- it's been a while since I've looked at it so I can't remember for sure -- but maybe you can look at that code to get some ideas.
Looking at the disassembly again:
The main overworld loop is in bank_0F.asm. Ctrl+F for "EnterOverworldLoop:"
JSR WaitForVBlank_L ; wait for VBlank
LDA #>oam ; and do sprite DMA
JSR OverworldMovement ; do any pending movement animations and whatnot
; also does any required map drawing and updates
; the scroll appropriately
The best spot to slip the animation code in there is between that STA and JSR. That is, after the OAM update, but before the scroll is adjusted.
You can JSR to your own routine.
If you need some extra bytes to fit in your JSR, there's some unnecessarily long frame-counter incrementing code immediately after that which uses ADC and can be replaced with shorter INC commands to free up some space.
Looking for TC related drawing code now....
Also in bank_0F.asm, Ctrl+F for "RedrawDoor:"
This code does the actual tile redrawing, which you can probably recycle for redrawing the treasure chest when it is first opened.
I also found 'DrawMapRowCol:' which does the drawing of the treasure chest tiles normally -- but it doesn't look like you'll have to mess with that, as it just draws preloaded information. The actual loading of that information is what you'd want to change... and that is...
You'd want to mess with "PrepSMRowCol:" (same bank_0F.asm file -- most stuff is in that bank):
LDY #$00 ; zero Y for following index
LDA (tmp), Y ; read a tile from source
TAY ; put the tile in Y for a source index
LDA tsa_ul, Y ; copy TSA and attribute bytes to drawing buffer
STA draw_buf_ul, X
Here the code uses Y as basically the tile it will draw. What you would want to do, is not use the tile directly, but instead replace it with the "open TC" tile if that chest has already been opened.
Code is too tight in this routine so you'd probably have to JSR elsewhere to do the checks, but it shouldn't be THAT difficult.
Another routine in this bank, "TalkToSMTile" shows an example of how to check to see if a tile is a chest, and
how to check to see if that chest has been opened. You can use that for reference when writing your routine.