The Wacky Frame Rate and Game Engine of Dr. Jekyll and Mr. Hyde (NES) - Behind the Code: Leveled Up
ฝัง
- เผยแพร่เมื่อ 23 ม.ค. 2024
- Why does the game run so fast in Level 6? Why is the frame rate so inconsistent on the NES?
If you would like to support this channel, here is a link to the Displaced Gamers Patreon page - / displacedgamers
Twitter: / displacedgamers
Facebook: / displacedgamers
Instagram: / displacedgamers
Music by:
/ hariboosx
/ @wolfandraven
#NES #Programming #Jekyll - เกม
I've never heard of a game getting FASTER when there's more work to do before. This is hilarious.
Any game that has game logic(advancing game state) tied to tick rate and rendering frame rate of the engine does it.
I can even give you an example of a game that was released just a few days ago: Tekken 8. The game runs at 60 FPS by default, no way to unlock it from inside the game. I modified the code and made it run at 120 FPS(well, any FPS you want actually), the game runs twice as fast at 120 FPS, because they advance game state on each tick of the engine. Then to fix that I made it so the game state only advances every 16.67ms(at 60 FPS), so now the game can run at high rendering frames but still tick at 60 Hz. This results in a very smooth visual experience for players and no speed up of the game. Works online, too. People are loving the mod, actually, because in the current era where we have monitors up to 500 Hz, locked 60 FPS is just not good enough anymore.
What changed here between my implementation and theirs is that theirs game logic implementation is tied to tick rate of the engine, and mine is actually tied to time: I don't care how often the engine tick is called and how many visual frames are rendered by the GPU, the game will always tick at 60 Hz no matter what, even if the engine runs at lower than 60 Hz and there's less than 60 rendering FPS.
Other few examples of games that do this are Dark Souls, Tekken 3.
Classic procrastinator that does more work just before the deadline
@@KulaGGin That's different (tying physics speed to refresh rate, but you can't change the refresh rate of an NES so it's irrelevant here - I'm talking about a game that compensates for doing more work by lagging less, but it lags less faster than the new work slows it down, so it runs faster the more it's doing). Nice work on your mod though!
@@KulaGGinSome flash games do that too. Super Mario 63 runs actually at 32 (not 30) fps but when i doubled the framerate, the speed of the game doubled too
2:20 "an interesting case study"
You missed a prime opportunity to say "Strange Case of Dr. Jekyll and Mr. Hyde", the title of the original story.
You know what's funny about that is... I thought about that parallel to the title after I had already scripted it and recorded it. Perhaps the initial words came from my subconscious mind. Perhaps the remaining words were there but were trapped inside -- held hostage by an alternate, evil personality that was....
... what were we talking about again?
The strange case study of Dr Jekyll and Mr Hyde
I’m going to have a Micronics “30 FPS is an Overachievement.” T shirt printed.
Don't forget to get a "Tiertex, we'll care about gameplay if we ever manage to reach 10 FPS" one as well. 😉
with today’s gaming 60 FPS should is an over achievement
@@nekononiaow oh now that’s a banger! I’d buy that one!!
This looks like a design adapted from an arcade machine using multiple CPUs to handle different engine tasks. Using two or even three 8-bit microprocessors simultaneously became relatively common in the mid-80's, and when you ask the question of frame processing in terms of "how do I make the most of multiple cores" you get an answer that resembles modern AAA engines: define the frame update in terms of discrete jobs that can be dispatched among multiple cores. This implementation in the AAA context has gradually progressed from "one thread each for AI, audio, physics, rendering, etc." towards buffering frames ahead of their actual display, in effect adding a controlled amount of latency in exchange for perceptual smoothness. When the load exceeds the latency threshold you get "stuttering".
Jekyll and Hyde almost delivers on the idea of scaling down a two-core design to a single CPU, but because it doesn't buffer its finished frames, it will never look smooth. This style of design has downsides for input handling, as well, since, besides the imposed latency, the pulse of controller reads is now likely to drift chaotically without additional timing and buffering logic. This kind of thing still afflicts modern games whenever they complicate their timing. A simple vsync deadline tends to still be the most straightforward thing to do, albeit it throws a lot of possible performance on the floor.
I very much doubt that inspiration from multi CPU hardware in arcade machines is the explanation for this design and for many reasons. First, at the time, few arcade machines had any kind of symmetric multi CPU setups, they were extremely rare if not totally absent. Second, console and arcade teams were almost never the same so sharing of such design would be unlikely. Finally, it's a very reasonable design even on bog standard mono CPU architectures. The only real problem in this particular implementation is twofold: first, many commands in the queue seem to be very inefficient and take more time than they should and second, timing considerations were likely not critical until late in the project. The fact that later levels tend to show more issues comfort this hypothesis: the coder(s?) likely discovered the timing inconsistencies as the game and levels got more and more complex and since they were **very** likely to be under time pressure to deliver they quickly resorted to the approximate method of padding the queue execution time with a "wasting" scheduler. They probably could have done better but most likely they were never given enough time to do so.
My own experience as a game developer (especially in the late 90s-early 00s) is that "not having enough time to code correctly" is the single most frequent explanation for many code quality and performance issues.
@@nekononiaowit's their first game tho and there's still a coin counter on the top.
It could have started as an arcade game, but the deal fell through when a lot of the game was already finished, so they pivoted to a NES release to recoup costs.
This game is a never ending source of amusement, just not in the way it was originally intended. 🤣
I remember renting this when I was a kid and I can assure you that any amusement derived is coincidental and was not intended. It was a clear instrument of torture. My father used to threaten to rent it when I misbehaved.
Wtf i've never seen such a weird system. like if the developers didn't know about vblank and tried to sync everything with CPU cycles like on some DOS games ?
Kinda funny that at the beginning of the video i thought "well that virtual machine-like queue system must be slow", but in fact it's too fast and it lags because they just wasted cycles on purpose.
I was gonna say, putting tasks into a queue sounds and executing them when ready like a reasonable solution for other programs, but not for a console video game. It's like they did this and THEN went "oh, actually we need to sync this to the video timing"
I like how it has a fairly good base for a neat design here, but just goes to town based on a poor understanding of the hardware
Agreed, it seems logical and well thought out, but nowhere near the intended use of the NES' timing. Makes me wonder if this was a port of something they started working on based on a different 6502 system or if they were just new game programmers, but experienced elsewhere.
@@BetweenTheBorders It reminds me a bit about a friend who made a fully functional interactive character sheet generator but didn't know that functions would return to it's call point.
@@informativt Reminds me of before I learned to use "gosub" instead of "goto" in BASIC. So much time and effort pointing to particular locations (I didn't know gosub, so I sure didn't know labels). Some things are just game changers once you know them.
years ago I looked at an early TAS of this game and noticed how the game seemed to start running faster in the final level. thank you for showing me why the heck that happened!
So speedrunners should try to keep a maximum of amount of things on screen to minimize lag :) That's a bit unusual.
He's going the distance... He's going for speed...
The big flaw of this system is that the counter assumes a constant load per action. If the throttle counter were to hit 0 at the same time every time, there would be no operational discrepancies. But as we know, certain actions are costlier than others, so when a high amount of cheap actions builds up and the counter drains quicker than expected, throttling ends too soon and the game speeds up.
A better solution to this would be what I would call a "cost indexing system", where actions wouldn't equally drain the counter by 1, but by an assigned value that would be larger for more expensive actions, and smaller for cheaper actions. That way the throttle counter can drain a lot more accurately, though this requires the developer to profile each and every action and grade it by cost.
Or they could just have waited let's until say 4 frames had passed since the last graphics update before making the next one. But I guess that would be too easy.
(absolutely do not quote me on this): I have heard that the NES version of Gradius 1 uses a system similar to what you are proposing to help time the sprite 0 raster split it does for the HUD at the bottom of the screen.
That kind of system works well on old school risc chips.
One thing I'd like to see in a potential future video is if there is a difference in the game engine between the Japan and US versions of Dr. Jekyll and Mr. Hyde. The Japanese release was on a UNROM cartridge and the US version is on an MMC1 cartridge with 2 levels removed. I wonder if some of the stall code was introduced/changed due to differences in accessing game data between the 2 types of cartridges in addition to game pacing.
Hmm. A lot of the RAM addresses are the same between the two versions (and that makes sense). So it is possible the performance monitoring scripts could be ported to the Japanese release. I am not sure if I will tackle this immediately, so perhaps I will at least upload the scripts to the DG github.
@@DisplacedGamersI would like to examine some part of main game code that i found in some japanese games such as snes sfa2 and some others i can't remember now.
Is this tactic known? Does it have a name? Why they choose that way? I find it complicated without reason.
On snes sfa2 the code is at c00107, it searches for 5 main routine positions.
The confusing part is that is holds each routine's stack address and registers. Why they didn't just use ram areas for these?
I found this "save session/restore session" very confusing without reason.
I have no idea what you guys are saying but I like listening anyways
"This is gonna be technical. No apologies." Man, this is the reason I have your channel on "notify me" for all videos. I love this deep dive stuff. I'm a C#/ Database integrations engineer by trade. I only understand the basics of assembly, but algorithms are the same regardless of language. I love these kind of deep dives. Thank you for posting this one.
Thanks!
I'm so fucking tired of youtubers who make some stupid smarmy joke about code being boring
Like. I'm here for a technical breakdown!!! don't just skip everything to summarize it!!! gah!!!
All of these frame rate issues could have been avoided if they had just implemented a tiny bit of communication between the NMI routine and the frame throttle handler.
If, for example, the throttle handler looped infinitely until a certain flag were set somewhere in RAM, and the NMI set that flag after a certain number of calls (for example, after counting 5 frames), the frame timing could have been consistent, regardless of action queue load (provided the NMI was counting high enough; might need additional communication to have the NMI handler count additional frames if we're not currently in the throttler code).
This feels like "baby's first timing loop." It's the kind of code I would have naively written as a kid when I was first learning to program.
Anyways, thanks for putting this video together! It was really interesting!
Although I don't have a huge sample of code for the total volume of games in the NES library, it would seem (from my research so far) that several developers have a good grasp on 6502 assembly but are lacking in NES-specific hardware knowledge. This makes perfect sense as 6502 assembly was a much more ubiquitous subject as it was used in various computing platforms, but Famicom/NES-specific documentation was likely quite limited in comparison.
How much documentation did they have for the NES? How much of it was learned from word of mouth from fellow devs? How much NES-specific knowledge was guesswork and therefore required the developer to use their "fallback knowledge" from another platform?
@@DisplacedGamers That's a good point. The developers would definitely need to know how the video timing of the NES works to arrive at my solution. If the documentation was poor, that would make things more difficult.
I think it could be even simpler without the flag, by just having a frame counter shared between the NMI handler and the frame throttle routine. The NMI handler would always increment the value of the frame counter, and the frame throttle would check if it is equal or above a certain threshold (let's say 5). When it reaches that threshold, the frame throttle would exit the loop and set the frame counter back to zero.
I wonder if that could be easily changed in the ROM.
@@jeffersonserafim2284 That's definitely one way to implement it. When I said "flag" I was really trying to leave it open ended (you're going to need that frame counter either way, so it does make sense to use it directly.)
"We just turned Jekyll and Hyde into Strider" is not a sentence I thought I would hear today. Or ever 😂
This game has JUST ENOUGH artistic integrity and purpose that I'm willing to believe that the "game speeds up as difficulty increases" thing is by design, rather than a bug.
Of all the things I thought I'd hear in this video, "Reluctantly crouched at the starting line" was never even up for consideration.
Thank you for going the distance and creating great content, you're one of my favorite channels!
Thanks!
Geese need HUGS
Same, the surprise Cake reference made me shriek slightly and startle my cat 😅
I really appreciate your GUI for showing what you're talking about, it all seems like magic.
Thank you. I use it during the research phase of video development as well. It helps me keep things straight while reversing.
It's a really clever idea with a really poor implementation. To start with, they need an NMI counter instead of that random "guess" loop. I agree that the behaviour looks seriously like a design flaw.
They wrote a game around a dynamic sleep command lol.
The more I learn about this game the more I think it must have been an experiment, in both game design and development.
As always, love this series. Having a leveling up variant is just all the more better.
Now that Tetris has been 'beat', maybe you could parse through it and see where the actual crash is happening? Line Count overflow? Level Count overflow?
I think there was a video that briefly mentions that the pointers go out of range and start referencing RAM values instead of ROM lookup data... Hmm.
There is a lot of work that has been done on Tetris already. Perhaps it wouldn't be too difficult to use that in order to "quick reverse" the game and reduce research time. Hmm.
Someone else did that video. It's caused by the NMI coming in the middle of score calculations, which take a long time when you get to a high level, and using the same zero page addresses causing one of them to overwrite the other's data and crash.
The table overflow is a separate bug which leads to weird color palettes.
i like to think that being technical is essential. even if people dont know what youre talking about, it either A, makes them want to know more, B, helps them understand by using the concept and talking as if they do know makes people feel smarter.
i mean it helps me. i am not a programmer but i am sorta understanding how NES games and such are working now. i also am getting a better understanding of coding(not that i would be able to write any without being taught though).
Don't have any experience in programming or game development or computer science, but these videos always feel so easy to understand and follow along with (which I can't say for a lot of other videos that dive deep into this kind of technical stuff).
I like how you show exactly what the code is doing by actually playing the game with the altered code and creating custom overlays.
Thank you for this comment. I always love to receive this sort of feedback as it gives me a reality check. I enjoy making content I know other programmers will enjoy, but I also want that content to have as much universal appeal as it can.
@@DisplacedGamersyou do a very good job at explaining these things. I couldn't program my way out of a paper bag, but I like watching these videos and feel like I understand nine tenths.
If Retro Game Mechanics Explained is an Appetizer then this is the main course. Sprinkle in some other channels of speedrunning, TAS and even game development and you got a nice video game education full course meal to boot.
Love these channels going deep into these games.
I see a new Displaced Gamers video, I click.
Always!
There's no other option.
The unthrottled game looks like a fast forwarding VHS tape hehe
You did an excellent job delving into how Jekyll and Hyde works, through the video the devs seemed almost competent. Good work!
Seeing how complicated some of this code is, it's amazing that software runs at all.
Its not that strange, a lot of games use "I assume game logic will always take the same amount of time to run", this one is even better than the most, since it adds delays, which implies that devs just didnt know how to check framerate. Works on my machine ™
DG: "I'd recommend three tacos for this one, let's get started."
Me, coincidentally eating three tacos for dinner tonight, with a taco halfway to my mouth: **Freeze**
Love these technical videos. I've dabbled in some 6502 programming so seeing how everything works behind the scenes of some games is really fascinating!
Love the deeper dives, so I'm glad to see this new series. Thanks!!
always a pleasant surprise to see a new video show up! Love your work
Thank you!
I love this new series idea! I'm a big fan of getting into the technical details, this was such an interesting watch!
"Action Queue" sounds like a day at a major theme park.
12 to 15 FPS?! my god. 😂😂😂😂 when the game runs at full/"regular" speed. WOW...fascinating how a few changes, changes how the game runs completely.
Have you ever played Super R-Type 😅 I swear that thing was 2-4 fps at times. I'd really love to see a breakdown of that one just for the slowdown reasons. Probably not much else interesting about it though.
@@computer_toucher i haven't, but I've heard about the slow down, and the qol patches people have released to make it play better (same w/ super double dragon).
Yeah it was my third game on the SNES (after SMW and F-Zero) and the slowness was horrible. Made it easier though, and even with the slowdown I could never finish it on hard - barely on normal. Haven't tried the patched ones on emulators though, but now I have a reason to :)
Gets my vote for best soundtrack though, F-Zero on 2nd@@thecunninlynguist
Your channel is one of the best available on the niche it's content belongs, with excellent production values.
Many interesting analysis in didactically fashion was produced with today's one among the greatest so far.
The FPS structure of the game and your dissection of it brought me joy!
I hope your channel keeps growing. I love this stuff.
Thank you
Love these + Talking Code
Wow! Thank you! Glad you enjoy them. More on the way.
@@DisplacedGamers Absolutely!
Really your videos. Very informative! Subscribed !
Thank you for the Cake shoutout, nicely done. 13:15
I love ALL of your videos. Keep it up!
This channel should be required learning in every high-school.
That's no exaggeration.
This is an excellent intersection of art and science.
I'm happy to know enough about NESdev to be able to follow this fully. Great video, already looking forward to the next one!
hell yes, ive been DYING for some more technical videos on this channel. definitely feel free to not hold back!
2:06 I love your dig at Micronics there. Jeremy Parish has covered a few of their games in his NES Works series, so that's how I know about them.
Heh. They churned out a few infamous titles, and I think a lot of them could likely be optimized.
Parish is just word salad. Overrated
@@videostash413 Thoroughly disagree.
@@videostash413 I would beg to differ.
@@videostash413 skill issue
This game is a treasure trove of fascinating code, and this is another great video!
A bug? Probably. Potentially an interesting game design choice? I would say yes. Under stress, I imagine for plenty of people, it would *feel* like things are starting to pile on you faster and faster, whether or not that's actually true in objective reality - and the game is, whether intending to or not, emulating that mentality (before the plug is pulled, anyway!). Now, in fairness...would I say it'd be a _good_ game design choice? Definitely up for debate, that could get ugly fast. But it could at least have the potential to be _interesting_ - if nothing else.
Although I dismissed it as a bug at the end of the video's script, I do find it very interesting regardless of if it was intentional or not. I agree with you - it is a fun debate.
I also feel the engine could be tweaked in order to keep a more consistent speed on average but still scale-up as more enemies/objects arrive.
This completely blew my mind. What a game! Thanks for doing this deep dive!
another behind the code, another great video, these never miss.
Coming from development on modern systems, this makes a lot of sense to me. Having g a queue of actions to process is like having a list of game entities to "tick". The only problem with this game is that it's made for a single processing core and/or doesn't manage its tick rate properly. I think it could work very well with a little bit of work.
Churning and burning, I yearn for more of these.
I see what you did there.
You deftly maneuver, and muscle for more?
I love the technical breakdown, I might not understand everything the more computer sciency it gets, but I enjoy hearing it and definitely appreciate visuals and breakdown of what's going on behind the scenes.
Thanks!
That Cake reference is a good way to confuse viewers under 30. I approve.
The delivery was incredible 😂
I am 30 or 40 years old and didn't catch it...
@@HelpTheWretched13:15 Here it is. I know the band because of Mission Hill personally
@@Justin240712 Oh, thanks. I knew something was up with that line but I couldn't place it.
Correction, under 30's that were raised on the wrong music
This was abaolutely fascinating. Ive never haed of an approach similar to this.
The queue reminds me of some Atari 800 code I wrote where certain actions needed to happen each frame and the rest went into a 256 byte queue that naturally looped as it was indexed. New entries were added to the next available byte and the index advanced until it matched the current queue write position. The queue ran asynchronously to the rest of the game and simply did something once the indices did not match. It would start (or continue wherever it was) at the end of the main loop and would be suspended again by the NMI handler at Vblank. As long as the important game elements happened at 60fps, modifications to the background could then spill over into the next frame(s) and no one would likely notice.
I don’t do coding, but you actually explain it well enough for me to understand the jank you are referring to
Love the Spaceballs reference at 19:00 :)
30 seconds in and I already subscribed.
Criminally underrated channel
For the algorithm. ✊
I am also doing engagement for the great lord algorithm.
😎✊
7:30 The concept of having one handler for multiple sprites, or multiple handlers for one enemy type is somewhat reminiscent of the MVVM principle in modern UI programming.
Loved the cake reference. Gave me a chuckle.
13:20 Engines pumping, and thumping in time.
The green light flashes, the flags go up.
Turning, and burning, they yearn for the cup.
Hey,I liked your behind the code videos with super Mario bros 2 and zelda 2:the adventure of link.So can make more behind the code series with super Mario bros 3 and NES final fantasy games?
I could not program a toaster but these videos always inspire me to learn how to program. Maybe 40 is a bit late too start.
It is never too late!
i liked that behind the code thing you talked about in the very beginnning
The whole "game becomes faster as the scene becomes busier" technique is actually present in Donkey Kong 64, this was the developers could compensate the bad optimization of the game and make _seem_ smooth at all times
There's one oversight however is that something as simple as the binoculars HUD *adds lag* and very infamously makes the Golden Banana inside the mechanical fish *_harder_* to obtain with the upgrade than without it
Not exactly. The game itself still slows down, just that certain entities like the player character are given extra speedvalues equal to the slowdown to make them run at normal speed at all times.
Speeding the player character up to compensate for lag was apparently a common practice at Rare; GoldenEye and Perfect Dark do it too.
Thankfully, speeding everything up when the framerate gets lower is normal nowadays, as very few newer releases slow down when the frame rate dips. (Or speed up when the framerate is above 60). I'm curious how practical it would be to keep game speed independent of frame rate on the NES, as I only have a tiny bit of 6502 knowledge and have never set up an entire game with it. Possibly storing a value of how many vertical interrupts occurred since last frame processed, then multiplying values by it?
@@Plide Modern games run at a consistent speed regardless of frame rate by multiplying all velocities by the amount of time elapsed since the previous frame. This is cheap on modern hardware, but on the NES, multiplication is expensive because the 6502 does not have a built-in multiply instruction. Add the fact that the NES doesn't give many ways to measure time with much precision, and it quickly becomes infeasible.
That said, if you add special hardware in the cartridge, it's certainly possible. For starters, you could just slap a modern CPU in there and run all of the game logic on that instead of the 6502, though personally I think it would kind of defeat the point of making an NES game. There are cartridges from the era with multipliers and timers built-in, so that might be an option, though it might still be too slow to be practical.
@@magicalgirlnicole I wonder just keeping sync with 60 or 30 is possible, with slowdown only occurring below 30 FPS. For 30 FPS, the ASL instruction can be used to double values, right?
Love these deep dives even thoiugh I can't keep up
Ooh the fabled triple-taco segment.
I've heard stories, but never thought....
i love seeing more in-depth stuff like this
So they fought hard to have the Game run at lower FPS than what NES could naturaly handle?
I am curious about something. The Star Trek 25th anniversary NES game came to mind like 4 mins ago. Back when it was featured in Nintendo Power magazine, the article referenced a cloaking device... When the game was available, that piece of the article didn't make sense... they had apparently cut it from the final game... I was wondering if they actually removed the code or just disabled it. I wonder if there is reference to it still in the code.
From the technical point of view I found this video to be easier to understand than some of the previous ones. So all in all looked about the same in the series.
Reluctantly crouched, at the starting line!
I speedrun this game from time to time and theres some really ??? type things that happen during the run when in out of bounds state is achieved and anytime after that. Id be curious to see what the heck the code is doing once that state is achieved. Theres some instant death pixels, enemies that freeze for the entire level, floating bombs, bombs that dont go off, bomb men that have only half a body, jekyll missing his head among other things i've seen so far.
Interesting.
Try to replace action 0x09 with custom one which would be synchronized to specific number of NMIs occurring. That would make frame rate consistent.
Indeed. Might be worth a try if someone wants to give it a whirl.
I would like to see you break down the hit boxes for The Little Ninja Bros. A great action RPG with JANK AS HECK hitboxes at times.
Perhaps if you replaced the stall frame routine with a Boolean flag. It checks if the queue is empty, if so set a 1 in memory and halt until NMI. NMI checks the flag, if it’s set do the draw routines and reset to zero, otherwise halt until sprite zero again and try to drain the queue more. Theory is that would end up like TMNT. It won’t be good, but it would be mostly consistent.
At first, this seems like a super clever system... and then it kind of falls apart for me since they probably could have avoided all that and just counted 4 frames every time and been TOTALLY fine. It seems like the game rarely gets to a point where it needs any more time than 4 frames, considering the speed it runs at without the throttling logic. Maybe they planned for the game to be way more complex and then scaled it back? But I think really it's just a poor understanding of the hardware they were working on, and perhaps not realizing how much power it had, or not planning ahead for it.
I feel like the game could have been written for at least 30 fps if they had a bit more knowledge of the hardware. The total waste of time waiting on the Sprite 0 hit could have squeezed in some housekeeping logic, and the total time necessary for all the various handlers isn't really that high.
And I felt the same regarding scaling back the game's complexity. I feel like they started development, made something that wasn't performing well, and then decided to add this system of "task counting" in attempt to regulate CPU work.
I've heard that Treasure Island Dizzy was the first NES game Codemasters developed, and it appears to update every 4 frames quite consistently. In the European version, they tried to fix the use of a "blacker than black" color, but I found it keeps changing back to the bad black... on every 4th frame.
An indepth about nes ghost n goblins? Ill be here for that!
4:04 THREE tacos...? I'm gonna' have to go to the store, I'll be back I guess.
Nice video, strange implementation!
Now I really want to know what the game actually does in the NMI handler though, why it takes so long, why it waits for sprite 0 hit, and why the graphics glitch if you remove the wait loop.
Aside from the standard tasks such as updating the sprites, it mostly wastes time. The two infinite loops during NMI really do perform no tasks at all except for looping. That HUD at the top of the screen is rather large, and I feel like they could have used that time to perform additional tasks before sliding into waiting on the Sprite 0 hit (used for splitting up the screen for scrolling).. The graphics glitch because the game doesn't get all the tasks for a new frame done in time (similar to Strider)
@@DisplacedGamers Thanks for the added info! But the game doesn't seem to care about syncing to vblank at all so I don't understand how it avoids glitching when run normally. Or how waiting helps make it get those tasks done in time.
Wow I could barely understand the main series 🙃 this is gonna be amazing
Ha! Well... hope you still enjoyed it!
Great explanation and very cool and weird design
Ah yes, the game that played a huge role in the creation of the AVGN
i dont know how open you guys are to suggestions, but the minecraft alpha source code was decompiled a few years ago, if you ever wanted to do a behind the code on a newer game that was written in a pretty popular language. i would love to see a "how minecraft draws blocks" or something like that.
I loved this video! ❤
well, this video really went “the distance “
Ha!
you're something else, this is great! i'm kind of hoping you wind up fixing this game and it's secretly a great game.
Not sure if this is possible compared to your normal process or would warrant a separate channel, but I'm curious about the mechanics of arcade games and whether it's possible for a person to beat games on one quarter/credit. You could look at beloved classics like simpsons or xmen or T2.
During the throttling, is input still processed? Can you miss inputs because of it?
13:16 "We need to choose a starting line (where we will be...reluctantly crouched)."
One might even say we're going an appropriate length value from the starting line to the finish line at a more than acceptable velocity. ;)
Would be cool to review the glitch in Legend of Zelda and the unlocking doors glitch to see if it is a glitch or a logical reason to exist.
13:16 "we need to choose a starting line, which will be reluctantly crouched" is that a Cake reference?
... yeah. Haha
You are amazing. I feel like this could be a college course.
you my favorite utuber
Is it possible that this game was a port? If so, timing things like velocities, gravity and the like would have been hard-coded already. And if the NES was a much faster machine than whatever the port was sourced from, they may have found that injecting a gigantic busy-loop into the system was a faster way to solve the timing problem than to rescale every single time-based value in the game.
I didn't see anything that would suggest it was a port, but most of this sort of thing is just me making assumptions.
Could the frame pacing have something to do with trying to normalizing frame rates between NTSC and PAL regions? Like it could waste fewer cycles on a PAL set?
That actually does make a lot of sense.
I always wanted to play this game as an adult as I was about maybe 10 or so when I played this last. Probably last time I played this game is from the video rental place called Video Den when I rented it way long before it got bulldozed ahaha
_Cries in video fundamentals._
Love that cake reference!
I wonder if there's a space somewhere in RAM to keep a simple counter. Increment it every NMI. Then change the stall routine to just keep checking that address to see if (value & 0x03 == 0) and you get a stable 4 NMI per frame every time. (Though if you miss it I guess you slow down to 8 NMI per frame but that doesn't seem likely in this game)