The Wacky Frame Rate and Game Engine of Dr. Jekyll and Mr. Hyde (NES) - Behind the Code: Leveled Up

[@Patashu]

I've never heard of a game getting FASTER when there's more work to do before. This is hilarious.

[@KulaGGin]

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.

[@MrCantStopTheRobot]

Classic procrastinator that does more work just before the deadline

[@Patashu]

@@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!

[@FigureFarter]

@@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

[@otaking3582]

​@KulaGGin First of all, most people can't afford a 500 Hz monitor, so you're not helping my perception of PC gamers flaunting their wealth. Secondly, I'm reminded of a GameShark code I found for Resident Evil 3 that doubled the frame rate. It was hilarious, but it made it impossible to climb down ladders properly, thus halting my progression.

[@glenngriffon8032]

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.

[@DisplacedGamers]

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?

[@thewhitefalcon8539]

The strange case study of Dr Jekyll and Mr Hyde

[@lacroustinette5299]

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.

[@rickpgriffin]

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"

[@informativt]

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

[@BetweenTheBorders]

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.

[@informativt]

@@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.

[@BetweenTheBorders]

@@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.

[@Hatchet2k4]

This game is a never ending source of amusement, just not in the way it was originally intended. 🤣

[@cvrator]

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.

[@JH-pe3ro]

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.

[@nekononiaow]

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.

[@pocpic]

​​@@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.

[@LeftyPem]

I’m going to have a Micronics “30 FPS is an Overachievement.” T shirt printed.

[@nekononiaow]

Don't forget to get a "Tiertex, we'll care about gameplay if we ever manage to reach 10 FPS" one as well. 😉

[@IaconDawnshire]

with today’s gaming 60 FPS should is an over achievement

[@LeftyPem]

@@nekononiaow oh now that’s a banger! I’d buy that one!!

[@etansivad]

"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.

[@DisplacedGamers]

Thanks!

[@Plain--Jane]

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!!!

[@TheJobberwock]

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!

[@possible-realities]

So speedrunners should try to keep a maximum of amount of things on screen to minimize lag :) That's a bit unusual.

[@Spaztron64]

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.

[@possible-realities]

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.

[@RT55J]

(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.

[@georgerogers1166]

That kind of system works well on old school risc chips.

[@michaelcalvin42]

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!

[@DisplacedGamers]

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?

[@michaelcalvin42]

@@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.

[@jeffersonserafim2284]

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.

[@michaelcalvin42]

@@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.)

[@LMNsama]

@@DisplacedGamers Exactly, a lot of people may forget that back in the days programming for a new hardware was not always fully documented. and there was no Internet yet! so you were on your own for the most part. And companies were not gentle to tell you, "sure, you can take all the time you want to learn this hardware" ... it would be more like "it's crunch time! now code quicker!" Anyways, love your videos. Thank you.

[@Choralone422]

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.

[@DisplacedGamers]

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.

[@gizaha]

@@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.

[@aschlamishowsup]

I have no idea what you guys are saying but I like listening anyways

[@ValkyrieTiara]

"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.

[@winteringgoose]

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!

[@DisplacedGamers]

Thanks!

[@Margen67]

Geese need HUGS

[@SovrinnK]

Same, the surprise Cake reference made me shriek slightly and startle my cat 😅

[@magikman79]

He's going the distance... He's going for speed...

[@johnkelley7257]

I was hoping someone else caught that

[@PenumbraPlays]

I really appreciate your GUI for showing what you're talking about, it all seems like magic.

[@DisplacedGamers]

Thank you. I use it during the research phase of video development as well. It helps me keep things straight while reversing.

[@getreadyforthecircus]

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.

[@DisplacedGamers]

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.

[@drworm5007]

​@@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.

[@MaladyKayjo]

13:16 "we need to choose a starting line, which will be reluctantly crouched" is that a Cake reference?

[@DisplacedGamers]

... yeah. Haha

[@kri249]

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.

[@Justin240712]

Love these + Talking Code

[@DisplacedGamers]

Wow! Thank you! Glad you enjoy them. More on the way.

[@Justin240712]

@@DisplacedGamers Absolutely!

[@Cassandra_Johnson]

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.

[@Likaboss480]

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.

[@Sniperbear13]

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).

[@lipidking4113]

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!

[@gsus3918]

They wrote a game around a dynamic sleep command lol.

[@marcbarber1231]

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?

[@DisplacedGamers]

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.

[@thewhitefalcon8539]

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.

[@DatingTV]

I see a new Displaced Gamers video, I click.

[@computer_toucher]

Always!

[@kri249]

There's no other option.

[@jonothanthrace1530]

Seeing how complicated some of this code is, it's amazing that software runs at all.

[@DarkPuIse]

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**

[@l9m241]

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.

[@craigmcconomy9346]

always a pleasant surprise to see a new video show up! Love your work

[@DisplacedGamers]

Thank you!

[@fnot804]

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 ™

[@Chronosv2]

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!

[@Desmaad]

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.

[@DisplacedGamers]

Heh. They churned out a few infamous titles, and I think a lot of them could likely be optimized.

[@videostash413]

Parish is just word salad. Overrated

[@HighPriestFuneral]

@@videostash413 Thoroughly disagree.

[@Desmaad]

@@videostash413 I would beg to differ.

[@qwertzy121212]

@@videostash413 skill issue

[@danmcnaughton2886]

Thank you for the Cake shoutout, nicely done. 13:15

[@JeremyNasmith]

Love the deeper dives, so I'm glad to see this new series. Thanks!!

[@DiamondLongplays]

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.

[@typecasto]

I love this new series idea! I'm a big fan of getting into the technical details, this was such an interesting watch!

[@3rdalbum]

"Action Queue" sounds like a day at a major theme park.

[@GiuseppeGaetanoSabatelli]

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.

[@chienforcer]

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.

[@thecunninlynguist]

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.

[@computer_toucher]

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.

[@thecunninlynguist]

@@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).

[@computer_toucher]

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

[@whamer100]

hell yes, ive been DYING for some more technical videos on this channel. definitely feel free to not hold back!

[@darkknightgamer123]

Here we see Dr Jekyll and Mr Hyde experimenting with Progressive Sidescrolling by utilising polyrhythmic frame generation

[@burnte]

I hope your channel keeps growing. I love this stuff.

[@DisplacedGamers]

Thank you

[@AmaroqStarwind]

13:20 Engines pumping, and thumping in time. The green light flashes, the flags go up. Turning, and burning, they yearn for the cup.

[@Darxide23]

That Cake reference is a good way to confuse viewers under 30. I approve.

[@Justin240712]

The delivery was incredible 😂

[@HelpTheWretched]

I am 30 or 40 years old and didn't catch it...

[@Justin240712]

@@HelpTheWretched13:15 Here it is. I know the band because of Mission Hill personally

[@HelpTheWretched]

@@Justin240712 Oh, thanks. I knew something was up with that line but I couldn't place it.

[@darthdemented]

Correction, under 30's that were raised on the wrong music

[@nintentyr2355]

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.

[@DisplacedGamers]

Thanks!

[@BohepansTheThird]

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.

[@DisplacedGamers]

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.

[@justanotheryoutubechannel]

This is absolutely crazy, it’s madness to me. It wastes so many frames between each “update”, stalling and wasting time for seemingly no reason. This game genuinely could be good but this is just baffling.

[@orpheus2883]

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!

[@jckf]

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.

[@DeepWeeb]

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

[@lpfan4491]

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.

[@LonelySpaceDetective]

Speeding the player character up to compensate for lag was apparently a common practice at Rare; GoldenEye and Perfect Dark do it too.

[@Plide]

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?

[@magicalgirlnicole]

​@@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.

[@Plide]

@@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?

[@SensSword]

30 seconds in and I already subscribed.

[@frenchyproductions9692]

This game is a treasure trove of fascinating code, and this is another great video!

[@Katosepe]

This completely blew my mind. What a game! Thanks for doing this deep dive!

[@JobeStroud]

I love ALL of your videos. Keep it up!

[@apollolux]

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. ;)

[@arnpoly]

I'm happy to know enough about NESdev to be able to follow this fully. Great video, already looking forward to the next one!

[@arciks11]

So they fought hard to have the Game run at lower FPS than what NES could naturaly handle?

[@perrymeril]

... honestly given the games source material and the stress that jekyll goes through causing more and more insanity.... this seems limlke a brilliant method to handle that aspect of the source material.

[@IamR3D88]

Reluctantly crouched, at the starting line!

[@thehoodedteddy1335]

I don’t do coding, but you actually explain it well enough for me to understand the jank you are referring to

[@rory_o]

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.

[@pr3st00]

This action queue system actually looks elegant. Would you say the problem relies on how it was implemented rather than the design itself?

[@DisplacedGamers]

Yes. I think they were close to having something good. Several others have pointed out how they could have used NMI occurrences as a timing mechanism rather than guessing how much time they need to stall based on action queue load.

[@bryede]

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.

[@ldd6098]

Really your videos. Very informative! Subscribed !

[@parlancex]

Everyone knows the human eye can't see more than 2 frames per second anyway.

[@SergeyLergDev]

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.

[@cdwilliams1]

Loved the cake reference. Gave me a chuckle.

[@tylerd4884]

well, this video really went “the distance “

[@DisplacedGamers]

Ha!

[@gavinhart5643]

I was eating my third taco's and almost spit it out! At 4:04

[@partlyawesome]

another behind the code, another great video, these never miss.

[@sjodinable]

Love the Spaceballs reference at 19:00 :)

[@soviut303]

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?

[@aaendi6661]

That actually does make a lot of sense.

[@enderkatze6129]

The best part of this is that i barely understand anything

[@Bobbias]

This was abaolutely fascinating. Ive never haed of an approach similar to this.

[@ThatLuckyBear]

Me: "hmm this video isn't really for me." Also me: >>watches every second of the video likes, subscribes, and comments on it

[@DisplacedGamers]

Thanks!

[@superluig164]

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.

[@DisplacedGamers]

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.

[@BagOfMagicFood]

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.

[@danieljimenez1989]

They term subjective is misused here. You could say it's unpredictable, determined at runtime, variable, or random, whichever applies.. still a great vídeo.

[@DisplacedGamers]

Ahh sorry. I did calculations to show how things came together so we would have some values to compare at different moments in time. There is definitely some variance here - the values won't always be the same. However, I also feel that the design and implementation of frame timing was just guesswork by the programmers. They tried to get frame timing to "feel right" rather than basing it on something that happens at regular intervals such as counting NMI, for example.

[@ncrecc6040]

i miss when game programming wasn't standardized

[@Retroman8077]

Class in session, take your seats......HOW DO I REACH THESE KIDS......Mr. Escalante buy buy we will miss you finger man

[@IntegerOfDoom]

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.

[@DisplacedGamers]

It is never too late!

[@WildMatsu]

"an interesting case study" A strange case, if you will

[@DisplacedGamers]

Indeed

[@poohbear01x48]

Criminally underrated channel

[@ThatGuyNamedBender]

Babe wake up new Behind The Code just dropped!

[@PizzaCat4yhwh]

Ah yes, the game that played a huge role in the creation of the AVGN

[@TheOnlyTherazan]

All along we thought the game was slow because it was struggling to keep the pace, when it actually had tons of buffer time and just took its sweet time doing anything.

[@gamekeeper777]

Churning and burning, I yearn for more of these.

[@DisplacedGamers]

I see what you did there.

[@darthdemented]

You deftly maneuver, and muscle for more?

[@RealRedRabbit]

4:04 THREE tacos...? I'm gonna' have to go to the store, I'll be back I guess.

[@sabinsx]

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.

[@LegendBegins]

I love watching Jekyll obtain full control over reality and freezing his enemies in place.

[@SteveNeubauer]

Love these deep dives even thoiugh I can't keep up

[@LordHonkInc]

3:31 "What does this tell us?" Well, I know you're gonna explain it in the next 16 minutes, but my working theory is "shit's wack as fuck" Also, mad respect for not once making a "bee-havior" joke in the segment starting at 7:10. That's a level of professional restraint I don't think I could muster.

[@kgsws]

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.

[@DisplacedGamers]

Indeed. Might be worth a try if someone wants to give it a whirl.

[@ChicDead26]

You could write an entire book series on the inner workings of this game alone

[@nickwallette6201]

It's always interesting to see when developers are clever enough to think of a way to structure the incredibly detailed accounting of objects and flow of game logic, but not clever enough to realize that their methods and assumptions are flawed. Like, it's a strange confluence of awareness and ignorance that makes me wonder, "if you didn't understand the issues with this, how were you able to come up with it?" haha

[@Sabeythang]

With how weird Jekyll & Hyde is on a fundamental level, it makes sense that there's mysterious and inscrutiable things going on under the hood as well. The NES truly was the wild west of game development in some ways.

[@vuurniacsquarewave5091]

The number of times I went "Oh no!" while watching this video is pretty high. I've always believed in the Megaman 3-type slowdown approach as it's resilient against crashes. Eventually you have to cap the number of entities or in the case of Jekyll and Hide, the actions that are added to the queue. I've thought about capping the framerate to 30 before, so that streaming raw PCM music is possible while playing the game. I'm hogging down 50% of the CPU in each 1/60 frame so it would make sense to "buy back" that other 50% of time lost that I'd normally have by limiting the game to 30 FPS. I can essentially work with one normal 1/60 frame's worth of time that I have across 2 of such frames. Some visual updates could be free of this restriction however to make the game "appear" to be running at a full framerate, like tile animations or palette changes.

[@CAHSR2020]

_Cries in video fundamentals._

[@GeneralBolas]

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.

[@DisplacedGamers]

I didn't see anything that would suggest it was a port, but most of this sort of thing is just me making assumptions.

[@JayceeGenocide]

When I was a kid I had Deadly Towers & Dr Jeckyll & Mr Hyde 🙄🥲😢😭😭😭