Well, there isn't really any news today. I've been messing around with a program I'm making that lets two people play a game together (Like watching someone play a VBA game and then taking over by capturing the screen's buffer and sending it over and some other stuff). I've also been playing around with the editor recreating Zelda Link's Awakening's maps (Which is actually pretty fun) and I noticed that I have to figure more out about interactions, because I can't seem to get the ID for those little green blobs that pop out.
Oh well. Until tomorrow, see ya later!
Subscribe to:
Post Comments (Atom)
Green blobs eh? ID 34. For sprite data, control code F6 is used to add enemies that have random co-ordinates assigned. For example, at 487DA, you see F6 40 34 00 That tells the game to randomly assign 4 green blobs around the room each time you enter. F7 is for exact co-ordinate placement. Furthermore, at 495E2, there is a jmp list of all the control codes. Control code F8 also has it's own sublist at 45E9F. Of course you know that F8 09 is what adds as floor switch to the room.
ReplyDeleteOh. I knew Green Blobs had the 34 00 ID (Or backwards, can't remember at the top of my head) but using type 2 would create a ship. I guess type 7 has a byte read immediately after F7 that goes on for the rest of the interactions until a type switch. Though, what this value does I'm not sure, but it plays an important role on what the outcome is. The blobs most likely have something similar to this too, and the same principle must apply to type 6 (Though a quick debug can quickly answer this).
ReplyDeleteMy bad for the double post, but I discovered that for basically any enemy you see in a dungeon to work, the type must be 7 and then some byte after it (My tests have shown that anything works. I haven't debugged to a point where I could figure out its purpose). Trying out ID 34 00 with type 7 did make the Green Blob show as I wanted. It also turns out the second ID byte controls what kind of blob is it. 00 is green, 01 is red, and anything else is a crash.
ReplyDeleteType 2 tells the game that the ID is an interaction, such as an event. Type 1 is the same, except there are no co-ordinates given. Type 3 is used to define enemy data pointers, while F4 is used for bosses. I'll take a look and see what some of the others do. For type 6, I believe the first byte is monster quantity, followed by the ID bytes. Changing an F7 to and F6 will bug the game, and vice versa. One needs 3 bytes, while the other needs 5.
ReplyDeleteSo I guess that means I had most of my guesses right. And for the type 6 monster quantity, it must only work for some enemies because anything would only spawn 1 (Including FF), and is only used immediately after the type switch. Type 8 I've seen with triggers, switches, and owl statues. Type 9 seems to be used several times wherever there are falling objects or as one of those events such as when you beat a dungeon, the red things come down and you get a hint on where the next essence is.
ReplyDeleteAlso, I really hate to ask, but would you happen to know how minimaps are created? I can't find it in the memory (Since the room order is stored in a different WRAM bank I'm guessing the minimap data is too), BGB doesn't break on the background write for it, and searched patterns in the ROM that might have resembled it (Including VRAM indexes like in LA), but in the end found nothing.