I used this trick to create a 2 player co-op mode for my game. The attack button input scripts for each player are separated but their content is largely the same
Doesn't he teleport right after getting hit, though? He warps to either south corner so you can't just run up to him and spam the sword, at least not if you don't know what's happening.
I can't believe these old games were programmed in assembly. How did they do it? Did you really have to be some kind of insane whiz just to program nintendo games? Did they use some kind of reference book/chart or something?
@@blaynestaleypro There actually would be a reference book, yeah. Effectively the user manual for the microprocessor they were using, it'd have the specs, pinout, registers, and a big ol' reference for the entire instruction set, in case anyone needed to go double-check the syntax or side-effects of a given instruction. (It wouldn't be huge, but it'd likely be between 100-300 pages). Programmers might also use it to check an instruction's performance (many simple instructions would take one sub-microsecond cycle, but more complex ones like multiply, divide, memory access, or shenanigans of convenience like comparisons or arithmetic with a value in memory could easily take several. Depending on the processor you were working with, sometimes there were instructions that'd eat a dozen or more clock cycles).
actual programming work isn't even that different from this, at least debugging and bug hunting. you don't need to deal with assembly much these days, but inspecting program state as it's running, writing debug logging or visualizations, and helper scripts is very common, it's a lot of fun sometimes.
I'm only at 4:30 and as a fellow coder, I really appreciate all the effort that went into just these first 4 minutes! It's easy to tell that you're dedicated to doing a superb job - you leave no stone unturned. I really appreciate that. I look forward to seeing this channel grow. Great job, man.
For real, even just to get to the first few minutes must've required an insane amount of time working in/with various tools. Most of my reverse engineering is based around more traditional means and methods (ie: executables or shared libraries) and I've always wanted to dig more into old school code (especially regarding all the architectures and assembly language). Cheers for creating this, it's great stuff!
As the lead developer of Zelda Classic, I always enjoy seeing this type of analysis of the original game code, quirks, and bugs. Well done, and thank you.
Im trying to get into code and your behind the code series is really making this stuff look really easy. Not gonna lie, when I first looked at assembly code, I was bombarded by the countless lines. Keep up the great work.
The biggest struggle for me personally was branching. 6502 Assembly (the NES programming language) doesn't use if/elseif/else like modern languages. I would often get it backwards, especially with AND statements.
This is an example of how great hit detection works. Would you consider explaining how a game with poor hit detection works and why it feels unsatisfactory? I ran across your channel a few days ago and thoroughly enjoy the deep dives into my childhood favorites.
If we consider that maybe there was supposed to be a swinging animation to the sword, then the fact that the hitbox is slightly offset to the left and to the top respectively makes a lot more sense. Those boxes would have more overlap with the actual area of the sword swinging animation.
I always knew for a long time that the wand's melee attack was bugged as it was striking things just above me (and I sure abused this fact while fighting Darknuts alright). It was very interesting to hear this detailed explanation as to why.
Honestly I'm just seeing this video now and I really appreciate all the hard work you put into it to not only break down the code but give visual representation of what is what with LUA and Mesen. Again, it still is amazing that 35 years later the same principles apply today with 2D games ever since then. The idea that Nintendo timed individual PPU frames assembly-wise with the collision detection to such a degree is remarkable and inspiring with any modern projects I work on today.
Loved the video! It's nice to see stuff like this presented in a consumable format. I've done a lot of technical work on Zelda 1 and came to the same conclusion you did about the sword likely having a swing animation originally and using the magical sword for an angled frame. In addition to the swing being active for the rod, it's also active for both the sword and rod for item collision, allowing some pretty amazing overhead pickups. In the process of making tools for this game, I discovered various other weird things with collision. For example, all items perform collision 3 pixels higher than they should to compensate for room treasures being placed 3 pixels too low; item collision with weapons all use Link's hitbox size instead of the weapon's because Link is moved to the weapons' positions for the collision checks; beams and arrows change their hitbox shape when Link changes between horizontal and vertical direction because their size is determined the same way as the sword's and rod's; Link's collision is misaligned on the overworld because he is drawn 2 pixels lower to align better with the background graphics; and the second fire and bomb slot has bugs with burning trees and interacting with dodongos because these objects don't properly handle a second slot. Really enjoying your content so far and looking forward to what you do next. Keep up the good work!
Fun fact, link moves on a grid. He can freely move up/down or left/right, but when changing from left/right to up/down (or vice versa), link will turn and align himself with the grid. I believe this is also why the screen wrap and block clipping glitches occur (link aligning himself and collision checks not happening during alignment)
Dude, I just discovered your channel and this is the most detailed yet accessible set of retro game reverse engineering videos I've come across. You've almost singlehandedly made a lot of assembly coding concepts clearer to me. You're doing a lot right.
Even just to get to the first few minutes of this video must've required an insane amount of time working in/with various tools. Most of my reverse engineering is based around more traditional means and methods (ie: executables or shared libraries) and I've always wanted to dig more into old school code (especially regarding all the architectures and assembly language). Cheers for creating this, it's great stuff!
Even among my favorite TH-camrs, there are few instances where I would watch an entire 30+ minute video without skipping around. This is one of them. Kudos!
I am amazed by 1) the amount of work you put into documenting the disassembled code in the debugger and figuring out the general logic, 2) the fantastic features of Mesen which allowed you to do so and 3) the amount of effort required to explain all of the above in video. I cannot imagine how much time this must have required for edition and cleanup. From a fellow (game) coder -> fantastic work! Thanks. 😉
When you showed the hitbox during wind up on the magic wand animation I immediately thought of the swings from Link's Awakening. Really amazing when you can only imagine what a prototype for Zelda 1 originally looked like or could have been. I wonder why they scraped the idea of a bigger and flashier sword swing in Z1? Amazing.
Your predicition about the overhead slash seems right on the money. It all falls into place so perfectly. Would love to see a game genie code for that. Would definitely improve the combat of the OG Zelda.
I'm thinking they (tried to) get rid of it because of the directional imbalance and the Darknut issue that came with it. That and they probably thought a stabbing motion worked better with the sword and wand shots. Heck, the wand might not have been intended to do melee damage and that could've just been a leftover from reusing the sword code for it. They didn't seem to care much that it happened that way, though; something like that'd just be another serendipitous Easter egg in Miyamoto's mind like tile edge wall jumping or the Minus World in SMB-a bug that was let pass as a free secret.
This is a really neat video, thank you :) When you demonstrated the hitbox I was also immediately thinking of an overhead-swing like in Links Awakening for the gameboy. So this theory is sound to me
With the rise of RISC architectures in consumer systems (especially on Apple platforms), I started getting serious with learning assembly this year, specifically ARMv8. CISC architectures always seemed so, so complex and messy, but RISC (and ARM in particular) appeal. It's with this context (and ~20 years of programming in C, Rust, Python, etc.) that I started watching your Behind the Code videos. I appreciate that I can actually follow the code once I know what the instructions do. Bravo and please keep making videos! :)
I love seeing these tours of how old games got things accomplished (or attempted to but didn't). Very cool! Also, @3:52 where you talk about how Mesen has Lua scripting built in and the scripts can interact with the emulation: yo dawg we heard u like programming so we put a programming in ur programming so u can program while u program Also also, @4:04, "using an ancient programming method called copy/paste/tweak/repeat": am dead
You're back! I love these because in game dev these days, it's different for sure, but the principles of manipulating sprites and inputs are very similar and manipulating how and when certain things happen. And you're like, the only one who analyzes the Assembly language so widely used back then. Keep it up! I love these so much!
I love this type of content. I can't wait until we are at this point with games from 10 or 15 years after this one, getting into the source code and understanding and possibly fixing and upgrading it. It's just so much easier to learn on these NES games than PC games from 2006, so this channel is the perfect way to get into the subject.
I think one of the most interesting things regarding combat in this game is blocking, so I'd love to see a breakdown of that. In particular, the interplay between a Darknut's shield and Link's bombs is fascinating
I’ve never studied assembly code however the way you explain it is extremely easy to follow. I have great respect for the work you put in your videos. Amazing work.
Ive paused my viewing just to aay this. The offset in the magic wand when facing right has a similar effect seen on one of the ghost ai in pacman. When pacman faces down, the pink ghost follows him on a slight left instead of directly down because of a negative byte overflow
Yknow for the Wand-Melee-Bug, I had an idea. I think the reason for why the hitbox comes above his head is not that he was going to raise it to the air before pointing it toward his target, but rather he was raising it up to bring it down onto the target's head, like one would with a mace.
I've watched a bunch of these videos over the last week but the moment you called Zelda an "action adventure game" and not an action RPG is the moment I subbed.
UNFFFF another Behind the Code, gotta drop everything and immediately watch. I'm working on BASIC and then assembly on my C64, and I already know a tiny bit of both, so that makes videos like these all the more interesting. :D
I love the topic I just went through a similar rabbithole of ASM recently and I just watched LUA scripting used in the exact same way in "A Cat Explains the Sonic 1 Spike Bug" which is a similar explainer video but for Sonic 1
One of these days I am going to take the deep-dive into learning 6502 assembly and videos like these are going to be the biggest help. I eagerly await more videos like these in the future.
Did you see how they handled aligning sprites to ensure better collision detection? From what I've heard, Zelda would nudge the sprite in line with other sprites when you would change direction. Since Link can move any number of pixels, the code would put you on certain rows or columns when you turned, so you were not misaligned from the enemies.
your theory about the sword swing being in the prototype - then removed, and the 3/4 swing sword used as an icon, as such being the origin of the wand bug. Damn that was clever.
Awesome video! The code introspection was very interesting. Can you do something on map storage in zelda, and how link collides with the map data (walls and such)?
Just a guess, but it seems like the center point for the weapon, in both vertical and horizontal orientations, is chosen to be in a location that would simulate link swinging a sword in a sweeping motion, rather than stabbing with it. I think this could explain why the weapon center point isn't in the geometric center of the sword. So maybe six pixels versus seven wasn't an oversight, but a deliberate choice.
The sword swing animation theory is further supported by how high the hitbox when facing east/west. My first thought for the upward bias was that it originally had a different animation.
Before you even GOT to the 'wacky wand HD', omg... I remember and knew what was coming, lol :D I LOVED 'hitting' enemies ABOVE me... by striking downward... AWAY from them (as a kid). :D What a trip.
This is amazing stuff man -- looking forward to learning new things about these older NES games and how they function! :D I am really into data-driven code, and you can't get more data-driven than Assembly! -- Subscribed! Please make more of these kinds of collision-oriented data-design scenarios so I can reference them and share them with others!!
I don't recall the specifics of the bug, but there's a funny story to that: They actually noticed how the spell was bugged in testing, and told the programmer about it, who *then* told them that he wasn't going to fix it because an ancient spell made well before any of the innovations of the modern era being so weak made sense to him. So they tried to fix it themselves, only to find that the programmer *ciphered the source code*, so they couldn't get into it. I don't recall the specific names; not big enough of an FF fan for that, but I imagine you can find the story around the net.
@@LonelySpaceDetective I know of that story! It's actually one of the reasons i want to figure the formula. I want to understand how exactly he 'cyphered' the code. Or if there's actually any indication he did that since that story seems to be more like a rumor tbh.
Thanks for explaining the Mesen debugger. It's nice to know how to label each memory address. Is there a way to do the following: *Label and comment on watches *Instantly deactivate or delete all breakpoints *Jump to a hex address
I'm wanting to make a top down game like the first Legends of Zelda, so I've been doing an ample amount of research to how things functioned in the first game. As someone with minimal programming experience, the visualization of the hit boxes really helped a lot. My only question is how Link's hitbox works when he's facing North. When he's facing North, his wall collision hitbox seems smaller, since half of the sprite doesn't collider with the wall when you run into it when facing North. Also I never knew about the magic wand bug, that would have been very helpful to know when I was playing through and 100%ing the first Zelda game tbh 😢
It would be fascinating to try and "restore" or implement the possibly intended swing animation. It would certainly make the windup feel less like input lag and more like a proper swing like Link's Awakening.
Not in my experience. Link's stab attack often seems out of reach for me. If only he slashed like in Awakening or A Link to the Past, then I wouldn't need perfect aim all the time.
It's nice to see how debuggers change for different systems and emulators. The NES debugger has lots of nice features, yet it still shares many similarities to the N64 debugger I use. I'd love to see a video about it if you made one!
I would love to see a continuation of this with A Link to the Past and Link's Awakening. ALttP's hit detection has always been a mystery to me, especially with how it calculates different levels of "height" despite being a 2D game. LA would also be interesting since that has a jumping mechanic and it seems that your hurtbox and sword's hitbox dynamically updates during your jump animation while your wall collision box stays stuck to your ground position (as indicated by your shadow). I'm also curious on whether or not LA uses slightly modified LoZ code for some of its functions, since most enemy collision is also a 16x16 box, and the unused sword swing collision looks more similar to the one used in LA.
For a better visualization I'd suggest using a *square* 16x16 hitbox for the enemies, instead of halving the values. That's a.) what was probably originally intended, b.) includes the entire enemy sprite, c.) does not change the enemy's hitbox depending on Link's direction. That'd make the swords hitbox 8x16 not 12x16, which is half a sprite.
very nice work. just the right level of detail, though at times I wished for pseudocode instead or in addition to raw assembly. Next, perhaps dive into how the individual screens are generated from the somewhat sparse map?
I loved seeing how this all worked! Hey, could you review the sword attack from Link to the Past? I've honestly been curious about that for a long time. There is a whole sweeping arc; does the game just snapshot portions of a sweep? Does it check an arc or a box? I really want to know!
Random trivia, Sonic Spinball was coded in C, instead of assembly, to get it out on time. As a result, the game ran at 30hz instead of the normal 60hz. It is possible to write c code on the genesis and get 60fps, but they only had a very small window to make the game (Like six to nine months I wanna say) and so they chose to write the engine in C and target 30hz, letting the overhead eaten by not writing in bare metal.
@@etansivad That's kind of a shame, I'm sure more people would have appreciated the game if it ran at 60. I always had a bit of a soft spot for it, but I'd be lying if I said it felt like "blast processing"
@@TheJadeFist I don't think it's that big of a deal it ran at 30; I thought the game was a really fun hybrid between sonic and pinball. Reminded me a lot of alien crush and demon crush on TG16.
3 ปีที่แล้ว +1
I really wish you had more subscribers. Your videos are awesome, very well made and, as a fellow coder, so we'll explained! I hope you grow big, even tho usually channels that are informative/educative tend to keep to a niche audience =/
I do my disassembly and analysis in OpenOffice Calc (free open source Excel). I wrote an assembler/disassembler in a script for it, but I always start with an execution log, then fill in the blanks with the disassembler. It's already a spreadsheet, so I can add not only comments but also structured data and calculations, as well as name tables for variables and types. This Mesen thing sounds like it has some awesome runtime integration, though.
It might just be that the debugger in this emulator is better than the one the developer used to write the emulator. ;-) That's some really friendly stuff there. Wish I had that for AVR... Also, I have always appreciated the level of effort some game devs go to, to handle effects like this. Keeping tracks of multiple events, and the animations involved in those events, and the guards against having incompatible things happening at the same time -- it's a ton of detail that makes for some very tedious architecting, coding, testing, and debugging. My hat's off to those guys doing this back in the late 80s without the aid of the fantastic tools at our disposal now.
That was a very, very instructive video. I do program in some middle/high level languages, but never dared to swim in the deep waters of Assembler. With your Behind the Code videos I started warming up to the idea of learning the language. Your content is really didactic. Are you a college graduate in Electronics or some Computer Science? 'Cause you sure seem to be pretty knowledgeable in both.
Thanks! I have a degree in computer science and have programmed professionally. I suppose I have had a hobby in engineering for a rather long time as well. I love all this stuff! Assembly is great. Give it a go! Choose your architecture and have fun
@@DisplacedGamers As a Sega Genesis fan, I'm very interested in the Motorola 68000. People have done wonders with the 68000 in the Genesis, the Amiga and the ST. Actually, there are unbelievable games and demos in all computers and consoles. Some talented programmers have learned how to drain every little drop of power from almost every architecture.
DG, you're the man. I absolutely love your videos. Do you ever plan on covering some of the 16 bit consoles? I would love your take on comparing console hardware of the same gen, I know its a topic thats covered a lot. But people don't realize that better hardware doesn't mean better games. The Sega Genesis despite being older and weaker held its own against other 16 bit consoles.
I would like to cover them. Mesen is a great emulator, and there is another version of it does SNES and GB. I feel like I am on a roll with NES right now, but I haven't ruled out other systems. The Sega Genesis is one that I wanted to get into even more, but I haven't found an emulator for the system that has a good layout/debugging that is convenient and fast to use. I did some work with the Genesis in the first teaser video for what turned into Behind the Code. It was manageable with the emulators I used at the time, but Mesen honestly raised the bar SO much. I also like to have some goals in mind for whatever game I select - like "Collision Detection" for LoZ. Did you have some specific actions/modifications for any particular Genesis games in mind?
I love these videos and this is all really great stuff, but I also have to say that I was at around the 10:00 mark when I was totally derailed and went: "Do I have Wolf and Raven going in another tab? No, it's this one. Is he playing Wolf and Raven? He is! Have I been listening to it for the last 10 minutes? I have! Awesome!!!" Anyways, now back to our regularly scheduled program. Content is really compelling as always.
The thing that separated worthwhile 2d platformers from shovelware licensed childrens game crap was definitely collision detection. Level design was important too and it was certainly bad in those games, but its the hit detection that rendered them unplayable. I'm watching this while I'm typing my comment so you might have said the same thing but one of the most important things in hit detection is having "big" hit boxes for things that help the player (making a jump, picking up a power up, etc) and small hitboxes for things that hurt the player (like obviously taking damage).
I don't know if it's possible, but what I've always wanted is the slash functionality from LttP and LA. It looks like having the sword's hitbox also go up to the top like the magic wand would get one step closer. But it really needs to start from 90 degrees off from where link is and move, or just be big enough. I've also always thought the stab hitbox was too short, and, yes, off center. Making it on center is great, but I'd also like it a bit longer. Unlike the above paragraph, that seems doable. The holy grail thought would be something I doubt could be done. Give me the ability to use the shield with a button. It just seems more intuitive to me. I always found combat in LoZ to be so much harder to avoid taking hits than any other game. Anything that would help with that would be welcome to me. Ooh-one more: maybe add the sword beam when you have one half heart of damage. Better yet, add it when you're down to half a heart total, as a desperation move.
I always wondered why it seemed oddly difficult to hit the spots where I knew Ganon was. Now I know, since the collision doesn't happen within the entirety of his sprite.
I have played Zelda 1 in various forms easily over 15 times. I have done multiple swordless first quest runs, which involve using the Rod a lot. I genuinely, until now, have never known about that extra hitbox on the Rod. I've noticed the jank with the sword a bit, but never anything with the Rod. Just...wow. TIL.
I felt so personally called out at "Ancient programming technique: copy, paste, tweak, repeat"
I used this trick to create a 2 player co-op mode for my game. The attack button input scripts for each player are separated but their content is largely the same
Å pp pp PP p
Hey, it's ancient because it works.
@@Outside998 tried and true
Don’t reinvent the wheel.
That was cool to show that Ganon didn't teleport.
Doesn't he teleport right after getting hit, though? He warps to either south corner so you can't just run up to him and spam the sword, at least not if you don't know what's happening.
What an amount of work to produce this video. Congratulations on the final result and thank you for it. Respect.
Thank you!
I can't believe these old games were programmed in assembly. How did they do it? Did you really have to be some kind of insane whiz just to program nintendo games? Did they use some kind of reference book/chart or something?
@@blaynestaleypro There actually would be a reference book, yeah. Effectively the user manual for the microprocessor they were using, it'd have the specs, pinout, registers, and a big ol' reference for the entire instruction set, in case anyone needed to go double-check the syntax or side-effects of a given instruction. (It wouldn't be huge, but it'd likely be between 100-300 pages). Programmers might also use it to check an instruction's performance (many simple instructions would take one sub-microsecond cycle, but more complex ones like multiply, divide, memory access, or shenanigans of convenience like comparisons or arithmetic with a value in memory could easily take several. Depending on the processor you were working with, sometimes there were instructions that'd eat a dozen or more clock cycles).
I'm not even a programmer and this was totally fascinating to me.
actual programming work isn't even that different from this, at least debugging and bug hunting. you don't need to deal with assembly much these days, but inspecting program state as it's running, writing debug logging or visualizations, and helper scripts is very common, it's a lot of fun sometimes.
@@ridespirals Except the code itself is much easier to read thanks to high-level programming languages like Java and Python.
The displaced sword hitbox is also a hint that there is a swinging animation supposed to be there.
I'm only at 4:30 and as a fellow coder, I really appreciate all the effort that went into just these first 4 minutes!
It's easy to tell that you're dedicated to doing a superb job - you leave no stone unturned. I really appreciate that. I look forward to seeing this channel grow. Great job, man.
Thanks!
For real, even just to get to the first few minutes must've required an insane amount of time working in/with various tools. Most of my reverse engineering is based around more traditional means and methods (ie: executables or shared libraries) and I've always wanted to dig more into old school code (especially regarding all the architectures and assembly language). Cheers for creating this, it's great stuff!
As the lead developer of Zelda Classic, I always enjoy seeing this type of analysis of the original game code, quirks, and bugs. Well done, and thank you.
As creator of this universe, I always enjoy seeing my human creations thanking each other and telling the truth. Thank you!
@@joefuentes2977 Look at his channel.
@@joefuentes2977thanks god
I like how each video focuses on something different. Not just a different game, but a different mechanic.
Im trying to get into code and your behind the code series is really making this stuff look really easy. Not gonna lie, when I first looked at assembly code, I was bombarded by the countless lines. Keep up the great work.
The biggest struggle for me personally was branching. 6502 Assembly (the NES programming language) doesn't use if/elseif/else like modern languages. I would often get it backwards, especially with AND statements.
Holy crap I love these Behind the Code videos so friggin much.
This is an example of how great hit detection works. Would you consider explaining how a game with poor hit detection works and why it feels unsatisfactory?
I ran across your channel a few days ago and thoroughly enjoy the deep dives into my childhood favorites.
If we consider that maybe there was supposed to be a swinging animation to the sword, then the fact that the hitbox is slightly offset to the left and to the top respectively makes a lot more sense. Those boxes would have more overlap with the actual area of the sword swinging animation.
I always knew for a long time that the wand's melee attack was bugged as it was striking things just above me (and I sure abused this fact while fighting Darknuts alright). It was very interesting to hear this detailed explanation as to why.
Honestly I'm just seeing this video now and I really appreciate all the hard work you put into it to not only break down the code but give visual representation of what is what with LUA and Mesen. Again, it still is amazing that 35 years later the same principles apply today with 2D games ever since then. The idea that Nintendo timed individual PPU frames assembly-wise with the collision detection to such a degree is remarkable and inspiring with any modern projects I work on today.
Loved the video! It's nice to see stuff like this presented in a consumable format. I've done a lot of technical work on Zelda 1 and came to the same conclusion you did about the sword likely having a swing animation originally and using the magical sword for an angled frame. In addition to the swing being active for the rod, it's also active for both the sword and rod for item collision, allowing some pretty amazing overhead pickups.
In the process of making tools for this game, I discovered various other weird things with collision. For example, all items perform collision 3 pixels higher than they should to compensate for room treasures being placed 3 pixels too low; item collision with weapons all use Link's hitbox size instead of the weapon's because Link is moved to the weapons' positions for the collision checks; beams and arrows change their hitbox shape when Link changes between horizontal and vertical direction because their size is determined the same way as the sword's and rod's; Link's collision is misaligned on the overworld because he is drawn 2 pixels lower to align better with the background graphics; and the second fire and bomb slot has bugs with burning trees and interacting with dodongos because these objects don't properly handle a second slot.
Really enjoying your content so far and looking forward to what you do next. Keep up the good work!
Fun fact, link moves on a grid. He can freely move up/down or left/right, but when changing from left/right to up/down (or vice versa), link will turn and align himself with the grid. I believe this is also why the screen wrap and block clipping glitches occur (link aligning himself and collision checks not happening during alignment)
Dude, I just discovered your channel and this is the most detailed yet accessible set of retro game reverse engineering videos I've come across. You've almost singlehandedly made a lot of assembly coding concepts clearer to me. You're doing a lot right.
Even just to get to the first few minutes of this video must've required an insane amount of time working in/with various tools. Most of my reverse engineering is based around more traditional means and methods (ie: executables or shared libraries) and I've always wanted to dig more into old school code (especially regarding all the architectures and assembly language). Cheers for creating this, it's great stuff!
Ganon sliding remembers me of good old "invisibility is the poor's man teleportation skill" in tabletop RPG ^^
Haven't gotten to that part yet but I can assume Ganon has a "blank" action frame
Even among my favorite TH-camrs, there are few instances where I would watch an entire 30+ minute video without skipping around. This is one of them. Kudos!
I am amazed by 1) the amount of work you put into documenting the disassembled code in the debugger and figuring out the general logic, 2) the fantastic features of Mesen which allowed you to do so and 3) the amount of effort required to explain all of the above in video. I cannot imagine how much time this must have required for edition and cleanup.
From a fellow (game) coder -> fantastic work! Thanks. 😉
When you showed the hitbox during wind up on the magic wand animation I immediately thought of the swings from Link's Awakening. Really amazing when you can only imagine what a prototype for Zelda 1 originally looked like or could have been. I wonder why they scraped the idea of a bigger and flashier sword swing in Z1? Amazing.
Probably because it was harder to program. Programming a projectile attack is so much easier than a sword.
Your predicition about the overhead slash seems right on the money. It all falls into place so perfectly. Would love to see a game genie code for that. Would definitely improve the combat of the OG Zelda.
I'm thinking they (tried to) get rid of it because of the directional imbalance and the Darknut issue that came with it. That and they probably thought a stabbing motion worked better with the sword and wand shots. Heck, the wand might not have been intended to do melee damage and that could've just been a leftover from reusing the sword code for it. They didn't seem to care much that it happened that way, though; something like that'd just be another serendipitous Easter egg in Miyamoto's mind like tile edge wall jumping or the Minus World in SMB-a bug that was let pass as a free secret.
Those assembly classes in college actual helped in understanding all this. This is pretty amazing.
This is a really neat video, thank you :)
When you demonstrated the hitbox I was also immediately thinking of an overhead-swing like in Links Awakening for the gameboy. So this theory is sound to me
With the rise of RISC architectures in consumer systems (especially on Apple platforms), I started getting serious with learning assembly this year, specifically ARMv8. CISC architectures always seemed so, so complex and messy, but RISC (and ARM in particular) appeal. It's with this context (and ~20 years of programming in C, Rust, Python, etc.) that I started watching your Behind the Code videos. I appreciate that I can actually follow the code once I know what the instructions do. Bravo and please keep making videos! :)
as a coder, this is amazing. all for a sword animation, i love coding these games or recoding these.
I love seeing these tours of how old games got things accomplished (or attempted to but didn't). Very cool!
Also, @3:52 where you talk about how Mesen has Lua scripting built in and the scripts can interact with the emulation: yo dawg we heard u like programming so we put a programming in ur programming so u can program while u program
Also also, @4:04, "using an ancient programming method called copy/paste/tweak/repeat": am dead
Much lulz.
You're back!
I love these because in game dev these days, it's different for sure, but the principles of manipulating sprites and inputs are very similar and manipulating how and when certain things happen.
And you're like, the only one who analyzes the Assembly language so widely used back then.
Keep it up! I love these so much!
I love this type of content. I can't wait until we are at this point with games from 10 or 15 years after this one, getting into the source code and understanding and possibly fixing and upgrading it. It's just so much easier to learn on these NES games than PC games from 2006, so this channel is the perfect way to get into the subject.
I think one of the most interesting things regarding combat in this game is blocking, so I'd love to see a breakdown of that. In particular, the interplay between a Darknut's shield and Link's bombs is fascinating
I’ve never studied assembly code however the way you explain it is extremely easy to follow. I have great respect for the work you put in your videos. Amazing work.
Easily one of the best channels on YT
One of my favorite channels
Thanks!
Ive paused my viewing just to aay this. The offset in the magic wand when facing right has a similar effect seen on one of the ghost ai in pacman. When pacman faces down, the pink ghost follows him on a slight left instead of directly down because of a negative byte overflow
Yknow for the Wand-Melee-Bug, I had an idea. I think the reason for why the hitbox comes above his head is not that he was going to raise it to the air before pointing it toward his target, but rather he was raising it up to bring it down onto the target's head, like one would with a mace.
I've watched a bunch of these videos over the last week but the moment you called Zelda an "action adventure game" and not an action RPG is the moment I subbed.
UNFFFF another Behind the Code, gotta drop everything and immediately watch. I'm working on BASIC and then assembly on my C64, and I already know a tiny bit of both, so that makes videos like these all the more interesting. :D
I am amazed you can tell what all the numbers mean. You're a wizard!
Good to see videos like this. NES code looks much harder to understand for a layman than more modern programs.
I didn't even know the wand could be used for melee attacks...
Nice choice of very fitting (80s style) music.
I love the topic I just went through a similar rabbithole of ASM recently and I just watched LUA scripting used in the exact same way in "A Cat Explains the Sonic 1 Spike Bug" which is a similar explainer video but for Sonic 1
One of these days I am going to take the deep-dive into learning 6502 assembly and videos like these are going to be the biggest help. I eagerly await more videos like these in the future.
Did you see how they handled aligning sprites to ensure better collision detection? From what I've heard, Zelda would nudge the sprite in line with other sprites when you would change direction. Since Link can move any number of pixels, the code would put you on certain rows or columns when you turned, so you were not misaligned from the enemies.
your theory about the sword swing being in the prototype - then removed, and the 3/4 swing sword used as an icon, as such being the origin of the wand bug. Damn that was clever.
explained everything very well i thought it was going to be a headache to follow along but it wasn't
Awesome video! The code introspection was very interesting. Can you do something on map storage in zelda, and how link collides with the map data (walls and such)?
Yes, I'd like to watch that too.
Geez that's a lot of work, reverse engineering assembly code sounds like hell to me
Just a guess, but it seems like the center point for the weapon, in both vertical and horizontal orientations, is chosen to be in a location that would simulate link swinging a sword in a sweeping motion, rather than stabbing with it. I think this could explain why the weapon center point isn't in the geometric center of the sword. So maybe six pixels versus seven wasn't an oversight, but a deliberate choice.
A very good point.
mmhm. yeah. mmhm. I know some of these words.
Thats a lot of information to take in. You made it easy to understand though! Great video mate! Thumbs up!
I have never played any of the Zelda games (I know!) but I did enjoy seeing the game code and the explanation on how it all works.
The sword swing animation theory is further supported by how high the hitbox when facing east/west. My first thought for the upward bias was that it originally had a different animation.
I don’t know anything about coding but these videos are always interesting. Great idea for a series.
Before you even GOT to the 'wacky wand HD', omg... I remember and knew what was coming, lol :D
I LOVED 'hitting' enemies ABOVE me... by striking downward... AWAY from them (as a kid). :D What a trip.
This is amazing stuff man -- looking forward to learning new things about these older NES games and how they function! :D
I am really into data-driven code, and you can't get more data-driven than Assembly! -- Subscribed!
Please make more of these kinds of collision-oriented data-design scenarios so I can reference them and share them with others!!
Love this channel, I've watched three videos so far and enjoyed every one of them. Thank you!
Sick man. Very cool. I would love to see you make a Zelda hack game. I bet you would do an amazing job with it. Thanks for these videos.
Love the Behind the Code series, keep it up!
What channel have I stumbled upon? A new favorite, clearly. Love the effort.
Heh that's some useful techniques. I might try to use some of it to figure out the damage formula for Final Fantasy 2's bugged Ultima spell.
I don't recall the specifics of the bug, but there's a funny story to that: They actually noticed how the spell was bugged in testing, and told the programmer about it, who *then* told them that he wasn't going to fix it because an ancient spell made well before any of the innovations of the modern era being so weak made sense to him. So they tried to fix it themselves, only to find that the programmer *ciphered the source code*, so they couldn't get into it.
I don't recall the specific names; not big enough of an FF fan for that, but I imagine you can find the story around the net.
@@LonelySpaceDetective I know of that story! It's actually one of the reasons i want to figure the formula. I want to understand how exactly he 'cyphered' the code. Or if there's actually any indication he did that since that story seems to be more like a rumor tbh.
Awesome job actually including codes in the video's. That is a really cool bonus & makes me want to try them out!
Thanks for explaining the Mesen debugger. It's nice to know how to label each memory address. Is there a way to do the following:
*Label and comment on watches
*Instantly deactivate or delete all breakpoints
*Jump to a hex address
MAN, I ABSOLUTELY LOVE THE SERIES!! Please, keep doing it! Liked and subscribed
Uncanny timing (Bismuth released an explainer about the bugs/exploits in a Zelda speed run)
Oh nice! I'll have to check it out
@@DisplacedGamers bismuth took his sweet time too god he had too much time on His hands
I'm wanting to make a top down game like the first Legends of Zelda, so I've been doing an ample amount of research to how things functioned in the first game. As someone with minimal programming experience, the visualization of the hit boxes really helped a lot. My only question is how Link's hitbox works when he's facing North. When he's facing North, his wall collision hitbox seems smaller, since half of the sprite doesn't collider with the wall when you run into it when facing North.
Also I never knew about the magic wand bug, that would have been very helpful to know when I was playing through and 100%ing the first Zelda game tbh 😢
It would be fascinating to try and "restore" or implement the possibly intended swing animation. It would certainly make the windup feel less like input lag and more like a proper swing like Link's Awakening.
zelda 1 had perfect hit detection. i never thought i was hitting someone and it didn't register. it was perfect.
Not in my experience. Link's stab attack often seems out of reach for me. If only he slashed like in Awakening or A Link to the Past, then I wouldn't need perfect aim all the time.
Amazing breakdown and analysis! Keep up the good work
It's nice to see how debuggers change for different systems and emulators. The NES debugger has lots of nice features, yet it still shares many similarities to the N64 debugger I use. I'd love to see a video about it if you made one!
Another great video letting me know how the games I grew up with worked. Thanks!
I would love to see a continuation of this with A Link to the Past and Link's Awakening.
ALttP's hit detection has always been a mystery to me, especially with how it calculates different levels of "height" despite being a 2D game.
LA would also be interesting since that has a jumping mechanic and it seems that your hurtbox and sword's hitbox dynamically updates during your jump animation while your wall collision box stays stuck to your ground position (as indicated by your shadow). I'm also curious on whether or not LA uses slightly modified LoZ code for some of its functions, since most enemy collision is also a 16x16 box, and the unused sword swing collision looks more similar to the one used in LA.
For a better visualization I'd suggest using a *square* 16x16 hitbox for the enemies, instead of halving the values. That's a.) what was probably originally intended, b.) includes the entire enemy sprite, c.) does not change the enemy's hitbox depending on Link's direction. That'd make the swords hitbox 8x16 not 12x16, which is half a sprite.
I had no idea Zelda collision detection would so interesting I'd watch half an hour video about it
I LOVE your behind the code
segments! Keep it going!
10:20
Just for the record, fighting game players have long had names for these states: Startup frames, active frames, and recovery frames.
Question... how does the wand know to light up a room if u have the magic book in inventory which allows flames to come out of the wand.
very nice work. just the right level of detail, though at times I wished for pseudocode instead or in addition to raw assembly. Next, perhaps dive into how the individual screens are generated from the somewhat sparse map?
So finally know the reason why the magic sword looks so weird. . . I am going to miss picturing link with a flamberge, though. . .
10:39 Excellent choice of background music there
I loved seeing how this all worked!
Hey, could you review the sword attack from Link to the Past? I've honestly been curious about that for a long time. There is a whole sweeping arc; does the game just snapshot portions of a sweep? Does it check an arc or a box? I really want to know!
"What is going on in a... _C_ ...of assembly code"
Random trivia, Sonic Spinball was coded in C, instead of assembly, to get it out on time. As a result, the game ran at 30hz instead of the normal 60hz. It is possible to write c code on the genesis and get 60fps, but they only had a very small window to make the game (Like six to nine months I wanna say) and so they chose to write the engine in C and target 30hz, letting the overhead eaten by not writing in bare metal.
@@etansivad That's kind of a shame, I'm sure more people would have appreciated the game if it ran at 60. I always had a bit of a soft spot for it, but I'd be lying if I said it felt like "blast processing"
@@TheJadeFist I don't think it's that big of a deal it ran at 30; I thought the game was a really fun hybrid between sonic and pinball. Reminded me a lot of alien crush and demon crush on TG16.
I really wish you had more subscribers. Your videos are awesome, very well made and, as a fellow coder, so we'll explained!
I hope you grow big, even tho usually channels that are informative/educative tend to keep to a niche audience =/
Thank you. It is definitely a lot more difficult to gain subscribers when you push deeper into technical elements.
I do my disassembly and analysis in OpenOffice Calc (free open source Excel). I wrote an assembler/disassembler in a script for it, but I always start with an execution log, then fill in the blanks with the disassembler. It's already a spreadsheet, so I can add not only comments but also structured data and calculations, as well as name tables for variables and types. This Mesen thing sounds like it has some awesome runtime integration, though.
Thank you for this great video, your recent videos have been a pleasure to watch.
Keep up the great work!
It might just be that the debugger in this emulator is better than the one the developer used to write the emulator. ;-) That's some really friendly stuff there. Wish I had that for AVR...
Also, I have always appreciated the level of effort some game devs go to, to handle effects like this. Keeping tracks of multiple events, and the animations involved in those events, and the guards against having incompatible things happening at the same time -- it's a ton of detail that makes for some very tedious architecting, coding, testing, and debugging. My hat's off to those guys doing this back in the late 80s without the aid of the fantastic tools at our disposal now.
"This wand is stupid, so let's fix it."
Btw, the routine-conflict spooked me.
Thank you so much for providing these in-depth videos!!
I'm surprised this channel doesn't have more subs. The TH-cam algorithm kinda sucks for anything meaningful
Love the background music.
Amazing video my dude
That was a very, very instructive video. I do program in some middle/high level languages, but never dared to swim in the deep waters of Assembler. With your Behind the Code videos I started warming up to the idea of learning the language. Your content is really didactic. Are you a college graduate in Electronics or some Computer Science? 'Cause you sure seem to be pretty knowledgeable in both.
Thanks!
I have a degree in computer science and have programmed professionally. I suppose I have had a hobby in engineering for a rather long time as well. I love all this stuff!
Assembly is great. Give it a go! Choose your architecture and have fun
@@DisplacedGamers As a Sega Genesis fan, I'm very interested in the Motorola 68000. People have done wonders with the 68000 in the Genesis, the Amiga and the ST. Actually, there are unbelievable games and demos in all computers and consoles. Some talented programmers have learned how to drain every little drop of power from almost every architecture.
DG, you're the man. I absolutely love your videos.
Do you ever plan on covering some of the 16 bit consoles? I would love your take on comparing console hardware of the same gen, I know its a topic thats covered a lot. But people don't realize that better hardware doesn't mean better games. The Sega Genesis despite being older and weaker held its own against other 16 bit consoles.
I would like to cover them. Mesen is a great emulator, and there is another version of it does SNES and GB. I feel like I am on a roll with NES right now, but I haven't ruled out other systems.
The Sega Genesis is one that I wanted to get into even more, but I haven't found an emulator for the system that has a good layout/debugging that is convenient and fast to use. I did some work with the Genesis in the first teaser video for what turned into Behind the Code. It was manageable with the emulators I used at the time, but Mesen honestly raised the bar SO much.
I also like to have some goals in mind for whatever game I select - like "Collision Detection" for LoZ. Did you have some specific actions/modifications for any particular Genesis games in mind?
I'd be interested in hearing about the technical magic behind Sega Channel.
I'm watching this after taking a computer architecture class and now the 6502 Assembly language actually makes sense now.
I love these videos and this is all really great stuff, but I also have to say that I was at around the 10:00 mark when I was totally derailed and went: "Do I have Wolf and Raven going in another tab? No, it's this one. Is he playing Wolf and Raven? He is! Have I been listening to it for the last 10 minutes? I have! Awesome!!!" Anyways, now back to our regularly scheduled program. Content is really compelling as always.
Love Wolf and Raven!
The thing that separated worthwhile 2d platformers from shovelware licensed childrens game crap was definitely collision detection. Level design was important too and it was certainly bad in those games, but its the hit detection that rendered them unplayable.
I'm watching this while I'm typing my comment so you might have said the same thing but one of the most important things in hit detection is having "big" hit boxes for things that help the player (making a jump, picking up a power up, etc) and small hitboxes for things that hurt the player (like obviously taking damage).
I don't know if it's possible, but what I've always wanted is the slash functionality from LttP and LA. It looks like having the sword's hitbox also go up to the top like the magic wand would get one step closer. But it really needs to start from 90 degrees off from where link is and move, or just be big enough.
I've also always thought the stab hitbox was too short, and, yes, off center. Making it on center is great, but I'd also like it a bit longer. Unlike the above paragraph, that seems doable.
The holy grail thought would be something I doubt could be done. Give me the ability to use the shield with a button. It just seems more intuitive to me.
I always found combat in LoZ to be so much harder to avoid taking hits than any other game. Anything that would help with that would be welcome to me.
Ooh-one more: maybe add the sword beam when you have one half heart of damage. Better yet, add it when you're down to half a heart total, as a desperation move.
I just discovered your channel and is AWESOME! Thank you so much for your effort making these videos!
I always wondered why it seemed oddly difficult to hit the spots where I knew Ganon was. Now I know, since the collision doesn't happen within the entirety of his sprite.
I have played Zelda 1 in various forms easily over 15 times. I have done multiple swordless first quest runs, which involve using the Rod a lot.
I genuinely, until now, have never known about that extra hitbox on the Rod. I've noticed the jank with the sword a bit, but never anything with the Rod. Just...wow. TIL.