Hey folks! First off, A HUGE THANK YOU to everyone who liked or commented on the last video. It blew up in a way that I did not expect. Special shoutout to those who took time to write detailed specifics on stuff I was unsure/confused about. Comments like those are invaluable, especially for a project like this where I'm just sorta figuring it out as I go. Also, heads up: This and the next two episodes don't take into account a lot of the useful info that was posted in the comments. The plan is to get those episodes posted before recording the next one. In the meantime, I'll be learning from all the useful comments. Thanks again for all the positivity ✌
As someone who is very familiar with most parts of the Zelda64 codebase (I've been hacking around in the game since probably 2013, and have contributed a significant portion to the OoT Randomizer and Decomp), it's been fun watching you stumble about and get a grasp of how things work
Great content Ben! Chill vibe together with Spirit temple music aswell. Programming sure is so fascinating, even though I'm not used to this low level language.
I remember doing the same code dive when the recomp was announced as finished. It was weird feeling seeing the code behind one of the predominate games of my childhood, like I was in The Matrix and seeing behind some forbidden reality I shouldn't have access too. I think I also made Link's tunic a rainbow RGB cycle. But... I also remember there being a PC/Linux/Mac port, with OpenGL or something and a ImGui layer, which means you could use that to run this code through the debugger to see the code flow.
So the reason game state source files differ from their game state names is because the majority of source files that have symbol data will either match the original source file name, or will take on the segment name that they belong in, whereas the GameState types/functions had a documentation pass done where they were given "more sensible" names to better match what they do.
Thanks for making this. Would love at some point to see something like an "architecture overview" of how entities work in general, how they update, spawn things, destroy, pooling etc. What you called "linker logic" is often called "X Macros". The idea is you can have an array somewhere where some macro FOO is invoked many times with each line looking like FOO(arg1, arg2, arg3) etc. FOO on its own is meaningless, so what people do is define FOO to do something like "arg1" or just "arg2" etc. This way you can define all your FOO(...) lines in one file, but then generate arrays by redefining FOO to return different things before you include the file. See wikipedia for more info! It's just a convenient common C idiom to generate these arrays and also keep all the attributes of things together. I think maybe you figured this stuff out in your Navi pop-ups that were edited in but wasn't sure, so maybe that helped.
Some folks had commented about this in the previous video, but it was still a little confusing. I looked up some info and found these docs (gcc.gnu.org/onlinedocs/cpp/Concatenation.html) and your context here helps solidify it. I'm excited to see how DEFINE_GAMESTATE is redefined and used in this codebase, apparently it's an enum or gameplaystate object depending where it's being used. Neat stuff! Cheers!
@@benvillalobos Ah yes. In C/C++ the preprocessor (#define, #include, etc.) has a mechanism to concatenate two arguments passed together using ## between them. By the way you can also turn an argument into a string with a single # (you can look it). Sometimes getting these to work is a little complicated for reasons we don't have space for here lol. Thanks again for making the video
9:19 quick clarification(tho, im not a expert in oot code or how it works, but i know a thing or two), those are not all the overlays, its just one of the overlay tables, those are only the gamestate overlays, which are the top level ones, there is also the actors, particle and pause/player overlay table
It was great to watch!, btw - do you recommend writing class diagrams when going over Object-Oriented language based codebases in order to understand the code you're going over? or do you usually consider it redundant?
I’d generally recommend sticking with a notebook to sketch things out as needed-a full diagram can sometimes be overkill, but it depends on the project. In this case, there's a lot of interest in the project from both technical and non-technical folks, and I’m a visual learner, so creating diagrams is a win-win. For projects with minimal documentation, diagrams can be really helpful for others, but for fast-moving projects, keep in mind that diagrams may get outdated quickly. It couldn't hurt to give it a shot and see how it works for you. Mermaid is a great option since it’s lightweight and only needs a text editor-mermaid.live and the docs on mermaid.js are both helpful resources. Thanks for the question, and feel free to ask any more, cheers!
C Preprocessor macros can be a brain twister. (Forest Temple, anyone?) You have to recursively check everything on the right to see if there is a `#define` to match and then figure out the expansion until you can actually construct the C source that the compiler (or tokenizer; please don’t “um, actually” me) would parse / compile.
Graph is short for the Graphics System, so Graph_Update() updates the graphics system, not updating the graph. I don't believe it has anything to do with Graphs. Also, the GAMSTATE stuff and the transition of the overlays, looks like a basic FSM (Finite State Machine).
Hey folks! First off, A HUGE THANK YOU to everyone who liked or commented on the last video. It blew up in a way that I did not expect. Special shoutout to those who took time to write detailed specifics on stuff I was unsure/confused about. Comments like those are invaluable, especially for a project like this where I'm just sorta figuring it out as I go.
Also, heads up: This and the next two episodes don't take into account a lot of the useful info that was posted in the comments. The plan is to get those episodes posted before recording the next one. In the meantime, I'll be learning from all the useful comments.
Thanks again for all the positivity ✌
As someone who is very familiar with most parts of the Zelda64 codebase (I've been hacking around in the game since probably 2013, and have contributed a significant portion to the OoT Randomizer and Decomp), it's been fun watching you stumble about and get a grasp of how things work
@@mzxrules glad you’ve been enjoying, your knowledge drops have been GREATLY appreciated! 🍻
Great content Ben! Chill vibe together with Spirit temple music aswell. Programming sure is so fascinating, even though I'm not used to this low level language.
Thanks so much! Glad you enjoyed the music as well 😁
Like your observation that going through the code is like going through a Zelda dungeon.
It really does feel like each new piece of information is a small key that gets you into the next area 🔑
Please keep making more of this Zelda game series. Like, like, like!
I remember doing the same code dive when the recomp was announced as finished. It was weird feeling seeing the code behind one of the predominate games of my childhood, like I was in The Matrix and seeing behind some forbidden reality I shouldn't have access too. I think I also made Link's tunic a rainbow RGB cycle. But... I also remember there being a PC/Linux/Mac port, with OpenGL or something and a ImGui layer, which means you could use that to run this code through the debugger to see the code flow.
Thank you for uploading this ❤
Thanks for watching!
So the reason game state source files differ from their game state names is because the majority of source files that have symbol data will either match the original source file name, or will take on the segment name that they belong in, whereas the GameState types/functions had a documentation pass done where they were given "more sensible" names to better match what they do.
I figured there must have been some reason the naming turned out the way it did, thanks for the context here!
Thanks for making this. Would love at some point to see something like an "architecture overview" of how entities work in general, how they update, spawn things, destroy, pooling etc.
What you called "linker logic" is often called "X Macros". The idea is you can have an array somewhere where some macro FOO is invoked many times with each line looking like FOO(arg1, arg2, arg3) etc. FOO on its own is meaningless, so what people do is define FOO to do something like "arg1" or just "arg2" etc. This way you can define all your FOO(...) lines in one file, but then generate arrays by redefining FOO to return different things before you include the file. See wikipedia for more info! It's just a convenient common C idiom to generate these arrays and also keep all the attributes of things together. I think maybe you figured this stuff out in your Navi pop-ups that were edited in but wasn't sure, so maybe that helped.
Some folks had commented about this in the previous video, but it was still a little confusing. I looked up some info and found these docs (gcc.gnu.org/onlinedocs/cpp/Concatenation.html) and your context here helps solidify it. I'm excited to see how DEFINE_GAMESTATE is redefined and used in this codebase, apparently it's an enum or gameplaystate object depending where it's being used.
Neat stuff! Cheers!
@@benvillalobos Ah yes. In C/C++ the preprocessor (#define, #include, etc.) has a mechanism to concatenate two arguments passed together using ## between them. By the way you can also turn an argument into a string with a single # (you can look it). Sometimes getting these to work is a little complicated for reasons we don't have space for here lol. Thanks again for making the video
This is very cool. Looking forward to see the deep dive into stalfos combat AI
I don't know C very well, but this is really interesting and fun to watch! Great background video when doing some nice python code
Love this! I have only one toe dipped in coding but its still fascinating
Let’s continue digging old code 🤓❤
Can't wait until if you release another video about this!
9:19 quick clarification(tho, im not a expert in oot code or how it works, but i know a thing or two), those are not all the overlays, its just one of the overlay tables, those are only the gamestate overlays, which are the top level ones, there is also the actors, particle and pause/player overlay table
Hey, thanks for sharing a thing! I haven't seen those overlays yet.
This is awesome! Thank you for doing this!
@@CowboyCoder21 cheers!
It was great to watch!, btw - do you recommend writing class diagrams when going over Object-Oriented language based codebases in order to understand the code you're going over? or do you usually consider it redundant?
I’d generally recommend sticking with a notebook to sketch things out as needed-a full diagram can sometimes be overkill, but it depends on the project. In this case, there's a lot of interest in the project from both technical and non-technical folks, and I’m a visual learner, so creating diagrams is a win-win.
For projects with minimal documentation, diagrams can be really helpful for others, but for fast-moving projects, keep in mind that diagrams may get outdated quickly.
It couldn't hurt to give it a shot and see how it works for you. Mermaid is a great option since it’s lightweight and only needs a text editor-mermaid.live and the docs on mermaid.js are both helpful resources.
Thanks for the question, and feel free to ask any more, cheers!
Who is going to belive that level of detail including macros was just "decompiled"? the source code got leaked somehow... And I am pleased:D
C Preprocessor macros can be a brain twister. (Forest Temple, anyone?) You have to recursively check everything on the right to see if there is a `#define` to match and then figure out the expansion until you can actually construct the C source that the compiler (or tokenizer; please don’t “um, actually” me) would parse / compile.
Graph is short for the Graphics System, so Graph_Update() updates the graphics system, not updating the graph. I don't believe it has anything to do with Graphs.
Also, the GAMSTATE stuff and the transition of the overlays, looks like a basic FSM (Finite State Machine).
Subbed❤
this isnt the original source code, but its realy neet how they did htis reverse coding for it l
Probably much more readable!