I couldn't click this fast enough. You know with this channel you are always getting a well-researched and insightful video on a gem from the past. This is the best gaming channel out there that balances technical content with entertainment.
I love Chris' unique niche here, it's challenging to both do the work and then present it in a compelling way, and it's a fascinating look into "how things are made" which is something I feel like we don't always get. I help teach people to learn basic programming for simple games. In my spare time I like to clone NES games and, while not a plug for the video, I've used some of what I've learned from these videos to look into ROMs to help understand how to replicate more authentic feeling experiences. But I find that because we don't do a lot of bare metal programming anymore, and because engines are often very complex and come fully formed out of the box, that people are often uniquely mistaken in ... what a game engine even does. But I think that's because if I look up an Unreal tutorial I'm going to see a lot of package installation and IDE stuff, "is there a library or extension that does this?" is more common than, "How have other people approached this task?" That bare metal exploration of how these things are made, why they are made, how those decisions affect what they do is ... not lost, but not at the forefront of our perspective. A long winded way of saying I love this look back at a time when just getting something on screen was itself a bit of a miracle, and looking at the diverse and interesting decisions made in that pursuit. Often these games were bad in many ways, but it still took a lot of technical know-how to bring it to life.
I think it is awesome that you help teach people, and I am so glad that you do. We really are in a different era of programming these days, aren't we? My hope is that we continue to move forward in efficiency and the features we have available while still understanding what goes on under the hood.
@@DisplacedGamers I think it's awesome you reply to so many of your commenters. I agree, someone who touches Unity or Gamemaker often misunderstand the core concept of the program loop. But it makes sense, you kind of learn that by doing *this* kind of ground-up programming writing an engine. I don't necessarily think everyone needs to know how to do multiplication on a 6502 but I do think knowing makes a lot of other basic programming much easier to understand (and maybe even appreciate!)
This is such a very well done video. To a certain type of person (myself included), this is literally fascinating. I wonder if this is how my wife feels when she's transfixed watching reality TV? I really should be getting ready for my works Xmas party right now, but I can't stop watching this.
@DisplacedGamers I enjoyed every minute of it. I also may have died a little insideFF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF from seeing that update code.
I've said it before, but I love how good of an educator you are. You make it so fun to learn and understand the things that are happening behind the scenes even for someone with no programming background that just loves games. Kerp it up!
yes... YES!!! It's a good day when displace gamers has a new video. Ok, gonna get my coffee and sit down to watch this. One of the few channels that demands my full attention. I've said it before, I'll say it again, you make this crusty old database programmer's heart happy when I can *FINALLY* understand why certain games I rented as a kid were so broken (That sinking feeling of "Why did I rent this game for the weekend...?"). Strider and Contra Force have been my favorite you've done so far. Thanks for posting this one!!
Wow. Thank you! I always worry about making a longer video. Those slides take so long to make, and I question if people are still watching as I add photoshop layer number 82 to a slide past the 20 minute mark of the video.
Needs a romhacker to fix it. Hope one of them watches this and is inspired to fix it themselves. Then just add a Easy Mode and might just give it a try.
Your videos speak so coherently and authoritatively to the promethean impulse manifested in these weird electronic pieces of moving art that they meld into that impulse and become part of the canon. Really remarkable stuff, DG. You have every right to be exceedingly proud of these productions.
@@DisplacedGamers We use the jank in the speedrun to clip through walls (which appears to be completely random and out of the player control, which is 'fun'), but also if you collect all the items and game over, the attract mode starts in the location of the map you needed to go to end the game, so it gives the attract mode the congrats screen. Using the jank to our advantage.
Everyone is talking about how your videos have a perfect balance of knowledge and entertainment...and they're right lmao Idk what's going on most of the time but I'm still actively watching and enjoying these videos
If you're going to do more micronics games, please figure out how walls work in Super Pitfall. Apparently their hit collision will just fail at random.
I would love to see this explained but I also feel like between all the other micronix videos and just his videos in general, we have enough puzzle pieces to work out a fairly logical reason ourselves 😅
This was exceptional ❤ very clear, easy to digest, professional, funny, and I learned a lot. Inspired to break out Ghidra to start digging around myself!
Your videos have significantly deepened my knowledge of 6502-based programming such that I've been able to do some reverse-engineering of my own as well as modifications to code. My greatest achievement by far so far is extracting one of Action 52's "games", both PRG and CHR, and packaging it into a single, fully functional ROM file. I even chose to convert the ROM into an MMC1-based ROM with 32KB of PRG data and 16KB of CHR data and wrote custom code to bank-switch between the two CHR banks between the result screens and the main game loop.
Fantastic video as always! Actually, I'm pretty sure you would have to divide the gravity constant (if there existed such a thing) by 9, not 3. Since it's an acceleration value.
Micronics: "Well we finished that Famicom port for you." Capcom: "Great!" Micronics: "But... we had to take some liberties." Capcom: **disappointed parent stare**
Yet another banger! honestly i could watch 3 continuos hours of you doing these deep dives, like, i thought this video was very concise, even though its half an hour long...
I was waiting eagerly for this one! This' one of my favourite games of theirs and it is great to dive deep into the mess of the code that brought it to live!
31:05 I'm not sure if you're saying that's a bug (or if you're saying something else is a bug and I'm not getting it), but it's by design that Arthur can't change trajectory in mid-air
It's realistic, though it's usually not what games do that began development after Super Mario Bros. The arcade version was a very early side scrolling platformer.
@@cube2fox it became relatively uncommon after the early 80s to have fixed jumps like that but it's a mainstay of the makaimura series, it's in every entry. half the reason the games are so difficult is because you have to negotiate complex platforming obstacles with these Donkey Kong-ass jumps. you can also jump forward while shooting backward
@@mycophobia Yeah. I just looked it up, the Ghosts 'n Goblins arcade actually came out a few days ahead of Super Mario Bros. Which makes it the, as far as I know, second side scrolling platformer, after Pac Land and before Super Mario Bros.
I think what he's getting at more is there isn't any allowance for hitting left/right shortly after pressing jump; if you hit jump technically the frame before you hit left or right, you are locked into jumping straight-up, which seems like it could be annoying. I haven't played any games that did fixed jump trajectories in a while though, I couldn't say for sure if this is normal implementation or not.
@@LonelySpaceDetective i'm not sure how that would work exactly if the jump is completely fixed in height and direction, but it did make me curious as to how the jump/directional inputs work in such games. here are my undoubtedly incredibly fascinating findings: Castlevania (NES) - Jump+Direction in the same frame will make Simon jump in that direction. Direction on any frame after the jump does not work, he jumps straight up. Ghouls n Ghosts (arcade) - Same as above Ghosts n Goblins (arcade) - Simultaneous Jump+Direction does NOT work. You must hold a direction for at least one frame before jumping, otherwise Arthur still jumps straight up. This makes sense as the first game in this series has kind of notoriously sticky controls. Crouching is a pain as well.
Man, this game….when I was like 10 my sister and I had saved and pooled our allowance for a while to buy Zelda. We went to the store to get it and I wandered off to look at the toys but when we got back to the car I saw she had Ghosts and Goblins. Guess Zelda had been sold out. Ghosts and goblins, which was so hard for my younger self I used to get my console taken away after I would throw my controllers in anger. Then I had to wait months to get Zelda for Xmas.
I had the same feeling with TMNT. He 'corrected' a few of the issues with that, including the dam water level. While that was great and all I can't imagine playing it that way
I'm definitely old, but I've always found this kind of jank deeply unpleasant. Back then I didn't have the words for it, but 2D games with excessively low framerate and especially ones like this that move sprites and background separately always felt off to me.
I do enjoy your videos, Thankyou for making them. The content is very good and I used to program for the Gameboy Color back in the 1990s so a lot of the Famicom hardware is very familiar and is good to see it presented graphically. I do find the tone almost unbearably condescending at times though, I’m not sure if it is a USA thing but I don’t understand why there is a kind of annoyed attitude or ridiculing of the code. I just find it unnecessary and gets in the way of all the amazing things youve discovered and the genuine insights you’ve made along the way. I dint think there is any need to apologise for any of the code the developer wrote, but I would love to take a look at the development tools they were using back then. Even for the Gameboy Color I was able to code and test mainly on a pc emulator with a breakpoint debugger, with only a few minute compile time, a full macro assembler, a high resolution display so I could see many lines of code , and a burn to cartridge of only a few minutes. I assume their tools were no where as useful and efficient as mine where then, but I definitely made just as many bugs ! Thanks again for making your videos, they really are great!
I am glad you mentioned that you detected a condescending tone as that was not at all what I was trying to be. Let me write about it just a little bit. It is never my intention to insult the code or the people that wrote it. I am definitely aware of the tools they had available, and I am thankful that I have tools that are amazing as they are today in order to pick apart what they wrote years ago. If I had an opportunity to speak to someone that wrote any of the code I have examined, I would be excited to listen to their stories. I've also written code in a professional environment that has been compromised by the features requested, time allotted, and design changes during development. I've released stuff that I thought was terrible. This may happen because of the reasons I just listed - OR - because I just didn't have the experience at the time. We're all human. Now as for humor - My style of humor (in real life) is deadpan. I'll say something ridiculous with a straight face that is not meant to be taken seriously. I fully recognize that this is not very Internet compatible. Nevertheless, I have started to include a bit more of my personality in my TH-cam videos to boost the entertainment factor. These are heavy topics, and a 30+ minute video about tech stuff needs a few laughs. I use the humor that makes me who I am. I am 100% not insulting the people involved in the code I dissect.
@ Thankyou for the reply. The way you talk about it here, I think it is clear that I’m just misreading your tone sometimes, it might just be me picking up on something that’s not even there. I feel rude now for mentioning it, but it sounds like you appreciated the feedback anyway :) Thanks again for all these amazing videos, you’ve actually inspired me to try and disassemble a ROM, it looks a lot of fun how you puzzle out where the variables and routines are.
@@DisplacedGamersfantastic dialogue to see going on in here. Keep up the good work DG, the content is great as it is, tonally, educationally and just plain old fun!
I'm amazed at how well you're able to dissect and explain a program architecture as complicated and janky as this one! That's definitely a skill in its own right.
Covering another great game developed by Micronics. Really interesting how their games handled scrolling compared to other games that did it more efficiently.
And the jank turns into the difficulty in playing the game. Now we have the understanding as to why. And knowing _is_ half the battle! The other half is just... figuring out how to deal with this knowledge and apply it to gameplay strategy...
Well done and interesting as always! But what happens when you force the game to run at a frame rate (such as 60 fps) which is so fast that it's not done with the updates before it needs to start on a new game frame? Do you just interrupt everything and start over? Wait for the first calculations to finish? It sounds too easy that you can just go up to 60 fps by decreasing that wait value without optimizing the code. (Well, I think I saw a graphics glitch in Ikari Warriors (30:00) that might have been related to that?)
If you go past the 60 fps window, the second 1/60th block will finish the work. When the work is finished inside that frame time, the infinite loop will still loop until the end of the frame is reached and NMI occurs. When you see the footage, you'll notice an inconsistency in speed depending on how many objects are on the screen. I think the 1942 footage clip I used is really fast and then slows down as more enemies arrive. That's why I added "(max)" to my 60 fps mode section of the video, because the game will slow down when necessary.
the good and bad news about not being able to move left or right if you press jump first is that it became a major feature of the SNES Super Ghouls n Ghosts. Its part of the difficulty of the game and having to commit to a direction when you jump or double jump is acknowledged by the level design and is punishing when you miss but quite rewarding when you land some precision jumps. In the NES entry though, i wouldnt mind the ability to move after jumping (mainly to alleviate some of the jank) but the SNES version should remain as is.
Fantastic video. But now I'm just wondering what it feels like running at 30 fps instead of 60 or 20. Is it a happy medium? Also, the jump movement being hardcoded to a LUT is crazy. It makes you really appreciate that Super Mario Bros and other games bothered to implement subpixel physics movement with gravity.
My assumption on that LUT was that it made things easier for them to tweak the frame rate of the game (point to a different table, perhaps) and not have to worry about adjusting a gravity constant. Maybe they had it running at 30 fps for a little while during development, and then decided to switch to 20 fps when a certain area of the game became bogged down with operations.
I have a genuine C64 that I need to dust off. It has sat for so long because I still have the original PSU and don't want to fry my system due to overvoltage.
The different graphics updating on different "subframes" and how that makes it kind of difficult to quantify the game's overall framerate is interesting. How common do you think that is on NES? It reminds me of the behavior of a lot of dual-processor Sega arcade games, from at least OutRun to Virtua Racing. Foreground and background graphics would either update on different frames or just have completely separate frame rates from each other. It became a thing on Saturn too (which also had a dual-CPU, dual-VDP design).
Wow, this is like the Strider sprite ignorance on crack! Btw: Please, oh please do an episode on Super Pitfall!!! I think that game is fascinating and would love to know why that 'walk through walls' bug works!
I wonder if Arthur's sprite flicker was actually desirable on CRTs to make the parts of his model blend with each other. Heck, it should work on LCDs too. May not have been on purpose but the effect could be fine. Updating the scroll without updating the sprites' positions is also an interesting one - if it were consistent, it would be fine. As in, if we could save CPU time by updating the sprite positions at a constant 20fps while the background scrolls at 60. What I would do to make it smoother without too many changes would be 1. Keep the two sprite buffers, but use them for double buffering. While writing to page 2, always read from page 3. While reversing sprites into page 3, always read from page 2. This sounds like what they wanted to do but didn't think through on how to do it. 2. Scroll the screen at 60fps in the NMI. That is, once the physics logic computes the next scroll position, update the actual scroll position smoothly over 3 frames. More extensive changes to the palette update logic, scrolling in general, etc. would be great too, but I think those two would fix a good chunk of the observed jank. I also wonder if you could instruct the NMI to return to a different memory address than the one the CPU was executing when it occurred. In that case you could always return to some light logic that processes only Arthur's movement, compute that at 60fps, then jump back to where the actual interrupt took place. Keep the sprite update at 20fps but the input handling of the main character at 60. Though if we're making such extensive changes maybe a rewrite of the entire logic would be simpler.
I always felt that the game was somehow off, and it wasn't just my limited skills that made me play so badly. The weird way the sprite positions could mismatch the background, and the weird way it reacted to user input, the way the jumps were handled, it just wasn't the way I was used to from other games and completely went against my muscle memory.
Mega Man 2's scrolling fascinates me because it seems to keep pace with the player's movement. It can even keep up with you during those crazy zips, which are about 5 times faster than your normal max speed (holding right on Item 2).
I can see how nightmarish this was, like holy moly "Consistently inconsistent" is an understatement, that timeline looks awful.. Never really gotten around to many of Micronics games in the library growing up, but it's a sort of thing that makes me wonder if they just went for speed of development rather than perfection that caused some of these issues? Perhaps a bit longer development would ironed out these issues with the sprites. I guess it's perfect for a Friday the 13th episode?
You should use the format you use for explaining the technology of NES games but for a PlayStation 2 game. The video might be eight hours, but it sure would be neat!
This basically breaks the logic of a game "running at" an FPS. I mean I guess technically when something is 30fps its still running at whatever the refresh rate of the hardware is tied to (the tv being 60 or 50 depending on region). But man, this is literally running at 60fps and just only doing some updates 1/3 of the time and others whenever. Hilarious. The only question is, when you switch that handler to a 1 and it runs at 60fps, what does it do with that unfinished sprite work? Since its just the reversal mostly, I guess it just ignores the reversal? It would be hard to tell because the flashing of the sprite would have to be 120fps now.
The game's frame rate timing is basically "unlocked." So if it finishes a frame within 1/60th of a second, it will start the next one after NMI. If it didn't finish, the game will naturally slow down. The infinite loop (pink boxes) will handle the impromptu wait period when the game slows down. That helps keep the game from crashing (although I did crash Ikari Warriors at one point).
@@DisplacedGamers Oh yeah that makes sense. Like I should have already known that after all the excellent explanations but I eventually start to forget stuff as I try to keep up with all these things.
There are other games that have this kind of behavior. There's a post on TH-camr Cathode Ray Dude's website where he talks about how Microsoft Flight Simulator 3 updates most of the dashboard at some unknown framerate independent of whatever framerate the viewport (and the remaining gauges) is running at. To quote an excerpt: _Generally speaking, prior to Windows taking over in about '97, games on the PC had direct access to video memory. There was no "rendering API" and no "GPU." You calculated the whole display with CPU instructions, produced a bitmap, and poked that bitmap into video RAM. This is why it took so long for the PC to get reasonable action games - the 8088 simply could not poke pixels very fast, acceleration hardware was virtually nonexistent, and the deployed base of 286-486 machines was minimal compared to original 8088 and clock-doubled variants._ _Screen tearing was a problem then as now, and made even worse by the incredibly slow speed at which the CPU plotted pixels. It was also solved the same way then as it is now: Instead of plotting pixels to the framebuffer that the graphics card is outputting from, plot them instead into a separate chunk of RAM, so the card keeps outputting the last good frame while you're slowly plotting pixels. Once a frame is done rendering, tell the graphics card to output from that other memory region, instantly swapping from the last good frame to the newest good frame. Then, start drawing your next frame to that original memory region, and repeat._ _This technique is known as "page flipping" and "double buffering." I believe the only difference is that with page flipping, you're telling the video card to draw from a different region of RAM, but with double buffering, you always output from the same memory, but when you finish drawing a frame you just quickly copy it from the temporary buffer into the active one._ _Nowadays, as far as I know, these features are both implemented at a very low level - but in the mid 80s you were doing everything by hand, with no help from an API. If you wanted to flip pages, you reprogrammed the CRT Controller chip on the graphics card by poking a new memory address into some registers. If you wanted to double buffer, you programmed the CPU to copy every single bit from one memory region to another. It was tedious - but it also meant that you weren't really married to any given technique._ _So, how are the gauges moving without a page flip? The answer is: Who cares? Who said a pageflip had to happen to update the screen? It's just a tool in your toolbox._ _Pageflipping IS used in this games rendering, but not all the time. At any given moment, maybe you're staring at page 0, seeing a frame from 800msec ago, while page 1 is slowly being drawn by the CPU, offscreen. It'll be another 200ms before it's ready to flip pages - but nothing says it HAS to finish rendering the next frame before it can update what's on screen. It's just RAM._ [...] _And so, while the 3D portion of the screen is rendered using pageflipping, the dashboard is not. When your session starts, the game renders the static parts of the dashboard once, into each page, and then every time it updates the gauges, it renders them to both pages as well, so whenever it does flip, the gauges in the other page will be up to date._
@LonelySpaceDetective amazing. I love this. I still love that incredibly smart and talented people slowly reach me things like this so one day I understand how everything works
Thanks, Interesting and informative as always. Ghosts 'N Goblins was an arcade favorite of mine, and the second game I got for my NES (after SMB) in 1987. One little detail though... the NES game was prone to hard-crashing on occasion. Sometimes it would just lock up with glitched graphics and the sound freezing. Tended to happen in the later stages. Do you have any insight on what might be happening here? (I'm reminded of the initial production run of Castlevania, which would occasionally hard-lock due to an issue with excessive sprites and an NMI.)
I'm pretty sure that tucked away in this analysis is the explanation for why the "P" in "1 UP" gets briefly duplicated above the fence at 3:19, followed two frames later by the hilt of a non-existent spear. Sprite priority or something. But still... the "P"?
Love your videos. I always got the impression the original GnG arcade games also used LUTs for jumping (I don’t know for sure though). I think that’s probably a good thing that the NES version also did it. I also didn’t understand your explanation of the OAM reversal strategy at all. Besides the drawback of it ending up off-kilter with the 3 frame issue, if it lets you have more sprites per scanline that seems nice versus the other example with Megaman flickering in and out of existence. Clever game design should avoid that by having less characters on screen or utilizing other tricks IMO. With that being said, IDK what the heck they were doing with some of this… Such as, the column drawing segment sometimes escaping the logic seems very odd. They are smart enough to get what they have, but at the same time missing that, I don’t understand it. Honestly it probably didn’t even matter with what’s presented on the screen and maybe it’s even more performant :P. You did mention time/deadlines probably playing a significant role and that can probably explain a lot of stuff. Still though, I feel like getting something working as well as it does should have caught stuff like that. You should start reverse engineering GB games with interesting implementations. I’ve seen some amazing/smart/baffling ways of doing things on the GB, but I’m biased because that’s what I understand the most.
So now I see what makes Micronics games so janky. By the way, do you ever plan to cover games on other systems supported by Mesen 2 on Behind the Code? I've heard from ROM hackers that Super Mario World has its own jank, though it's nothing on the level of Micronics.
I do. I have only touched upon a few SNES games in the past - usually due to the fact they share code with NES games as they are ports. We'll see what the future brings. I really love Mesen's features and interface. That said, NES is my comfort zone. It doesn't take too long to dive into a game and reverse it, so I have just kinda stuck with it.
![KRK - ชนิสรา Ft.WanMai , N/A [Official MV] Prod. By Sakarin](http://i.ytimg.com/vi/C-WMwwYobcU/mqdefault.jpg)
![ค้าง (STILL) - GEMINI [ OFFICIAL MV ]](http://i.ytimg.com/vi/Ftxx3hk5vkU/mqdefault.jpg)
I couldn't click this fast enough. You know with this channel you are always getting a well-researched and insightful video on a gem from the past. This is the best gaming channel out there that balances technical content with entertainment.
Thank you. I was really happy with how this one turned out.
I love Chris' unique niche here, it's challenging to both do the work and then present it in a compelling way, and it's a fascinating look into "how things are made" which is something I feel like we don't always get. I help teach people to learn basic programming for simple games. In my spare time I like to clone NES games and, while not a plug for the video, I've used some of what I've learned from these videos to look into ROMs to help understand how to replicate more authentic feeling experiences. But I find that because we don't do a lot of bare metal programming anymore, and because engines are often very complex and come fully formed out of the box, that people are often uniquely mistaken in ... what a game engine even does. But I think that's because if I look up an Unreal tutorial I'm going to see a lot of package installation and IDE stuff, "is there a library or extension that does this?" is more common than, "How have other people approached this task?" That bare metal exploration of how these things are made, why they are made, how those decisions affect what they do is ... not lost, but not at the forefront of our perspective.
A long winded way of saying I love this look back at a time when just getting something on screen was itself a bit of a miracle, and looking at the diverse and interesting decisions made in that pursuit. Often these games were bad in many ways, but it still took a lot of technical know-how to bring it to life.
I think it is awesome that you help teach people, and I am so glad that you do.
We really are in a different era of programming these days, aren't we? My hope is that we continue to move forward in efficiency and the features we have available while still understanding what goes on under the hood.
@@DisplacedGamers I think it's awesome you reply to so many of your commenters. I agree, someone who touches Unity or Gamemaker often misunderstand the core concept of the program loop. But it makes sense, you kind of learn that by doing *this* kind of ground-up programming writing an engine.
I don't necessarily think everyone needs to know how to do multiplication on a 6502 but I do think knowing makes a lot of other basic programming much easier to understand (and maybe even appreciate!)
This is such a very well done video. To a certain type of person (myself included), this is literally fascinating. I wonder if this is how my wife feels when she's transfixed watching reality TV?
I really should be getting ready for my works Xmas party right now, but I can't stop watching this.
This title made me immediately excited to watch. I have all the popcorn ready for this. I love your stuff. Thank you for all your work.
I am glad you have popcorn ready. This script and video were so big, I thought about asking people to bring lunch!
@DisplacedGamers I enjoyed every minute of it. I also may have died a little insideFF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF from seeing that update code.
I've said it before, but I love how good of an educator you are. You make it so fun to learn and understand the things that are happening behind the scenes even for someone with no programming background that just loves games. Kerp it up!
Aw shit, it’s Micronics Time
Here we go again " 😂
Micronics is to @DisplacedGamer as Masterlock is to @LockpickingLawyer
yes... YES!!! It's a good day when displace gamers has a new video. Ok, gonna get my coffee and sit down to watch this. One of the few channels that demands my full attention. I've said it before, I'll say it again, you make this crusty old database programmer's heart happy when I can *FINALLY* understand why certain games I rented as a kid were so broken (That sinking feeling of "Why did I rent this game for the weekend...?"). Strider and Contra Force have been my favorite you've done so far.
Thanks for posting this one!!
Wow. Thank you! I always worry about making a longer video. Those slides take so long to make, and I question if people are still watching as I add photoshop layer number 82 to a slide past the 20 minute mark of the video.
That classic Micronics jank 😋
Ain't no Game Genie codes fixing this one!
Needs a romhacker to fix it. Hope one of them watches this and is inspired to fix it themselves. Then just add a Easy Mode and might just give it a try.
@@Animebryan2 just say you don't want to play the game
Your videos speak so coherently and authoritatively to the promethean impulse manifested in these weird electronic pieces of moving art that they meld into that impulse and become part of the canon. Really remarkable stuff, DG. You have every right to be exceedingly proud of these productions.
A Ghosts n' Goblins video on Friday the 13th? Hell yeah
Quality of history, presentation, content, and delivery, outstanding as always. Keep up the great work!
Thank you!
Another Banger from Displaced Gamers!
This channel is like my version of ASMR. I understand like 1/3 of it, the rest is "I like your funny coding words, magic man"
Can't believe I stumbled upon this video while I was searching for another one of yours!
I always wondered why this game felt so...bogged down.
Super Pitfall mention! Explaining all the jank in that game and speedrun would be a great video. It's an encyclopedia of jank.
Super Pitfall feels like an instance of - "Wait. That assignment is due tomorrow??"
@@DisplacedGamers We use the jank in the speedrun to clip through walls (which appears to be completely random and out of the player control, which is 'fun'), but also if you collect all the items and game over, the attract mode starts in the location of the map you needed to go to end the game, so it gives the attract mode the congrats screen. Using the jank to our advantage.
Oh wow my new favorite tech archaeologist!
whoa... 1942 looks playable with your fix.
Now it just needs real music instead of that annoying series of beeps that it calls music.
Everyone is talking about how your videos have a perfect balance of knowledge and entertainment...and they're right lmao
Idk what's going on most of the time but I'm still actively watching and enjoying these videos
If you're going to do more micronics games, please figure out how walls work in Super Pitfall. Apparently their hit collision will just fail at random.
I would love to see this explained but I also feel like between all the other micronix videos and just his videos in general, we have enough puzzle pieces to work out a fairly logical reason ourselves 😅
Yes in the speedrun you use it to just phase through walls... But sometimes you also phase into the floor and die.
Currently working on an NES game and your channel has been a great guide on what NOT to do. Kudos!
I find these kind of videos fascinating, especially if they're well presented like this was. Good work.
This was exceptional ❤ very clear, easy to digest, professional, funny, and I learned a lot. Inspired to break out Ghidra to start digging around myself!
You are consistently the best! I love this series so much... to be willing to dig into the code of something like this... god bless man
Your videos have significantly deepened my knowledge of 6502-based programming such that I've been able to do some reverse-engineering of my own as well as modifications to code.
My greatest achievement by far so far is extracting one of Action 52's "games", both PRG and CHR, and packaging it into a single, fully functional ROM file. I even chose to convert the ROM into an MMC1-based ROM with 32KB of PRG data and 16KB of CHR data and wrote custom code to bank-switch between the two CHR banks between the result screens and the main game loop.
Love when these videos drop!!!
HERE WE GO
Fantastic video as always!
Actually, I'm pretty sure you would have to divide the gravity constant (if there existed such a thing) by 9, not 3. Since it's an acceleration value.
Heh. Even the "now what" slide had me throwing in "more math here" because I was just ready to be DONE. I apologize for being lazy.
Micronics: "Well we finished that Famicom port for you."
Capcom: "Great!"
Micronics: "But... we had to take some liberties."
Capcom: **disappointed parent stare**
Incredible work. I love that you're pulling your older videos in to demonstrate things you've already shown.
Lovely Yoshikazu Yasuhiko art for the thumbnail ❤
Oh, here we go with Micronics
Finally! Ive always wondered why this game had the low framerate!
Yet another banger! honestly i could watch 3 continuos hours of you doing these deep dives, like, i thought this video was very concise, even though its half an hour long...
This game gives me exactly the same feeling as the Toki (Juju Densetsu) game.
Toki on Atari Lynx was golden
Ghosts'n Goblins and Junk 💀 Love your videos, man! ⭐⭐⭐⭐⭐
Capcom letting a game be made in their name that has slow down, or doesn't run at full frame rate? Say it ain't so.
Another great deep dive! Very informative, great presentation, and I appreciate how you tested other games too.
Another excellent video. Great stuff.
Subscribed!
Wish I had found this channel sooner.
i was just struggling so hard to find a long video to fall asleep to, this dropped at the perfect time
you gonna have nightmares
It’s interesting. That sort of comment can be very insulting, or a compliment, and it varies from person to person making it and receiving it…
I'm new to this channel. Very impressive work. I quickly subscribed.
I was waiting eagerly for this one!
This' one of my favourite games of theirs and it is great to dive deep into the mess of the code that brought it to live!
Great video, had me laughing a good bit.
Excellent work as usual 👏
wow, in depth is an understatement, i love it!
Another excellent video :)
Getsu Fuuma Den mentioned! Let's GO!
Most underrated channel.
31:05 I'm not sure if you're saying that's a bug (or if you're saying something else is a bug and I'm not getting it), but it's by design that Arthur can't change trajectory in mid-air
It's realistic, though it's usually not what games do that began development after Super Mario Bros. The arcade version was a very early side scrolling platformer.
@@cube2fox it became relatively uncommon after the early 80s to have fixed jumps like that but it's a mainstay of the makaimura series, it's in every entry. half the reason the games are so difficult is because you have to negotiate complex platforming obstacles with these Donkey Kong-ass jumps. you can also jump forward while shooting backward
@@mycophobia Yeah. I just looked it up, the Ghosts 'n Goblins arcade actually came out a few days ahead of Super Mario Bros. Which makes it the, as far as I know, second side scrolling platformer, after Pac Land and before Super Mario Bros.
I think what he's getting at more is there isn't any allowance for hitting left/right shortly after pressing jump; if you hit jump technically the frame before you hit left or right, you are locked into jumping straight-up, which seems like it could be annoying.
I haven't played any games that did fixed jump trajectories in a while though, I couldn't say for sure if this is normal implementation or not.
@@LonelySpaceDetective i'm not sure how that would work exactly if the jump is completely fixed in height and direction, but it did make me curious as to how the jump/directional inputs work in such games. here are my undoubtedly incredibly fascinating findings:
Castlevania (NES) - Jump+Direction in the same frame will make Simon jump in that direction. Direction on any frame after the jump does not work, he jumps straight up.
Ghouls n Ghosts (arcade) - Same as above
Ghosts n Goblins (arcade) - Simultaneous Jump+Direction does NOT work. You must hold a direction for at least one frame before jumping, otherwise Arthur still jumps straight up. This makes sense as the first game in this series has kind of notoriously sticky controls. Crouching is a pain as well.
Man, this game….when I was like 10 my sister and I had saved and pooled our allowance for a while to buy Zelda. We went to the store to get it and I wandered off to look at the toys but when we got back to the car I saw she had Ghosts and Goblins. Guess Zelda had been sold out. Ghosts and goblins, which was so hard for my younger self I used to get my console taken away after I would throw my controllers in anger. Then I had to wait months to get Zelda for Xmas.
Maybe I'm just old but I find the frame rate and general jankyness of the nes port quirky and charming....or maybe I'm just sadistic
I had the same feeling with TMNT. He 'corrected' a few of the issues with that, including the dam water level. While that was great and all I can't imagine playing it that way
@@PigeonHoledByYT I dunno. I'd be quite happy if Konami had fixed those awful collision issues with the water level. :P
no you're masochistic, because you're the one who suffer from it.
I'm definitely old, but I've always found this kind of jank deeply unpleasant. Back then I didn't have the words for it, but 2D games with excessively low framerate and especially ones like this that move sprites and background separately always felt off to me.
I love these videos. I watch all of them
Megaman 3 has a bizarre sluggishness/delay in its input compared to Megaman 2. Is it possible to solve this?
I hear "Micronics" and I know I'm in for a great episode!
Great, as always.
love these videos on tricks to make games run better.
I do enjoy your videos, Thankyou for making them.
The content is very good and I used to program for the Gameboy Color back in the 1990s so a lot of the Famicom hardware is very familiar and is good to see it presented graphically.
I do find the tone almost unbearably condescending at times though, I’m not sure if it is a USA thing but I don’t understand why there is a kind of annoyed attitude or ridiculing of the code. I just find it unnecessary and gets in the way of all the amazing things youve discovered and the genuine insights you’ve made along the way.
I dint think there is any need to apologise for any of the code the developer wrote, but I would love to take a look at the development tools they were using back then.
Even for the Gameboy Color I was able to code and test mainly on a pc emulator with a breakpoint debugger, with only a few minute compile time, a full macro assembler, a high resolution display so I could see many lines of code , and a burn to cartridge of only a few minutes.
I assume their tools were no where as useful and efficient as mine where then, but I definitely made just as many bugs !
Thanks again for making your videos, they really are great!
I am glad you mentioned that you detected a condescending tone as that was not at all what I was trying to be. Let me write about it just a little bit.
It is never my intention to insult the code or the people that wrote it. I am definitely aware of the tools they had available, and I am thankful that I have tools that are amazing as they are today in order to pick apart what they wrote years ago.
If I had an opportunity to speak to someone that wrote any of the code I have examined, I would be excited to listen to their stories.
I've also written code in a professional environment that has been compromised by the features requested, time allotted, and design changes during development. I've released stuff that I thought was terrible. This may happen because of the reasons I just listed - OR - because I just didn't have the experience at the time. We're all human.
Now as for humor - My style of humor (in real life) is deadpan. I'll say something ridiculous with a straight face that is not meant to be taken seriously. I fully recognize that this is not very Internet compatible. Nevertheless, I have started to include a bit more of my personality in my TH-cam videos to boost the entertainment factor. These are heavy topics, and a 30+ minute video about tech stuff needs a few laughs. I use the humor that makes me who I am. I am 100% not insulting the people involved in the code I dissect.
@ Thankyou for the reply. The way you talk about it here, I think it is clear that I’m just misreading your tone sometimes, it might just be me picking up on something that’s not even there.
I feel rude now for mentioning it, but it sounds like you appreciated the feedback anyway :)
Thanks again for all these amazing videos, you’ve actually inspired me to try and disassemble a ROM, it looks a lot of fun how you puzzle out where the variables and routines are.
@@DisplacedGamersfantastic dialogue to see going on in here. Keep up the good work DG, the content is great as it is, tonally, educationally and just plain old fun!
I'm amazed at how well you're able to dissect and explain a program architecture as complicated and janky as this one! That's definitely a skill in its own right.
I have yet to understand a single video. I have watched them all and sit here nodding yes mappers I have heard this word before. 🤔
technically the game works... welcome to the world of programming...
Love this channel and this one was really good! So.... when do you start on updating that physics engine?? :P
Covering another great game developed by Micronics. Really interesting how their games handled scrolling compared to other games that did it more efficiently.
It feels like a miracle that games like this work at all, given how they seem to be held together with spit and baling wire.
And the jank turns into the difficulty in playing the game. Now we have the understanding as to why.
And knowing _is_ half the battle!
The other half is just... figuring out how to deal with this knowledge and apply it to gameplay strategy...
This video is very well made.
Well done and interesting as always!
But what happens when you force the game to run at a frame rate (such as 60 fps) which is so fast that it's not done with the updates before it needs to start on a new game frame? Do you just interrupt everything and start over? Wait for the first calculations to finish? It sounds too easy that you can just go up to 60 fps by decreasing that wait value without optimizing the code. (Well, I think I saw a graphics glitch in Ikari Warriors (30:00) that might have been related to that?)
If you go past the 60 fps window, the second 1/60th block will finish the work. When the work is finished inside that frame time, the infinite loop will still loop until the end of the frame is reached and NMI occurs.
When you see the footage, you'll notice an inconsistency in speed depending on how many objects are on the screen. I think the 1942 footage clip I used is really fast and then slows down as more enemies arrive. That's why I added "(max)" to my 60 fps mode section of the video, because the game will slow down when necessary.
the good and bad news about not being able to move left or right if you press jump first is that it became a major feature of the SNES Super Ghouls n Ghosts. Its part of the difficulty of the game and having to commit to a direction when you jump or double jump is acknowledged by the level design and is punishing when you miss but quite rewarding when you land some precision jumps. In the NES entry though, i wouldnt mind the ability to move after jumping (mainly to alleviate some of the jank) but the SNES version should remain as is.
Fantastic video. But now I'm just wondering what it feels like running at 30 fps instead of 60 or 20. Is it a happy medium? Also, the jump movement being hardcoded to a LUT is crazy. It makes you really appreciate that Super Mario Bros and other games bothered to implement subpixel physics movement with gravity.
My assumption on that LUT was that it made things easier for them to tweak the frame rate of the game (point to a different table, perhaps) and not have to worry about adjusting a gravity constant. Maybe they had it running at 30 fps for a little while during development, and then decided to switch to 20 fps when a certain area of the game became bogged down with operations.
You'd probably enjoy diving into the 6502-based C64 graphics design. The C64 demo scene is unreal.
I have a genuine C64 that I need to dust off. It has sat for so long because I still have the original PSU and don't want to fry my system due to overvoltage.
The different graphics updating on different "subframes" and how that makes it kind of difficult to quantify the game's overall framerate is interesting. How common do you think that is on NES? It reminds me of the behavior of a lot of dual-processor Sega arcade games, from at least OutRun to Virtua Racing. Foreground and background graphics would either update on different frames or just have completely separate frame rates from each other. It became a thing on Saturn too (which also had a dual-CPU, dual-VDP design).
Wow, this is like the Strider sprite ignorance on crack! Btw: Please, oh please do an episode on Super Pitfall!!! I think that game is fascinating and would love to know why that 'walk through walls' bug works!
I wonder if Arthur's sprite flicker was actually desirable on CRTs to make the parts of his model blend with each other. Heck, it should work on LCDs too. May not have been on purpose but the effect could be fine. Updating the scroll without updating the sprites' positions is also an interesting one - if it were consistent, it would be fine. As in, if we could save CPU time by updating the sprite positions at a constant 20fps while the background scrolls at 60. What I would do to make it smoother without too many changes would be
1. Keep the two sprite buffers, but use them for double buffering. While writing to page 2, always read from page 3. While reversing sprites into page 3, always read from page 2. This sounds like what they wanted to do but didn't think through on how to do it.
2. Scroll the screen at 60fps in the NMI. That is, once the physics logic computes the next scroll position, update the actual scroll position smoothly over 3 frames.
More extensive changes to the palette update logic, scrolling in general, etc. would be great too, but I think those two would fix a good chunk of the observed jank.
I also wonder if you could instruct the NMI to return to a different memory address than the one the CPU was executing when it occurred. In that case you could always return to some light logic that processes only Arthur's movement, compute that at 60fps, then jump back to where the actual interrupt took place. Keep the sprite update at 20fps but the input handling of the main character at 60. Though if we're making such extensive changes maybe a rewrite of the entire logic would be simpler.
Great video! Peace out
I always felt that the game was somehow off, and it wasn't just my limited skills that made me play so badly. The weird way the sprite positions could mismatch the background, and the weird way it reacted to user input, the way the jumps were handled, it just wasn't the way I was used to from other games and completely went against my muscle memory.
Awesome
Mega Man 2's scrolling fascinates me because it seems to keep pace with the player's movement. It can even keep up with you during those crazy zips, which are about 5 times faster than your normal max speed (holding right on Item 2).
Nice analysis
HYPE
I can see how nightmarish this was, like holy moly "Consistently inconsistent" is an understatement, that timeline looks awful..
Never really gotten around to many of Micronics games in the library growing up, but it's a sort of thing that makes me wonder if they just went for speed of development rather than perfection that caused some of these issues? Perhaps a bit longer development would ironed out these issues with the sprites.
I guess it's perfect for a Friday the 13th episode?
Essa série ficou viciante, não posso esperar pelo próximo vídeo.
Do you plan to touch other systems?
There is an adaptation to run ghidra on Gens Gs.
I still have this game on cartridge. Makes me feel - NO - realize how spoiled I am to program a Space Invaders clone in Lua with a LOVE 2D framework.
You should use the format you use for explaining the technology of NES games but for a PlayStation 2 game. The video might be eight hours, but it sure would be neat!
Tiger Heli at 60 fps? Amazing.
This basically breaks the logic of a game "running at" an FPS.
I mean I guess technically when something is 30fps its still running at whatever the refresh rate of the hardware is tied to (the tv being 60 or 50 depending on region). But man, this is literally running at 60fps and just only doing some updates 1/3 of the time and others whenever. Hilarious.
The only question is, when you switch that handler to a 1 and it runs at 60fps, what does it do with that unfinished sprite work? Since its just the reversal mostly, I guess it just ignores the reversal? It would be hard to tell because the flashing of the sprite would have to be 120fps now.
The game's frame rate timing is basically "unlocked." So if it finishes a frame within 1/60th of a second, it will start the next one after NMI. If it didn't finish, the game will naturally slow down. The infinite loop (pink boxes) will handle the impromptu wait period when the game slows down. That helps keep the game from crashing (although I did crash Ikari Warriors at one point).
@@DisplacedGamers Oh yeah that makes sense. Like I should have already known that after all the excellent explanations but I eventually start to forget stuff as I try to keep up with all these things.
There are other games that have this kind of behavior. There's a post on TH-camr Cathode Ray Dude's website where he talks about how Microsoft Flight Simulator 3 updates most of the dashboard at some unknown framerate independent of whatever framerate the viewport (and the remaining gauges) is running at.
To quote an excerpt:
_Generally speaking, prior to Windows taking over in about '97, games on the PC had direct access to video memory. There was no "rendering API" and no "GPU." You calculated the whole display with CPU instructions, produced a bitmap, and poked that bitmap into video RAM. This is why it took so long for the PC to get reasonable action games - the 8088 simply could not poke pixels very fast, acceleration hardware was virtually nonexistent, and the deployed base of 286-486 machines was minimal compared to original 8088 and clock-doubled variants._
_Screen tearing was a problem then as now, and made even worse by the incredibly slow speed at which the CPU plotted pixels. It was also solved the same way then as it is now: Instead of plotting pixels to the framebuffer that the graphics card is outputting from, plot them instead into a separate chunk of RAM, so the card keeps outputting the last good frame while you're slowly plotting pixels. Once a frame is done rendering, tell the graphics card to output from that other memory region, instantly swapping from the last good frame to the newest good frame. Then, start drawing your next frame to that original memory region, and repeat._
_This technique is known as "page flipping" and "double buffering." I believe the only difference is that with page flipping, you're telling the video card to draw from a different region of RAM, but with double buffering, you always output from the same memory, but when you finish drawing a frame you just quickly copy it from the temporary buffer into the active one._
_Nowadays, as far as I know, these features are both implemented at a very low level - but in the mid 80s you were doing everything by hand, with no help from an API. If you wanted to flip pages, you reprogrammed the CRT Controller chip on the graphics card by poking a new memory address into some registers. If you wanted to double buffer, you programmed the CPU to copy every single bit from one memory region to another. It was tedious - but it also meant that you weren't really married to any given technique._
_So, how are the gauges moving without a page flip? The answer is: Who cares? Who said a pageflip had to happen to update the screen? It's just a tool in your toolbox._
_Pageflipping IS used in this games rendering, but not all the time. At any given moment, maybe you're staring at page 0, seeing a frame from 800msec ago, while page 1 is slowly being drawn by the CPU, offscreen. It'll be another 200ms before it's ready to flip pages - but nothing says it HAS to finish rendering the next frame before it can update what's on screen. It's just RAM._
[...]
_And so, while the 3D portion of the screen is rendered using pageflipping, the dashboard is not. When your session starts, the game renders the static parts of the dashboard once, into each page, and then every time it updates the gauges, it renders them to both pages as well, so whenever it does flip, the gauges in the other page will be up to date._
@LonelySpaceDetective amazing. I love this. I still love that incredibly smart and talented people slowly reach me things like this so one day I understand how everything works
Thanks, Interesting and informative as always. Ghosts 'N Goblins was an arcade favorite of mine, and the second game I got for my NES (after SMB) in 1987. One little detail though... the NES game was prone to hard-crashing on occasion. Sometimes it would just lock up with glitched graphics and the sound freezing. Tended to happen in the later stages. Do you have any insight on what might be happening here? (I'm reminded of the initial production run of Castlevania, which would occasionally hard-lock due to an issue with excessive sprites and an NMI.)
Now I freaking want to see damned Ghosts'n'Goblins fixed!!!
Yess!
Ok I really want to play Tiger-Heli at 60 fps. That was one of my favorite games as a kid.
I'm pretty sure that tucked away in this analysis is the explanation for why the "P" in "1 UP" gets briefly duplicated above the fence at 3:19, followed two frames later by the hilt of a non-existent spear. Sprite priority or something. But still... the "P"?
Talented developers more like 1 developers and i’m not lying
3:08 Well! I expect that kind of language at Denny's, but not here!
Love your videos. I always got the impression the original GnG arcade games also used LUTs for jumping (I don’t know for sure though). I think that’s probably a good thing that the NES version also did it.
I also didn’t understand your explanation of the OAM reversal strategy at all. Besides the drawback of it ending up off-kilter with the 3 frame issue, if it lets you have more sprites per scanline that seems nice versus the other example with Megaman flickering in and out of existence. Clever game design should avoid that by having less characters on screen or utilizing other tricks IMO.
With that being said, IDK what the heck they were doing with some of this… Such as, the column drawing segment sometimes escaping the logic seems very odd. They are smart enough to get what they have, but at the same time missing that, I don’t understand it. Honestly it probably didn’t even matter with what’s presented on the screen and maybe it’s even more performant :P. You did mention time/deadlines probably playing a significant role and that can probably explain a lot of stuff. Still though, I feel like getting something working as well as it does should have caught stuff like that.
You should start reverse engineering GB games with interesting implementations. I’ve seen some amazing/smart/baffling ways of doing things on the GB, but I’m biased because that’s what I understand the most.
Very informative, as always-but what I want to know is just what the heck was the cover artist told about this game to get them to put out…that?
Someone at Micronics was more interested in showing off than in writing efficient code.
So now I see what makes Micronics games so janky.
By the way, do you ever plan to cover games on other systems supported by Mesen 2 on Behind the Code? I've heard from ROM hackers that Super Mario World has its own jank, though it's nothing on the level of Micronics.
I do. I have only touched upon a few SNES games in the past - usually due to the fact they share code with NES games as they are ports. We'll see what the future brings. I really love Mesen's features and interface. That said, NES is my comfort zone. It doesn't take too long to dive into a game and reverse it, so I have just kinda stuck with it.
I actually like this version.
jank is so, very interesting!
Here's hoping for a 60fps (Super) Famicom port of Famicom GnG
I wonder what NES games would be like if there was something like Nesmaker back then
That reminds me, I wonder what the HeII happened with Ghostbusters...
A ja myślałem, że Contra Force jest najbardziej spierdolona... lecz dopiero tutaj jest prawdziwy burdel 😎