Red Candle - User contributions [en]

The Legend of Zelda

2020-10-09T12:41:14Z

Fiskbit: The Recorder: Rewrites much of the section for clarity and increased detail. Removes confusing joke.

= Getting Started =

Here are some resources commonly requested by new players:

Picking an emulator: [[The Legend of Zelda/Emulators]]

Route options: [https://www.orderoftheate.com/the-legend-of-zelda Order of the Ate] has a list of popular routes that are easier to finish, with a sliding scale of time/difficulty tradeoffs.

Tutorial videos: [[The Legend of Zelda/Tutorial Videos]]

Basic maps: [http://nesmaps.com/maps/Zelda/Zelda.html NESMaps]

Discord: [https://discord.gg/t7sgWzq Invitation to Lack's LoZ Discord server]

= Version differences =

Here is an entire page devoted to [[The Legend of Zelda/Version Differences|version differences]].

=Categories=

The categories, and their rules, are all documented at [https://www.speedrun.com/The_Legend_of_Zelda speedrun.com's board].

If those categories aren't enough, there's also a [https://www.speedrun.com/zelda1ce Category Extensions board] with its own rules in [https://www.speedrun.com/zelda1ce/forum the forum sticky posts].

=Game Mechanics and Glitches=

==Screen Scroll==

The 'screen scroll' trick is useful for getting over overworld obstacles, as well as for clipping through blocks in dungeons. That means you get to some stairs without killing all the enemies first! Here's a graphic with some pointers:

http://redcandle.us/wp-content/uploads/2012/10/screenscroll.png

Since the above chart was made, an alternate way of clipping through a block has been discovered by [https://twitter.com/hal_yotsuba はる＠よつば]. First, you get onto the pixel as in the above picture, with the top of Link's head lined up with the flat part of the block. Then, instead of doing a single-frame tap, slash the sword and press right or left. The sword slash, done correctly, will prevent you from moving. You will get the same effect as the single frame tap, so if you're positioned right, you will turn around. After the sword slash, walk through the block. This trick only works with block clips, not overworld scrolls or ladder clips.

Here's an additional quick demonstration of the pixels for the "reverse" clip:

http://redcandle.us/wp-content/uploads/reverseclip.png

==Drops==

=== Random drops ===

The enemy drops are not random. Whether they do drop an item is random, but when they do drop, here's what they'll be. The counter starts at 0, and goes up by 1 every time you kill (most) enemies. Zols' gels and vires' keese do not advance the counter. Chart via [http://tasvideos.org/2091S.html Baxter at TASVideos]<nowiki>:</nowiki>

http://redcandle.us/wp-content/uploads/2012/10/zeldaitemdropsnr2.png

===Drop Rates ===

The chance of getting a drop from group A is 80/256 = 31%.

Group B: 104/256 = 41%

Group C: 152/256 = 59%

Group D: 104/256 = 41%

==== Forced drops ====

However there are also the ''consecutive'' kill counters. Kill 10 enemies without getting hit (by an enemy, even a non-damaging bubble, or by the whirlwind from the recorder) and you'll get a forced, guaranteed 5 rupee drop from the next enemy that drops items (not in the X group). Kill the 10th enemy with a bomb instead, and instead of a 5 rupee you'll get a forced, guaranteed bomb drop!

Kill 16 enemies in a row and you get a fairy drop forced, but only if the 16th enemy is capable of dropping an item (not in the X group).

Note that if the 10th enemy does not drop items (in the X group), then killing that enemy with a bomb means the next drop that does happen will be a bomb. Killing that 10th enemy with the sword or any thing else will mean the next drop will be a rupee, even if you kill the next-dropping enemy with a bomb. It's the actual 10th enemy kill that counts, not the succeeding enemy that drops items.

However if the 16th enemy does not drop items, the fairy drop will be skipped entirely, and another one will not happen unless you get hit and the counters reset.

In some rooms that drop an item (such as the 5-Stalfos room in Level 1 that gives a key at the end), one enemy will act like it was holding the drop like a stalfos with a visible key, or a gibdo with a visible bomb. As a result, that enemy will never drop anything, and it will be able to store a forced drop and/or bypass a fairy drop, just like enemies that never drop items.

Note that splitting a Zol into two Gels, or splitting a Vire into two Keese, will not count as a kill or a consecutive kill. Killing one of those split Gels or Keese will not count as a kill for drops, but will count as a consecutive kill. Yes, there are some circumstances that are an exception to this. If the Zol is trapped against a barrier, it can sometimes trigger an extra 'kill' that way. A kill sound in place of a split sound indicates that this has happened. This does not occur with Vires.

Further note: Multiple simultaneous kills will not take you past 10 on the consecutive kill counter, per Darkwing Duck. If they would take you past 10 they leave you at 10 instead.

Advanced strategies: If a forced bomb/rupee or forced fairy drops, the consecutive counter for bombs/rupees is reset, but not the counter for fairies. So no matter how many hits you get on Manhandla with one well-placed bomb, the 10 count is reset after defeating him. The same is true of Dodongo. Likewise with a "Hippo Fairy" (going into a Patra with 7 on the consecutive counters, so that the Patra's center will be kill #16 and get a fairy), the bomb/rupee count resets to 0. Credit to Khananaphone for this discovery.

This means that if you get a forced fairy drop, the next consecutive bomb/rupee kill will not be at 20. It will be at 26. So bomb/rupee drops work in one of two methods:

# 10, (Fairy at 16), 26, 36, 46...
# 10, (Skip fairy at 16 by killing non-dropping enemy), 20, 30, 40...

Credit to Darkwing Duck for this discovery.

==Luck Manipulation==

See [[The Legend of Zelda/Luck Manipulation]]

==The Recorder==

The recorder loops you through all the dungeons for which you have the Triforce, sequentially, according to the direction Link is facing. It has an internal counter that starts at 1. The counter changes every time you blow the recorder in a place where the whirlwind can appear (that is, any overworld screen where the recorder doesn't spawn a staircase). If Link is facing up or right, then the counter goes up to the next completed dungeon. If Link is facing down or left, then the counter goes down to the previous completed dungeon. The counter wraps around as needed. This counter is only initialized on power-on or reset, and so it does not reset during the run or even if you switch save files.

Let's look at some examples:
* You've completed levels 1, 3, 4, and 5 and haven't yet blown the recorder. If you blow the recorder once facing down, you will be taken to level 5, because the counter started at 1 and then looped around to 5.
* You then blow the recorder 3 more times while facing down. The counter will go 4, 3, 1, skipping 2 because level 2 is not completed. The whirlwind would then take you to level 1.
* You then blow the recorder once facing up and then once facing down. The counter goes from 1 to 3 and then 3 to 1, so the whirlwind would take Link to level 1 again. This technique is used in some routes.

Note that if you turn on the same frame that you use the recorder, the counter will change as though you were facing the old direction, not the new direction. This is a common source of recorder mistakes. Also, level ordering in the second quest is different, and this affects the order for the recorder. Levels 2 & 3, 4 & 5, and 7 & 8 are swapped, so the counter goes 1, 3, 2, 5, 4, 6, 8, 7.

==Bombing Darknuts==

Whether a Darknut blocks a bomb's explosion with its shield is determined by two things. First, the direction Link is facing when he lays the bomb. Second, the direction the Darknut is facing when the explosion hits him. If Link's position when laying the bomb is facing the direction the Darknut is looking when the bomb goes off, the bomb won't work.

Here is a graphic by Lackattack24.

http://redcandle.us/wp-content/uploads/darknuts-lackattack.png

==Bombing Walls==

Note that bombs do not check to see if a hole should be opened whenever a shutter is opening or closing. Beware of that.

Image by Eunos on positioning:

http://redcandle.us/wp-content/uploads/eunos-bomb-positions.png

==Free Locked Door==

If you enter a dungeon and the first room has a locked door on top then you can leave and immediately reenter to unlock that door for free!

==Walking through enemies==

If an enemy has just been hit, then Link can temporarily walk through that enemy without damage or knockback. However the enemy itself must not be knocked back or split in order for that to work. So this doesn't work against Zols or Vires. Striking a Darknut's shield also prevents this from working.

Enemies won't be knocked back if hit perpendicular to their movement direction while they're between tiles. When they're directly on a tile, they can be knocked back in any direction.

Link normally stops walking temporarily when using the sword. Exceptions to this are while stepping onto the ladder (useful in 7 after the hungry Goriya, and in 1 to steal the key from the Stalfos after the Gels), and when stepping into a door (useful in 9 when skipping the first Patra). Catching a boomerang while stabbing will also allow Link to start moving immediately.

== Skipping Patras ==

Walking through Patras is a special case. It turns out that the orbiting eyes of the Patra don't actually exist hitbox-wise right away. This gives you time to walk through them. This is important for being able to actually skip the first Patra in level 9, when going toward the Old Man who talks about the Next Room. It's also great for trying to skip the second Patra, on the way back from the Silver Arrows, going toward Gannon.

Note that when walking through that first Patra, there's a trick to it. You can't just walk through the door. You have to hesitate after unlocking the door, before going through, and stabbing your way through the eye that will otherwise hit you.

Skipping the second Patra going toward the Silver Arrows is a matter of getting a good pattern of movement, and getting your block clip quickly and accurately.

Sadly the Patra before Gannon cannot be skipped with present knowledge.

Additionally, in Level 9 there's a special "reverse" block clip that's very useful to get done quickly, to get out of the wizzrobe room immediately south of the Silver Arrows. It's in theory a standard block clip, but it's coming from the opposite direction most runners do a block clip from, and it's under immense time pressure.

[https://www.youtube.com/watch?v=20p65-Vn6yY Here's a video of the Patra skips and the reverse clip in level 9], from LackAttack24's 29:56 then-WR run.

== Heart Duplication ==

Only possible in the 1.0 FDS version? https://www.youtube.com/watch?v=4iGwBE4aAzU

== Recorder Wrong Warping ==

http://redcandle.us/wp-content/uploads/roocorder4ds.png

Fiskbit: Regarding the technical stuff: The raft and whirlwind both set Link's direction when picking him up. Because Link gets picked up by the raft second, his direction is set to up, which determines the scroll direction. Because he's in the whirlwind, the recorder destination (which is one screen left of the target level) is used as the screen he's scrolling from, and the direction from the raft makes him scroll up.

Fun fact: Both the whirlwind and the raft are controlling Link's position. The whirlwind modifies only his X position, while the raft only modifies his Y position, so he winds up moving diagonally while being carried by both.

http://redcandle.us/wp-content/uploads/overworld_roocorder.png

Eunos: Required execution for Roocorder to save time vs. properly executed current WR route strats. https://youtu.be/MJ7HDzrUUrk

= Other Technical Information =

There are a lot of small interactions and weird corner cases in this game. Here's a section of the site dedicated to them.

[[Legend of Zelda/Technical Information]]

=Fighting Bosses=

[[Legend of Zelda/Bosses]]

=Tutorial Videos=

[[The Legend of Zelda/Tutorial Videos]]

[[The Legend of Zelda/Room Tutorial Series]]

=Routes=

Routing of this game changes all the time. But here are some resources.

Again, [https://www.orderoftheate.com/the-legend-of-zelda Order of the Ate] is a very good site for referencing routes.

If you're better than that, you need to start looking at routes used by top runners, and do research.

Here's some of that research:

* Saver's [http://imgur.com/a/56TXh route tracking] maps.
* Eunos has been putting together some documents: [https://docs.google.com/spreadsheets/d/1MiAI6uH4zMJ7fvYWnELaTu-r8PcDd_p4eT_LqX7edVI/edit Updating Saver's maps] and [https://docs.google.com/document/d/1g5aMlSu5TtMe0liFzc1Ow3fsCReHC_uVJ4HaTsIb010/edit?usp=sharing 100% route document].
* The [https://discord.gg/6GAYGBa routing channel on Lack's LoZ discord] is invaluable for routing.

Some notable historical routes:

Here's [https://archive.org/details/Zelda1_3404 Tom Votava's 34:04 run] from 2003, which was a good route if you didn't know anything at all about block clips, screen wraps, or item drop manipulation.

[https://www.twitch.tv/darkwing_duck_sda/v/49914035 Darkwing Duck's 31:25] is notable as an upgrade from that, beginning to incorporate modern knowledge of the game.

Saver had an sub-30 run early, that skipped the Magic Sword. It's a tough route, but valid, though the video has been lost to the public.

=Maps=

The instructions above assume you know the overworld map, as well as where to get everything inside the dungeons themselves. For maps see [http://www.nesmaps.com NESMaps.com], including [http://www.nesmaps.com/maps/Zelda/Zelda.html dungeon maps] and a [http://www.nesmaps.com/maps/Zelda/ZeldaOverworldQ1.html fully annotated overworld map].

=Records=

See [http://www.speedrun.com/The_Legend_of_Zelda Speedrun.com]

=Randomizer!=

See [[The Legend of Zelda/Randomizer]] for mechanics and techniques specific to [https://sites.google.com/site/zeldarandomizer/ Fred Coughlin's Legend of Zelda Randomizer]

= Tools =

How to patch a ROM? Get an IPS patcher, such as:
* [https://fusoya.eludevisibility.org/lips/ Lunar IPS]
* [https://www.romhacking.net/utilities/746 MultiPatch]
* [https://github.com/fbeaudet/ips.py ips.py]

== ROM Patches ==

These work in a real NES

[https://github.com/helgefmi/tloz-prachack Practice Hack] in development. Shows drop counters. Later may give other useful information.

[http://redcandle.us/w/images/b/b8/Buffet_Zelda_1.2.zip Buffet 1.2 practice hack] by Fiskbit. Displays a timer, drop/spawn/recorder counters, and screen scroll / block clip help. Has a select menu for editing inventory, screen/level warping, and features like making Ganon visible. Archive also contains no-music hacks and FCEUX LUA scripts for things like hitbox and enemy targeting visualization.

[http://redcandle.us/wp-content/uploads/show-target-by-fiskbit.ips AI target viewer] by Fiskbit (in the form of an IPS patch from the PRG0 ROM)

[http://redcandle.us/wp-content/uploads/Legend%20of%20Zelda%2C%20The%20%28U%29%20%28PRG1%29%20%5Baccessible%5D.ips Patch to remove screen flashing] by [https://twitter.com/ireneista/status/946576170392440832 @ireneista]

== Lua scripts ==

These work in select emulators

[https://pastebin.com/UrcyJi7L Hitbox visualizer script v1.2] by Fiskbit

[http://redcandle.us/wp-content/uploads/Zelda_Object_Targeting.lua Zelda Object Targeting v1.0]

[http://games.technoplaza.net/lozsrame/ Legend of Zelda save editor].

== Reading the code ==

[https://github.com/camthesaxman/zeldasource Disassembly project]

[http://zelda.zewt.org/asm.html Another disassembly]

== Miscellaneous ==

[http://avidemux.sourceforge.net Avidemux] is the best tool out there for timing runs.

= History =

[http://redcandle.us/wp-content/Zelda-Historical-Graphs/loz.html History of the record]

[https://www.youtube.com/watch?v=kDluReuJDOk World Record Progression: The Legend of Zelda]

{{#ev:youtube| kDluReuJDOk}}

The Legend of Zelda/Randomizer

2019-03-29T05:23:44Z

Fiskbit: Free Locked Door Extension - Rewrote section (hopefully more clear!). Added recorder/roocorder info.

Twitch user fcoughlin has a [https://sites.google.com/site/zeldarandomizer/ Randomizer] for the Legend of Zelda that's getting really popular to run and to race.

Big thanks to Twitch user [http://twitch.tv/catastrophe573/profile Catastrophe573] for putting together a lot of this information.

See more at [https://www.orderoftheate.com/zelda-1-randomizer Order of the Ate]

=Tutorial Video=

[https://www.twitch.tv/jkoper/v/122851608 Tutorial video by jkoper]

{{#ev:twitchvod|122851608}}

=Randomizer Mechanics and Glitches=

== Ganon's Cry ==

Normally Ganon makes a typical boss noise when you are adjacent to his boss room. When the layout of Level-9 is randomized this is a very useful hint! However, there are some special cases which can trick you.

First, the room with the skull layout on the floor (Ganon's normal room) will NEVER make the sound. Do not assume Ganon isn't next door!

Another case are the Patras. Their cry/roar will mask Ganon's. If you want to 'listen' in a room with a Patra you must first kill it, leave the room, and reenter the room.

== Bomb Out of Ganon's Room ==

Or any other room that has tried to lock you in! If you're stuck and don't want to defeat the enemies (or can't!) then break out the bombs!

== Triforce Room Doors ==

The room which requires you to have the Triforce to pass will NEVER contain a bomb wall. If an expected exit is "missing", such as the north exit in the 1st quest, then that wall is 100% guaranteed to be solid.

A door missing in this way is not necessarily covering Ganon or Zelda. Don't assume anything about the other side of the wall.

== Decoding Warp Stairs Order ==

The any-road shortcuts form a loop of 4 destinations, and each staircase warps you forward in the loop. From left to right, the staircases advance Link by 1, 2, and 3 screens. To see all of the destinations, just keep taking the left staircase.

== Money Making Game Abuse ==

Sometimes you just need a lot of rupees. It happens, especially in the second quest.

If a Money Making Game is anywhere near the starting screen (such as in the non-randomized 1st quest) then you can cheat by saving and reloading your game. Up-A will not work. It must be a full save and retry.

The mechanics of the game are unimportant. Just take the center choice every time.

== Skip Door Repairs ==

If you Up-A out of a door repair before the message finishes then you won't be charged anything! Of course you'll be sent back to the start when you continue. It's up to you if the time/rupees tradeoff is worth it.

== Useful Screen Wraps ==

Avoiding backtracking and taking efficient routes is very important when racing Zelda Randomizer. Here are some unusual screen wraps which save a lot of time, plus a visual reference for the first two.

=== Lost Woods Skip ===

Go one screen north of the Lost Woods. (There is a candle location here.)

Performing the screen wrap from right to left is easier if you position Link directly under the trees and use the visual guide below.

INSERT IMAGE HERE (cannot upload, need privileges)

All screen wraps work just like this one.

=== Ladder-Heart Wrap ===

This one is mentioned separately because it is unique. It requires the ladder! First, collect the heart container on the overworld which requires the stepladder.

Basically you're going to use the screen wrap technique, but in the middle of the screen while standing on the ladder. This allows you to get extra uses out of your ladder while standing on it!

INSERT IMAGE HERE

If you need to explore the green area to the left this will save a lot of walking around.

=== Top Left Reset Wrap ===

If you screen wrap out of bounds you'll be sent back to the starting screen. The only practical place to do this is in the top left corner of the overworld where Level-9 appears in the second quest.

This produces the same effect as using Up-A except that it saves your current hearts! It could be useful after exploring this corner of the world.

=== Other Useful Wraps ===

INSERT IMAGE HERE

For all of these wraps, do the standard screen wrap like the Lost Woods Skip. Beware, most of them need to be done from the center edge of the screen! If you try to use a nearby wall for visual reference then you may end up stuck inside a wall after scrolling the screen.

== Free Locked Doors ==

Entering a dungeon room will open the bombable wall or locked door that you entered through, even if the other side is still sealed. This is how the level 1 locked door trick works in the vanilla game, where leaving and reentering level 1 will open the locked door at the top of the starting screen, but it's actually more general than this.

When you exit off the edge of a screen, the game figures out the direction you're entering the next screen. However, when using up+A or entering a dungeon, the last entrance direction is preserved into the dungeon's starting screen. Because of this, when you leave a dungeon, the game thinks you're entering the next (overworld) screen by that opposite direction, but it doesn't recalculate this when you reenter the dungeon, so the door opposite the one you used to leave the level will be opened. Scrolling on the overworld also marks the entrance direction as open, so entering a screen containing a dungeon from particular directions can be used to open doors on those corresponding directions in the dungeon. This even works with the recorder (always entering from the left), roocorder (always entering from the bottom), and overworld up+A (preserves the last entrance direction).

You can also do this trick with up+A in dungeons, but it's more complicated. When you use up+A in the dungeon, the opened-door state on the old screen will be applied to the starting screen, so any door on the old screen that ''can'' be closed (bombable wall, locked door, shutter door) and is currently open will be able to open its corresponding door on the dungeon entrance screen. You can even use this as you enter a room through a shutter door, since it starts out open; it will stay marked as open for several frames after appearing closed, so mashing start while entering should catch it. Note that while standard doors and false walls are open, they do not count as having been ''opened'' and can't be used for this trick.

== Room Drops ==

https://docs.google.com/spreadsheets/d/1LYqWn7kiYbJ-xnnByOA6RCV7Pob1RoI-7BrHFvrRICA/edit#gid=1711498188

The Legend of Zelda

2019-03-23T19:49:23Z

Fiskbit: /* Lua scripts */ Fixed the link to the object targeting LUA script.

= Getting Started =

Here are some resources commonly requested by new players:

Picking an emulator: [[The Legend of Zelda/Emulators]]

Route options: [https://www.orderoftheate.com/the-legend-of-zelda Order of the Ate] has a list of popular routes that are easier to finish, with a sliding scale of time/difficulty tradeoffs.

Tutorial videos: [[The Legend of Zelda/Tutorial Videos]]

Basic maps: [http://nesmaps.com/maps/Zelda/Zelda.html NESMaps]

Discord: [https://discord.gg/t7sgWzq Invitation to Lack's LoZ Discord server]

== Version differences ==

Here is an entire page devoted to [[The Legend of Zelda/Version Differences|version differences]].

==Categories==

The categories, and their rules, are all documented at [https://www.speedrun.com/The_Legend_of_Zelda speedrun.com's board].

If those categories aren't enough, there's also a [https://www.speedrun.com/zelda1ce Category Extensions board] with its own rules in [https://www.speedrun.com/zelda1ce/forum the forum sticky posts].

==Game Mechanics and Glitches==

===Screen Scroll===

The 'screen scroll' trick is useful for getting over overworld obstacles, as well as for clipping through blocks in dungeons. That means you get to some stairs without killing all the enemies first! Here's a graphic with some pointers:

http://redcandle.us/wp-content/uploads/2012/10/screenscroll.png

Since the above chart was made, an alternate way of clipping through a block has been discovered by [https://twitter.com/hal_yotsuba はる＠よつば]. First, you get onto the pixel as in the above picture, with the top of Link's head lined up with the flat part of the block. Then, instead of doing a single-frame tap, slash the sword and press right or left. The sword slash, done correctly, will prevent you from moving. You will get the same effect as the single frame tap, so if you're positioned right, you will turn around. After the sword slash, walk through the block. This trick only works with block clips, not overworld scrolls or ladder clips.

Here's an additional quick demonstration of the pixels for the "reverse" clip:

http://redcandle.us/wp-content/uploads/reverseclip.png

===Drops===

==== Random drops ====

The enemy drops are not random. Whether they do drop an item is random, but when they do drop, here's what they'll be. The counter starts at 0, and goes up by 1 every time you kill (most) enemies. Zols' gels and vires' keese do not advance the counter. Chart via [http://tasvideos.org/2091S.html Baxter at TASVideos]<nowiki>:</nowiki>

http://redcandle.us/wp-content/uploads/2012/10/zeldaitemdropsnr2.png

====Drop Rates ====

The chance of getting a drop from group A is 80/256 = 31%.

Group B: 104/256 = 41%

Group C: 152/256 = 59%

Group D: 104/256 = 41%

==== Forced drops ====

However there are also the ''consecutive'' kill counters. Kill 10 enemies without getting hit (by an enemy, even a non-damaging bubble, or by the whirlwind from the recorder) and you'll get a forced, guaranteed 5 rupee drop from the next enemy that drops items (not in the X group). Kill the 10th enemy with a bomb instead, and instead of a 5 rupee you'll get a forced, guaranteed bomb drop!

Kill 16 enemies in a row and you get a fairy drop forced, but only if the 16th enemy is capable of dropping an item (not in the X group).

Note that if the 10th enemy does not drop items (in the X group), then killing that enemy with a bomb means the next drop that does happen will be a bomb. Killing that 10th enemy with the sword or any thing else will mean the next drop will be a rupee, even if you kill the next-dropping enemy with a bomb. It's the actual 10th enemy kill that counts, not the succeeding enemy that drops items.

However if the 16th enemy does not drop items, the fairy drop will be skipped entirely, and another one will not happen unless you get hit and the counters reset.

In some rooms that drop an item (such as the 5-Stalfos room in Level 1 that gives a key at the end), one enemy will act like it was holding the drop like a stalfos with a visible key, or a gibdo with a visible bomb. As a result, that enemy will never drop anything, and it will be able to store a forced drop and/or bypass a fairy drop, just like enemies that never drop items.

Note that splitting a Zol into two Gels, or splitting a Vire into two Keese, will not count as a kill or a consecutive kill. Killing one of those split Gels or Keese will not count as a kill for drops, but will count as a consecutive kill. Yes, there are some circumstances that are an exception to this. If the Zol is trapped against a barrier, it can sometimes trigger an extra 'kill' that way. A kill sound in place of a split sound indicates that this has happened. This does not occur with Vires.

Further note: Multiple simultaneous kills will not take you past 10 on the consecutive kill counter, per Darkwing Duck. If they would take you past 10 they leave you at 10 instead.

Advanced strategies: If a forced bomb/rupee or forced fairy drops, the consecutive counter for bombs/rupees is reset, but not the counter for fairies. So no matter how many hits you get on Manhandla with one well-placed bomb, the 10 count is reset after defeating him. The same is true of Dodongo. Likewise with a "Hippo Fairy" (going into a Patra with 7 on the consecutive counters, so that the Patra's center will be kill #16 and get a fairy), the bomb/rupee count resets to 0. Credit to Khananaphone for this discovery.

This means that if you get a forced fairy drop, the next consecutive bomb/rupee kill will not be at 20. It will be at 26. So bomb/rupee drops work in one of two methods:

# 10, (Fairy at 16), 26, 36, 46...
# 10, (Skip fairy at 16 by killing non-dropping enemy), 20, 30, 40...

Credit to Darkwing Duck for this discovery.

===Luck Manipulation===

See [[The Legend of Zelda/Luck Manipulation]]

===The Recorder===

The recorder loops you through all the dungeons you've gotten the Triforce in, sequentially, according to the direction link is facing. It has an internal counter that starts at 1. Every time you blow the recorder in a place where the whirlwind would appear (that is, in most overworld screens, but not all), the counter changes according to the direction Link is facing. If Link is facing right or up, then the counter goes up one. If Link is facing down or left, then the counter goes down one.

Note that this counter does not reset during the run.

For example, hold your right foot turnwise to the out. If Link is facing where your toes point cross-wise, then the count will be cremented.

OK, never mind that. Let's say Link has completed dungeons 1, 3, 4, and 5. If Link blows the whistle once facing down. Link will then be taken to level 5, because the count started at one, and then looped around to 5.

Let's say link then blows the whistle 3 more times while facing down. The count will go 4, 3, 1, skipping 2 since the player has not completed 2 yet, and Link will be taken to 1.

So let's go back to the first example. Link just completed Level 5, and blows the whistle twice. Once facing down, once facing right. The counter will go from 1 to 5, and then back from 5 to 1, taking Link to Level 1. This is a technique used in record runs.

NOTE: the order of the dungeons is different in the second quest. (2/3, 4/5, 7/8 swapped?)

===Bombing Darknuts===

Whether a Darknut blocks a bomb's explosion with its shield is determined by two things. First, the direction Link is facing when he lays the bomb. Second, the direction the Darknut is facing when the explosion hits him. If Link's position when laying the bomb is facing the direction the Darknut is looking when the bomb goes off, the bomb won't work.

Here is a graphic by Lackattack24.

http://redcandle.us/wp-content/uploads/darknuts-lackattack.png

===Bombing Walls===

Note that bombs do not check to see if a hole should be opened whenever a shutter is opening or closing. Beware of that.

Image by Eunos on positioning:

http://redcandle.us/wp-content/uploads/eunos-bomb-positions.png

===Free Locked Door===

If you enter a dungeon and the first room has a locked door on top then you can leave and immediately reenter to unlock that door for free!

===Walking through enemies===

If an enemy has just been hit, then Link can temporarily walk through that enemy without damage or knockback. However the enemy itself must not be knocked back or split in order for that to work. So this doesn't work against Zols or Vires. Striking a Darknut's shield also prevents this from working.

Enemies won't be knocked back if hit perpendicular to their movement direction while they're between tiles. When they're directly on a tile, they can be knocked back in any direction.

Link normally stops walking temporarily when using the sword. Exceptions to this are while stepping onto the ladder (useful in 7 after the hungry Goriya, and in 1 to steal the key from the Stalfos after the Gels), and when stepping into a door (useful in 9 when skipping the first Patra). Catching a boomerang while stabbing will also allow Link to start moving immediately.

=== Skipping Patras ===

Walking through Patras is a special case. It turns out that the orbiting eyes of the Patra don't actually exist hitbox-wise right away. This gives you time to walk through them. This is important for being able to actually skip the first Patra in level 9, when going toward the Old Man who talks about the Next Room. It's also great for trying to skip the second Patra, on the way back from the Silver Arrows, going toward Gannon.

Note that when walking through that first Patra, there's a trick to it. You can't just walk through the door. You have to hesitate after unlocking the door, before going through, and stabbing your way through the eye that will otherwise hit you.

Skipping the second Patra going toward the Silver Arrows is a matter of getting a good pattern of movement, and getting your block clip quickly and accurately.

Sadly the Patra before Gannon cannot be skipped with present knowledge.

Additionally, in Level 9 there's a special "reverse" block clip that's very useful to get done quickly, to get out of the wizzrobe room immediately south of the Silver Arrows. It's in theory a standard block clip, but it's coming from the opposite direction most runners do a block clip from, and it's under immense time pressure.

[https://www.youtube.com/watch?v=20p65-Vn6yY Here's a video of the Patra skips and the reverse clip in level 9], from LackAttack24's 29:56 then-WR run.

=== Heart Duplication ===

Only possible in the 1.0 FDS version? https://www.youtube.com/watch?v=4iGwBE4aAzU

=== Recorder Wrong Warping ===

http://redcandle.us/wp-content/uploads/roocorder4ds.png

Fiskbit: Regarding the technical stuff: The raft and whirlwind both set Link's direction when picking him up. Because Link gets picked up by the raft second, his direction is set to up, which determines the scroll direction. Because he's in the whirlwind, the recorder destination (which is one screen left of the target level) is used as the screen he's scrolling from, and the direction from the raft makes him scroll up.

Fun fact: Both the whirlwind and the raft are controlling Link's position. The whirlwind modifies only his X position, while the raft only modifies his Y position, so he winds up moving diagonally while being carried by both.

http://redcandle.us/wp-content/uploads/overworld_roocorder.png

Eunos: Required execution for Roocorder to save time vs. properly executed current WR route strats. https://youtu.be/MJ7HDzrUUrk

== Other Technical Information ==

There are a lot of small interactions and weird corner cases in this game. Here's a section of the site dedicated to them.

[[Legend of Zelda/Technical Information]]

==Fighting Bosses==

[[Legend of Zelda/Bosses]]

==Tutorial Videos==

[[The Legend of Zelda/Tutorial Videos]]

==Routes==

Routing of this game changes all the time. But here are some resources.

Again, [https://www.orderoftheate.com/the-legend-of-zelda Order of the Ate] is a very good site for referencing routes.

If you're better than that, you need to start looking at routes used by top runners, and do research.

Here's some of that research:

* Saver's [http://imgur.com/a/56TXh route tracking] maps.
* Eunos has been putting together some documents: [https://docs.google.com/spreadsheets/d/1MiAI6uH4zMJ7fvYWnELaTu-r8PcDd_p4eT_LqX7edVI/edit Updating Saver's maps] and [https://docs.google.com/document/d/1g5aMlSu5TtMe0liFzc1Ow3fsCReHC_uVJ4HaTsIb010/edit?usp=sharing 100% route document].
* The [https://discord.gg/6GAYGBa routing channel on Lack's LoZ discord] is invaluable for routing.

Some notable historical routes:

Here's [https://archive.org/details/Zelda1_3404 Tom Votava's 34:04 run] from 2003, which was a good route if you didn't know anything at all about block clips, screen wraps, or item drop manipulation.

[https://www.twitch.tv/darkwing_duck_sda/v/49914035 Darkwing Duck's 31:25] is notable as an upgrade from that, beginning to incorporate modern knowledge of the game.

Saver had an sub-30 run early, that skipped the Magic Sword. It's a tough route, but valid, though the video has been lost to the public.

==Maps==

The instructions above assume you know the overworld map, as well as where to get everything inside the dungeons themselves. For maps see [http://www.nesmaps.com NESMaps.com], including [http://www.nesmaps.com/maps/Zelda/Zelda.html dungeon maps] and a [http://www.nesmaps.com/maps/Zelda/ZeldaOverworldQ1.html fully annotated overworld map].

==Records==

See [http://www.speedrun.com/The_Legend_of_Zelda Speedrun.com]

==Randomizer!==

See [[The Legend of Zelda/Randomizer]] for mechanics and techniques specific to [https://sites.google.com/site/zeldarandomizer/ Fred Coughlin's Legend of Zelda Randomizer]

== Tools ==

How to patch a ROM? Get an IPS patcher, such as:
* [https://fusoya.eludevisibility.org/lips/ Lunar IPS]
* [https://www.romhacking.net/utilities/746 MultiPatch]
* [https://github.com/fbeaudet/ips.py ips.py]

=== ROM Patches ===

These work in a real NES

[https://github.com/helgefmi/tloz-prachack Practice Hack] in development. Shows drop counters. Later may give other useful information.

[http://redcandle.us/w/images/b/b8/Buffet_Zelda_1.2.zip Buffet 1.2 practice hack] by Fiskbit. Displays a timer, drop/spawn/recorder counters, and screen scroll / block clip help. Has a select menu for editing inventory, screen/level warping, and features like making Ganon visible. Archive also contains no-music hacks and FCEUX LUA scripts for things like hitbox and enemy targeting visualization.

[http://redcandle.us/wp-content/uploads/show-target-by-fiskbit.ips AI target viewer] by Fiskbit (in the form of an IPS patch from the PRG0 ROM)

[http://redcandle.us/wp-content/uploads/Legend%20of%20Zelda%2C%20The%20%28U%29%20%28PRG1%29%20%5Baccessible%5D.ips Patch to remove screen flashing] by [https://twitter.com/ireneista/status/946576170392440832 @ireneista]

=== Lua scripts ===

These work in select emulators

[https://pastebin.com/UrcyJi7L Hitbox visualizer script v1.2] by Fiskbit

[http://redcandle.us/wp-content/uploads/Zelda_Object_Targeting.lua Zelda Object Targeting v1.0]

[http://games.technoplaza.net/lozsrame/ Legend of Zelda save editor].

=== Reading the code ===

[https://github.com/camthesaxman/zeldasource Disassembly project]

[http://zelda.zewt.org/asm.html Another disassembly]

=== Misc ===

[http://avidemux.sourceforge.net Avidemux] is the best tool out there for timing runs.

== History ==

[http://redcandle.us/wp-content/Zelda-Historical-Graphs/loz.html History of the record]

[https://www.youtube.com/watch?v=kDluReuJDOk World Record Progression: The Legend of Zelda]

{{#ev:youtube| kDluReuJDOk}}

The Legend of Zelda

2019-03-13T09:37:28Z

Fiskbit: Tools - Updates the Buffet link to 1.2 and adds a feature description.

= Getting Started =

Here are some resources commonly requested by new players:

Picking an emulator: [[The Legend of Zelda/Emulators]]

Route options: [https://www.orderoftheate.com/the-legend-of-zelda Order of the Ate] has a list of popular routes that are easier to finish, with a sliding scale of time/difficulty tradeoffs.

Tutorial videos: [[The Legend of Zelda/Tutorial Videos]]

Basic maps: [http://nesmaps.com/maps/Zelda/Zelda.html NESMaps]

Discord: [https://discord.gg/t7sgWzq Invitation to Lack's LoZ Discord server]

== Version differences ==

Here is an entire page devoted to [[The Legend of Zelda/Version Differences|version differences]].

==Categories==

The categories, and their rules, are all documented at [https://www.speedrun.com/The_Legend_of_Zelda speedrun.com's board].

If those categories aren't enough, there's also a [https://www.speedrun.com/zelda1ce Category Extensions board] with its own rules in [https://www.speedrun.com/zelda1ce/forum the forum sticky posts].

==Game Mechanics and Glitches==

===Screen Scroll===

The 'screen scroll' trick is useful for getting over overworld obstacles, as well as for clipping through blocks in dungeons. That means you get to some stairs without killing all the enemies first! Here's a graphic with some pointers:

http://redcandle.us/wp-content/uploads/2012/10/screenscroll.png

Since the above chart was made, an alternate way of clipping through a block has been discovered by [https://twitter.com/hal_yotsuba はる＠よつば]. First, you get onto the pixel as in the above picture, with the top of Link's head lined up with the flat part of the block. Then, instead of doing a single-frame tap, slash the sword and press right or left. The sword slash, done correctly, will prevent you from moving. You will get the same effect as the single frame tap, so if you're positioned right, you will turn around. After the sword slash, walk through the block. This trick only works with block clips, not overworld scrolls or ladder clips.

Here's an additional quick demonstration of the pixels for the "reverse" clip:

http://redcandle.us/wp-content/uploads/reverseclip.png

===Drops===

==== Random drops ====

The enemy drops are not random. Whether they do drop an item is random, but when they do drop, here's what they'll be. The counter starts at 0, and goes up by 1 every time you kill (most) enemies. Zols' gels and vires' keese do not advance the counter. Chart via [http://tasvideos.org/2091S.html Baxter at TASVideos]<nowiki>:</nowiki>

http://redcandle.us/wp-content/uploads/2012/10/zeldaitemdropsnr2.png

====Drop Rates ====

The chance of getting a drop from group A is 80/256 = 31%.

Group B: 104/256 = 41%

Group C: 152/256 = 59%

Group D: 104/256 = 41%

==== Forced drops ====

However there are also the ''consecutive'' kill counters. Kill 10 enemies without getting hit (by an enemy, even a non-damaging bubble, or by the whirlwind from the recorder) and you'll get a forced, guaranteed 5 rupee drop from the next enemy that drops items (not in the X group). Kill the 10th enemy with a bomb instead, and instead of a 5 rupee you'll get a forced, guaranteed bomb drop!

Kill 16 enemies in a row and you get a fairy drop forced, but only if the 16th enemy is capable of dropping an item (not in the X group).

Note that if the 10th enemy does not drop items (in the X group), then killing that enemy with a bomb means the next drop that does happen will be a bomb. Killing that 10th enemy with the sword or any thing else will mean the next drop will be a rupee, even if you kill the next-dropping enemy with a bomb. It's the actual 10th enemy kill that counts, not the succeeding enemy that drops items.

However if the 16th enemy does not drop items, the fairy drop will be skipped entirely, and another one will not happen unless you get hit and the counters reset.

In some rooms that drop an item (such as the 5-Stalfos room in Level 1 that gives a key at the end), one enemy will act like it was holding the drop like a stalfos with a visible key, or a gibdo with a visible bomb. As a result, that enemy will never drop anything, and it will be able to store a forced drop and/or bypass a fairy drop, just like enemies that never drop items.

Note that splitting a Zol into two Gels, or splitting a Vire into two Keese, will not count as a kill or a consecutive kill. Killing one of those split Gels or Keese will not count as a kill for drops, but will count as a consecutive kill. Yes, there are some circumstances that are an exception to this. If the Zol is trapped against a barrier, it can sometimes trigger an extra 'kill' that way. A kill sound in place of a split sound indicates that this has happened. This does not occur with Vires.

Further note: Multiple simultaneous kills will not take you past 10 on the consecutive kill counter, per Darkwing Duck. If they would take you past 10 they leave you at 10 instead.

Advanced strategies: If a forced bomb/rupee or forced fairy drops, the consecutive counter for bombs/rupees is reset, but not the counter for fairies. So no matter how many hits you get on Manhandla with one well-placed bomb, the 10 count is reset after defeating him. The same is true of Dodongo. Likewise with a "Hippo Fairy" (going into a Patra with 7 on the consecutive counters, so that the Patra's center will be kill #16 and get a fairy), the bomb/rupee count resets to 0. Credit to Khananaphone for this discovery.

This means that if you get a forced fairy drop, the next consecutive bomb/rupee kill will not be at 20. It will be at 26. So bomb/rupee drops work in one of two methods:

# 10, (Fairy at 16), 26, 36, 46...
# 10, (Skip fairy at 16 by killing non-dropping enemy), 20, 30, 40...

Credit to Darkwing Duck for this discovery.

===Luck Manipulation===

See [[The Legend of Zelda/Luck Manipulation]]

===The Recorder===

The recorder loops you through all the dungeons you've gotten the Triforce in, sequentially, according to the direction link is facing. It has an internal counter that starts at 1. Every time you blow the recorder in a place where the whirlwind would appear (that is, in most overworld screens, but not all), the counter changes according to the direction Link is facing. If Link is facing right or up, then the counter goes up one. If Link is facing down or left, then the counter goes down one.

Note that this counter does not reset during the run.

For example, hold your right foot turnwise to the out. If Link is facing where your toes point cross-wise, then the count will be cremented.

OK, never mind that. Let's say Link has completed dungeons 1, 3, 4, and 5. If Link blows the whistle once facing down. Link will then be taken to level 5, because the count started at one, and then looped around to 5.

Let's say link then blows the whistle 3 more times while facing down. The count will go 4, 3, 1, skipping 2 since the player has not completed 2 yet, and Link will be taken to 1.

So let's go back to the first example. Link just completed Level 5, and blows the whistle twice. Once facing down, once facing right. The counter will go from 1 to 5, and then back from 5 to 1, taking Link to Level 1. This is a technique used in record runs.

NOTE: the order of the dungeons is different in the second quest. (2/3, 4/5, 7/8 swapped?)

===Bombing Darknuts===

Whether a Darknut blocks a bomb's explosion with its shield is determined by two things. First, the direction Link is facing when he lays the bomb. Second, the direction the Darknut is facing when the explosion hits him. If Link's position when laying the bomb is facing the direction the Darknut is looking when the bomb goes off, the bomb won't work.

Here is a graphic by Lackattack24.

http://redcandle.us/wp-content/uploads/darknuts-lackattack.png

===Bombing Walls===

Note that bombs do not check to see if a hole should be opened whenever a shutter is opening or closing. Beware of that.

Image by Eunos on positioning:

http://redcandle.us/wp-content/uploads/eunos-bomb-positions.png

===Free Locked Door===

If you enter a dungeon and the first room has a locked door on top then you can leave and immediately reenter to unlock that door for free!

===Walking through enemies===

If an enemy has just been hit, then Link can temporarily walk through that enemy without damage or knockback. However the enemy itself must not be knocked back or split in order for that to work. So this doesn't work against Zols or Vires. Striking a Darknut's shield also prevents this from working.

Enemies won't be knocked back if hit perpendicular to their movement direction while they're between tiles. When they're directly on a tile, they can be knocked back in any direction.

Link normally stops walking temporarily when using the sword. Exceptions to this are while stepping onto the ladder (useful in 7 after the hungry Goriya, and in 1 to steal the key from the Stalfos after the Gels), and when stepping into a door (useful in 9 when skipping the first Patra). Catching a boomerang while stabbing will also allow Link to start moving immediately.

=== Skipping Patras ===

Walking through Patras is a special case. It turns out that the orbiting eyes of the Patra don't actually exist hitbox-wise right away. This gives you time to walk through them. This is important for being able to actually skip the first Patra in level 9, when going toward the Old Man who talks about the Next Room. It's also great for trying to skip the second Patra, on the way back from the Silver Arrows, going toward Gannon.

Note that when walking through that first Patra, there's a trick to it. You can't just walk through the door. You have to hesitate after unlocking the door, before going through, and stabbing your way through the eye that will otherwise hit you.

Skipping the second Patra going toward the Silver Arrows is a matter of getting a good pattern of movement, and getting your block clip quickly and accurately.

Sadly the Patra before Gannon cannot be skipped with present knowledge.

Additionally, in Level 9 there's a special "reverse" block clip that's very useful to get done quickly, to get out of the wizzrobe room immediately south of the Silver Arrows. It's in theory a standard block clip, but it's coming from the opposite direction most runners do a block clip from, and it's under immense time pressure.

[https://www.youtube.com/watch?v=20p65-Vn6yY Here's a video of the Patra skips and the reverse clip in level 9], from LackAttack24's 29:56 then-WR run.

=== Heart Duplication ===

Only possible in the 1.0 FDS version? https://www.youtube.com/watch?v=4iGwBE4aAzU

=== Recorder Wrong Warping ===

http://redcandle.us/wp-content/uploads/roocorder4ds.png

Fiskbit: Regarding the technical stuff: The raft and whirlwind both set Link's direction when picking him up. Because Link gets picked up by the raft second, his direction is set to up, which determines the scroll direction. Because he's in the whirlwind, the recorder destination (which is one screen left of the target level) is used as the screen he's scrolling from, and the direction from the raft makes him scroll up.

Fun fact: Both the whirlwind and the raft are controlling Link's position. The whirlwind modifies only his X position, while the raft only modifies his Y position, so he winds up moving diagonally while being carried by both.

http://redcandle.us/wp-content/uploads/overworld_roocorder.png

Eunos: Required execution for Roocorder to save time vs. properly executed current WR route strats. https://youtu.be/MJ7HDzrUUrk

== Other Technical Information ==

There are a lot of small interactions and weird corner cases in this game. Here's a section of the site dedicated to them.

[[Legend of Zelda/Technical Information]]

==Fighting Bosses==

[[Legend of Zelda/Bosses]]

==Tutorial Videos==

[[The Legend of Zelda/Tutorial Videos]]

==Routes==

Routing of this game changes all the time. But here are some resources.

Again, [https://www.orderoftheate.com/the-legend-of-zelda Order of the Ate] is a very good site for referencing routes.

If you're better than that, you need to start looking at routes used by top runners, and do research.

Here's some of that research:

* Saver's [http://imgur.com/a/56TXh route tracking] maps.
* Eunos has been putting together some documents: [https://docs.google.com/spreadsheets/d/1MiAI6uH4zMJ7fvYWnELaTu-r8PcDd_p4eT_LqX7edVI/edit Updating Saver's maps] and [https://docs.google.com/document/d/1g5aMlSu5TtMe0liFzc1Ow3fsCReHC_uVJ4HaTsIb010/edit?usp=sharing 100% route document].
* The [https://discord.gg/6GAYGBa routing channel on Lack's LoZ discord] is invaluable for routing.

Some notable historical routes:

Here's [https://archive.org/details/Zelda1_3404 Tom Votava's 34:04 run] from 2003, which was a good route if you didn't know anything at all about block clips, screen wraps, or item drop manipulation.

[https://www.twitch.tv/darkwing_duck_sda/v/49914035 Darkwing Duck's 31:25] is notable as an upgrade from that, beginning to incorporate modern knowledge of the game.

Saver had an sub-30 run early, that skipped the Magic Sword. It's a tough route, but valid, though the video has been lost to the public.

==Maps==

The instructions above assume you know the overworld map, as well as where to get everything inside the dungeons themselves. For maps see [http://www.nesmaps.com NESMaps.com], including [http://www.nesmaps.com/maps/Zelda/Zelda.html dungeon maps] and a [http://www.nesmaps.com/maps/Zelda/ZeldaOverworldQ1.html fully annotated overworld map].

==Records==

See [http://www.speedrun.com/The_Legend_of_Zelda Speedrun.com]

==Randomizer!==

See [[The Legend of Zelda/Randomizer]] for mechanics and techniques specific to [https://sites.google.com/site/zeldarandomizer/ Fred Coughlin's Legend of Zelda Randomizer]

== Tools ==

[http://games.technoplaza.net/lozsrame/ Legend of Zelda save editor].

[https://github.com/helgefmi/tloz-prachack Practice Hack] in development. Shows drop counters. Later may give other useful information.

[http://redcandle.us/w/images/b/b8/Buffet_Zelda_1.2.zip Buffet 1.2 practice hack] by Fiskbit. Displays a timer, drop/spawn/recorder counters, and screen scroll / block clip help. Has a select menu for editing inventory, screen/level warping, and features like making Ganon visible. Archive also contains no-music hacks and FCEUX LUA scripts for things like hitbox and enemy targeting visualization.

[https://pastebin.com/UrcyJi7L Hitbox visualizer script v1.2] by Fiskbit

[http://redcandle.us/wp-content/uploads/show-target-by-fiskbit.ips AI target viewer] by Fiskbit (in the form of an IPS patch from the PRG0 ROM)

[https://github.com/camthesaxman/zeldasource Disassembly project]

[http://zelda.zewt.org/asm.html Another disassembly]

[http://redcandle.us/wp-content/uploads/Legend%20of%20Zelda%2C%20The%20%28U%29%20%28PRG1%29%20%5Baccessible%5D.ips Patch to remove screen flashing] by [https://twitter.com/ireneista/status/946576170392440832 @ireneista]

[http://avidemux.sourceforge.net Avidemux] is the best tool out there for timing runs.

== History ==

[http://redcandle.us/wp-content/Zelda-Historical-Graphs/loz.html History of the record]

[https://www.youtube.com/watch?v=kDluReuJDOk World Record Progression: The Legend of Zelda]

{{#ev:youtube| kDluReuJDOk}}

File:Buffet Zelda 1.2.zip

2019-03-11T03:30:57Z

Fiskbit: The 1.2 release of Buffet, a Zelda 1 practice hack.

The 1.2 release of Buffet, a Zelda 1 practice hack.

Legend of Zelda/Technical Information

2019-03-06T14:22:26Z

Fiskbit: Dungeon graphics corruption - Adds a screenshot and improves the description of the glitch.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Objects ==

=== Object system ===

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

=== Object movement ===

Most non-flying objects are restricted to moving along a movement grid, consisting of edges and vertices. The length of an edge in this grid depends on the object index, with the standard length being 16 pixels and Link's being 8. When an object isn't on a vertex, its direction is restricted such that it can only be parallel to the current edge. An object is on a vertex when its position along the current edge (object_subgrid_offset) is 0, regardless of its current subpixel position (object_subpos).

Every frame that an object chooses to move, it undergoes 4 movement ticks that each move the object by less than one pixel. Within each tick, its speed (object_speed) is added to or subtracted from its subpixel position, depending on whether the movement is in a positive (down or right) or negative (up or left) direction. If the subgrid offset hasn't reached either limit for this kind of object ($010E subgrid_offset_limit_positive and $010F subgrid_offset_limit_negative), the carry from the subpixel arithmetic is added to or subtracted from both the subgrid offset and whole pixel position.

If either limit has been reached, then subsequent ticks within the same frame continue to modify the subpixel position as normal, but the offset and whole pixel values lock into place. This causes objects to stick to vertices, which is where important operations such as background collision detection and screen edge detection take place. When movement is complete, if the subgrid offset is equal to one of the limits, it is set back to 0.

Note that there is only one subpixel position, despite there being two axes. This is because standard objects can only move along one axis at a time, with the other axis coordinate aligned to the grid, so it's only ever relevant to the current one. However, this value isn't cleared when turning perpendicular, so the object may be closer to or further from the next pixel than expected when turning.

=== Screen scroll glitch ===

Normally, Link and other objects walk from a subgrid offset of 0 toward either the positive or negative limit, which will prevent further whole-pixel movement that frame. However, this same clamping behavior doesn't occur for 0. Normally, this isn't a problem, because if an object starts on 0, moves in a direction, and then turns around before reaching the next vertex and walks back, it will necessarily land on 0 again because it moves the same speed both ways, precisely retracing the steps it took. Non-Link objects also usually do not change their direction except on vertices. However, knockback can cause a problem for Link. When an object is hit and knocked back, it moves one entire pixel per tick for 4 ticks per frame through a separate mechanism from standard movement. This can cause Link to be at an unusual position along an edge, which could cause him to skip past 0 because he moves 1.5 pixels per frame (#$60 subpixels per tick).

Skipping past 0 results in the collision event at 0 being skipped. This bypasses Link's screen boundary check for scrolling, and causes the object to continue using the background tile it sampled at the last vertex as its current one. Realistically, that tile will be nonsolid, so the object may be able to skip past one solid tile.

A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

To fix this issue, the game includes a hack to ensure that the vertex Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

With the hack, holding up would first convert the offset to -6 (preserving the distance of 2.5 pixels from the vertex), and Link would then move to offset -7 subpixel #$00, and try to move to offset -9 subpixel #$80, but the clamping on the -8 limit would cause him to end up at offset -8 subpixel #$80, which would set his offset back to 0 and allow him to handle collision and move up.

For standard screen scrolling, if Link is facing right on a horizontal edge at offset 3 subpixel #$00, perpendicular input will convert the offset to -5 and move Link to offset -7 subpixel #$80. Walking right will then move him to offset -5 subpixel #$00, offset -4 subpixel #$80, offset -2 subpixel #$00, offset -1 subpixel #$80, and then offset 1 subpixel #$00, skipping 0.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link kills a second dodongo with a sword before the first one has dropped its bomb, the second will not drop a bomb because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Overkill''': When an enemy is killed by a weapon, it still finishes checking the remaining weapons that frame, as normal. This means it can be hit by those additional weapons, which may also kill it. The consecutive kill counters are incremented at kill time, so these additional kills will each increment the counters like with any normal kill. As a result, killing a single enemy by hitting it with multiple weapons on one frame can add more than one to the counts. This can be done most practically by timing multiple attacks to hit when an enemy's iframes expire.

Note that the health the enemy has after a killing blow can vary. If the weapon damage was equal to the enemy's current health, the resulting health is 0, so any following hits will count as kills. However, if the damage was more than the current health, the health is unchanged. Furthermore, the order in which weapons are checked can impact how many kills the enemy gives because each weapon hit may reduce the health for the following weapons. Weapon check order is boomerang, beam (sword/rod), flame/bomb slot A, flame/bomb slot B, sword, arrow/rod.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Glitches ==

=== Dungeon graphics corruption ===

[[File:Glitch_dungeon_graphics_corruption.png]]

When entering a dungeon on the same frame that a background block is changed, such as an armos statue or bombable wall, there's a 50% chance that the dungeon graphics won't load properly, resulting in the overworld graphics being used but with some minor corruption. While some of the corruption will persist until reset, the issue is mostly corrected upon leaving the dungeon.

When you change areas, the game has to copy over all of the area's graphics from ROM to VRAM. This can't be done directly; instead, the game has to tell the PPU where in VRAM it wants to put the graphics, and then hands the bytes to the PPU one-by-one to put at the specified location. After each byte is written, the target address is automatically incremented by the PPU, and there's a PPU setting that controls whether the increment is by 1 or 32. This is to make it easy to change adjacent 8x8 tiles on the screen; if incrementing by 1, it'll target the next tile in the row, and if by 32, the next tile in the column (because rows are 32 tiles wide).

The graphics copying function assumes that the PPU is set to increment by 1 per write, but doesn't actually guarantee this by setting it this way. Background block updates in Zelda go vertically (increment by 32), so if that was the last thing to configure the PPU before you enter a new area, the setting will be wrong and the graphics copy will erroneously splatter the graphics data throughout VRAM (modifying only 1 out of every 32 bytes) instead of copying the contiguous chunks as it should. This normally doesn't happen because updates to the HUD leave the PPU in the correct increment-by-1 configuration. HUD updates occur every other frame, so there is only a 1-frame window during which you can enter with the incorrect PPU settings. Because of the difficulty of timing these events to fall between HUD updates, you effectively have a 50% chance of triggering the glitch by entering a dungeon on the same frame as a background update.

Because area graphics are loaded on every area transition, most of the issue is corrected by leaving the dungeon. However, some graphics are only copied to VRAM on power on or reset and will remain partially corrupted until then.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

File:Glitch dungeon graphics corruption.png

2019-03-06T14:08:38Z

Fiskbit: Level 3 after triggering a glitch that prevents graphics from loading properly.

Level 3 after triggering a glitch that prevents graphics from loading properly.

The Legend of Zelda

2018-11-27T01:45:31Z

Fiskbit: Forced drops: Improves information about zol/vire consecutive counting.

== Version differences ==

[[The Legend of Zelda/Version Differences]]

==Categories==

===Any%===

Get to Zelda as fast as you can.

As there are no known means of getting to Zelda without defeating Gannon and taking the Triforce, and there are no known means of getting into Level 9 without all of the Triforce pieces, this means one must complete every dungeon. Items needed: Wooden Sword, Bombs, Bow, Candle, Raft, Ladder, Recorder, Bait, Arrows, Silver Arrows. Items acquired for maximum speed in current routing: Heart containers, Magic Sword.

===Swordless===

This is a challenge category. One plays the game according to the Any% rules, with two changes: No sword is allowed, and the run ends upon reaching Gannon and holding up the Triforce. Gannon cannot be killed without a sword, unlike other enemies who can be killed with Bombs, Boomerang, Arrows, Candles, or the Wand. See [[The Legend of Zelda/Swordless Route]] for information on a way to run this category.

===100%===

The category requires the player to acquire:

* 13 heart containers (for 16 total)
* Letter
* Power Bracelet
* Magic Sword
* Both bomb upgrades
* Bow
* Magic Boomerang
* Raft
* Ladder
* Recorder
* Wand
* Red Candle
* Book/Bible
* Magic Key
* Silver Arrows
* Red Ring

Items that are infinitely obtainable and consumable (such as the Bait, Red Potion, Blue Potion, Rupees, Magic Shield, keys other than the Magic Key, or the Bombs themselves) or are replaced (such as the Wooden Boomerang, the Wooden Sword, the White Sword, the Blue Ring, keys other than the Magic Key, and the Blue Candle) are not required.

==Game Mechanics and Glitches==

===Screen Scroll===

The 'screen scroll' trick is useful for getting over overworld obstacles, as well as for clipping through blocks in dungeons. That means you get to some stairs without killing all the enemies first! Here's a graphic with some pointers:

http://redcandle.us/wp-content/uploads/2012/10/screenscroll.png

Since the above chart was made, an alternate way of clipping through a block has been discovered by [https://twitter.com/hal_yotsuba はる＠よつば]. First, you get onto the pixel as in the above picture, with the top of Link's head lined up with the flat part of the block. Then, instead of doing a single-frame tap, slash the sword and press right or left. The sword slash, done correctly, will prevent you from moving. You will get the same effect as the single frame tap, so if you're positioned right, you will turn around. After the sword slash, walk through the block. This trick only works with block clips, not overworld scrolls or ladder clips.

Here's an additional quick demonstration of the pixels for the "reverse" clip:

http://redcandle.us/wp-content/uploads/reverseclip.png

===Drops===

==== Random drops ====

The enemy drops are not random. Whether they do drop an item is random, but when they do drop, here's what they'll be. The counter starts at 0, and goes up by 1 every time you kill (most) enemies. Zols' gels and vires' keese do not advance the counter. Chart via [http://tasvideos.org/2091S.html Baxter at TASVideos]<nowiki>:</nowiki>

http://redcandle.us/wp-content/uploads/2012/10/zeldaitemdropsnr2.png

====Drop Rates ====

The chance of getting a drop from group A is 80/256 = 31%.

Group B: 104/256 = 41%

Group C: 152/256 = 59%

Group D: 104/256 = 41%

==== Forced drops ====

However there are also the ''consecutive'' kill counters. Kill 10 enemies without getting hit (by an enemy, even a non-damaging bubble, or by the whirlwind from the recorder) and you'll get a forced, guaranteed 5 rupee drop from the next enemy that drops items (not in the X group). Kill the 10th enemy with a bomb instead, and instead of a 5 rupee you'll get a forced, guaranteed bomb drop!

Kill 16 enemies in a row and you get a fairy drop forced, but only if the 16th enemy is capable of dropping an item (not in the X group).

Note that if the 10th enemy does not drop items (in the X group), then killing that enemy with a bomb means the next drop that does happen will be a bomb. Killing that 10th enemy with the sword or any thing else will mean the next drop will be a rupee, even if you kill the next-dropping enemy with a bomb. It's the actual 10th enemy kill that counts, not the succeeding enemy that drops items.

However if the 16th enemy does not drop items, the fairy drop will be skipped entirely, and another one will not happen unless you get hit and the counters reset.

In some rooms that drop an item (such as the 5-Stalfos room in Level 1 that gives a key at the end), one enemy will act like it was holding the drop like a stalfos with a visible key, or a gibdo with a visible bomb. As a result, that enemy will never drop anything, and it will be able to store a forced drop and/or bypass a fairy drop, just like enemies that never drop items.

Note that splitting a Zol into two Gels, or splitting a Vire into two Keese, will not count as a kill or a consecutive kill. Killing one of those split Gels or Keese will not count as a kill for drops, but will count as a consecutive kill. Yes, there are some circumstances that are an exception to this. If the Zol is trapped against a barrier, it can sometimes trigger an extra 'kill' that way. A kill sound in place of a split sound indicates that this has happened. This does not occur with Vires.

Further note: Multiple simultaneous kills will not take you past 10 on the consecutive kill counter, per Darkwing Duck. If they would take you past 10 they leave you at 10 instead.

Advanced strategies: If a forced bomb/rupee or forced fairy drops, the consecutive counter for bombs/rupees is reset, but not the counter for fairies. So no matter how many hits you get on Manhandla with one well-placed bomb, the 10 count is reset after defeating him. The same is true of Dodongo. Likewise with a "Hippo Fairy" (going into a Patra with 7 on the consecutive counters, so that the Patra's center will be kill #16 and get a fairy), the bomb/rupee count resets to 0. Credit to Khananaphone for this discovery.

This means that if you get a forced fairy drop, the next consecutive bomb/rupee kill will not be at 20. It will be at 26. So bomb/rupee drops work in one of two methods:

# 10, (Fairy at 16), 26, 36, 46...
# 10, (Skip fairy at 16 by killing non-dropping enemy), 20, 30, 40...

Credit to Darkwing Duck for this discovery.

===Luck Manipulation===

See [[The Legend of Zelda/Luck Manipulation]]

===The Recorder===

The recorder loops you through all the dungeons you've gotten the Triforce in, sequentially, according to the direction link is facing. It has an internal counter that starts at 1. Every time you blow the recorder in a place where the whirlwind would appear (that is, in most overworld screens, but not all), the counter changes according to the direction Link is facing. If Link is facing right or up, then the counter goes up one. If Link is facing down or left, then the counter goes down one.

Note that this counter does not reset during the run.

For example, hold your right foot turnwise to the out. If Link is facing where your toes point cross-wise, then the count will be cremented.

OK, never mind that. Let's say Link has completed dungeons 1, 3, 4, and 5. If Link blows the whistle once facing down. Link will then be taken to level 5, because the count started at one, and then looped around to 5.

Let's say link then blows the whistle 3 more times while facing down. The count will go 4, 3, 1, skipping 2 since the player has not completed 2 yet, and Link will be taken to 1.

So let's go back to the first example. Link just completed Level 5, and blows the whistle twice. Once facing down, once facing right. The counter will go from 1 to 5, and then back from 5 to 1, taking Link to Level 1. This is a technique used in record runs.

NOTE: the order of the dungeons is different in the second quest. (2/3, 4/5, 7/8 swapped?)

===Bombing Darknuts===

Whether a Darknut blocks a bomb's explosion with its shield is determined by two things. First, the direction Link is facing when he lays the bomb. Second, the direction the Darknut is facing when the explosion hits him. If Link's position when laying the bomb is facing the direction the Darknut is looking when the bomb goes off, the bomb won't work.

Here is a graphic by Lackattack24.

http://redcandle.us/wp-content/uploads/darknuts-lackattack.png

===Bombing Walls===

Note that bombs do not check to see if a hole should be opened whenever a shutter is opening or closing. Beware of that.

Image by Eunos on positioning:

http://redcandle.us/wp-content/uploads/eunos-bomb-positions.png

===Free Locked Door===

If you enter a dungeon and the first room has a locked door on top then you can leave and immediately reenter to unlock that door for free!

===Walking through enemies===

If an enemy has just been hit, then Link can temporarily walk through that enemy without damage or knockback. However the enemy itself must not be knocked back or split in order for that to work. So this doesn't work against Zols or Vires. Striking a Darknut's shield also prevents this from working.

Enemies won't be knocked back if hit perpendicular to their movement direction while they're between tiles. When they're directly on a tile, they can be knocked back in any direction.

Link normally stops walking temporarily when using the sword. Exceptions to this are while stepping onto the ladder (useful in 7 after the hungry Goriya, and in 1 to steal the key from the Stalfos after the Gels), and when stepping into a door (useful in 9 when skipping the first Patra). Catching a boomerang while stabbing will also allow Link to start moving immediately.

=== Skipping Patras ===

Walking through Patras is a special case. It turns out that the orbiting eyes of the Patra don't actually exist hitbox-wise right away. This gives you time to walk through them. This is important for being able to actually skip the first Patra in level 9, when going toward the Old Man who talks about the Next Room. It's also great for trying to skip the second Patra, on the way back from the Silver Arrows, going toward Gannon.

Note that when walking through that first Patra, there's a trick to it. You can't just walk through the door. You have to hesitate after unlocking the door, before going through, and stabbing your way through the eye that will otherwise hit you.

Skipping the second Patra going toward the Silver Arrows is a matter of getting a good pattern of movement, and getting your block clip quickly and accurately.

Sadly the Patra before Gannon cannot be skipped with present knowledge.

Additionally, in Level 9 there's a special "reverse" block clip that's very useful to get done quickly, to get out of the wizzrobe room immediately south of the Silver Arrows. It's in theory a standard block clip, but it's coming from the opposite direction most runners do a block clip from, and it's under immense time pressure.

[https://www.youtube.com/watch?v=20p65-Vn6yY Here's a video of the Patra skips and the reverse clip in level 9], from LackAttack24's 29:56 then-WR run.

=== Heart Duplication ===

Only possible in the 1.0 FDS version? https://www.youtube.com/watch?v=4iGwBE4aAzU

=== Recorder Wrong Warping ===

http://redcandle.us/wp-content/uploads/roocorder4ds.png

Fiskbit: Regarding the technical stuff: The raft and whirlwind both set Link's direction when picking him up. Because Link gets picked up by the raft second, his direction is set to up, which determines the scroll direction. Because he's in the whirlwind, the recorder destination (which is one screen left of the target level) is used as the screen he's scrolling from, and the direction from the raft makes him scroll up.

Fun fact: Both the whirlwind and the raft are controlling Link's position. The whirlwind modifies only his X position, while the raft only modifies his Y position, so he winds up moving diagonally while being carried by both.

http://redcandle.us/wp-content/uploads/overworld_roocorder.png

Eunos: Required execution for Roocorder to save time vs. properly executed current WR route strats. https://youtu.be/MJ7HDzrUUrk

== Other Technical Information ==

There are a lot of small interactions and weird corner cases in this game. Here's a section of the site dedicated to them.

[[Legend of Zelda/Technical Information]]

==Fighting Bosses==

[[Legend of Zelda/Bosses]]

==Tutorials and guides==

===Darkwing Duck's Impromptu Guide===

Old, but this is [https://www.twitch.tv/darkwing_duck_sda/v/50222274 an incredibly informative video].

===Zelda for Mortals===

Also old, but [https://www.twitch.tv/presjpolk/v/50217130 here is the Presjpolk followup] for beginners

Also see the Zelda Any%s Beginner Route link for a video by Jkoper

===Beginner Any% Route===

Rather than duplicate their work, I'll just link you to the [https://sites.google.com/site/zeldaanypercents/beginner-routes/blue-ring-route Zelda Any%s Blue Ring Route]

===Second Quest===

RedBirdGrad made this [https://youtu.be/mhUybnTPQaM Second Quest tutorial] for a category many believe to be under-appreciated.

==More advanced routes==

'''Warning: A lot of stuff here is out of date. The basic thing to know here is a LOT of routes are capable of putting up elite times.'''

This route benefits from the "screen scroll" but does not strictly require it. You're strongly advised at least to do the wrap into level 5, and the wrap past the lost woods, even if you don't do any others. The most important block clip you'll want to start doing is the one on the way to the Recorder.

[[The Legend of Zelda/Old Record Route]]

This route is the one that got to sub-30.

[[The Legend of Zelda/Record Route]]

This alternate route makes more advanced use of the screen scroll than the old record route, but has the benefit over the old record route in that it puts the player under less rupee pressure, as the Blue Candle is not bought. It's theoretically slower than either of the record routes, though.

[[The Legend of Zelda/Red Candle Route]]

Routing in this game is constantly updating these days, as people try more ideas. Ategenos is also trying to document some at his site [https://sites.google.com/site/zeldaanypercents/home Zelda Any Percents].

There's also Saver's [http://imgur.com/a/56TXh route tracking] maps.

Creating a successor to Saver's maps, Eunos has been putting together some documents: [https://docs.google.com/document/d/1g5aMlSu5TtMe0liFzc1Ow3fsCReHC_uVJ4HaTsIb010/edit?usp=sharing 100%] and [https://docs.google.com/document/d/1g5aMlSu5TtMe0liFzc1Ow3fsCReHC_uVJ4HaTsIb010/edit?usp=sharing Any% no Up+A].

==Maps==

The instructions above assume you know the overworld map, as well as where to get everything inside the dungeons themselves. For maps see [http://www.nesmaps.com NESMaps.com], including [http://www.nesmaps.com/maps/Zelda/Zelda.html dungeon maps] and a [http://www.nesmaps.com/maps/Zelda/ZeldaOverworldQ1.html fully annotated overworld map].

==Records==

See [http://www.speedrun.com/The_Legend_of_Zelda Speedrun.com]

==Randomizer!==

See [[The Legend of Zelda/Randomizer]] for mechanics and techniques specific to [https://sites.google.com/site/zeldarandomizer/ Fred Coughlin's Legend of Zelda Randomizer]

== Tools ==

[http://games.technoplaza.net/lozsrame/ Legend of Zelda save editor].

[https://github.com/helgefmi/tloz-prachack Practice Hack] in development. Shows drop counters. Later may give other useful information.

[https://pastebin.com/UrcyJi7L Hitbox visualizer script v1.2] by Fiskbit

[http://redcandle.us/wp-content/uploads/show-target-by-fiskbit.ips AI target viewer] by Fiskbit (in the form of an IPS patch from the PRG0 ROM)

[https://github.com/camthesaxman/zeldasource Disassembly project]

[http://zelda.zewt.org/asm.html Another disassembly]

[http://redcandle.us/wp-content/uploads/Legend%20of%20Zelda%2C%20The%20%28U%29%20%28PRG1%29%20%5Baccessible%5D.ips Patch to remove screen flashing] by [https://twitter.com/ireneista/status/946576170392440832 @ireneista]

== History ==

[http://redcandle.us/wp-content/Zelda-Historical-Graphs/loz.html History of the record]

The Legend of Zelda/Version Differences

2018-11-16T11:45:44Z

Fiskbit: Game Boy Advance - Minor wording improvement (s/screen/image).

= Versions =

The history of The Legend of Zelda is more complicated than some games. Here are some of the major versions out there, with speed running differences highlighted. See [https://tcrf.net/The_Legend_of_Zelda The Cutting Room Floor] for more.

== Famicom Disk System ==

The original version was for the Famicom Disk System. It features Load times, Japanese text, a thin HUD font, and music that uses the FM synth channel of the FDS. The Pols Voice enemies can only be defeated by blowing/talking into the Controller 2 microphone.

== Nintendo Entertainment System ==

The NES version has a number of small changes from the FDS version. It is translated to English, uses a thicker HUD font, adds enemies to a few out of the way rooms, and the Pols Voice are not killable with a microphone or arrows. The music is also simplified to deal with the missing FM channel. It also has no load times.

Note that there are two cartridge versions, known as PRG0 and PRG1. PRG1 is a little different, most notably having sound glitches.

== Famicom ==

The NES version was ported back to the Famicom. The thicker HUD font and simplified music remain, but the Japanese text returns and Pols Voice are no longer killable with arrows. The load times are still gone. However this version also added some fixes and optimizations to the engine. Lag times are cut in half. They fixed the glitch causing extra cloud time at the Blue Ring shop.

== Game Boy Advance ==

Because of the smaller screen (240x160 vs the NES' 256x240), the image is scaled down, which may pose a problem for screen scrolling and especially block clipping. Horizontally, the screen is cropped such that 8 pixels are dropped from each of the left and right edges of the screen, but the image is otherwise unscaled in this dimension. As a result, screen scrolling should be mostly unaffected, but may require a new reference point because Link will be partially offscreen. Vertically, the image is squished, which may pose a problem for block clipping and probably more so for ladder clipping. Sprites and backgrounds are scaled differently (sprites are proportionally larger) because sprites tend to be less resilient to losing scanlines than backgrounds are. As a result, vertical clips may require very different reference points, and may have inconsistencies depending on how the sprite/background scaling lines up (though this hasn't been thoroughly researched).

Beyond this, version differences are yet to be documented.

== Japanese Wii Virtual Console ==

The Japanese Wii VC version is based on the FDS version, only with much shorter load times. The microphone is simulated with the right joystick on the Classic Controller.

The emulation runs at a slightly different framerate, though. It's slightly slower because it runs at 60.002 frames per second, instead of the NES/Famicom's 60.098.

== US Wii Virtual Console ==

The US Wii VC is based on the US NES release, and runs at the same framerate as the Japanese VC version, so is slightly slower than the US NES version.

== Gamecube (Japan and US) ==

I *think* these are the same as the Wii VC versions, but I'm not sure. I've never had them.

= Text Differences / Timing Conversion =

== Text Differences ==

Here are the scripts with character counts in the Japanese Famiom and US NES versions. Note that any 'missing spaces' are intentional because line breaks are skipped over instantly, unlike spaces.

<pre>
ヒトリデハキケンジャコレヲ　サズケヨウ 19
スキナ　ホウヲサズケヨウ 12
ミンナニ　ナイショダヨ 11
ナンカコウテクレヤ 9
スキナ　ホウヲサズケヨウ 12
ミンナニ　ナイショダヨ 11
スキナ　ホウヲサズケヨウ 12
コレハネウチモノデッセ 11
ナンカコウテクレヤ 9
ブツ　ブツ　。。。。 10
ツカイコナセルナラコレヲ　サズケヨウ 18
トナリノヘヤヘ　ユケ 10

IT’S DANGEROUS TO GOALONE! TAKE THIS. 37
TAKE ANY ONE YOU WANT. 22
IT’S A SECRETTO EVERYBODY. 26
BUY SOMETHIN’ WILL YA! 22
TAKE ANY ONE YOU WANT. 22
IT’S A SECRETTO EVERYBODY. 26
TAKE ANY ONE YOU WANT. 22
BOY, THIS ISREALLY EXPENSIVE! 29
BUY SOMETHIN’ WILL YA! 22
GRUMBLE,GRUMBLE。。。 18
MASTER USING IT ANDYOU CAN HAVE THIS. 37
GO TO THE NEXT ROOM. 20
</pre>

== Timing Conversion ==

Back before we knew about lag differences, converting times seemed like it made sense. How we did it, for reference:

Each character is shown for 6 frames. As a result, at 60.098 FPS, the Famicom version is 20.67 seconds faster in the Any% Deathless route than the NES version on the old Darkwing WR route, and 19.67 on the new world wrap WR route. That difference is due to one fewer "TAKE ANY ONE YOU WANT" cave.

The Legend of Zelda/Version Differences

2018-11-16T09:37:04Z

Fiskbit: Game Boy Advance - Added description of screen resolution differences.

= Versions =

The history of The Legend of Zelda is more complicated than some games. Here are some of the major versions out there, with speed running differences highlighted. See [https://tcrf.net/The_Legend_of_Zelda The Cutting Room Floor] for more.

== Famicom Disk System ==

The original version was for the Famicom Disk System. It features Load times, Japanese text, a thin HUD font, and music that uses the FM synth channel of the FDS. The Pols Voice enemies can only be defeated by blowing/talking into the Controller 2 microphone.

== Nintendo Entertainment System ==

The NES version has a number of small changes from the FDS version. It is translated to English, uses a thicker HUD font, adds enemies to a few out of the way rooms, and the Pols Voice are not killable with a microphone or arrows. The music is also simplified to deal with the missing FM channel. It also has no load times.

Note that there are two cartridge versions, known as PRG0 and PRG1. PRG1 is a little different, most notably having sound glitches.

== Famicom ==

The NES version was ported back to the Famicom. The thicker HUD font and simplified music remain, but the Japanese text returns and Pols Voice are no longer killable with arrows. The load times are still gone. However this version also added some fixes and optimizations to the engine. Lag times are cut in half. They fixed the glitch causing extra cloud time at the Blue Ring shop.

== Game Boy Advance ==

Because of the smaller screen (240x160 vs the NES' 256x240), the screen is scaled down, which may pose a problem for screen scrolling and especially block clipping. Horizontally, the screen is cropped such that 8 pixels are dropped from each of the left and right edges of the screen, but the image is otherwise unscaled in this dimension. As a result, screen scrolling should be mostly unaffected, but may require a new reference point because Link will be partially offscreen. Vertically, the image is squished, which may pose a problem for block clipping and probably more so for ladder clipping. Sprites and backgrounds are scaled differently (sprites are proportionally larger) because sprites tend to be less resilient to losing scanlines than backgrounds are. As a result, vertical clips may require very different reference points, and may have inconsistencies depending on how the sprite/background scaling lines up (though this hasn't been thoroughly researched).

Beyond this, version differences are yet to be documented.

== Japanese Wii Virtual Console ==

The Japanese Wii VC version is based on the FDS version, only with much shorter load times. The microphone is simulated with the right joystick on the Classic Controller.

The emulation runs at a slightly different framerate, though. It's slightly slower because it runs at 60.002 frames per second, instead of the NES/Famicom's 60.098.

== US Wii Virtual Console ==

The US Wii VC is based on the US NES release, and runs at the same framerate as the Japanese VC version, so is slightly slower than the US NES version.

== Gamecube (Japan and US) ==

I *think* these are the same as the Wii VC versions, but I'm not sure. I've never had them.

= Text Differences / Timing Conversion =

== Text Differences ==

Here are the scripts with character counts in the Japanese Famiom and US NES versions. Note that any 'missing spaces' are intentional because line breaks are skipped over instantly, unlike spaces.

<pre>
ヒトリデハキケンジャコレヲ　サズケヨウ 19
スキナ　ホウヲサズケヨウ 12
ミンナニ　ナイショダヨ 11
ナンカコウテクレヤ 9
スキナ　ホウヲサズケヨウ 12
ミンナニ　ナイショダヨ 11
スキナ　ホウヲサズケヨウ 12
コレハネウチモノデッセ 11
ナンカコウテクレヤ 9
ブツ　ブツ　。。。。 10
ツカイコナセルナラコレヲ　サズケヨウ 18
トナリノヘヤヘ　ユケ 10

IT’S DANGEROUS TO GOALONE! TAKE THIS. 37
TAKE ANY ONE YOU WANT. 22
IT’S A SECRETTO EVERYBODY. 26
BUY SOMETHIN’ WILL YA! 22
TAKE ANY ONE YOU WANT. 22
IT’S A SECRETTO EVERYBODY. 26
TAKE ANY ONE YOU WANT. 22
BOY, THIS ISREALLY EXPENSIVE! 29
BUY SOMETHIN’ WILL YA! 22
GRUMBLE,GRUMBLE。。。 18
MASTER USING IT ANDYOU CAN HAVE THIS. 37
GO TO THE NEXT ROOM. 20
</pre>

== Timing Conversion ==

Back before we knew about lag differences, converting times seemed like it made sense. How we did it, for reference:

Each character is shown for 6 frames. As a result, at 60.098 FPS, the Famicom version is 20.67 seconds faster in the Any% Deathless route than the NES version on the old Darkwing WR route, and 19.67 on the new world wrap WR route. That difference is due to one fewer "TAKE ANY ONE YOU WANT" cave.

Legend of Zelda/Technical Information

2018-10-19T18:08:15Z

Fiskbit: Dungeon graphics corruption: Corrects statement about how long corruption lasts.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Objects ==

=== Object system ===

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

=== Object movement ===

Most non-flying objects are restricted to moving along a movement grid, consisting of edges and vertices. The length of an edge in this grid depends on the object index, with the standard length being 16 pixels and Link's being 8. When an object isn't on a vertex, its direction is restricted such that it can only be parallel to the current edge. An object is on a vertex when its position along the current edge (object_subgrid_offset) is 0, regardless of its current subpixel position (object_subpos).

Every frame that an object chooses to move, it undergoes 4 movement ticks that each move the object by less than one pixel. Within each tick, its speed (object_speed) is added to or subtracted from its subpixel position, depending on whether the movement is in a positive (down or right) or negative (up or left) direction. If the subgrid offset hasn't reached either limit for this kind of object ($010E subgrid_offset_limit_positive and $010F subgrid_offset_limit_negative), the carry from the subpixel arithmetic is added to or subtracted from both the subgrid offset and whole pixel position.

If either limit has been reached, then subsequent ticks within the same frame continue to modify the subpixel position as normal, but the offset and whole pixel values lock into place. This causes objects to stick to vertices, which is where important operations such as background collision detection and screen edge detection take place. When movement is complete, if the subgrid offset is equal to one of the limits, it is set back to 0.

Note that there is only one subpixel position, despite there being two axes. This is because standard objects can only move along one axis at a time, with the other axis coordinate aligned to the grid, so it's only ever relevant to the current one. However, this value isn't cleared when turning perpendicular, so the object may be closer to or further from the next pixel than expected when turning.

=== Screen scroll glitch ===

Normally, Link and other objects walk from a subgrid offset of 0 toward either the positive or negative limit, which will prevent further whole-pixel movement that frame. However, this same clamping behavior doesn't occur for 0. Normally, this isn't a problem, because if an object starts on 0, moves in a direction, and then turns around before reaching the next vertex and walks back, it will necessarily land on 0 again because it moves the same speed both ways, precisely retracing the steps it took. Non-Link objects also usually do not change their direction except on vertices. However, knockback can cause a problem for Link. When an object is hit and knocked back, it moves one entire pixel per tick for 4 ticks per frame through a separate mechanism from standard movement. This can cause Link to be at an unusual position along an edge, which could cause him to skip past 0 because he moves 1.5 pixels per frame (#$60 subpixels per tick).

Skipping past 0 results in the collision event at 0 being skipped. This bypasses Link's screen boundary check for scrolling, and causes the object to continue using the background tile it sampled at the last vertex as its current one. Realistically, that tile will be nonsolid, so the object may be able to skip past one solid tile.

A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

To fix this issue, the game includes a hack to ensure that the vertex Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

With the hack, holding up would first convert the offset to -6 (preserving the distance of 2.5 pixels from the vertex), and Link would then move to offset -7 subpixel #$00, and try to move to offset -9 subpixel #$80, but the clamping on the -8 limit would cause him to end up at offset -8 subpixel #$80, which would set his offset back to 0 and allow him to handle collision and move up.

For standard screen scrolling, if Link is facing right on a horizontal edge at offset 3 subpixel #$00, perpendicular input will convert the offset to -5 and move Link to offset -7 subpixel #$80. Walking right will then move him to offset -5 subpixel #$00, offset -4 subpixel #$80, offset -2 subpixel #$00, offset -1 subpixel #$80, and then offset 1 subpixel #$00, skipping 0.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link kills a second dodongo with a sword before the first one has dropped its bomb, the second will not drop a bomb because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Overkill''': When an enemy is killed by a weapon, it still finishes checking the remaining weapons that frame, as normal. This means it can be hit by those additional weapons, which may also kill it. The consecutive kill counters are incremented at kill time, so these additional kills will each increment the counters like with any normal kill. As a result, killing a single enemy by hitting it with multiple weapons on one frame can add more than one to the counts. This can be done most practically by timing multiple attacks to hit when an enemy's iframes expire.

Note that the health the enemy has after a killing blow can vary. If the weapon damage was equal to the enemy's current health, the resulting health is 0, so any following hits will count as kills. However, if the damage was more than the current health, the health is unchanged. Furthermore, the order in which weapons are checked can impact how many kills the enemy gives because each weapon hit may reduce the health for the following weapons. Weapon check order is boomerang, beam (sword/rod), flame/bomb slot A, flame/bomb slot B, sword, arrow/rod.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Glitches ==

=== Dungeon graphics corruption ===

When entering a dungeon on the same frame that a background block is changed, such as an armos statue or bombable wall, there's a 50% chance that the dungeon graphics won't load properly, resulting in the overworld graphics being used but with some minor corruption. While some of the corruption will persist until reset, the issue is mostly corrected upon leaving the dungeon.

When you change areas, the game has to copy over all of the area's graphics from ROM to VRAM. This can't be done directly; instead, the game has to tell the PPU where in VRAM it wants to put the graphics, and then hands the bytes to the PPU one-by-one to put at the specified location. After each byte is written, the target address is automatically incremented by the PPU, and there's a PPU setting that controls whether the increment is by 1 or 32. This is to make it easy to change adjacent 8x8 tiles on the screen; if incrementing by 1, it'll target the next tile in the row, and if by 32, the next tile in the column (because rows are 32 tiles wide).

The graphics copying function assumes that the PPU is set to increment by 1 per write, but doesn't actually guarantee this by setting it this way. Background block updates in Zelda go vertically (increment by 32), so if that was the last thing to configure the PPU before you enter a new area, the setting will be wrong and the graphics copy will erroneously splatter the graphics data throughout VRAM (modifying only 1 out of every 32 bytes) instead of copying the contiguous chunks as it should. Normally, things work correctly because updates to the HUD leave the PPU in the correct increment-by-1 configuration. The HUD is updated every other frame, regardless of whether there is new information to display, so even if you enter on the same frame as the background update, the HUD update has a 50% chance of properly configuring the PPU before the copy occurs.

Because area graphics are loaded on every area transition, most of the issue is corrected by leaving the dungeon. However, some graphics are only copied to VRAM on power on or reset and will remain partially corrupted until then.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

Legend of Zelda/Technical Information

2018-09-13T07:04:49Z

Fiskbit: Technical Info: Adds a section on the dungeon graphics corruption bug.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Objects ==

=== Object system ===

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

=== Object movement ===

Most non-flying objects are restricted to moving along a movement grid, consisting of edges and vertices. The length of an edge in this grid depends on the object index, with the standard length being 16 pixels and Link's being 8. When an object isn't on a vertex, its direction is restricted such that it can only be parallel to the current edge. An object is on a vertex when its position along the current edge (object_subgrid_offset) is 0, regardless of its current subpixel position (object_subpos).

Every frame that an object chooses to move, it undergoes 4 movement ticks that each move the object by less than one pixel. Within each tick, its speed (object_speed) is added to or subtracted from its subpixel position, depending on whether the movement is in a positive (down or right) or negative (up or left) direction. If the subgrid offset hasn't reached either limit for this kind of object ($010E subgrid_offset_limit_positive and $010F subgrid_offset_limit_negative), the carry from the subpixel arithmetic is added to or subtracted from both the subgrid offset and whole pixel position.

If either limit has been reached, then subsequent ticks within the same frame continue to modify the subpixel position as normal, but the offset and whole pixel values lock into place. This causes objects to stick to vertices, which is where important operations such as background collision detection and screen edge detection take place. When movement is complete, if the subgrid offset is equal to one of the limits, it is set back to 0.

Note that there is only one subpixel position, despite there being two axes. This is because standard objects can only move along one axis at a time, with the other axis coordinate aligned to the grid, so it's only ever relevant to the current one. However, this value isn't cleared when turning perpendicular, so the object may be closer to or further from the next pixel than expected when turning.

=== Screen scroll glitch ===

Normally, Link and other objects walk from a subgrid offset of 0 toward either the positive or negative limit, which will prevent further whole-pixel movement that frame. However, this same clamping behavior doesn't occur for 0. Normally, this isn't a problem, because if an object starts on 0, moves in a direction, and then turns around before reaching the next vertex and walks back, it will necessarily land on 0 again because it moves the same speed both ways, precisely retracing the steps it took. Non-Link objects also usually do not change their direction except on vertices. However, knockback can cause a problem for Link. When an object is hit and knocked back, it moves one entire pixel per tick for 4 ticks per frame through a separate mechanism from standard movement. This can cause Link to be at an unusual position along an edge, which could cause him to skip past 0 because he moves 1.5 pixels per frame (#$60 subpixels per tick).

Skipping past 0 results in the collision event at 0 being skipped. This bypasses Link's screen boundary check for scrolling, and causes the object to continue using the background tile it sampled at the last vertex as its current one. Realistically, that tile will be nonsolid, so the object may be able to skip past one solid tile.

A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

To fix this issue, the game includes a hack to ensure that the vertex Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

With the hack, holding up would first convert the offset to -6 (preserving the distance of 2.5 pixels from the vertex), and Link would then move to offset -7 subpixel #$00, and try to move to offset -9 subpixel #$80, but the clamping on the -8 limit would cause him to end up at offset -8 subpixel #$80, which would set his offset back to 0 and allow him to handle collision and move up.

For standard screen scrolling, if Link is facing right on a horizontal edge at offset 3 subpixel #$00, perpendicular input will convert the offset to -5 and move Link to offset -7 subpixel #$80. Walking right will then move him to offset -5 subpixel #$00, offset -4 subpixel #$80, offset -2 subpixel #$00, offset -1 subpixel #$80, and then offset 1 subpixel #$00, skipping 0.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link kills a second dodongo with a sword before the first one has dropped its bomb, the second will not drop a bomb because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Overkill''': When an enemy is killed by a weapon, it still finishes checking the remaining weapons that frame, as normal. This means it can be hit by those additional weapons, which may also kill it. The consecutive kill counters are incremented at kill time, so these additional kills will each increment the counters like with any normal kill. As a result, killing a single enemy by hitting it with multiple weapons on one frame can add more than one to the counts. This can be done most practically by timing multiple attacks to hit when an enemy's iframes expire.

Note that the health the enemy has after a killing blow can vary. If the weapon damage was equal to the enemy's current health, the resulting health is 0, so any following hits will count as kills. However, if the damage was more than the current health, the health is unchanged. Furthermore, the order in which weapons are checked can impact how many kills the enemy gives because each weapon hit may reduce the health for the following weapons. Weapon check order is boomerang, beam (sword/rod), flame/bomb slot A, flame/bomb slot B, sword, arrow/rod.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Glitches ==

=== Dungeon graphics corruption ===

When entering a dungeon on the same frame that a background block is changed, such as an armos statue or bombable wall, there's a 50% chance that the dungeon graphics won't load properly, resulting in the overworld graphics being used but with some minor corruption. While most of the corruption will persist until reset, the issue is otherwise corrected upon leaving the dungeon.

When you change areas, the game has to copy over all of the area's graphics from ROM to VRAM. This can't be done directly; instead, the game has to tell the PPU where in VRAM it wants to put the graphics, and then hands the bytes to the PPU one-by-one to put at the specified location. After each byte is written, the target address is automatically incremented by the PPU, and there's a PPU setting that controls whether the increment is by 1 or 32. This is to make it easy to change adjacent 8x8 tiles on the screen; if incrementing by 1, it'll target the next tile in the row, and if by 32, the next tile in the column (because rows are 32 tiles wide).

The graphics copying function assumes that the PPU is set to increment by 1 per write, but doesn't actually guarantee this by setting it this way. Background block updates in Zelda go vertically (increment by 32), so if that was the last thing to configure the PPU before you enter a new area, the setting will be wrong and the graphics copy will erroneously splatter the graphics data throughout VRAM (modifying only 1 out of every 32 bytes) instead of copying the contiguous chunks as it should. Normally, things work correctly because updates to the HUD leave the PPU in the correct increment-by-1 configuration. The HUD is updated every other frame, regardless of whether there is new information to display, so even if you enter on the same frame as the background update, the HUD update has a 50% chance of properly configuring the PPU before the copy occurs.

Because area graphics are loaded on every area transition, most of the issue is corrected by leaving the dungeon. However, some graphics are only copied to VRAM on power on or reset and will remain partially corrupted until then.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

The Legend of Zelda

2018-03-20T05:16:55Z

Fiskbit: Tools - Updated the hitbox visualizer script from version 1.1 to 1.2.

== Version differences ==

[[The Legend of Zelda/Version Differences]]

==Categories==

===Any%===

Get to Zelda as fast as you can.

As there are no known means of getting to Zelda without defeating Gannon and taking the Triforce, and there are no known means of getting into Level 9 without all of the Triforce pieces, this means one must complete every dungeon. Items needed: Wooden Sword, Bombs, Bow, Candle, Raft, Ladder, Recorder, Bait, Arrows, Silver Arrows. Items acquired for maximum speed in current routing: Heart containers, Magic Sword.

===Swordless===

This is a challenge category. One plays the game according to the Any% rules, with two changes: No sword is allowed, and the run ends upon reaching Gannon and holding up the Triforce. Gannon cannot be killed without a sword, unlike other enemies who can be killed with Bombs, Boomerang, Arrows, Candles, or the Wand. See [[The Legend of Zelda/Swordless Route]] for information on a way to run this category.

===100%===

The category requires the player to acquire:

* 13 heart containers (for 16 total)
* Letter
* Power Bracelet
* Magic Sword
* Both bomb upgrades
* Bow
* Magic Boomerang
* Raft
* Ladder
* Recorder
* Wand
* Red Candle
* Book/Bible
* Magic Key
* Silver Arrows
* Red Ring

Items that are infinitely obtainable and consumable (such as the Bait, Red Potion, Blue Potion, Rupees, Magic Shield, keys other than the Magic Key, or the Bombs themselves) or are replaced (such as the Wooden Boomerang, the Wooden Sword, the White Sword, the Blue Ring, keys other than the Magic Key, and the Blue Candle) are not required.

==Game Mechanics and Glitches==

===Screen Scroll===

The 'screen scroll' trick is useful for getting over overworld obstacles, as well as for clipping through blocks in dungeons. That means you get to some stairs without killing all the enemies first! Here's a graphic with some pointers:

http://redcandle.us/wp-content/uploads/2012/10/screenscroll.png

Since the above chart was made, an alternate way of clipping through a block has been discovered by [https://twitter.com/hal_yotsuba はる＠よつば]. First, you get onto the pixel as in the above picture, with the top of Link's head lined up with the flat part of the block. Then, instead of doing a single-frame tap, slash the sword and press right or left. The sword slash, done correctly, will prevent you from moving. You will get the same effect as the single frame tap, so if you're positioned right, you will turn around. After the sword slash, walk through the block. This trick only works with block clips, not overworld scrolls or ladder clips.

Here's an additional quick demonstration of the pixels for the "reverse" clip:

http://redcandle.us/wp-content/uploads/reverseclip.png

===Drops===

==== Random drops ====

The enemy drops are not random. Whether they do drop an item is random, but when they do drop, here's what they'll be. The counter starts at 0, and goes up by 1 every time you kill (most) enemies. Zols' gels and vires' keese do not advance the counter. Chart via [http://tasvideos.org/2091S.html Baxter at TASVideos]<nowiki>:</nowiki>

http://redcandle.us/wp-content/uploads/2012/10/zeldaitemdropsnr2.png

====Drop Rates ====

The chance of getting a drop from group A is 80/256 = 31%.

Group B: 104/256 = 41%

Group C: 152/256 = 59%

Group D: 104/256 = 41%

==== Forced drops ====

However there are also the ''consecutive'' kill counters. Kill 10 enemies without getting hit (by an enemy, even a non-damaging bubble, or by the whirlwind from the recorder) and you'll get a forced, guaranteed 5 rupee drop from the next enemy that drops items (not in the X group). Kill the 10th enemy with a bomb instead, and instead of a 5 rupee you'll get a forced, guaranteed bomb drop!

Kill 16 enemies in a row and you get a fairy drop forced, but only if the 16th enemy is capable of dropping an item (not in the X group).

Note that if the 10th enemy does not drop items (in the X group), then killing that enemy with a bomb means the next drop that does happen will be a bomb. Killing that 10th enemy with the sword or any thing else will mean the next drop will be a rupee, even if you kill the next-dropping enemy with a bomb. It's the actual 10th enemy kill that counts, not the succeeding enemy that drops items.

However if the 16th enemy does not drop items, the fairy drop will be skipped entirely, and another one will not happen unless you get hit and the counters reset.

In some rooms that drop an item (such as the 5-Stalfos room in Level 1 that gives a key at the end), one enemy will act like it was holding the drop like a stalfos with a visible key, or a gibdo with a visible bomb. As a result, that enemy will never drop anything, and it will be able to store a forced drop and/or bypass a fairy drop, just like enemies that never drop items.

Note that splitting a Zol into two Gels, or splitting a Vire into two Keese, will not count as a kill or a consecutive kill. Killing one of those split Gels or Keese will not count as a kill for drops, but will count as a consecutive kill. Yes, there are some circumstances that are an exception to this. If the Zol/Vire is trapped against a barrier, it can sometimes trigger an extra 'kill' that way. A kill sound in place of a split sound is a hint to when this might happen.

Further note: Multiple simultaneous kills will not take you past 10 on the consecutive kill counter, per Darkwing Duck. If they would take you past 10 they leave you at 10 instead.

Advanced strategies: If a forced bomb/rupee or forced fairy drops, the consecutive counter for bombs/rupees is reset, but not the counter for fairies. So no matter how many hits you get on Manhandla with one well-placed bomb, the 10 count is reset after defeating him. The same is true of Dodongo. Likewise with a "Hippo Fairy" (going into a Patra with 7 on the consecutive counters, so that the Patra's center will be kill #16 and get a fairy), the bomb/rupee count resets to 0. Credit to Khananaphone for this discovery.

This means that if you get a forced fairy drop, the next consecutive bomb/rupee kill will not be at 20. It will be at 26. So bomb/rupee drops work in one of two methods:

# 10, (Fairy at 16), 26, 36, 46...
# 10, (Skip fairy at 16 by killing non-dropping enemy), 20, 30, 40...

Credit to Darkwing Duck for this discovery.

===Luck Manipulation===

See [[The Legend of Zelda/Luck Manipulation]]

===The Recorder===

The recorder loops you through all the dungeons you've gotten the Triforce in, sequentially, according to the direction link is facing. It has an internal counter that starts at 1. Every time you blow the recorder in a place where the whirlwind would appear (that is, in most overworld screens, but not all), the counter changes according to the direction Link is facing. If Link is facing right or up, then the counter goes up one. If Link is facing down or left, then the counter goes down one.

Note that this counter does not reset during the run.

For example, hold your right foot turnwise to the out. If Link is facing where your toes point cross-wise, then the count will be cremented.

OK, never mind that. Let's say Link has completed dungeons 1, 3, 4, and 5. If Link blows the whistle once facing down. Link will then be taken to level 5, because the count started at one, and then looped around to 5.

Let's say link then blows the whistle 3 more times while facing down. The count will go 4, 3, 1, skipping 2 since the player has not completed 2 yet, and Link will be taken to 1.

So let's go back to the first example. Link just completed Level 5, and blows the whistle twice. Once facing down, once facing right. The counter will go from 1 to 5, and then back from 5 to 1, taking Link to Level 1. This is a technique used in record runs.

===Bombing Darknuts===

Whether a Darknut blocks a bomb's explosion with its shield is determined by two things. First, the direction Link is facing when he lays the bomb. Second, the direction the Darknut is facing when the explosion hits him. If Link's position when laying the bomb is facing the direction the Darknut is looking when the bomb goes off, the bomb won't work.

Here is a graphic by Lackattack24.

http://redcandle.us/wp-content/uploads/darknuts-lackattack.png

===Bombing Walls===

Note that bombs do not check to see if a hole should be opened whenever a shutter is opening or closing. Beware of that.

Image by Eunos on positioning:

http://redcandle.us/wp-content/uploads/eunos-bomb-positions.png

===Free Locked Door===

If you enter a dungeon and the first room has a locked door on top then you can leave and immediately reenter to unlock that door for free!

===Walking through enemies===

If an enemy has just been hit, then Link can temporarily walk through that enemy without damage or knockback. However the enemy itself must not be knocked back or split in order for that to work. So this doesn't work against Zols or Vires. Striking a Darknut's shield also prevents this from working.

Enemies won't be knocked back if hit perpendicular to their movement direction while they're between tiles. When they're directly on a tile, they can be knocked back in any direction.

Link normally stops walking temporarily when using the sword. Exceptions to this are while stepping onto the ladder (useful in 7 after the hungry Goriya, and in 1 to steal the key from the Stalfos after the Gels), and when stepping into a door (useful in 9 when skipping the first Patra). Catching a boomerang while stabbing will also allow Link to start moving immediately.

=== Skipping Patras ===

Walking through Patras is a special case. It turns out that the orbiting eyes of the Patra don't actually exist hitbox-wise right away. This gives you time to walk through them. This is important for being able to actually skip the first Patra in level 9, when going toward the Old Man who talks about the Next Room. It's also great for trying to skip the second Patra, on the way back from the Silver Arrows, going toward Gannon.

Note that when walking through that first Patra, there's a trick to it. You can't just walk through the door. You have to hesitate after unlocking the door, before going through, and stabbing your way through the eye that will otherwise hit you.

Skipping the second Patra going toward the Silver Arrows is a matter of getting a good pattern of movement, and getting your block clip quickly and accurately.

Sadly the Patra before Gannon cannot be skipped with present knowledge.

Additionally, in Level 9 there's a special "reverse" block clip that's very useful to get done quickly, to get out of the wizzrobe room immediately south of the Silver Arrows. It's in theory a standard block clip, but it's coming from the opposite direction most runners do a block clip from, and it's under immense time pressure.

[https://www.youtube.com/watch?v=20p65-Vn6yY Here's a video of the Patra skips and the reverse clip in level 9], from LackAttack24's 29:56 then-WR run.

=== Heart Duplication ===

Only possible in the 1.0 FDS version? https://www.youtube.com/watch?v=4iGwBE4aAzU

=== Recorder Wrong Warping ===

http://redcandle.us/wp-content/uploads/roocorder4ds.png

Fiskbit: Regarding the technical stuff: The raft and whirlwind both set Link's direction when picking him up. Because Link gets picked up by the raft second, his direction is set to up, which determines the scroll direction. Because he's in the whirlwind, the recorder destination (which is one screen left of the target level) is used as the screen he's scrolling from, and the direction from the raft makes him scroll up.

Fun fact: Both the whirlwind and the raft are controlling Link's position. The whirlwind modifies only his X position, while the raft only modifies his Y position, so he winds up moving diagonally while being carried by both.

http://redcandle.us/wp-content/uploads/overworld_roocorder.png

Eunos: Required execution for Roocorder to save time vs. properly executed current WR route strats. https://youtu.be/MJ7HDzrUUrk

== Other Technical Information ==

There are a lot of small interactions and weird corner cases in this game. Here's a section of the site dedicated to them.

[[Legend of Zelda/Technical Information]]

==Fighting Bosses==

[[Legend of Zelda/Bosses]]

==Tutorials and guides==

===Darkwing Duck's Impromptu Guide===

Old, but this is [https://www.twitch.tv/darkwing_duck_sda/v/50222274 an incredibly informative video].

===Zelda for Mortals===

Also old, but [https://www.twitch.tv/presjpolk/v/50217130 here is the Presjpolk followup] for beginners

Also see the Zelda Any%s Beginner Route link for a video by Jkoper

===Beginner Any% Route===

Rather than duplicate their work, I'll just link you to the [https://sites.google.com/site/zeldaanypercents/beginner-routes/blue-ring-route Zelda Any%s Blue Ring Route]

===Second Quest===

RedBirdGrad made this [https://youtu.be/mhUybnTPQaM Second Quest tutorial] for a category many believe to be under-appreciated.

==More advanced routes==

This route benefits from the "screen scroll" but does not strictly require it. You're strongly advised at least to do the wrap into level 5, and the wrap past the lost woods, even if you don't do any others. The most important block clip you'll want to start doing is the one on the way to the Recorder.

[[The Legend of Zelda/Old Record Route]]

This route is the one that got to sub-30.

[[The Legend of Zelda/Record Route]]

This alternate route makes more advanced use of the screen scroll than the old record route, but has the benefit over the old record route in that it puts the player under less rupee pressure, as the Blue Candle is not bought. It's theoretically slower than either of the record routes, though.

[[The Legend of Zelda/Red Candle Route]]

Routing in this game is constantly updating these days, as people try more ideas. Ategenos is also trying to document some at his site [https://sites.google.com/site/zeldaanypercents/home Zelda Any Percents].

There's also Saver's [http://imgur.com/a/56TXh route tracking] maps.

==Maps==

The instructions above assume you know the overworld map, as well as where to get everything inside the dungeons themselves. For maps see [http://www.nesmaps.com NESMaps.com], including [http://www.nesmaps.com/maps/Zelda/Zelda.html dungeon maps] and a [http://www.nesmaps.com/maps/Zelda/ZeldaOverworldQ1.html fully annotated overworld map].

==Records==

See [http://www.speedrun.com/The_Legend_of_Zelda Speedrun.com]

==Randomizer!==

See [[The Legend of Zelda/Randomizer]] for mechanics and techniques specific to [https://sites.google.com/site/zeldarandomizer/ Fred Coughlin's Legend of Zelda Randomizer]

== Tools ==

[http://games.technoplaza.net/lozsrame/ Legend of Zelda save editor].

[https://github.com/helgefmi/tloz-prachack Practice Hack] in development. Shows drop counters. Later may give other useful information.

[https://pastebin.com/UrcyJi7L Hitbox visualizer script v1.2] by Fiskbit

[http://redcandle.us/wp-content/uploads/show-target-by-fiskbit.ips AI target viewer] by Fiskbit (in the form of an IPS patch from the PRG0 ROM)

[https://github.com/camthesaxman/zeldasource Disassembly project]

[http://zelda.zewt.org/asm.html Another disassembly]

[http://redcandle.us/wp-content/uploads/Legend%20of%20Zelda%2C%20The%20%28U%29%20%28PRG1%29%20%5Baccessible%5D.ips Patch to remove screen flashing] by [https://twitter.com/ireneista/status/946576170392440832 @ireneista]

== History ==

[http://redcandle.us/wp-content/Zelda-Historical-Graphs/loz.html History of the record]

Legend of Zelda/Technical Information

2018-02-28T10:42:51Z

Fiskbit: Forced Drops - Fixed misinformation in the Overkill section on how health is handled.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Objects ==

=== Object system ===

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

=== Object movement ===

Most non-flying objects are restricted to moving along a movement grid, consisting of edges and vertices. The length of an edge in this grid depends on the object index, with the standard length being 16 pixels and Link's being 8. When an object isn't on a vertex, its direction is restricted such that it can only be parallel to the current edge. An object is on a vertex when its position along the current edge (object_subgrid_offset) is 0, regardless of its current subpixel position (object_subpos).

Every frame that an object chooses to move, it undergoes 4 movement ticks that each move the object by less than one pixel. Within each tick, its speed (object_speed) is added to or subtracted from its subpixel position, depending on whether the movement is in a positive (down or right) or negative (up or left) direction. If the subgrid offset hasn't reached either limit for this kind of object ($010E subgrid_offset_limit_positive and $010F subgrid_offset_limit_negative), the carry from the subpixel arithmetic is added to or subtracted from both the subgrid offset and whole pixel position.

If either limit has been reached, then subsequent ticks within the same frame continue to modify the subpixel position as normal, but the offset and whole pixel values lock into place. This causes objects to stick to vertices, which is where important operations such as background collision detection and screen edge detection take place. When movement is complete, if the subgrid offset is equal to one of the limits, it is set back to 0.

Note that there is only one subpixel position, despite there being two axes. This is because standard objects can only move along one axis at a time, with the other axis coordinate aligned to the grid, so it's only ever relevant to the current one. However, this value isn't cleared when turning perpendicular, so the object may be closer to or further from the next pixel than expected when turning.

=== Screen scroll glitch ===

Normally, Link and other objects walk from a subgrid offset of 0 toward either the positive or negative limit, which will prevent further whole-pixel movement that frame. However, this same clamping behavior doesn't occur for 0. Normally, this isn't a problem, because if an object starts on 0, moves in a direction, and then turns around before reaching the next vertex and walks back, it will necessarily land on 0 again because it moves the same speed both ways, precisely retracing the steps it took. Non-Link objects also usually do not change their direction except on vertices. However, knockback can cause a problem for Link. When an object is hit and knocked back, it moves one entire pixel per tick for 4 ticks per frame through a separate mechanism from standard movement. This can cause Link to be at an unusual position along an edge, which could cause him to skip past 0 because he moves 1.5 pixels per frame (#$60 subpixels per tick).

Skipping past 0 results in the collision event at 0 being skipped. This bypasses Link's screen boundary check for scrolling, and causes the object to continue using the background tile it sampled at the last vertex as its current one. Realistically, that tile will be nonsolid, so the object may be able to skip past one solid tile.

A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

To fix this issue, the game includes a hack to ensure that the vertex Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

With the hack, holding up would first convert the offset to -6 (preserving the distance of 2.5 pixels from the vertex), and Link would then move to offset -7 subpixel #$00, and try to move to offset -9 subpixel #$80, but the clamping on the -8 limit would cause him to end up at offset -8 subpixel #$80, which would set his offset back to 0 and allow him to handle collision and move up.

For standard screen scrolling, if Link is facing right on a horizontal edge at offset 3 subpixel #$00, perpendicular input will convert the offset to -5 and move Link to offset -7 subpixel #$80. Walking right will then move him to offset -5 subpixel #$00, offset -4 subpixel #$80, offset -2 subpixel #$00, offset -1 subpixel #$80, and then offset 1 subpixel #$00, skipping 0.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link kills a second dodongo with a sword before the first one has dropped its bomb, the second will not drop a bomb because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Overkill''': When an enemy is killed by a weapon, it still finishes checking the remaining weapons that frame, as normal. This means it can be hit by those additional weapons, which may also kill it. The consecutive kill counters are incremented at kill time, so these additional kills will each increment the counters like with any normal kill. As a result, killing a single enemy by hitting it with multiple weapons on one frame can add more than one to the counts. This can be done most practically by timing multiple attacks to hit when an enemy's iframes expire.

Note that the health the enemy has after a killing blow can vary. If the weapon damage was equal to the enemy's current health, the resulting health is 0, so any following hits will count as kills. However, if the damage was more than the current health, the health is unchanged. Furthermore, the order in which weapons are checked can impact how many kills the enemy gives because each weapon hit may reduce the health for the following weapons. Weapon check order is boomerang, beam (sword/rod), flame/bomb slot A, flame/bomb slot B, sword, arrow/rod.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

Legend of Zelda/Technical Information

2018-02-28T07:45:36Z

Fiskbit: Forced Drops - Adds a section on overkill causing multiple counts on one enemy.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Objects ==

=== Object system ===

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

=== Object movement ===

Most non-flying objects are restricted to moving along a movement grid, consisting of edges and vertices. The length of an edge in this grid depends on the object index, with the standard length being 16 pixels and Link's being 8. When an object isn't on a vertex, its direction is restricted such that it can only be parallel to the current edge. An object is on a vertex when its position along the current edge (object_subgrid_offset) is 0, regardless of its current subpixel position (object_subpos).

Every frame that an object chooses to move, it undergoes 4 movement ticks that each move the object by less than one pixel. Within each tick, its speed (object_speed) is added to or subtracted from its subpixel position, depending on whether the movement is in a positive (down or right) or negative (up or left) direction. If the subgrid offset hasn't reached either limit for this kind of object ($010E subgrid_offset_limit_positive and $010F subgrid_offset_limit_negative), the carry from the subpixel arithmetic is added to or subtracted from both the subgrid offset and whole pixel position.

If either limit has been reached, then subsequent ticks within the same frame continue to modify the subpixel position as normal, but the offset and whole pixel values lock into place. This causes objects to stick to vertices, which is where important operations such as background collision detection and screen edge detection take place. When movement is complete, if the subgrid offset is equal to one of the limits, it is set back to 0.

Note that there is only one subpixel position, despite there being two axes. This is because standard objects can only move along one axis at a time, with the other axis coordinate aligned to the grid, so it's only ever relevant to the current one. However, this value isn't cleared when turning perpendicular, so the object may be closer to or further from the next pixel than expected when turning.

=== Screen scroll glitch ===

Normally, Link and other objects walk from a subgrid offset of 0 toward either the positive or negative limit, which will prevent further whole-pixel movement that frame. However, this same clamping behavior doesn't occur for 0. Normally, this isn't a problem, because if an object starts on 0, moves in a direction, and then turns around before reaching the next vertex and walks back, it will necessarily land on 0 again because it moves the same speed both ways, precisely retracing the steps it took. Non-Link objects also usually do not change their direction except on vertices. However, knockback can cause a problem for Link. When an object is hit and knocked back, it moves one entire pixel per tick for 4 ticks per frame through a separate mechanism from standard movement. This can cause Link to be at an unusual position along an edge, which could cause him to skip past 0 because he moves 1.5 pixels per frame (#$60 subpixels per tick).

Skipping past 0 results in the collision event at 0 being skipped. This bypasses Link's screen boundary check for scrolling, and causes the object to continue using the background tile it sampled at the last vertex as its current one. Realistically, that tile will be nonsolid, so the object may be able to skip past one solid tile.

A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

To fix this issue, the game includes a hack to ensure that the vertex Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

With the hack, holding up would first convert the offset to -6 (preserving the distance of 2.5 pixels from the vertex), and Link would then move to offset -7 subpixel #$00, and try to move to offset -9 subpixel #$80, but the clamping on the -8 limit would cause him to end up at offset -8 subpixel #$80, which would set his offset back to 0 and allow him to handle collision and move up.

For standard screen scrolling, if Link is facing right on a horizontal edge at offset 3 subpixel #$00, perpendicular input will convert the offset to -5 and move Link to offset -7 subpixel #$80. Walking right will then move him to offset -5 subpixel #$00, offset -4 subpixel #$80, offset -2 subpixel #$00, offset -1 subpixel #$80, and then offset 1 subpixel #$00, skipping 0.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link kills a second dodongo with a sword before the first one has dropped its bomb, the second will not drop a bomb because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Overkill''': When an enemy is killed by a weapon, it still finishes checking the remaining weapons that frame, as normal. This means it can be hit by those additional weapons. Because the enemy is dead, it has 0 health, so any other weapons hitting it that frame will also kill it. The consecutive kill counters are incremented at kill time, so these additional kills will each increment the counters like with any normal kill. As a result, killing a single enemy by hitting it with multiple weapons on one frame can add more than one to the count. This can be done most practically by timing multiple attacks to hit when an enemy's iframes expire. Note that the order in which weapons are checked can impact how many kills the enemy gives because each weapon hit reduces the health for the next weapon. Weapon check order is boomerang, beam (sword/rod), flame/bomb slot A, flame/bomb slot B, sword, and arrow/rod.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

Legend of Zelda/Technical Information

2018-02-09T11:52:44Z

Fiskbit: Forced drops - Clarifies when stabbing multiple dodongos will and will not drop forced bombs.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Objects ==

=== Object system ===

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

=== Object movement ===

Most non-flying objects are restricted to moving along a movement grid, consisting of edges and vertices. The length of an edge in this grid depends on the object index, with the standard length being 16 pixels and Link's being 8. When an object isn't on a vertex, its direction is restricted such that it can only be parallel to the current edge. An object is on a vertex when its position along the current edge (object_subgrid_offset) is 0, regardless of its current subpixel position (object_subpos).

Every frame that an object chooses to move, it undergoes 4 movement ticks that each move the object by less than one pixel. Within each tick, its speed (object_speed) is added to or subtracted from its subpixel position, depending on whether the movement is in a positive (down or right) or negative (up or left) direction. If the subgrid offset hasn't reached either limit for this kind of object ($010E subgrid_offset_limit_positive and $010F subgrid_offset_limit_negative), the carry from the subpixel arithmetic is added to or subtracted from both the subgrid offset and whole pixel position.

If either limit has been reached, then subsequent ticks within the same frame continue to modify the subpixel position as normal, but the offset and whole pixel values lock into place. This causes objects to stick to vertices, which is where important operations such as background collision detection and screen edge detection take place. When movement is complete, if the subgrid offset is equal to one of the limits, it is set back to 0.

Note that there is only one subpixel position, despite there being two axes. This is because standard objects can only move along one axis at a time, with the other axis coordinate aligned to the grid, so it's only ever relevant to the current one. However, this value isn't cleared when turning perpendicular, so the object may be closer to or further from the next pixel than expected when turning.

=== Screen scroll glitch ===

Normally, Link and other objects walk from a subgrid offset of 0 toward either the positive or negative limit, which will prevent further whole-pixel movement that frame. However, this same clamping behavior doesn't occur for 0. Normally, this isn't a problem, because if an object starts on 0, moves in a direction, and then turns around before reaching the next vertex and walks back, it will necessarily land on 0 again because it moves the same speed both ways, precisely retracing the steps it took. Non-Link objects also usually do not change their direction except on vertices. However, knockback can cause a problem for Link. When an object is hit and knocked back, it moves one entire pixel per tick for 4 ticks per frame through a separate mechanism from standard movement. This can cause Link to be at an unusual position along an edge, which could cause him to skip past 0 because he moves 1.5 pixels per frame (#$60 subpixels per tick).

Skipping past 0 results in the collision event at 0 being skipped. This bypasses Link's screen boundary check for scrolling, and causes the object to continue using the background tile it sampled at the last vertex as its current one. Realistically, that tile will be nonsolid, so the object may be able to skip past one solid tile.

A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

To fix this issue, the game includes a hack to ensure that the vertex Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

With the hack, holding up would first convert the offset to -6 (preserving the distance of 2.5 pixels from the vertex), and Link would then move to offset -7 subpixel #$00, and try to move to offset -9 subpixel #$80, but the clamping on the -8 limit would cause him to end up at offset -8 subpixel #$80, which would set his offset back to 0 and allow him to handle collision and move up.

For standard screen scrolling, if Link is facing right on a horizontal edge at offset 3 subpixel #$00, perpendicular input will convert the offset to -5 and move Link to offset -7 subpixel #$80. Walking right will then move him to offset -5 subpixel #$00, offset -4 subpixel #$80, offset -2 subpixel #$00, offset -1 subpixel #$80, and then offset 1 subpixel #$00, skipping 0.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link kills a second dodongo with a sword before the first one has dropped its bomb, the second will not drop a bomb because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

Legend of Zelda/Technical Information

2017-12-28T14:24:26Z

Fiskbit: Screen scroll glitch - Minor wording improvement.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Objects ==

=== Object system ===

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

=== Object movement ===

Most non-flying objects are restricted to moving along a movement grid, consisting of edges and vertices. The length of an edge in this grid depends on the object index, with the standard length being 16 pixels and Link's being 8. When an object isn't on a vertex, its direction is restricted such that it can only be parallel to the current edge. An object is on a vertex when its position along the current edge (object_subgrid_offset) is 0, regardless of its current subpixel position (object_subpos).

Every frame that an object chooses to move, it undergoes 4 movement ticks that each move the object by less than one pixel. Within each tick, its speed (object_speed) is added to or subtracted from its subpixel position, depending on whether the movement is in a positive (down or right) or negative (up or left) direction. If the subgrid offset hasn't reached either limit for this kind of object ($010E subgrid_offset_limit_positive and $010F subgrid_offset_limit_negative), the carry from the subpixel arithmetic is added to or subtracted from both the subgrid offset and whole pixel position.

If either limit has been reached, then subsequent ticks within the same frame continue to modify the subpixel position as normal, but the offset and whole pixel values lock into place. This causes objects to stick to vertices, which is where important operations such as background collision detection and screen edge detection take place. When movement is complete, if the subgrid offset is equal to one of the limits, it is set back to 0.

Note that there is only one subpixel position, despite there being two axes. This is because standard objects can only move along one axis at a time, with the other axis coordinate aligned to the grid, so it's only ever relevant to the current one. However, this value isn't cleared when turning perpendicular, so the object may be closer to or further from the next pixel than expected when turning.

=== Screen scroll glitch ===

Normally, Link and other objects walk from a subgrid offset of 0 toward either the positive or negative limit, which will prevent further whole-pixel movement that frame. However, this same clamping behavior doesn't occur for 0. Normally, this isn't a problem, because if an object starts on 0, moves in a direction, and then turns around before reaching the next vertex and walks back, it will necessarily land on 0 again because it moves the same speed both ways, precisely retracing the steps it took. Non-Link objects also usually do not change their direction except on vertices. However, knockback can cause a problem for Link. When an object is hit and knocked back, it moves one entire pixel per tick for 4 ticks per frame through a separate mechanism from standard movement. This can cause Link to be at an unusual position along an edge, which could cause him to skip past 0 because he moves 1.5 pixels per frame (#$60 subpixels per tick).

Skipping past 0 results in the collision event at 0 being skipped. This bypasses Link's screen boundary check for scrolling, and causes the object to continue using the background tile it sampled at the last vertex as its current one. Realistically, that tile will be nonsolid, so the object may be able to skip past one solid tile.

A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

To fix this issue, the game includes a hack to ensure that the vertex Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

With the hack, holding up would first convert the offset to -6 (preserving the distance of 2.5 pixels from the vertex), and Link would then move to offset -7 subpixel #$00, and try to move to offset -9 subpixel #$80, but the clamping on the -8 limit would cause him to end up at offset -8 subpixel #$80, which would set his offset back to 0 and allow him to handle collision and move up.

For standard screen scrolling, if Link is facing right on a horizontal edge at offset 3 subpixel #$00, perpendicular input will convert the offset to -5 and move Link to offset -7 subpixel #$80. Walking right will then move him to offset -5 subpixel #$00, offset -4 subpixel #$80, offset -2 subpixel #$00, offset -1 subpixel #$80, and then offset 1 subpixel #$00, skipping 0.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link rapidly kills multiple dodongos with a sword, only one bomb will drop because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

Legend of Zelda/Technical Information

2017-12-27T23:59:49Z

Fiskbit: Adds technical sections on object movement and the screen scroll glitch.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Objects ==

=== Object system ===

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

=== Object movement ===

Most non-flying objects are restricted to moving along a movement grid, consisting of edges and vertices. The length of an edge in this grid depends on the object index, with the standard length being 16 pixels and Link's being 8. When an object isn't on a vertex, its direction is restricted such that it can only be parallel to the current edge. An object is on a vertex when its position along the current edge (object_subgrid_offset) is 0, regardless of its current subpixel position (object_subpos).

Every frame that an object chooses to move, it undergoes 4 movement ticks that each move the object by less than one pixel. Within each tick, its speed (object_speed) is added to or subtracted from its subpixel position, depending on whether the movement is in a positive (down or right) or negative (up or left) direction. If the subgrid offset hasn't reached either limit for this kind of object ($010E subgrid_offset_limit_positive and $010F subgrid_offset_limit_negative), the carry from the subpixel arithmetic is added to or subtracted from both the subgrid offset and whole pixel position.

If either limit has been reached, then subsequent ticks within the same frame continue to modify the subpixel position as normal, but the offset and whole pixel values lock into place. This causes objects to stick to vertices, which is where important operations such as background collision detection and screen edge detection take place. When movement is complete, if the subgrid offset is equal to one of the limits, it is set back to 0.

Note that there is only one subpixel position, despite there being two axes. This is because standard objects can only move along one axis at a time, with the other axis coordinate aligned to the grid, so it's only ever relevant to the current one. However, this value isn't cleared when turning perpendicular, so the object may be closer to or further from the next pixel than expected when turning.

=== Screen scroll glitch ===

Normally, Link and other objects walk from a subgrid offset of 0 toward either the positive or negative limit, which will prevent further whole-pixel movement that frame. However, this same clamping behavior doesn't occur for 0. Normally, this isn't a problem, because if an object starts on 0, moves in a direction, and then turns around before reaching the next vertex and walks back, it will necessarily land on 0 again because it moves the same speed both ways, precisely retracing the steps it took. Non-Link objects also usually do not change their direction except on vertices. However, knockback can cause a problem for Link. When an object is hit and knocked back, it moves one entire pixel per tick for 4 ticks per frame through a separate mechanism from standard movement. This can cause Link to be at an unusual position along an edge, which could cause him to skip past 0 because he moves 1.5 pixels per frame (#$60 subpixels per tick).

Skipping past 0 results in the collision event at 0 being skipped. This bypasses Link's screen boundary check for scrolling, and causes the object to continue using the background tile it sampled at the last vertex as its current one. Realistically, that tile will be nonsolid, so the object may be able to skip past one solid tile.

A worse side effect, though, is how this interacts with perpendicular movement. When Link receives perpendicular input, he attempts to walk to the nearest vertex before then turning in that direction. If that nearest vertex is at 0 and Link isn't lined up to be able to land on 0, he'll miss the vertex and land on the other side. On the next frame, he'll try again to reach the vertex, missing again and ending up back where he started. This causes him to be stuck, alternating from side to side, unable to reach the vertex without first moving elsewhere.

To fix this issue, the game includes a hack to ensure that the subgrid offset Link walks toward when attempting to turn perpendicular is at a limit rather than at 0, so proper clamping can occur. For example, if Link is walking toward the positive limit and turns around with perpendicular input, his subgrid offset will be adjusted so that the vertex he came from will now be at the negative limit instead of 0. This fixes the stuck issue, but allows Link to easily configure the next vertex to be at 0 rather than a limit by just tapping perpendicular. By just walking toward that vertex, he can skip over it, assuming he's properly aligned.

Let's do some examples. Without the perpendicular movement hack, if Link were facing right on a horizontal edge at subgrid offset 2 and subpixel position #$80, holding up would cause him to walk left to offset 1 subpixel #$00, and then offset -1 subpixel #$80 (with the subpixel for negative numbers representing how close the object is to the next larger number, not smaller). The offset never became 0, so Link didn't handle collision there and wasn't able to start moving up. On the next frame, he would walk right again back to offset 1 subpixel #$00, and would continue to alternate back and forth.

With the hack, holding up would first convert the offset to -6 (preserving the distance of 2.5 pixels from the vertex), and Link would then move to offset -7 subpixel #$00, and try to move to offset -9 subpixel #$80, but the clamping on the -8 limit would cause him to end up at offset -8 subpixel #$80, which would set his offset back to 0 and allow him to handle collision and move up.

For standard screen scrolling, if Link is facing right on a horizontal edge at offset 3 subpixel #$00, perpendicular input will convert the offset to -5 and move Link to offset -7 subpixel #$80. Walking right will then move him to offset -5 subpixel #$00, offset -4 subpixel #$80, offset -2 subpixel #$00, offset -1 subpixel #$80, and then offset 1 subpixel #$00, skipping 0.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link rapidly kills multiple dodongos with a sword, only one bomb will drop because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

The Legend of Zelda/Randomizer

2017-11-23T22:32:53Z

Fiskbit: Free Locked Door Extension - Clarifies up+A on the overworld.

Twitch user fcoughlin has a [https://sites.google.com/site/zeldarandomizer/ Randomizer] for the Legend of Zelda that's getting really popular to run and to race.

Big thanks to Twitch user [http://twitch.tv/catastrophe573/profile Catastrophe573] for putting together a lot of this information.

=Tutorial Video=

[https://www.twitch.tv/jkoper/v/66858825 Tutorial video by jkoper]

=Randomizer Mechanics and Glitches=

== Ganon's Cry ==

Normally Ganon makes a typical boss noise when you are adjacent to his boss room. When the layout of Level-9 is randomized this is a very useful hint! However, there are some special cases which can trick you.

First, the room with the skull layout on the floor (Ganon's normal room) will NEVER make the sound. Do not assume Ganon isn't next door!

Another case are the Patras. Their cry/roar will mask Ganon's. If you want to 'listen' in a room with a Patra you must first kill it, leave the room, and reenter the room.

== Bomb Out of Ganon's Room ==

Or any other room that has tried to lock you in! If you're stuck and don't want to defeat the enemies (or can't!) then break out the bombs!

== Triforce Room Doors ==

The room which requires you to have the Triforce to pass will NEVER contain a bomb wall. If an expected exit is "missing", such as the north exit in the 1st quest, then that wall is 100% guaranteed to be solid.

A door missing in this way is not necessarily covering Ganon or Zelda. Don't assume anything about the other side of the wall.

== Decoding Warp Stairs Order ==

The any-road shortcuts form a loop of 4 destinations, and each staircase warps you forward in the loop. From left to right, the staircases advance Link by 1, 2, and 3 screens. To see all of the destinations, just keep taking the left staircase.

== Money Making Game Abuse ==

Sometimes you just need a lot of rupees. It happens, especially in the second quest.

If a Money Making Game is anywhere near the starting screen (such as in the non-randomized 1st quest) then you can cheat by saving and reloading your game. Up-A will not work. It must be a full save and retry.

The mechanics of the game are unimportant. Just take the center choice every time.

== Skip Door Repairs ==

If you Up-A out of a door repair before the message finishes then you won't be charged anything! Of course you'll be sent back to the start when you continue. It's up to you if the time/rupees tradeoff is worth it.

== Useful Screen Wraps ==

Avoiding backtracking and taking efficient routes is very important when racing Zelda Randomizer. Here are some unusual screen wraps which save a lot of time, plus a visual reference for the first two.

=== Lost Woods Skip ===

Go one screen north of the Lost Woods. (There is a candle location here.)

Performing the screen wrap from right to left is easier if you position Link directly under the trees and use the visual guide below.

INSERT IMAGE HERE (cannot upload, need privileges)

All screen wraps work just like this one.

=== Ladder-Heart Wrap ===

This one is mentioned separately because it is unique. It requires the ladder! First, collect the heart container on the overworld which requires the stepladder.

Basically you're going to use the screen wrap technique, but in the middle of the screen while standing on the ladder. This allows you to get extra uses out of your ladder while standing on it!

INSERT IMAGE HERE

If you need to explore the green area to the left this will save a lot of walking around.

=== Top Left Reset Wrap ===

If you screen wrap out of bounds you'll be sent back to the starting screen. The only practical place to do this is in the top left corner of the overworld where Level-9 appears in the second quest.

This produces the same effect as using Up-A except that it saves your current hearts! It could be useful after exploring this corner of the world.

=== Other Useful Wraps ===

INSERT IMAGE HERE

For all of these wraps, do the standard screen wrap like the Lost Woods Skip. Beware, most of them need to be done from the center edge of the screen! If you try to use a nearby wall for visual reference then you may end up stuck inside a wall after scrolling the screen.

== Free Locked Door Extension ==

Leaving and reentering the first room of a dungeon will actually open a bomb wall OR locked door on the north side. This is especially common on levels 5, 7, and 9. This works because entering a screen will open the door you entered through, and the game thinks you came in through the top because the last door you left through was the bottom one.

This trick is even more general than this. The direction through which you entered the overworld screen that has the dungeon will also be treated as the door you came through, so if you entered the overworld screen from the left and go into the dungeon, the left door will be opened if it can be.

You can also use this trick with up+A, but it's more complicated. When you use up+A in the dungeon, any door on the screen that CAN be closed (bomb wall, locked door, shutter door) and is currently open will be able to open a door on the dungeon entrance screen. You can even use this as you enter a room through a shutter door, since it starts out open; it will stay marked as open for several frames after appearing closed, so mashing start while entering should catch it.

Finally, up+A can also be used on the overworld to preserve your entrance direction in case there is a dungeon on the start screen and that screen doesn't allow you to enter it from the side you'd want to.

== Room Drops ==

https://docs.google.com/spreadsheets/d/1LYqWn7kiYbJ-xnnByOA6RCV7Pob1RoI-7BrHFvrRICA/edit#gid=1711498188

The Legend of Zelda/Randomizer

2017-11-23T22:15:39Z

Fiskbit: Free Locked Door Extension - Adds information about opening side doors and using up+A.

Twitch user fcoughlin has a [https://sites.google.com/site/zeldarandomizer/ Randomizer] for the Legend of Zelda that's getting really popular to run and to race.

Big thanks to Twitch user [http://twitch.tv/catastrophe573/profile Catastrophe573] for putting together a lot of this information.

=Tutorial Video=

[https://www.twitch.tv/jkoper/v/66858825 Tutorial video by jkoper]

=Randomizer Mechanics and Glitches=

== Ganon's Cry ==

Normally Ganon makes a typical boss noise when you are adjacent to his boss room. When the layout of Level-9 is randomized this is a very useful hint! However, there are some special cases which can trick you.

First, the room with the skull layout on the floor (Ganon's normal room) will NEVER make the sound. Do not assume Ganon isn't next door!

Another case are the Patras. Their cry/roar will mask Ganon's. If you want to 'listen' in a room with a Patra you must first kill it, leave the room, and reenter the room.

== Bomb Out of Ganon's Room ==

Or any other room that has tried to lock you in! If you're stuck and don't want to defeat the enemies (or can't!) then break out the bombs!

== Triforce Room Doors ==

The room which requires you to have the Triforce to pass will NEVER contain a bomb wall. If an expected exit is "missing", such as the north exit in the 1st quest, then that wall is 100% guaranteed to be solid.

A door missing in this way is not necessarily covering Ganon or Zelda. Don't assume anything about the other side of the wall.

== Decoding Warp Stairs Order ==

The any-road shortcuts form a loop of 4 destinations, and each staircase warps you forward in the loop. From left to right, the staircases advance Link by 1, 2, and 3 screens. To see all of the destinations, just keep taking the left staircase.

== Money Making Game Abuse ==

Sometimes you just need a lot of rupees. It happens, especially in the second quest.

If a Money Making Game is anywhere near the starting screen (such as in the non-randomized 1st quest) then you can cheat by saving and reloading your game. Up-A will not work. It must be a full save and retry.

The mechanics of the game are unimportant. Just take the center choice every time.

== Skip Door Repairs ==

If you Up-A out of a door repair before the message finishes then you won't be charged anything! Of course you'll be sent back to the start when you continue. It's up to you if the time/rupees tradeoff is worth it.

== Useful Screen Wraps ==

Avoiding backtracking and taking efficient routes is very important when racing Zelda Randomizer. Here are some unusual screen wraps which save a lot of time, plus a visual reference for the first two.

=== Lost Woods Skip ===

Go one screen north of the Lost Woods. (There is a candle location here.)

Performing the screen wrap from right to left is easier if you position Link directly under the trees and use the visual guide below.

INSERT IMAGE HERE (cannot upload, need privileges)

All screen wraps work just like this one.

=== Ladder-Heart Wrap ===

This one is mentioned separately because it is unique. It requires the ladder! First, collect the heart container on the overworld which requires the stepladder.

Basically you're going to use the screen wrap technique, but in the middle of the screen while standing on the ladder. This allows you to get extra uses out of your ladder while standing on it!

INSERT IMAGE HERE

If you need to explore the green area to the left this will save a lot of walking around.

=== Top Left Reset Wrap ===

If you screen wrap out of bounds you'll be sent back to the starting screen. The only practical place to do this is in the top left corner of the overworld where Level-9 appears in the second quest.

This produces the same effect as using Up-A except that it saves your current hearts! It could be useful after exploring this corner of the world.

=== Other Useful Wraps ===

INSERT IMAGE HERE

For all of these wraps, do the standard screen wrap like the Lost Woods Skip. Beware, most of them need to be done from the center edge of the screen! If you try to use a nearby wall for visual reference then you may end up stuck inside a wall after scrolling the screen.

== Free Locked Door Extension ==

Leaving and reentering the first room of a dungeon will actually open a bomb wall OR locked door on the north side. This is especially common on levels 5, 7, and 9. This works because entering a screen will open the door you entered through, and the game thinks you came in through the top because the last door you left through was the bottom one.

This trick is even more general than this. The direction through which you entered the overworld screen that has the dungeon will also be treated as the door you came through, so if you entered the overworld screen from the left and go into the dungeon, the left door will be opened if it can be.

You can also use this trick with up+A, but it's more complicated. When you use up+A in the dungeon, any door on the screen that CAN be closed (bomb wall, locked door, shutter door) and is currently open will be able to open a door on the dungeon entrance screen. You can even use this as you enter a room through a shutter door, since it starts out open; it will stay marked as open for several frames after appearing closed, so mashing start while entering should catch it.

Finally, this can also be used on the overworld to preserve your entrance direction in case there is a dungeon on the start screen and that screen doesn't allow you to enter it from the side you'd want to.

== Room Drops ==

https://docs.google.com/spreadsheets/d/1LYqWn7kiYbJ-xnnByOA6RCV7Pob1RoI-7BrHFvrRICA/edit#gid=1711498188

The Legend of Zelda

2017-11-19T12:30:11Z

Fiskbit: Walking through enemies - Adds a note about stabbing while catching the boomerang.

== Version differences ==

[[The Legend of Zelda/Version Differences]]

==Categories==

===Any%===

Get to Zelda as fast as you can.

As there are no known means of getting to Zelda without defeating Gannon and taking the Triforce, and there are no known means of getting into Level 9 without all of the Triforce pieces, this means one must complete every dungeon. Items needed: Wooden Sword, Bombs, Bow, Candle, Raft, Ladder, Recorder, Bait, Arrows, Silver Arrows. Items acquired for maximum speed in current routing: Heart containers, Magic Sword.

===Swordless===

This is a challenge category. One plays the game according to the Any% rules, with two changes: No sword is allowed, and the run ends upon reaching Gannon and holding up the Triforce. Gannon cannot be killed without a sword, unlike other enemies who can be killed with Bombs, Boomerang, Arrows, Candles, or the Wand. See [[The Legend of Zelda/Swordless Route]] for information on a way to run this category.

===100%===

The category requires the player to acquire:

* 13 heart containers (for 16 total)
* Letter
* Power Bracelet
* Magic Sword
* Both bomb upgrades
* Bow
* Magic Boomerang
* Raft
* Ladder
* Recorder
* Wand
* Red Candle
* Book/Bible
* Magic Key
* Silver Arrows
* Red Ring

Items that are infinitely obtainable and consumable (such as the Bait, Red Potion, Blue Potion, Rupees, Magic Shield, keys other than the Magic Key, or the Bombs themselves) or are replaced (such as the Wooden Boomerang, the Wooden Sword, the White Sword, the Blue Ring, keys other than the Magic Key, and the Blue Candle) are not required.

==Game Mechanics and Glitches==

===Screen Scroll===

The 'screen scroll' trick is useful for getting over overworld obstacles, as well as for clipping through blocks in dungeons. That means you get to some stairs without killing all the enemies first! Here's a graphic with some pointers:

http://redcandle.us/wp-content/uploads/2012/10/screenscroll.png

Since the above chart was made, an alternate way of clipping through a block has been discovered by [https://twitter.com/hal_yotsuba はる＠よつば]. First, you get onto the pixel as in the above picture, with the top of Link's head lined up with the flat part of the block. Then, instead of doing a single-frame tap, slash the sword and press right or left. The sword slash, done correctly, will prevent you from moving. You will get the same effect as the single frame tap, so if you're positioned right, you will turn around. After the sword slash, walk through the block. This trick only works with block clips, not overworld scrolls or ladder clips.

Here's an additional quick demonstration of the pixels for the "reverse" clip:

http://redcandle.us/wp-content/uploads/reverseclip.png

===Drops===

==== Random drops ====

The enemy drops are not random. Whether they do drop an item is random, but when they do drop, here's what they'll be. The counter starts at 0, and goes up by 1 every time you kill (most) enemies. Zols' gels and vires' keese do not advance the counter. Chart via [http://tasvideos.org/2091S.html Baxter at TASVideos]<nowiki>:</nowiki>

http://redcandle.us/wp-content/uploads/2012/10/zeldaitemdropsnr2.png

====Drop Rates ====

The chance of getting a drop from group A is 80/256 = 31%.

Group B: 104/256 = 41%

Group C: 152/256 = 59%

Group D: 104/256 = 41%

==== Forced drops ====

However there are also the ''consecutive'' kill counters. Kill 10 enemies without getting hit (by an enemy, even a non-damaging bubble, or by the whirlwind from the recorder) and you'll get a forced, guaranteed 5 rupee drop from the next enemy that drops items (not in the X group). Kill the 10th enemy with a bomb instead, and instead of a 5 rupee you'll get a forced, guaranteed bomb drop!

Kill 16 enemies in a row and you get a fairy drop forced, but only if the 16th enemy is capable of dropping an item (not in the X group).

Note that if the 10th enemy does not drop items (in the X group), then killing that enemy with a bomb means the next drop that does happen will be a bomb. Killing that 10th enemy with the sword or any thing else will mean the next drop will be a rupee, even if you kill the next-dropping enemy with a bomb. It's the actual 10th enemy kill that counts, not the succeeding enemy that drops items.

However if the 16th enemy does not drop items, the fairy drop will be skipped entirely, and another one will not happen unless you get hit and the counters reset.

In some rooms that drop an item (such as the 5-Stalfos room in Level 1 that gives a key at the end), one enemy will act like it was holding the drop like a stalfos with a visible key, or a gibdo with a visible bomb. As a result, that enemy will never drop anything, and it will be able to store a forced drop and/or bypass a fairy drop, just like enemies that never drop items.

Note that splitting a Zol into two Gels, or splitting a Vire into two Keese, will not count as a kill or a consecutive kill. Killing one of those split Gels or Keese will not count as a kill for drops, but will count as a consecutive kill. Yes, there are some circumstances that are an exception to this. If the Zol/Vire is trapped against a barrier, it can sometimes trigger an extra 'kill' that way. A kill sound in place of a split sound is a hint to when this might happen.

Further note: Multiple simultaneous kills will not take you past 10 on the consecutive kill counter, per Darkwing Duck. If they would take you past 10 they leave you at 10 instead.

Advanced strategies: If a forced bomb/rupee or forced fairy drops, the consecutive counter for bombs/rupees is reset, but not the counter for fairies. So no matter how many hits you get on Manhandla with one well-placed bomb, the 10 count is reset after defeating him. The same is true of Dodongo. Likewise with a "Hippo Fairy" (going into a Patra with 7 on the consecutive counters, so that the Patra's center will be kill #16 and get a fairy), the bomb/rupee count resets to 0. Credit to Khananaphone for this discovery.

This means that if you get a forced fairy drop, the next consecutive bomb/rupee kill will not be at 20. It will be at 26. So bomb/rupee drops work in one of two methods:

# 10, (Fairy at 16), 26, 36, 46...
# 10, (Skip fairy at 16 by killing non-dropping enemy), 20, 30, 40...

Credit to Darkwing Duck for this discovery.

===Luck Manipulation===

See [[The Legend of Zelda/Luck Manipulation]]

===The Recorder===

The recorder loops you through all the dungeons you've gotten the Triforce in, sequentially, according to the direction link is facing. It has an internal counter that starts at 1. Every time you blow the recorder in a place where the whirlwind would appear (that is, in most overworld screens, but not all), the counter changes according to the direction Link is facing. If Link is facing right or up, then the counter goes up one. If Link is facing down or left, then the counter goes down one.

Note that this counter does not reset during the run.

For example, hold your right foot turnwise to the out. If Link is facing where your toes point cross-wise, then the count will be cremented.

OK, never mind that. Let's say Link has completed dungeons 1, 3, 4, and 5. If Link blows the whistle once facing down. Link will then be taken to level 5, because the count started at one, and then looped around to 5.

Let's say link then blows the whistle 3 more times while facing down. The count will go 4, 3, 1, skipping 2 since the player has not completed 2 yet, and Link will be taken to 1.

So let's go back to the first example. Link just completed Level 5, and blows the whistle twice. Once facing down, once facing right. The counter will go from 1 to 5, and then back from 5 to 1, taking Link to Level 1. This is a technique used in record runs.

===Bombing Darknuts===

Whether a Darknut blocks a bomb's explosion with its shield is determined by two things. First, the direction Link is facing when he lays the bomb. Second, the direction the Darknut is facing when the explosion hits him. If Link's position when laying the bomb is facing the direction the Darknut is looking when the bomb goes off, the bomb won't work.

Here is a graphic by Lackattack24.

http://redcandle.us/wp-content/uploads/darknuts-lackattack.png

===Bombing Walls===

Note that bombs do not check to see if a hole should be opened whenever a shutter is opening or closing. Beware of that.

===Free Locked Door===

If you enter a dungeon and the first room has a locked door on top then you can leave and immediately reenter to unlock that door for free!

===Walking through enemies===

If an enemy has just been hit, then Link can temporarily walk through that enemy without damage or knockback. However the enemy itself must not be knocked back or split in order for that to work. So this doesn't work against Zols or Vires. Striking a Darknut's shield also prevents this from working.

Enemies won't be knocked back if hit perpendicular to their movement direction while they're between tiles. When they're directly on a tile, they can be knocked back in any direction.

Link normally stops walking temporarily when using the sword. Exceptions to this are while stepping onto the ladder (useful in 7 after the hungry Goriya, and in 1 to steal the key from the Stalfos after the Gels), and when stepping into a door (useful in 9 when skipping the first Patra). Catching a boomerang while stabbing will also allow Link to start moving immediately.

=== Skipping Patras ===

Walking through Patras is a special case. It turns out that the orbiting eyes of the Patra don't actually exist hitbox-wise right away. This gives you time to walk through them. This is important for being able to actually skip the first Patra in level 9, when going toward the Old Man who talks about the Next Room. It's also great for trying to skip the second Patra, on the way back from the Silver Arrows, going toward Gannon.

Note that when walking through that first Patra, there's a trick to it. You can't just walk through the door. You have to hesitate after unlocking the door, before going through, and stabbing your way through the eye that will otherwise hit you.

Skipping the second Patra going toward the Silver Arrows is a matter of getting a good pattern of movement, and getting your block clip quickly and accurately.

Sadly the Patra before Gannon cannot be skipped with present knowledge.

Additionally, in Level 9 there's a special "reverse" block clip that's very useful to get done quickly, to get out of the wizzrobe room immediately south of the Silver Arrows. It's in theory a standard block clip, but it's coming from the opposite direction most runners do a block clip from, and it's under immense time pressure.

[https://www.youtube.com/watch?v=20p65-Vn6yY Here's a video of the Patra skips and the reverse clip in level 9], from LackAttack24's 29:56 then-WR run.

=== Heart Duplication ===

Only possible in the 1.0 FDS version? https://www.youtube.com/watch?v=4iGwBE4aAzU

== Other Technical Information ==

There are a lot of small interactions and weird corner cases in this game. Here's a section of the site dedicated to them.

[[Legend of Zelda/Technical Information]]

==Fighting Bosses==

[[Legend of Zelda/Bosses]]

==Beginning Advice==

===Darkwing Duck's Impromptu Guide===

Old, but this is [https://www.twitch.tv/darkwing_duck_sda/v/50222274 an incredibly informative video].

===Zelda for Mortals===

Also old, but [https://www.twitch.tv/presjpolk/v/50217130 here is the Presjpolk followup] for beginners

Also see the Zelda Any%s Beginner Route link for a video by Jkoper

===Beginner Any% Route===

Rather than duplicate their work, I'll just link you to the [https://sites.google.com/site/zeldaanypercents/beginner-routes/blue-ring-route Zelda Any%s Blue Ring Route]

==More advanced routes==

This route benefits from the "screen scroll" but does not strictly require it. You're strongly advised at least to do the wrap into level 5, and the wrap past the lost woods, even if you don't do any others. The most important block clip you'll want to start doing is the one on the way to the Recorder.

[[The Legend of Zelda/Old Record Route]]

This route is the one that got to sub-30.

[[The Legend of Zelda/Record Route]]

This alternate route makes more advanced use of the screen scroll than the old record route, but has the benefit over the old record route in that it puts the player under less rupee pressure, as the Blue Candle is not bought. It's theoretically slower than either of the record routes, though.

[[The Legend of Zelda/Red Candle Route]]

Routing in this game is constantly updating these days, as people try more ideas. Ategenos is also trying to document some at his site [https://sites.google.com/site/zeldaanypercents/home Zelda Any Percents].

There's also Saver's [http://imgur.com/a/56TXh route tracking] maps.

==Maps==

The instructions above assume you know the overworld map, as well as where to get everything inside the dungeons themselves. For maps see [http://www.nesmaps.com NESMaps.com], including [http://www.nesmaps.com/maps/Zelda/Zelda.html dungeon maps] and a [http://www.nesmaps.com/maps/Zelda/ZeldaOverworldQ1.html fully annotated overworld map].

==Records==

See [http://www.speedrun.com/The_Legend_of_Zelda Speedrun.com]

==Randomizer!==

See [[The Legend of Zelda/Randomizer]] for mechanics and techniques specific to [https://sites.google.com/site/zeldarandomizer/ Fred Coughlin's Legend of Zelda Randomizer]

== Tools ==

[http://games.technoplaza.net/lozsrame/ Legend of Zelda save editor].

[https://github.com/helgefmi/tloz-prachack Practice Hack] in development. Shows drop counters. Later may give other useful information.

[https://pastebin.com/7KejFYTF Hitbox visualization script 1.1] by Fiskbit

[http://redcandle.us/wp-content/uploads/show-target-by-fiskbit.ips AI target viewer] by Fiskbit (in the form of an IPS patch from the PRG0 ROM)

[https://github.com/camthesaxman/zeldasource Disassembly project]

== History ==

[http://redcandle.us/wp-content/Zelda-Historical-Graphs/loz.html History of the record]

The Legend of Zelda

2017-11-19T12:28:35Z

Fiskbit: Walking through enemies - Corrects and clarifies knockback info.

== Version differences ==

[[The Legend of Zelda/Version Differences]]

==Categories==

===Any%===

Get to Zelda as fast as you can.

As there are no known means of getting to Zelda without defeating Gannon and taking the Triforce, and there are no known means of getting into Level 9 without all of the Triforce pieces, this means one must complete every dungeon. Items needed: Wooden Sword, Bombs, Bow, Candle, Raft, Ladder, Recorder, Bait, Arrows, Silver Arrows. Items acquired for maximum speed in current routing: Heart containers, Magic Sword.

===Swordless===

This is a challenge category. One plays the game according to the Any% rules, with two changes: No sword is allowed, and the run ends upon reaching Gannon and holding up the Triforce. Gannon cannot be killed without a sword, unlike other enemies who can be killed with Bombs, Boomerang, Arrows, Candles, or the Wand. See [[The Legend of Zelda/Swordless Route]] for information on a way to run this category.

===100%===

The category requires the player to acquire:

* 13 heart containers (for 16 total)
* Letter
* Power Bracelet
* Magic Sword
* Both bomb upgrades
* Bow
* Magic Boomerang
* Raft
* Ladder
* Recorder
* Wand
* Red Candle
* Book/Bible
* Magic Key
* Silver Arrows
* Red Ring

Items that are infinitely obtainable and consumable (such as the Bait, Red Potion, Blue Potion, Rupees, Magic Shield, keys other than the Magic Key, or the Bombs themselves) or are replaced (such as the Wooden Boomerang, the Wooden Sword, the White Sword, the Blue Ring, keys other than the Magic Key, and the Blue Candle) are not required.

==Game Mechanics and Glitches==

===Screen Scroll===

The 'screen scroll' trick is useful for getting over overworld obstacles, as well as for clipping through blocks in dungeons. That means you get to some stairs without killing all the enemies first! Here's a graphic with some pointers:

http://redcandle.us/wp-content/uploads/2012/10/screenscroll.png

Since the above chart was made, an alternate way of clipping through a block has been discovered by [https://twitter.com/hal_yotsuba はる＠よつば]. First, you get onto the pixel as in the above picture, with the top of Link's head lined up with the flat part of the block. Then, instead of doing a single-frame tap, slash the sword and press right or left. The sword slash, done correctly, will prevent you from moving. You will get the same effect as the single frame tap, so if you're positioned right, you will turn around. After the sword slash, walk through the block. This trick only works with block clips, not overworld scrolls or ladder clips.

Here's an additional quick demonstration of the pixels for the "reverse" clip:

http://redcandle.us/wp-content/uploads/reverseclip.png

===Drops===

==== Random drops ====

The enemy drops are not random. Whether they do drop an item is random, but when they do drop, here's what they'll be. The counter starts at 0, and goes up by 1 every time you kill (most) enemies. Zols' gels and vires' keese do not advance the counter. Chart via [http://tasvideos.org/2091S.html Baxter at TASVideos]<nowiki>:</nowiki>

http://redcandle.us/wp-content/uploads/2012/10/zeldaitemdropsnr2.png

====Drop Rates ====

The chance of getting a drop from group A is 80/256 = 31%.

Group B: 104/256 = 41%

Group C: 152/256 = 59%

Group D: 104/256 = 41%

==== Forced drops ====

However there are also the ''consecutive'' kill counters. Kill 10 enemies without getting hit (by an enemy, even a non-damaging bubble, or by the whirlwind from the recorder) and you'll get a forced, guaranteed 5 rupee drop from the next enemy that drops items (not in the X group). Kill the 10th enemy with a bomb instead, and instead of a 5 rupee you'll get a forced, guaranteed bomb drop!

Kill 16 enemies in a row and you get a fairy drop forced, but only if the 16th enemy is capable of dropping an item (not in the X group).

Note that if the 10th enemy does not drop items (in the X group), then killing that enemy with a bomb means the next drop that does happen will be a bomb. Killing that 10th enemy with the sword or any thing else will mean the next drop will be a rupee, even if you kill the next-dropping enemy with a bomb. It's the actual 10th enemy kill that counts, not the succeeding enemy that drops items.

However if the 16th enemy does not drop items, the fairy drop will be skipped entirely, and another one will not happen unless you get hit and the counters reset.

In some rooms that drop an item (such as the 5-Stalfos room in Level 1 that gives a key at the end), one enemy will act like it was holding the drop like a stalfos with a visible key, or a gibdo with a visible bomb. As a result, that enemy will never drop anything, and it will be able to store a forced drop and/or bypass a fairy drop, just like enemies that never drop items.

Note that splitting a Zol into two Gels, or splitting a Vire into two Keese, will not count as a kill or a consecutive kill. Killing one of those split Gels or Keese will not count as a kill for drops, but will count as a consecutive kill. Yes, there are some circumstances that are an exception to this. If the Zol/Vire is trapped against a barrier, it can sometimes trigger an extra 'kill' that way. A kill sound in place of a split sound is a hint to when this might happen.

Further note: Multiple simultaneous kills will not take you past 10 on the consecutive kill counter, per Darkwing Duck. If they would take you past 10 they leave you at 10 instead.

Advanced strategies: If a forced bomb/rupee or forced fairy drops, the consecutive counter for bombs/rupees is reset, but not the counter for fairies. So no matter how many hits you get on Manhandla with one well-placed bomb, the 10 count is reset after defeating him. The same is true of Dodongo. Likewise with a "Hippo Fairy" (going into a Patra with 7 on the consecutive counters, so that the Patra's center will be kill #16 and get a fairy), the bomb/rupee count resets to 0. Credit to Khananaphone for this discovery.

This means that if you get a forced fairy drop, the next consecutive bomb/rupee kill will not be at 20. It will be at 26. So bomb/rupee drops work in one of two methods:

# 10, (Fairy at 16), 26, 36, 46...
# 10, (Skip fairy at 16 by killing non-dropping enemy), 20, 30, 40...

Credit to Darkwing Duck for this discovery.

===Luck Manipulation===

See [[The Legend of Zelda/Luck Manipulation]]

===The Recorder===

The recorder loops you through all the dungeons you've gotten the Triforce in, sequentially, according to the direction link is facing. It has an internal counter that starts at 1. Every time you blow the recorder in a place where the whirlwind would appear (that is, in most overworld screens, but not all), the counter changes according to the direction Link is facing. If Link is facing right or up, then the counter goes up one. If Link is facing down or left, then the counter goes down one.

Note that this counter does not reset during the run.

For example, hold your right foot turnwise to the out. If Link is facing where your toes point cross-wise, then the count will be cremented.

OK, never mind that. Let's say Link has completed dungeons 1, 3, 4, and 5. If Link blows the whistle once facing down. Link will then be taken to level 5, because the count started at one, and then looped around to 5.

Let's say link then blows the whistle 3 more times while facing down. The count will go 4, 3, 1, skipping 2 since the player has not completed 2 yet, and Link will be taken to 1.

So let's go back to the first example. Link just completed Level 5, and blows the whistle twice. Once facing down, once facing right. The counter will go from 1 to 5, and then back from 5 to 1, taking Link to Level 1. This is a technique used in record runs.

===Bombing Darknuts===

Whether a Darknut blocks a bomb's explosion with its shield is determined by two things. First, the direction Link is facing when he lays the bomb. Second, the direction the Darknut is facing when the explosion hits him. If Link's position when laying the bomb is facing the direction the Darknut is looking when the bomb goes off, the bomb won't work.

Here is a graphic by Lackattack24.

http://redcandle.us/wp-content/uploads/darknuts-lackattack.png

===Bombing Walls===

Note that bombs do not check to see if a hole should be opened whenever a shutter is opening or closing. Beware of that.

===Free Locked Door===

If you enter a dungeon and the first room has a locked door on top then you can leave and immediately reenter to unlock that door for free!

===Walking through enemies===

If an enemy has just been hit, then Link can temporarily walk through that enemy without damage or knockback. However the enemy itself must not be knocked back or split in order for that to work. So this doesn't work against Zols or Vires. Striking a Darknut's shield also prevents this from working.

Enemies won't be knocked back if hit perpendicular to their movement direction while they're between tiles. When they're directly on a tile, they can be knocked back in any direction.

Link normally stops walking temporarily when using the sword. Exceptions to this are while stepping onto the ladder (useful in 7 after the hungry Goriya, and in 1 to steal the key from the Stalfos after the Gels), and when stepping into a door (useful in 9 when skipping the first Patra).

=== Skipping Patras ===

Walking through Patras is a special case. It turns out that the orbiting eyes of the Patra don't actually exist hitbox-wise right away. This gives you time to walk through them. This is important for being able to actually skip the first Patra in level 9, when going toward the Old Man who talks about the Next Room. It's also great for trying to skip the second Patra, on the way back from the Silver Arrows, going toward Gannon.

Note that when walking through that first Patra, there's a trick to it. You can't just walk through the door. You have to hesitate after unlocking the door, before going through, and stabbing your way through the eye that will otherwise hit you.

Skipping the second Patra going toward the Silver Arrows is a matter of getting a good pattern of movement, and getting your block clip quickly and accurately.

Sadly the Patra before Gannon cannot be skipped with present knowledge.

Additionally, in Level 9 there's a special "reverse" block clip that's very useful to get done quickly, to get out of the wizzrobe room immediately south of the Silver Arrows. It's in theory a standard block clip, but it's coming from the opposite direction most runners do a block clip from, and it's under immense time pressure.

[https://www.youtube.com/watch?v=20p65-Vn6yY Here's a video of the Patra skips and the reverse clip in level 9], from LackAttack24's 29:56 then-WR run.

=== Heart Duplication ===

Only possible in the 1.0 FDS version? https://www.youtube.com/watch?v=4iGwBE4aAzU

== Other Technical Information ==

There are a lot of small interactions and weird corner cases in this game. Here's a section of the site dedicated to them.

[[Legend of Zelda/Technical Information]]

==Fighting Bosses==

[[Legend of Zelda/Bosses]]

==Beginning Advice==

===Darkwing Duck's Impromptu Guide===

Old, but this is [https://www.twitch.tv/darkwing_duck_sda/v/50222274 an incredibly informative video].

===Zelda for Mortals===

Also old, but [https://www.twitch.tv/presjpolk/v/50217130 here is the Presjpolk followup] for beginners

Also see the Zelda Any%s Beginner Route link for a video by Jkoper

===Beginner Any% Route===

Rather than duplicate their work, I'll just link you to the [https://sites.google.com/site/zeldaanypercents/beginner-routes/blue-ring-route Zelda Any%s Blue Ring Route]

==More advanced routes==

This route benefits from the "screen scroll" but does not strictly require it. You're strongly advised at least to do the wrap into level 5, and the wrap past the lost woods, even if you don't do any others. The most important block clip you'll want to start doing is the one on the way to the Recorder.

[[The Legend of Zelda/Old Record Route]]

This route is the one that got to sub-30.

[[The Legend of Zelda/Record Route]]

This alternate route makes more advanced use of the screen scroll than the old record route, but has the benefit over the old record route in that it puts the player under less rupee pressure, as the Blue Candle is not bought. It's theoretically slower than either of the record routes, though.

[[The Legend of Zelda/Red Candle Route]]

Routing in this game is constantly updating these days, as people try more ideas. Ategenos is also trying to document some at his site [https://sites.google.com/site/zeldaanypercents/home Zelda Any Percents].

There's also Saver's [http://imgur.com/a/56TXh route tracking] maps.

==Maps==

The instructions above assume you know the overworld map, as well as where to get everything inside the dungeons themselves. For maps see [http://www.nesmaps.com NESMaps.com], including [http://www.nesmaps.com/maps/Zelda/Zelda.html dungeon maps] and a [http://www.nesmaps.com/maps/Zelda/ZeldaOverworldQ1.html fully annotated overworld map].

==Records==

See [http://www.speedrun.com/The_Legend_of_Zelda Speedrun.com]

==Randomizer!==

See [[The Legend of Zelda/Randomizer]] for mechanics and techniques specific to [https://sites.google.com/site/zeldarandomizer/ Fred Coughlin's Legend of Zelda Randomizer]

== Tools ==

[http://games.technoplaza.net/lozsrame/ Legend of Zelda save editor].

[https://github.com/helgefmi/tloz-prachack Practice Hack] in development. Shows drop counters. Later may give other useful information.

[https://pastebin.com/7KejFYTF Hitbox visualization script 1.1] by Fiskbit

[http://redcandle.us/wp-content/uploads/show-target-by-fiskbit.ips AI target viewer] by Fiskbit (in the form of an IPS patch from the PRG0 ROM)

[https://github.com/camthesaxman/zeldasource Disassembly project]

== History ==

[http://redcandle.us/wp-content/Zelda-Historical-Graphs/loz.html History of the record]

Legend of Zelda/Technical Information

2017-11-17T10:37:12Z

Fiskbit: Technical Information - Forces table of contents.

''(Note that details and naming are subject to change as more is learned; analysis of the game is ongoing)''

== Object system ==

The game allocates memory for up to 19 objects of varying types. These types and their indices are:

* #$00 - Link
* #$01-0B - dynamic objects
* #$0D - the sword
* #$0E - the sword or rod beam
* #$0F - the boomerang or the bait
* #$10-11 - flames and bombs
* #$12 - the rod or an arrow
* #$13 - and the room treasure

Dynamic objects consist of enemies, their projectiles, NPCs, and Link's ladder, and are allocated dynamically rather than having a static index. Link's weapons have their own slots so they can be used even when the enemy cap has been reached, though some share slots to limit their memory footprint, which means they can't be used at the same time. For bombs and flames, they are dynamically assigned the first free slot of the two available, so a mixture of two of these can be on the screen at once. Note that nothing is ever assigned to slot #$0C, though its timer and memory are sometimes used for other purposes.

Object data is stored in a number of arrays that are indexed with the object index. Many of these arrays are available to all objects, while some are limited to only dynamic objects and sometimes Link. The following are many of the most relevant ones:

'''$28 - object_timer''': A timer that automatically decrements each frame, usually dedicated to the object.

'''$3C - object_stun_timer''': A long timer that decrements when the long_timer_tick ($26) goes below 0, usually used to indicate an enemy is stunned by the boomerang. Because this timer can be set at any time, the first tick will usually be too short.

'''$70 - object_pos_x''': The X position of the object on the screen.

'''$84 - object_pos_y''': The Y position of the object on the screen. Note that this is considered block-aligned when ending in #$D rather than #$0. This is to give some illusion of depth by drawing objects 2 pixels higher than the block they're on (only 2 because the PPU draws sprites 1 scanline lower than their specified Y coordinate). Unfortunately, this gives rise to various bugs, such as gels popping out of zols a full block too low.

'''$98 - object_face_direction''': The direction the object is facing. Objects with grid-based movement will restrict this to the grid to avoid off-grid movement. For room treasures, this is the item ID. Like with most direction-based tracking in this game, the direction order is up, down, left, right (UDLR, most to least significant) in the low nybble.

'''$AC - object_status''': Used for many different state-related tracking for different objects. Many objects use this to track what state the AI is in. Link uses it for his attack sequences as well as entirely disabling his handling (movement and collision). Link's weapon object slots are empty when this is clear.

'''$C0 - object_knockback_direction''': Indicates which direction the object should travel when the knockback timer is set. UDLR in the low nybble. When the object has been hit, bit 7 is set to indicate that the direction needs to be sanity-checked to prevent knockback from knocking an object off-grid, and if the object doesn't reverse direction when it collides with Link, bit 6 is also set, but this appears to go unused.

'''$D3 - object_knockback_timer''': The number of movement ticks for which the object should undergo knockback. Like with standard movement, 4 ticks are consumed each frame, but the knockback speed is always 1 full pixel per tick. When this hits 0, the corresponding object_knockback_direction variable is cleared.

'''$034F - dynamic_id''': The object ID for dynamic objects. If this is 0, the slot is unoccupied, except in rare circumstances when slots are being controlled by another object (eg gleeok controlling its attached heads). ''(No index 0)''

'''$0394 - object_subgrid_offset''': The object's position along its current gridline. When sitting on a grid intersection, this will be 0, and positive (right and down) and negative (left and up) movement will increase or decrease this in lock-step with the object's pixel position. This is clamped in either direction by subgrid_offset_limit_positive ($010E) and subgrid_offset_limit_negative ($010F), which are +/-8 for Link and +/-16 for enemies, and further movement is not allowed that frame if clamped. If this is 0 or either limit after movement is complete, it is set to 0 and collision is handled.

'''$03A8 - object_subpos''': The object's subpixel position. Because grid-based objects can't move more than one direction at a time, this acts as the subpixel position for the current direction, whether horizontal or vertical. This doesn't get cleared when clamped to a grid intersection, and isn't cleared when changing directions. This results in quirks like faster movement when going diagonally by alternating positive/negative directions, or the boomerang having unpredictable speed when moving diagonally (because both directions interpret the subpos as being in their own direction). For dropped items, this variable acts as the timer (2 frames per tick).

'''$03BC - object_speed''': An object's subpixel speed per movement tick. 4 ticks are done per frame, limiting an object's speed to just under 4 pixels. Because object movement is clamped when reaching new grid intersections, an object might only move 1-3 ticks on a given frame.

'''$03D0 - object_animation_timer''': The number of frames before advancing to the next frame of the object's animation.

'''$03E4 - object_frame''': The current frame of the object's animation.

'''$03F8 - dynamic_move_direction''': The direction the object is moving in, for Link or dynamic objects. UDLR in the low nybble.

'''$0405 - dynamic_spawn_state''': The object's state when spawning or dying. ''(No index 0)''

'''$0485 - dynamic_health''': The object's current health. For some reason, object health is handled in multiples of #$10, so it can't exceed an effective value of 15. If health is 0 and an object gets hit by any weapon it's vulnerable to, it will die, even if that weapon does 0 damage. ''(No index 0)''

'''$049E - object_collision_tile''': The ID of the last tile the object collided with.

'''$04B2 - dynamic_immunities''': Flags indicating the weapons the object is immune to. These are:

* Bit 0 - sword
* Bit 1 - boomerang
* Bit 2 - arrow
* Bit 3 - bomb
* Bit 4 - rod
* Bit 5 - flame

Bits 6 and 7 appear to be unused, but are set normally set for enemies that have any immunities. ''(No index 0)''

'''$04BF - dynamic_properties''': Flags indicating properties of the object. These are:

* Bit 0 - The object's AI is responsible for drawing the object and calling weapon and Link collision functions, rather than these being done automatically after the AI has run.
* Bit 1 - The object is drawn using 1 tile, not 2.
* Bit 2 - The object's AI is responsible for drawing the object.
* Bit 3 - The object's AI is responsible for setting its own frame attributes (in $04 and $05) before calling the object drawing functions.
* Bit 4 - The object always reverses direction when colliding with an obstacle (block, wall, or screen boundary), overriding the more complicated turning behavior normally exhibited. This appears to be unused.
* Bit 5 - Disables weapon collision for the object.
* Bit 6 - Moves the object's collision center 4 pixels to the left, under the (often incorrect) assumption that thin objects are centered by being positioned 4 pixels to the right. This is why many vertical projectiles can be dodged more easily on the right.
* Bit 7 - Makes the object not reverse direction when colliding with Link.

''(No index 0)''

'''$04F0 - object_iframes''': The number of frames before the object will handle object collision again. The low two bits determine which palette the object's sprite will use.

== Forced drops ==

Some item drops can be forced and take priority over the standard drop system. Forced drops are handled by two consecutive kill counters and a bomb flag. The first counter, the ten count ($50), controls whether a forced 5 rupee is dropped. The bomb flag ($51) controls whether the ten count drop should be a bomb, instead. The second counter, the fairy count ($0627), controls whether fairies are dropped. All of these variables are cleared when Link collides with an enemy (including bubbles and even the recorder whirlwind).

When Link kills an enemy (that is, the enemy makes a dying sound), both counters are incremented. This occurs at kill time, before the dying animation. Item drops occur later, after the dying animation completes. When the drop is calculated, the game checks the counters to decide what to drop. If the fairy count is 16, then a fairy is dropped and the ten count and bomb flag are cleared. Otherwise, if the ten count is 10, either a 5 rupee is dropped if the bomb flag is clear or a bomb is dropped if the flag is set, and the ten count and bomb flag are then cleared. So, in the case of any forced drop, the ten count and bomb flag are cleared, but the fairy count is not.

Some enemies cannot drop items. Because they don't run the drop code, they also can't drop forced items, and thus won't consume the counters. These enemies are those in the no-drop group, as well as stalfos, gibdos, and like likes in slot 1 (because these enemies may be carrying the room treasure, and it would be undesirable if they dropped both the treasure and an item). We'll call these no-drop enemies.

If the ten count transitions from 9 to 10 due to a bomb kill, the bomb flag is set. The ten count cannot exceed 10 and will hold at that value even if additional kills occur before the forced item can be dropped, such as by killing a group of enemies at once or killing no-drop enemies. Once any forced drop occurs, the counter is reset to 0.

The fairy counter, however, has no hard limit. It will continue to increase with each kill. Because of this, the fairy drop can be skipped. Any drop occurring when the fairy counter is 16 will be a fairy, so killing a group of enemies to bring the count above 16 at drop time will skip the fairy. Alternatively, because no-drop enemies can't drop forced items, they can die with the counter at 16 without performing the drop. Skipping the fairy will avoid resetting the ten count and bomb flag.

Because the fairy counter isn't cleared when the drop occurs, multiple fairies can be dropped from the same count. For example, if the counter is 12 and 4 enemies are quickly killed before any of them can calculate a drop, the counter will be 16 when the drops are handled, so all 4 drops will be fairies.

Note that while the fairy counter has no hard limit, it is an 8-bit value and will overflow to 0 at 256 kills, allowing it to force more fairies at the next 16.

There are some notable special cases and edge cases with counters. These include:

'''Dodongos''': Killing a dodongo does not increment either counter, whether killed with bombs or the sword. If the dodongo is killed with a sword, however, the ten count is set to 10 and the bomb flag is set, forcing a bomb at drop time. This method of forcing the bomb can result in unexpected behavior. If Link takes a hit after killing the dodongo, but before the drop, the forced bomb will be lost. Furthermore, if the fairy count is 16 when the drop occurs, the fairy will be dropped instead of the bomb and the ten count and bomb flag will be cleared. Finally, if Link rapidly kills multiple dodongos with a sword, only one bomb will drop because the forced drop system has no way of queuing up multiple forced bombs.

'''Vulnerable unkillable enemies''': Enemies such as the manhandla core and flying gleeok heads are invincible, but actually handle weapon collision and will clear their iframes and unkill themselves each frame. This means they count as a kill every frame that a weapon is touching them. Bombing these enemies is a good way to force a bomb because it will quickly max out the ten count and set the bomb flag, but it will also be adding to the fairy counter, which could override the bomb drop when killing the boss. The old man in the dungeon also behaves this way, but because he doesn't clear his iframes, he'll only count as one kill per attack.

'''Multi-part enemies''': Manhandla's hands, gleeok's attached heads, and moldorm's and lanmola's segments each increment the consecutive counters when killed, but the death of the whole enemy does not grant an additional consecutive kill; that is, killing the last part will only add 1 to the counters, not 2. A perfect bomb on manhandla will increase the counters by 5 instead of 4, though, because the core is also hit and counts as a kill.

'''Leader enemies''': When a ringleader (such as the level 2 goriya leader) is killed, the other enemies in the room die by being directly transitioned to the dying state (by setting dynamic_spawn_state to #$10) and will not impact the consecutive counters. The ringleader itself counts as normal, however. Ghini leaders also share this same behavior (through a similar mechanism).

'''Zols''': While splitting enemies (zols and vires) don't normally count as kills when split, zols are vulnerable to an additional weapon hit on the frame they split, allowing them to be killed and counted as a consecutive kill. This is due to a bug where zols delete themselves before splitting (in case there aren't enough slots for the gels they're creating), but instead of exiting immediately afterward, their AI continues to do meaningful work on the deleted object, including collision checks. The deletion (through ClearObject at Bank7_FEB1) clears the object_iframes variable, which guarantees the zol can take a hit during this one last check. Because deletion clears the object's dynamic_id variable, the zol doesn't run again and thus can't drop an item nor increment the global counter. Its health is not cleared by ClearObject, so the weapons it collides with must do enough damage to kill it. Note that if a gel was spawned into the zol's slot, the gel will be hit, instead.

Vires are more robustly written and don't suffer from this bug.

'''Sub-frame behavior''': Because everything in the game must be handled sequentially, events handled earlier can directly impact those handled later, so the order of execution can result in surprising behavior. For example, if an enemy is killed on the same frame that multiple other enemies are dropping items, and that kill sets the fairy counter to 16, then any drops handled before the kill was registered would be normal random drops, and drops after the kill would be forced fairies, despite all of the drops happening on the same frame.

== Additional references ==

[http://userpages.monmouth.com/~colonel/videogames/zelda/moonmap.html A Moonmap for Legend of Zelda] - A technical overview of Zelda, primarily covering graphics layout, level format, and sound.

[http://www.obelisk.me.uk/6502/reference.html 6502 Instruction Reference] - The full 6502 instruction set, including cycle counts.

[http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Nesdev Wiki] - Comprehensive documentation on everything related to NES hardware behavior.
__FORCETOC__

Legend of Zelda/Technical Information

2017-11-17T10:31:08Z

Fiskbit: Adds a technical section on forced drops.

The Legend of Zelda

2017-11-16T09:31:37Z

Fiskbit: Random drops - Adds caveat about zols' gels and vires' keese.

== Version differences ==

[[The Legend of Zelda/Version Differences]]

==Categories==

===Any%===

Get to Zelda as fast as you can.

As there are no known means of getting to Zelda without defeating Gannon and taking the Triforce, and there are no known means of getting into Level 9 without all of the Triforce pieces, this means one must complete every dungeon. Items needed: Wooden Sword, Bombs, Bow, Candle, Raft, Ladder, Recorder, Bait, Arrows, Silver Arrows. Items acquired for maximum speed in current routing: Heart containers, Magic Sword.

===Swordless===

This is a challenge category. One plays the game according to the Any% rules, with two changes: No sword is allowed, and the run ends upon reaching Gannon and holding up the Triforce. Gannon cannot be killed without a sword, unlike other enemies who can be killed with Bombs, Boomerang, Arrows, Candles, or the Wand. See [[The Legend of Zelda/Swordless Route]] for information on a way to run this category.

===100%===

The category requires the player to acquire:

* 13 heart containers (for 16 total)
* Letter
* Power Bracelet
* Magic Sword
* Both bomb upgrades
* Bow
* Magic Boomerang
* Raft
* Ladder
* Recorder
* Wand
* Red Candle
* Book/Bible
* Magic Key
* Silver Arrows
* Red Ring

Items that are infinitely obtainable and consumable (such as the Bait, Red Potion, Blue Potion, Rupees, Magic Shield, keys other than the Magic Key, or the Bombs themselves) or are replaced (such as the Wooden Boomerang, the Wooden Sword, the White Sword, the Blue Ring, keys other than the Magic Key, and the Blue Candle) are not required.

==Game Mechanics and Glitches==

===Screen Scroll===

The 'screen scroll' trick is useful for getting over overworld obstacles, as well as for clipping through blocks in dungeons. That means you get to some stairs without killing all the enemies first! Here's a graphic with some pointers:

http://redcandle.us/wp-content/uploads/2012/10/screenscroll.png

Since the above chart was made, an alternate way of clipping through a block has been discovered by [https://twitter.com/hal_yotsuba はる＠よつば]. First, you get onto the pixel as in the above picture, with the top of Link's head lined up with the flat part of the block. Then, instead of doing a single-frame tap, slash the sword and press right or left. The sword slash, done correctly, will prevent you from moving. You will get the same effect as the single frame tap, so if you're positioned right, you will turn around. After the sword slash, walk through the block. This trick only works with block clips, not overworld scrolls or ladder clips.

Here's an additional quick demonstration of the pixels for the "reverse" clip:

http://redcandle.us/wp-content/uploads/reverseclip.png

===Drops===

==== Random drops ====

The enemy drops are not random. Whether they do drop an item is random, but when they do drop, here's what they'll be. The counter starts at 0, and goes up by 1 every time you kill (most) enemies. Zols' gels and vires' keese do not advance the counter. Chart via [http://tasvideos.org/2091S.html Baxter at TASVideos]<nowiki>:</nowiki>

http://redcandle.us/wp-content/uploads/2012/10/zeldaitemdropsnr2.png

====Drop Rates ====

The chance of getting a drop from group A is 80/256 = 31%.

Group B: 104/256 = 41%

Group C: 152/256 = 59%

Group D: 104/256 = 41%

==== Forced drops ====

However there are also the ''consecutive'' kill counters. Kill 10 enemies without getting hit (by an enemy, even a non-damaging bubble, or by the whirlwind from the recorder) and you'll get a forced, guaranteed 5 rupee drop from the next enemy that drops items (not in the X group). Kill the 10th enemy with a bomb instead, and instead of a 5 rupee you'll get a forced, guaranteed bomb drop!

Kill 16 enemies in a row and you get a fairy drop forced, but only if the 16th enemy is capable of dropping an item (not in the X group).

Note that if the 10th enemy does not drop items (in the X group), then killing that enemy with a bomb means the next drop that does happen will be a bomb. Killing that 10th enemy with the sword or any thing else will mean the next drop will be a rupee, even if you kill the next-dropping enemy with a bomb. It's the actual 10th enemy kill that counts, not the succeeding enemy that drops items.

However if the 16th enemy does not drop items, the fairy drop will be skipped entirely, and another one will not happen unless you get hit and the counters reset.

In some rooms that drop an item (such as the 5-Stalfos room in Level 1 that gives a key at the end), one enemy will act like it was holding the drop like a stalfos with a visible key, or a gibdo with a visible bomb. As a result, that enemy will never drop anything, and it will be able to store a forced drop and/or bypass a fairy drop, just like enemies that never drop items.

Note that splitting a Zol into two Gels, or splitting a Vire into two Keese, will not count as a kill or a consecutive kill. Killing one of those split Gels or Keese will not count as a kill for drops, but will count as a consecutive kill. Yes, there are some circumstances that are an exception to this. If the Zol/Vire is trapped against a barrier, it can sometimes trigger an extra 'kill' that way. A kill sound in place of a split sound is a hint to when this might happen.

Further note: Multiple simultaneous kills will not take you past 10 on the consecutive kill counter, per Darkwing Duck. If they would take you past 10 they leave you at 10 instead.

Advanced strategies: If a forced bomb/rupee or forced fairy drops, the consecutive counter for bombs/rupees is reset, but not the counter for fairies. So no matter how many hits you get on Manhandla with one well-placed bomb, the 10 count is reset after defeating him. The same is true of Dodongo. Likewise with a "Hippo Fairy" (going into a Patra with 7 on the consecutive counters, so that the Patra's center will be kill #16 and get a fairy), the bomb/rupee count resets to 0. Credit to Khananaphone for this discovery.

This means that if you get a forced fairy drop, the next consecutive bomb/rupee kill will not be at 20. It will be at 26. So bomb/rupee drops work in one of two methods:

# 10, (Fairy at 16), 26, 36, 46...
# 10, (Skip fairy at 16 by killing non-dropping enemy), 20, 30, 40...

Credit to Darkwing Duck for this discovery.

===Luck Manipulation===

See [[The Legend of Zelda/Luck Manipulation]]

===The Recorder===

The recorder loops you through all the dungeons you've gotten the Triforce in, sequentially, according to the direction link is facing. It has an internal counter that starts at 1. Every time you blow the recorder in a place where the whirlwind would appear (that is, in most overworld screens, but not all), the counter changes according to the direction Link is facing. If Link is facing right or up, then the counter goes up one. If Link is facing down or left, then the counter goes down one.

Note that this counter does not reset during the run.

For example, hold your right foot turnwise to the out. If Link is facing where your toes point cross-wise, then the count will be cremented.

OK, never mind that. Let's say Link has completed dungeons 1, 3, 4, and 5. If Link blows the whistle once facing down. Link will then be taken to level 5, because the count started at one, and then looped around to 5.

Let's say link then blows the whistle 3 more times while facing down. The count will go 4, 3, 1, skipping 2 since the player has not completed 2 yet, and Link will be taken to 1.

So let's go back to the first example. Link just completed Level 5, and blows the whistle twice. Once facing down, once facing right. The counter will go from 1 to 5, and then back from 5 to 1, taking Link to Level 1. This is a technique used in record runs.

===Bombing Darknuts===

Whether a Darknut blocks a bomb's explosion with its shield is determined by two things. First, the direction Link is facing when he lays the bomb. Second, the direction the Darknut is facing when the explosion hits him. If Link's position when laying the bomb is facing the direction the Darknut is looking when the bomb goes off, the bomb won't work.

Here is a graphic by Lackattack24.

http://redcandle.us/wp-content/uploads/darknuts-lackattack.png

===Bombing Walls===

Note that bombs do not check to see if a hole should be opened whenever a shutter is opening or closing. Beware of that.

===Free Locked Door===

If you enter a dungeon and the first room has a locked door on top then you can leave and immediately reenter to unlock that door for free!

===Walking through enemies===

If an enemy has just been hit, then Link can temporarily walk through that enemy without damage or knockback. However the enemy itself must not be knocked back or split in order for that to work. So this doesn't work against Zols or Vires. Striking a Darknut's shield also prevents this from working (however Darknuts do not suffer knockback unless struck in the back).

To avoid the enemy being knocked back, the enemy must be moving between tiles.

Link normally stops walking temporarily when using the sword. Exceptions to this are while stepping onto the ladder (useful in 7 after the hungry Goriya, and in 1 to steal the key from the Stalfos after the Gels), and when stepping into a door (useful in 9 when skipping the first Patra).

=== Skipping Patras ===

Walking through Patras is a special case. It turns out that the orbiting eyes of the Patra don't actually exist hitbox-wise right away. This gives you time to walk through them. This is important for being able to actually skip the first Patra in level 9, when going toward the Old Man who talks about the Next Room. It's also great for trying to skip the second Patra, on the way back from the Silver Arrows, going toward Gannon.

Note that when walking through that first Patra, there's a trick to it. You can't just walk through the door. You have to hesitate after unlocking the door, before going through, and stabbing your way through the eye that will otherwise hit you.

Skipping the second Patra going toward the Silver Arrows is a matter of getting a good pattern of movement, and getting your block clip quickly and accurately.

Sadly the Patra before Gannon cannot be skipped with present knowledge.

Additionally, in Level 9 there's a special "reverse" block clip that's very useful to get done quickly, to get out of the wizzrobe room immediately south of the Silver Arrows. It's in theory a standard block clip, but it's coming from the opposite direction most runners do a block clip from, and it's under immense time pressure.

[https://www.youtube.com/watch?v=20p65-Vn6yY Here's a video of the Patra skips and the reverse clip in level 9], from LackAttack24's 29:56 then-WR run.

=== Heart Duplication ===

Only possible in the 1.0 FDS version? https://www.youtube.com/watch?v=4iGwBE4aAzU

== Other Technical Information ==

There are a lot of small interactions and weird corner cases in this game. Here's a section of the site dedicated to them.

[[Legend of Zelda/Technical Information]]

==Fighting Bosses==

[[Legend of Zelda/Bosses]]

==Beginning Advice==

===Darkwing Duck's Impromptu Guide===

Old, but this is [https://www.twitch.tv/darkwing_duck_sda/v/50222274 an incredibly informative video].

===Zelda for Mortals===

Also old, but [https://www.twitch.tv/presjpolk/v/50217130 here is the Presjpolk followup] for beginners

Also see the Zelda Any%s Beginner Route link for a video by Jkoper

===Beginner Any% Route===

Rather than duplicate their work, I'll just link you to the [https://sites.google.com/site/zeldaanypercents/beginner-routes/blue-ring-route Zelda Any%s Blue Ring Route]

==More advanced routes==

This route benefits from the "screen scroll" but does not strictly require it. You're strongly advised at least to do the wrap into level 5, and the wrap past the lost woods, even if you don't do any others. The most important block clip you'll want to start doing is the one on the way to the Recorder.

[[The Legend of Zelda/Old Record Route]]

This route is the one that got to sub-30.

[[The Legend of Zelda/Record Route]]

This alternate route makes more advanced use of the screen scroll than the old record route, but has the benefit over the old record route in that it puts the player under less rupee pressure, as the Blue Candle is not bought. It's theoretically slower than either of the record routes, though.

[[The Legend of Zelda/Red Candle Route]]

Routing in this game is constantly updating these days, as people try more ideas. Ategenos is also trying to document some at his site [https://sites.google.com/site/zeldaanypercents/home Zelda Any Percents].

There's also Saver's [http://imgur.com/a/56TXh route tracking] maps.

==Maps==

The instructions above assume you know the overworld map, as well as where to get everything inside the dungeons themselves. For maps see [http://www.nesmaps.com NESMaps.com], including [http://www.nesmaps.com/maps/Zelda/Zelda.html dungeon maps] and a [http://www.nesmaps.com/maps/Zelda/ZeldaOverworldQ1.html fully annotated overworld map].

==Records==

See [http://www.speedrun.com/The_Legend_of_Zelda Speedrun.com]

==Randomizer!==

See [[The Legend of Zelda/Randomizer]] for mechanics and techniques specific to [https://sites.google.com/site/zeldarandomizer/ Fred Coughlin's Legend of Zelda Randomizer]

== Tools ==

[http://games.technoplaza.net/lozsrame/ Legend of Zelda save editor].

[https://github.com/helgefmi/tloz-prachack Practice Hack] in development. Shows drop counters. Later may give other useful information.

[https://pastebin.com/7KejFYTF Hitbox visualization script 1.1] by Fiskbit

[http://redcandle.us/wp-content/uploads/show-target-by-fiskbit.ips AI target viewer] by Fiskbit (in the form of an IPS patch from the PRG0 ROM)

[https://github.com/camthesaxman/zeldasource Disassembly project]

== History ==

[http://redcandle.us/wp-content/Zelda-Historical-Graphs/loz.html History of the record]

Legend of Zelda/Bosses

2017-11-14T11:37:56Z

Fiskbit: Gannon - Adds details on movement pattern and hitbox size & location. Fixes wood sword hits.

=Manhandla=

Use bombs wisely. A bomb in the center of Manhandla will kill all four petals and kill him instantly. However this is suboptimal in Level 3. What is wanted is for the bomb to be placed off center, with Manhandla moving into the explosion. This way many 'hits' are racked up on the center before he dies, generating a forced bomb drop when Manhandla finally dies.

Manhandla is vulnerable to most weapons, but cannot be Boomerang-stunned.

=Gleeok=

Cutting off the first head takes 10 hits with the wooden sword, That head will then float around. The remaining head (in Level 4) takes 6 more hits.

Many hitboxes and effects in the game skew to the side. This is particularly evident with Gleeok, whose head hitboxes skew far to the right of the sprites. This means it is best to fight Gleeok on the right half of the room. Aim just to the right of the visible sprite of the head. Yes, this hit him:

http://redcandle.us/wp-content/uploads/Gleeok-Hit.png

Gleeok can only have one fireball on screen at a time. Use this. Alternate between standing directly to Gleeok's right, and standing below Gleeok (but to the right, as explained above). When a fireball is sent one direction, use its airtime to get in hits from the other direction, and alternate.

Gleeok can only be harmed by the Wand body or the Sword.

=Digdogger=

Use bombs wisely. Shrunken Digdoggers take two bomb hits to kill. Typically one will lay a bomb, switch to Recorder, blow, immediately switch back to bombs, and finally lay a second bomb. This won't let the Digdogger pieces run away.

Prefer laying the first bomb to the left of Digdogger, as the pieces will skew to that side after the Recorder blow.

Digdogger can only be harmed after using the Recorder, after which he is vulnerable to all weapons, even the Boomerang.

When fighting a three-piece Digdogger, in an emergency you can leave the room after killing one of the three pieces. The boss will count as being killed when you return.

=Dodongo=

Use bombs wisely. Ideally one wants to get bombs from Dodongo by killing him with the sword (though that doesn't work with Swordless, so just feed him two bombs in that case).

The ideal way to kill Dodongo is to lay a bomb in front of him, a half tile off center of him so he won't eat it. When he walks into that smoke he dislikes, he will freeze. Stab him and get a guaranteed bomb.

http://redcandle.us/wp-content/uploads/Dodongo-Kill.png

But Trolldongo can be tough to get a bomb in front of. A safer approach can be to feed him a bomb to freeze him, then lay a bomb after so the smoke stuns him for the sword stab. If your bomb misses, wait for it to completely disappear before placing another or he will completely ignore the second bomb.

Dodongo is immune to all other weapons.

=Gohma=

Aim for the open spot! How fast you can kill him purely depends on the pattern you get. If he walks forward and opens, fire an arrow at the eye, and you're done.

Gohma is immune to all other weapons.

=Aquamentus=

Carefully time bombs and sword slashes so a bomb goes off between sword slashes, and you can kill him faster than with sword or bombs alone.

Aquamentus can also be killed with the Wand body and Arrows.

=Patra=

Patra has eight orbiting pieces and one core. The eight pieces will alternate between two patterns: a close orbiting pattern, and its attack pattern. Each Patra has a fixed attack pattern, one of two different options. There is the "2D" attack pattern (names courtesy Darkwing Duck), which expands into a wider version of the close orbiting pattern, and the "3D" attack pattern, which instead of expanding into a circle, skews the pieces into a constantly shifting ellipse.

Of the eight pieces, one of them is the 'master'. Kill it, and whatever pattern the Patra pieces are in, they will stay in for the remainder of the fight. That's good when the pieces are in the close orbiting pattern. If they're in the 3D attack pattern, shifting will never end and can result in crazy screen wrapping if it goes on long enough. If they're in the 2D attack pattern, the pieces will continuously expand and contract, arguably the single most dangerous Patra situation. So it can be safer to kill pieces of 2D Patras only in the contracted form (in the Any% route, only the first Patra is of that pattern).

If you get to Patra with 7 consecutive kills, and don't get hit, you can force a fairy off of the center piece. Credit to King Hippo for that strategy.

Patra is vulnerable to the Wand body, in addition to the Sword.

=Gannon=

Gannon moves toward you in a 'figure 8' type pattern. He's not just warping around crazily. In fact his movement is smooth, as seen in [https://www.youtube.com/watch?v=hsZCqlqPGmY this video by Fred] of Randomizer fame. Specifically, Gannon moves 4 blocks at a time before turning 90 degrees toward Link. He reverses direction if he runs into an obstacle. After teleporting, Gannon will finish whatever movement he was doing when he was stabbed; this can cause his pattern to become unusual by changing his alignment within the room.

After you hit him, there is a narrow window after his hit invincibility ends, but before he moves again, away from you before he starts approaching again. Hit him during that window and you can stun lock him. This works if you're hitting him in the lower-left or lower-right corners of the map, because whenever he's hit he will re-spawn in one of those two corners.

When he turns red, fire a Silver Arrow at him.

Note that you can only make him turn red with a sword (any sword, 4 hits with the Magic Sword, 8 with the White, 15(!) with the Wooden). You can only kill him with the Silver Arrow. Bombs, Wands, Arrows, nothing else will turn him red, and only the Silver Arrows will kill him when he turns red. Gannon is therefore the only enemy you cannot kill Swordless, which is why the Swordless run ends upon holding up the Triforce in Gannon's room.

Gannon has a four-tile sprite, but his 'real' position is the top-left corner sprite. That is where he fires his fireballs from, and he will never move into a position where the top-left corner sprite is in a wall or in one of the statues in the corners of the room. This makes it safer to be standing on the far left edge of the room, because it's harder to get hit by his body. Even though Gannon appears large, his actual hitbox is the same size as any standard enemy and is located in the center of his sprite, a half-block down and right of where the fireballs spawn.

If you need to manipulate Gannon's spawn (usually not needed in any% but sometimes needed in low% or if you died to Gannon), re-enter the diamond room before Gannon repeatedly. just enter the underground stairs area, and go back to the Diamond room (the one that has Like Likes, Bubbles, and Zols). Typically, if you go from start straight to Gannon (as though you already had silver arrows), re-entering that room 4 times will get the 'standard' spawn.

Here's how to fight him with the standard spawn, as used in runs such as [https://youtu.be/R7VssAcflUQ?t=36m49s this one by LackAttack24]

http://redcandle.us/wp-content/uploads/GannonStrat.png

The Legend of Zelda/Randomizer

2017-11-14T07:12:21Z

Fiskbit: Decoding Warp Stairs Order - Clarifies any-road behavior significantly.

Twitch user fcoughlin has a [https://sites.google.com/site/zeldarandomizer/ Randomizer] for the Legend of Zelda that's getting really popular to run and to race.

Big thanks to Twitch user [http://twitch.tv/catastrophe573/profile Catastrophe573] for putting together a lot of this information.

=Tutorial Video=

[https://www.twitch.tv/jkoper/v/66858825 Tutorial video by jkoper]

=Randomizer Mechanics and Glitches=

== Ganon's Cry ==

Normally Ganon makes a typical boss noise when you are adjacent to his boss room. When the layout of Level-9 is randomized this is a very useful hint! However, there are some special cases which can trick you.

First, the room with the skull layout on the floor (Ganon's normal room) will NEVER make the sound. Do not assume Ganon isn't next door!

Another case are the Patras. Their cry/roar will mask Ganon's. If you want to 'listen' in a room with a Patra you must first kill it, leave the room, and reenter the room.

== Bomb Out of Ganon's Room ==

Or any other room that has tried to lock you in! If you're stuck and don't want to defeat the enemies (or can't!) then break out the bombs!

== Triforce Room Doors ==

The room which requires you to have the Triforce to pass will NEVER contain a bomb wall. If an expected exit is "missing", such as the north exit in the 1st quest, then that wall is 100% guaranteed to be solid.

A door missing in this way is not necessarily covering Ganon or Zelda. Don't assume anything about the other side of the wall.

== Decoding Warp Stairs Order ==

The any-road shortcuts form a loop of 4 destinations, and each staircase warps you forward in the loop. From left to right, the staircases advance Link by 1, 2, and 3 screens. To see all of the destinations, just keep taking the left staircase.

== Money Making Game Abuse ==

Sometimes you just need a lot of rupees. It happens, especially in the second quest.

If a Money Making Game is anywhere near the starting screen (such as in the non-randomized 1st quest) then you can cheat by saving and reloading your game. Up-A will not work. It must be a full save and retry.

The mechanics of the game are unimportant. Just take the center choice every time.

== Skip Door Repairs ==

If you Up-A out of a door repair before the message finishes then you won't be charged anything! Of course you'll be sent back to the start when you continue. It's up to you if the time/rupees tradeoff is worth it.

== Useful Screen Wraps ==

Avoiding backtracking and taking efficient routes is very important when racing Zelda Randomizer. Here are some unusual screen wraps which save a lot of time, plus a visual reference for the first two.

=== Lost Woods Skip ===

Go one screen north of the Lost Woods. (There is a candle location here.)

Performing the screen wrap from right to left is easier if you position Link directly under the trees and use the visual guide below.

INSERT IMAGE HERE (cannot upload, need privileges)

All screen wraps work just like this one.

=== Ladder-Heart Wrap ===

This one is mentioned separately because it is unique. It requires the ladder! First, collect the heart container on the overworld which requires the stepladder.

Basically you're going to use the screen wrap technique, but in the middle of the screen while standing on the ladder. This allows you to get extra uses out of your ladder while standing on it!

INSERT IMAGE HERE

If you need to explore the green area to the left this will save a lot of walking around.

=== Top Left Reset Wrap ===

If you screen wrap out of bounds you'll be sent back to the starting screen. The only practical place to do this is in the top left corner of the overworld where Level-9 appears in the second quest.

This produces the same effect as using Up-A except that it saves your current hearts! It could be useful after exploring this corner of the world.

=== Other Useful Wraps ===

INSERT IMAGE HERE

For all of these wraps, do the standard screen wrap like the Lost Woods Skip. Beware, most of them need to be done from the center edge of the screen! If you try to use a nearby wall for visual reference then you may end up stuck inside a wall after scrolling the screen.

== Free Locked Door Extension ==

Leaving and reentering the first room of a dungeon will actually open a bomb wall OR locked door on the north side. This is especially common on levels 5, 7, and 9.

== Room Drops ==

https://docs.google.com/spreadsheets/d/1LYqWn7kiYbJ-xnnByOA6RCV7Pob1RoI-7BrHFvrRICA/edit#gid=1711498188

Legend of Zelda/Bosses

2017-11-13T12:50:17Z

Fiskbit: Gohma - Fixes typo.

=Manhandla=

Use bombs wisely. A bomb in the center of Manhandla will kill all four petals and kill him instantly. However this is suboptimal in Level 3. What is wanted is for the bomb to be placed off center, with Manhandla moving into the explosion. This way many 'hits' are racked up on the center before he dies, generating a forced bomb drop when Manhandla finally dies.

Manhandla is vulnerable to most weapons, but cannot be Boomerang-stunned.

=Gleeok=

Cutting off the first head takes 10 hits with the wooden sword, That head will then float around. The remaining head (in Level 4) takes 6 more hits.

Many hitboxes and effects in the game skew to the side. This is particularly evident with Gleeok, whose head hitboxes skew far to the right of the sprites. This means it is best to fight Gleeok on the right half of the room. Aim just to the right of the visible sprite of the head. Yes, this hit him:

http://redcandle.us/wp-content/uploads/Gleeok-Hit.png

Gleeok can only have one fireball on screen at a time. Use this. Alternate between standing directly to Gleeok's right, and standing below Gleeok (but to the right, as explained above). When a fireball is sent one direction, use its airtime to get in hits from the other direction, and alternate.

Gleeok can only be harmed by the Wand body or the Sword.

=Digdogger=

Use bombs wisely. Shrunken Digdoggers take two bomb hits to kill. Typically one will lay a bomb, switch to Recorder, blow, immediately switch back to bombs, and finally lay a second bomb. This won't let the Digdogger pieces run away.

Prefer laying the first bomb to the left of Digdogger, as the pieces will skew to that side after the Recorder blow.

Digdogger can only be harmed after using the Recorder, after which he is vulnerable to all weapons, even the Boomerang.

When fighting a three-piece Digdogger, in an emergency you can leave the room after killing one of the three pieces. The boss will count as being killed when you return.

=Dodongo=

Use bombs wisely. Ideally one wants to get bombs from Dodongo by killing him with the sword (though that doesn't work with Swordless, so just feed him two bombs in that case).

The ideal way to kill Dodongo is to lay a bomb in front of him, a half tile off center of him so he won't eat it. When he walks into that smoke he dislikes, he will freeze. Stab him and get a guaranteed bomb.

http://redcandle.us/wp-content/uploads/Dodongo-Kill.png

But Trolldongo can be tough to get a bomb in front of. A safer approach can be to feed him a bomb to freeze him, then lay a bomb after so the smoke stuns him for the sword stab. If your bomb misses, wait for it to completely disappear before placing another or he will completely ignore the second bomb.

Dodongo is immune to all other weapons.

=Gohma=

Aim for the open spot! How fast you can kill him purely depends on the pattern you get. If he walks forward and opens, fire an arrow at the eye, and you're done.

Gohma is immune to all other weapons.

=Aquamentus=

Carefully time bombs and sword slashes so a bomb goes off between sword slashes, and you can kill him faster than with sword or bombs alone.

Aquamentus can also be killed with the Wand body and Arrows.

=Patra=

Patra has eight orbiting pieces and one core. The eight pieces will alternate between two patterns: a close orbiting pattern, and its attack pattern. Each Patra has a fixed attack pattern, one of two different options. There is the "2D" attack pattern (names courtesy Darkwing Duck), which expands into a wider version of the close orbiting pattern, and the "3D" attack pattern, which instead of expanding into a circle, skews the pieces into a constantly shifting ellipse.

Of the eight pieces, one of them is the 'master'. Kill it, and whatever pattern the Patra pieces are in, they will stay in for the remainder of the fight. That's good when the pieces are in the close orbiting pattern. If they're in the 3D attack pattern, shifting will never end and can result in crazy screen wrapping if it goes on long enough. If they're in the 2D attack pattern, the pieces will continuously expand and contract, arguably the single most dangerous Patra situation. So it can be safer to kill pieces of 2D Patras only in the contracted form (in the Any% route, only the first Patra is of that pattern).

If you get to Patra with 7 consecutive kills, and don't get hit, you can force a fairy off of the center piece. Credit to King Hippo for that strategy.

Patra is vulnerable to the Wand body, in addition to the Sword.

=Gannon=

Gannon moves toward you in a 'figure 8' type pattern. He's not just warping around crazily. In fact his movement is smooth, as seen in [https://www.youtube.com/watch?v=hsZCqlqPGmY this video by Fred] of Randomizer fame.

After you hit him, there is a narrow window after his hit invincibility ends, but before he moves again, away from you before he starts approaching again. Hit him during that window and you can stun lock him. This works if you're hitting him in the lower-left or lower-right corners of the map, because whenever he's hit he will re-spawn in one of those two corners.

When he turns red, fire a Silver Arrow at him.

Note that you can only make him turn red with a sword (any sword, 4 hits with the Magic Sword, 8 with the White, 16(!) with the Wooden). You can only kill him with the Silver Arrow. Bombs, Wands, Arrows, nothing else will turn him red, and only the Silver Arrows will kill him when he turns red. Gannon is therefore the only enemy you cannot kill Swordless, which is why the Swordless run ends upon holding up the Triforce in Gannon's room.

Gannon has a four-tile sprite, but his 'real' position is the top-left corner sprite. That is where he fires his fireballs from, and he will never move into a position where the top-left corner sprite is in a wall or in one of the statues in the corners of the room. This makes it safer to be standing on the far left edge of the room, because it's harder to get hit by his body.

If you need to manipulate Gannon's spawn (usually not needed in any% but sometimes needed in low% or if you died to Gannon), re-enter the diamond room before Gannon repeatedly. just enter the underground stairs area, and go back to the Diamond room (the one that has Like Likes, Bubbles, and Zols). Typically, if you go from start straight to Gannon (as though you already had silver arrows), re-entering that room 4 times will get the 'standard' spawn.

Here's how to fight him with the standard spawn, as used in runs such as [https://youtu.be/R7VssAcflUQ?t=36m49s this one by LackAttack24]

http://redcandle.us/wp-content/uploads/GannonStrat.png

Legend of Zelda/Bosses

2017-11-13T12:48:32Z

Fiskbit: Dodongo - Adds a note to wait for missed bombs to fully clear.

=Manhandla=

Use bombs wisely. A bomb in the center of Manhandla will kill all four petals and kill him instantly. However this is suboptimal in Level 3. What is wanted is for the bomb to be placed off center, with Manhandla moving into the explosion. This way many 'hits' are racked up on the center before he dies, generating a forced bomb drop when Manhandla finally dies.

Manhandla is vulnerable to most weapons, but cannot be Boomerang-stunned.

=Gleeok=

Cutting off the first head takes 10 hits with the wooden sword, That head will then float around. The remaining head (in Level 4) takes 6 more hits.

Many hitboxes and effects in the game skew to the side. This is particularly evident with Gleeok, whose head hitboxes skew far to the right of the sprites. This means it is best to fight Gleeok on the right half of the room. Aim just to the right of the visible sprite of the head. Yes, this hit him:

http://redcandle.us/wp-content/uploads/Gleeok-Hit.png

Gleeok can only have one fireball on screen at a time. Use this. Alternate between standing directly to Gleeok's right, and standing below Gleeok (but to the right, as explained above). When a fireball is sent one direction, use its airtime to get in hits from the other direction, and alternate.

Gleeok can only be harmed by the Wand body or the Sword.

=Digdogger=

Use bombs wisely. Shrunken Digdoggers take two bomb hits to kill. Typically one will lay a bomb, switch to Recorder, blow, immediately switch back to bombs, and finally lay a second bomb. This won't let the Digdogger pieces run away.

Prefer laying the first bomb to the left of Digdogger, as the pieces will skew to that side after the Recorder blow.

Digdogger can only be harmed after using the Recorder, after which he is vulnerable to all weapons, even the Boomerang.

When fighting a three-piece Digdogger, in an emergency you can leave the room after killing one of the three pieces. The boss will count as being killed when you return.

=Dodongo=

Use bombs wisely. Ideally one wants to get bombs from Dodongo by killing him with the sword (though that doesn't work with Swordless, so just feed him two bombs in that case).

The ideal way to kill Dodongo is to lay a bomb in front of him, a half tile off center of him so he won't eat it. When he walks into that smoke he dislikes, he will freeze. Stab him and get a guaranteed bomb.

http://redcandle.us/wp-content/uploads/Dodongo-Kill.png

But Trolldongo can be tough to get a bomb in front of. A safer approach can be to feed him a bomb to freeze him, then lay a bomb after so the smoke stuns him for the sword stab. If your bomb misses, wait for it to completely disappear before placing another or he will completely ignore the second bomb.

Dodongo is immune to all other weapons.

=Gohma=

Aim for the open spot! How fast you can kill him purely depends on the pattern you get. If he walks forward and opens, fir an arrow at the eye, and you're done.

Gohma is immune to all other weapons.

=Aquamentus=

Carefully time bombs and sword slashes so a bomb goes off between sword slashes, and you can kill him faster than with sword or bombs alone.

Aquamentus can also be killed with the Wand body and Arrows.

=Patra=

Patra has eight orbiting pieces and one core. The eight pieces will alternate between two patterns: a close orbiting pattern, and its attack pattern. Each Patra has a fixed attack pattern, one of two different options. There is the "2D" attack pattern (names courtesy Darkwing Duck), which expands into a wider version of the close orbiting pattern, and the "3D" attack pattern, which instead of expanding into a circle, skews the pieces into a constantly shifting ellipse.

Of the eight pieces, one of them is the 'master'. Kill it, and whatever pattern the Patra pieces are in, they will stay in for the remainder of the fight. That's good when the pieces are in the close orbiting pattern. If they're in the 3D attack pattern, shifting will never end and can result in crazy screen wrapping if it goes on long enough. If they're in the 2D attack pattern, the pieces will continuously expand and contract, arguably the single most dangerous Patra situation. So it can be safer to kill pieces of 2D Patras only in the contracted form (in the Any% route, only the first Patra is of that pattern).

If you get to Patra with 7 consecutive kills, and don't get hit, you can force a fairy off of the center piece. Credit to King Hippo for that strategy.

Patra is vulnerable to the Wand body, in addition to the Sword.

=Gannon=

Gannon moves toward you in a 'figure 8' type pattern. He's not just warping around crazily. In fact his movement is smooth, as seen in [https://www.youtube.com/watch?v=hsZCqlqPGmY this video by Fred] of Randomizer fame.

After you hit him, there is a narrow window after his hit invincibility ends, but before he moves again, away from you before he starts approaching again. Hit him during that window and you can stun lock him. This works if you're hitting him in the lower-left or lower-right corners of the map, because whenever he's hit he will re-spawn in one of those two corners.

When he turns red, fire a Silver Arrow at him.

Note that you can only make him turn red with a sword (any sword, 4 hits with the Magic Sword, 8 with the White, 16(!) with the Wooden). You can only kill him with the Silver Arrow. Bombs, Wands, Arrows, nothing else will turn him red, and only the Silver Arrows will kill him when he turns red. Gannon is therefore the only enemy you cannot kill Swordless, which is why the Swordless run ends upon holding up the Triforce in Gannon's room.

Gannon has a four-tile sprite, but his 'real' position is the top-left corner sprite. That is where he fires his fireballs from, and he will never move into a position where the top-left corner sprite is in a wall or in one of the statues in the corners of the room. This makes it safer to be standing on the far left edge of the room, because it's harder to get hit by his body.

If you need to manipulate Gannon's spawn (usually not needed in any% but sometimes needed in low% or if you died to Gannon), re-enter the diamond room before Gannon repeatedly. just enter the underground stairs area, and go back to the Diamond room (the one that has Like Likes, Bubbles, and Zols). Typically, if you go from start straight to Gannon (as though you already had silver arrows), re-entering that room 4 times will get the 'standard' spawn.

Here's how to fight him with the standard spawn, as used in runs such as [https://youtu.be/R7VssAcflUQ?t=36m49s this one by LackAttack24]

http://redcandle.us/wp-content/uploads/GannonStrat.png

Legend of Zelda/Technical Information

2017-11-13T10:22:58Z

Fiskbit: Object system - Minor fix to specify when unused immunity bits are set.

Legend of Zelda/Technical Information

2017-11-13T09:32:15Z

Fiskbit: Object system - Minor clarification to object_iframes description.

Legend of Zelda/Technical Information

2017-11-13T09:26:57Z

Fiskbit: /* Object system */

Legend of Zelda/Technical Information

2017-11-13T06:53:48Z

Fiskbit: Adds an explanation of the object system and many of the object arrays.