Lag & Blanking - Super Nintendo Entertainment System Features Pt. 06
Vložit
- čas přidán 19. 04. 2018
- Ever wondered why exactly older games tended to lag a lot? It's all explained right here.
LINKS
Twitter (updates): / retrogamemechex
Patreon (support): / rgmechex
Discord (discussion): discord.rgmechex.com
PATRONS
Thank you everyone for your help! It means so much to me.
Markus Persson, Matthew Mahorney, Ange Albertini, Avi Drissman, Chris, Martin Trozell, Robert Hunt, Larry Koubiak, Joshua Goyder, Greg Miell, Owen Christensen, Gynvael, Alec Johnson, FFVIMan, Si Davies, Chris Margroff, Seth Tierney, Stephen1704, 333Rich333, Daniel L, Juli Mallett, Glenn Sugden, Jordan Wiens, Alex Yancey, Chell Jones, David Mazarro, Steven, LiraNuna, Austin Hughes, Vaendryl, null, Brandon Pelfrey, Curtis Ware, Corey Ogburn, Scott Harper, Garret Kelly, Mike Gerow, Jake Hickman, Joel Kuhn, Dan Shedd, Robert Schultz, Tina Wuest, Xander Webb, ParoXoN, 4F Panda, Max Roncace, A Sentient JDAM, Travis Nellor, Nick Strauss, Zach Komon, Tianyu Ge, Buddy, Mikely Whiplash, Tim Stöcker, Yakov, Joseph, Oxygen Chen, Micah Elizabeth Scott, JockeTF, Tyler, Khalill Marsh, Dave Voyles, Stephan Packard, foxspresso, Daniel, sapphirepaw, Kieran Hayles, Corrodias, silsha fux, Aaron, hyperforce, Alejandro Cadavid, Leon, Matthew, dan, Ryan, Hex Witch Circe, John Armstrong, Vangald, Hans Eriksson, Josh Wolfe, Luke Chang, Salvidrim, Navarro Parker, Andrew, Paolo Pisati, Wenting, Jeru Sanders, Q, Dan Balestrieri, asf, Robert Butler, Pat Randell, Michael Furtak, Martin Harding, Douglas Confere, Arnt Richard Johansen, DrunkCat, Skylar Brown, cab404, Matt Coburn, Kevin Turner, Manuel Tiedtke, David, Matt Godbolt, John H., Antti Nykanen, Rob Cameron, Roni Mizrahi, Nick, Nathan O. Marsh, briandef, Pablo, Brian Henriquez, Joseph Edwards, Mike Magin, thegirlg33k, Dane Orie, Ellis HP, Matias Christensen, Rasmus Bååth, Daniel Granerud, Justin Carter, iodbc '- The Black Box, Sijmen Schoon, AddOhms Tutorials, Grumbel, TheGreatCodeholio, Turn Left Right Make A U-Turn Recalculating You Have Arrived At Your , Diarmaid Roche, matchai, TheWaffleWizard, Mate Varga, John Cudney, Narien, Cameron Porcaro, & Andrew - Hry
>Processor runs out of instructions this frame
"I'll try spinning, that's a neat trick!"
Before, i thought that SNES has a "slow motion" effect whenever something cool happens in the game like that zelda's bomb spot or jumping over a flame snake and dodging a dog and two zombies in ghouls n ghosts
shhhhhh, it's all totally intentional
Changing the speed of the game for the enjoyment of the player, when it is just lag.
That's how Space Invaders changed the speed of the UFOs while playing. Drawing all these sprites basically made the rendering slow, because each frame took so long, but the more UFOs you shot down, the less there was to process and the faster the game ran.
When I was a kid playing SHMUPS I thought: huh, it’s slowing down the game when it gets really hectic. How thoughtful! 😅
@@HappyBeezerStudios that’s awesome: I never thought of that, but it makes perfect sense!
I know from the depths does that. When an ammo storage detonates the game goes into slowmo for a second (intentionally).
Then again the game's performance also tanks when large vehicles collide (because they're both made of thousands of blocks). So the accidental cool highlighting is still going strong 😂
How the actual crap did people figure this stuff out?
"AH YES, WE'LL HAVE AN ELECTRON BEAM DIRECTED BY MAGNETIC FIELDS AT 60hZ TO CREATE THE ILLUSION OF A PERSISTENT IMAGE."
And people get for granted all these technologies while "simple stuff" like old TVs are so complex.
The 60hz was out of convenience for how American power worked. I'd recommend you watch Technology Connections, as it breaks down how analog TV works in far more detail than this channel does.
amaaaaaazing vid :O
@@YaroKasear TechnologyConnections is awesome!
Thank Philo Farnsworth for that one.
I'm always impressed by the really detailed and precise animations that help visualize things.
These are like professional quality videos, this dude is a god
yeah
I went on the comment section just to write the same thing. The level of detail to help people visualize concepts is amazing.
I came here to say the same thing.
You're making these videos so well it's incredible. This is what I wish I could have seen five years ago when I was struggling with that stuff, and at the same time it's only now that I actually *understand* it. Can't thank you enough for everything you're doing!
These might be the best visualizations I've ever seen to enhance explanations of a topic, and I'm a 3Blue1Brown fan. Damn you're good
8:08 That image of the instruction timing shown in the context of screen draws and what happens outside the screen is one of the most elegant presentations I've ever seen. Major kudos.
The visualization of instruction run times mapped to electron beam location is superb. The entire video is great, but that particularly stood out.
The realtime visualization of the blanking/spinning animation is extraordinarily good. I feel spoilt with the quality we're getting.
This is so cool. I knew exactly how a CRT worked but I had no idea how it worked in relation to oldschool consoles.
Thanks for the awesome, easy to understand, video! Reminds me of the book Racing the Beam, which talks about developing for the Atari 2600, which was a herculean feat because the hardware was incredibly limited.
That's exactly what I was thinking! Nick montfort visualized the Atari screen much the same way as in this video, and that forced blanking during h blank is familiar from old atari games with lots of black artifacts like space invaders
A lot of the more advanced graphical techniques can be traced back to the 2600.
For later systems they were used for complex effects but were sort of optional.
But the design of the 2600 means you basically need to do them as a matter of routine.
Almost all 8 and 16 bit systems do variations on this stuff though.
Does remind me of the Atari 8 bit home computers; They essentially have an upgraded version of the 2600's graphics chip, but then have a second chip that is like a special-purpose CPU, which for basic tasks does the stuffing of the data into the main graphics chip for you automatically.
This design was exceptionally flexible, and let you do things like switch graphics modes 5 times in a single screen, changing resolution, colour depth, to text or graphics mode, etc, all basically without CPU intervention.
It's still the same principle though; Change the data each scanline...
Yeah, pretty much the frame buffers solved that issue, so from then onwards you only had to race the beam during VBlank, the display was handled automatically.
The Atari 2600 was a machine designed to run Tank. Making any other game run on it required that your cartridge pretty much hack the console in real time.
Really cool video on CRTs and Blanking! I never really noticed the black flashing on the top of the screen, but this is really cool to see at a hardware standpoint!
Thanks for another awesome video!
Correct me if I'm wrong, but the black bar at the very top of the screen would probably be hidden by the TV's over-scan, thus you would never actually see it on a CRT.
If the bar is sufficiently small, its possible it could be hidden; however, there's not really a limit to how badly it can lag--the black bar could even take up the whole screen if the v-blank routine took an insane amount of time.
How does your comment say "1 day ago"?
It's only been less than an hour!
Patrons can get early access ;)
Are there examples of games in which we can easily observe this problem?
Your videos are a masterpiece, instead of just speaking, and mentioning just the happy path, you show extremely well-designed instructional graphics and exhaustively explain in detail every mode of operation and edge case.
You are a legend, my friend 🙏🏻
Wow, well now I know why that happens in Zelda with that bomb spot.
These videos are absolutely perfect every time, you deserve 44 MILION subscribers rather than 44 thousand.
Keep up the amazing videos!
I would say 2 billion.
@@nathansos8480 2.147 billion
I am absolutely amazed to find out that "slow down" didn't happen at ALL how I thought it did. (Though to be fair, I was a kid when I formed my thoughts on how it happened!)
How did you think it happened as a kid?
I sort of pictured it as so much info getting dumped onto the processor that it literally had to slow down, so the machine was just doing everything it always did, but at a slower pace. I now see that a CPU running "slower" now makes no sense. And how could you cram more info into it than it could take at once? =o)
Well, CPU would just run at constant speed unless you use some sort of variable crystal clock to mod the CPU, or the CPU can run multiple cycles in one clock tick. Both aren't happening in retro CPUs.
As for CPU running slower, it can happen in modern CPUs, for combating overheat situations. (That's mainly why laptop seems to "degrade" in performance over time.)
As for cramming more info into the CPU, well, people actually found ways to do that. But it's a bit too complicated so the simple way to say it is, info lines up better nowadays and thus CPU can take less time grabbing the info and spend more time working on it.
野龍
Which is great information my 36 year old self understands, but my 8 year old self would have been like, "That's a whole lot of words I don't understand." Then he would have farted at you because farts were the epitome of comedy at that age.
Dargonhuman
At the time you was 8 I wasn't even born yet. And since I'm in China, the thing is, people are still believing that human bacteria can infect computer and thus every computer room have their visiters taking their shoes off.
Also, even nowadays, just how easier it is to explain how CPU power improves over time anyway? :) I mean, most people, including me when I was a teenager, would just think that "better clock speed = higher performance" and assume we know everything already XD
mmh. Really well explained.
Worth noting that a major advantage of PAL systems (which is rarely utilised, because doing so would make games that are almost unplayable on an NTSC machine, which for obvious reasons isn't great if you expect to sell the game... It would preclude selling it in America or Japan...).
Anyway, they have a substantial advantage in terms of how much VBLANK time you have to work with.
It's anything up to 85% more time. In theory this would allow some really complex graphical routines that would choke an NTSC machine, but as I said, for practical reasons this tends to be avoided. (except in tech demos.)
This by the way isn't an advantage to the SNES specifically. Variations of this advantage show up nearly across the board in 8 and 16 bit consoles and home computers.
It's such a big advantage that a lot of the demoscene uses PAL machines in preference to anything else...
Or maybe arcade cabinets tend to build on PAL system instead? I'm not sure if that's the case though. (At least in China, many old cabinets were probably pirated ones, while newer ones basically just don't have to worry about these stuffs at all, and there aren't really any LCD screen that works exclusively on 50Hz.)
That seems unlikely, but it's possible. Most arcade machines are simply more powerful than home systems in general.
You can see that by looking at the Neo Geo, which had a home version with the same specifications as an arcade machine, but was exceptionally expensive...
CRT arcade machines didn't use PAL, NTSC or any color encoding, they used RGB component signal. Refresh rate is controlled by the game, doesn't necessarily have to be 50 or 60hz.
For example original Mortal Kombat runs at 53Hz.
Worstplayer
But it doesn't stop people from turning a SNES into an arcade machine. Not sure if the game can adjust hsync and vsync though...
One of the reasons C64 demos were so more popular in Europe.
Best one yet! I didn't want this video to end. I'll never forget the flickering black line at the top of the screen, now I know what causes it. The Sega Genesis and its infamous CRAM dots make more sense to me now as well, I better understand why programmers needed to hide palette changes in the 'offscreen' code.
Congratulations on those gold videos, this is the kind of information I searched so much on the internet in vain. These SNES delays mainly when there are many koopas in SMW I believed to be a limitation of the sprites table, I never imagined that the problem would be directly related to the old tvs
The quality of the animation is always super good; even if I know most of the stuff I just can't sdtop looking for a single second
Hoooooly crap, what an informative and incredible video. You go into some incredibly in-depth things here, but you manage to explain them in layman's terms that anyone could understand, with some amazing editing thrown in. Dude, you're a legend.
Really loving this series so far!
I understand almost nothing about the hardware/code aspect of these things (Games/Consoles) and have always wanted to understand it. Your explanations and visual examples have really helped me to understand these things!
Thank you so very much for your amazing work, and I look forward to seeing your next video! ^~^
Your videos are so freaking good, it is unreal. I wish you continued success.
this is so cool. I stumbled upon this while doing some super Mario world research, and I'm glad I did. 10/10 best explanation series ever. Animations, commentary, and info is just so great. I can't believe learning can be this enjoyable, even after graduation! Thanks
I'm... going to need to watch this once more. I couldn't take in everything at once.
You really go out of your way to make these videos in depth.
Each new entry in this series is a real treat that I patiently wait for. Awesome work man! I am so looking forward to the SPC700 video.
What a fantastic series. I mean this in all seriousness, this series deserves recognition well beyond the bubble that is youtube and the gamer-kid sphere. Outstandingly comprehensive with superbly produced presentation.
This was incredibly fascinating, and your animations helped so much to clarify things!
I learn so much in these videos... really fascinating stuff. Keep up the good work!
Holy shit I just found you and your stuff is great. For someone with such high quality stuff you deserve more subscribers. Keep doing what you’re doing man
i've being watching all your videos about nes/snes and it really blows me away; i'm noob at the subject but you made me understand with more ease, and i really appreciate it!
You've done an amazing job here, excellent work!
Best video in the series so far, in my opinion. Really interesting stuff. Good work!
These are some amazing visualizations. Thank you for doing this series.
Awesome video as always! I never knew that actual CRT functionality was calculated in the SNES!
MegaZeroX7 it surely does. In fact, the light gun used in the SNES detects the point you're aiming at by reading the CRT position when you fire it. Basically, the light gun is pointing at a specific point, and when it detects light, it tells the SNES to read the CRT position to determine where you're aiming
Sadly, because of this, it doesn't work on LCDs
@@ddnava96 wait, I thought the SNES had a white square for one frame when you pulled the trigger, and whether or not the gun saw that square determined if you shot..
or am I thinking of the NES light gun?
Yes, You’re thinking of the NES. Unfortunately that also doesn’t work on LCD screens
@@ddnava96 That's amazing. See, this is why we should have stuck with CRTs.
@@flurf5245. That one with white squares was on the NES and it had to stop the game while it was showing the squares. The SNES had a more clever approach with the CRT position in order to calculate it immediately without needing to stop the game
I love these videos! I always come in confused and come out with actual knowledge, plus I love learning how electronics work! Keep it up!
Thank you for the great video! Is the script or tool you used for overlaying the overall timing utilization (14:49) something that occurs in real time, or composited in post-production? If it's a script, it would be a wonderful TASing tool!
I use a modified version of this script I made to create that scene: pastebin.com/2rmgbL7V
It's built for lsnes and the offsets at the top are set for the English version of Super Mario World (it should work for any SNES game given you know where to hook those two parameters).
Pastebin? Dude, get a GitHub! This is useful stuff!
Thanks, Mr. Explained! This channel is just amazing and explains things very well.
I not only learned how the SNES works, I also now know how CRTs draw images. After watching this I finally could understand Technology Connections' video on television, heh
This is really interesting. The little infographics are well put together and clear too - thanks for this.
Very nicely done, I liked the animations you've used as well as the subject itself!
The visualizations are just wonderful, I've been working with these concepts in mind for years (albeit on the NES, but it's 90% the same) and it's great to actually see it represented by something more than activating a tint register when spinning begins to see a visual representation of the CPU load.
I get so happy every time you upload!
Great video! You did a good job of explaining one of the more important but overlooked parts of retro graphics.
This is awesome and very well explaned! I can't believe how much time it must've taken to edit!
Wow, now I'm so interested about HDMA, having revisited your earlier videos on this subject! Awesome work! Very detailed and informative. The math explanation in Mode7 is top notch! :)
And as with this video is likewise very very well made. Even if you may grasp some of these on the fly without really understanding what it does, your videos make one see exactly what's going on.
This is so well-explained and animated that it was easy for me to understand the concept despite not being knowledgeable on this topic. Really good job with this video!
These are great videos. As someone who used to write emulators for their full time job: I'd want you on my team. You explain the Super Nintendo hardware very well.
great video, really informative and the visuals helped explain everything clearly
dude your videos are awesome, I see them since more than a year for first time I comment, keep up the good work!
I really thought I wouldn't understand this topic, but your explanations and visual representations are great. I had this doubt for ages and now I clearly understand what's happening. You are the best.
Had to comment on that data visualisation you pulled out for the time it takes for everything to happen in a frame. I work with data as part of my job and that's one of the best things I've seen this year.
Really love these videos, keep em coming!#
Wow, that animation for H-blank and V-blanking was so good. I had always seen those but never really knew what they meant, good job!
I had no idea so few instructions could be completed per frame. Thanks for the visualization!
Excellent depth of content here. And well demonstrated. Thankyou :)
Writing a simple composite or rgb display program for a pic or fpga really gets the idea across how analog screens worked
Your videos are so great I never thought I could understand and learn something like this though a youtube video
Fantastic video! This explains a lot! Thanks for the content!!
Another excellent video! Thank you for these!
This video was EPIC! I now know more about the SNES than I ever did before... I can't wait for more!
Fantastic content, well researched and highly informative.
Fantastic video. I don't think I've ever really understood why the SNES only used 224 lines instead of 240. I've always figured that the V-BLANK period for the SNES was the same as the VBLANK period for a TV. Now it makes sense.
LOVE the commentary. I guy I know said that you've discontinued it. If that's true I hope you start again. I fucking love it.
Back In The Day when I developed for the Nintendo DS (whose PPU was similar to the SNES's but it allowed register updates and DMA during rasterization), I actually used a trick to visualize what routines were taking up my frame time so that I could order my routines appropriately, by changing a palette entry at the start of each function. This let me see when in the frame each function was running and how long it took, so I could then change the order they were run in and try to prevent them from occurring during or after their part of the screen refresh. :)
This is a trick I picked up from the demoscene, since the Amiga had the "copper" coprocessor which was used in this way purposefully (and some enterprising PC developers figured out means of simulating it in the main CPU instead).
We used to do the same on PS2 also, it had a background colour register you could write at any time during the frame. Kind of epilepsy inducing if running at anything lower than 1 frame though!
And here I was thinking that this episode would be boring, when I can now safely say it was one of the most interesting ones to date! Can't wait for the next one!
The level of detail you give on these concepts is worthy of a GDC talk if not outright it's own course
This was a very informative video, now I feel like I finally understand these concepts.
This is amazing. Really well done
Great visualizations!
Damn, I love your animation, I like to learn visually and that really helps
wonderful work as always. cheers
So well explained and presented so well on top of that. 11/10 stars
This was a great video. Thanks for making it.
Amazingly detailed explanation! Thanks a lot!
Terrific work as always :-)
Great video! Loved it!
"This all takes place within a frame of course"
That's actually really fuckin impressive for what it's doing, this shit amazes me
When I turned off my SNES on my old TV I had, it would always show colorful lines, mostly blue and purple on a black background. Now I get an idea what those lines were for.
Man I'm loving these, can't wait for more! Anyone know where to find more videos like this? I'd be really interested on a detailed breakdown of how, say, the Sega Genesis worked.
Anyway, keep up the fantastic work!
Nice video! I've learnt a lot!
Great video. So far the easiest to understand. Thanks a lot :)
I love how programmers back in the day knew all of this about the hardware and just used it to their advantage. One way I could see it being used is maybe preset a puzzle or physics effect, have a timer that is really just a couple frames and use those lag frames to do all the movement calculations, then it just spits out preset values for where things would go. Not sure if the RAM is big enough to store all that but it's a start
11:28 - so that explains the quick black bar I've noticed in ALttP when one lifts the big block in the basement of the Thieve's Town dungeon.
Amazing stuff man.
Some of the finer minutia goes over my head but overall I understand these videos pretty well. I'm very much of a fan of this approach to explaining how an old console works, your active examples and demonstrations make it far easier for a visual learner like me to better understand it.
And for period accuracy of the time, even if you could actively notice at that one point that black line at the top when the background was updating from that bomb explosion, you really wouldn't be able to physically see it on a CRT because most TV sets of the day had thick plastic framing around the tube that would crop off the edges of the screen, a little on the sides and a lot at the corners. All the ones I ever owned did.
Of course, if you're into retro consoles, I'd still recommend an old CRT TV to play them on, it's how they were meant to be seen.
Thanks for another awesome video!
Wow. Just when I thought this channel was dead, you upload! Awesome!
This one probably took a bit longer to make due to how precise and dense the animations had to be.
Wow, this is top quality stuff dude. I'm amazed!
Would you consider doing a very simple introduction to programming on the SNES?
ie; explaining the boilerplate code, drawing a single pixel, etc..??
Really interesting stuff, thanks!
Omg. You are a monster! Excelente video my friend! You rule!
Great video as always
You're awesome dude. Fiending for my next fix
Man, that's a good stuff!! Thank you!!
Holy shit those are some good animations!
The precision of old tech is incredible
super interesting, great job!
Been looking forward to this!
New RGMX and 3B1B videos on the same day?!? I can die happy now
Interesting that the DRAM strip in the frame paint is in the exact spot that people exhibit the video flaw of a lighter line in the video output...I wonder if writing to DRAM is causing a strain on some of the components which leads to this video artifact on many aging SNES consoles...
I always thought it was coupled noise, but hm, it could be PSU fluctuation. Might be interesting to watch the 5V rail on a scope with a h-sync trigger.
It's a common flaw to other systems too. The Mega Drive/Genesis frequently develops the same problem.
Fundamentally it's some kind of noise on the video output. Though the exact source is unclear.
There are many known fixes for the Mega Drive, and on that system it clearly has nothing to do with DRAM, but on the SNES... I'm not so sure.
It's also a form of visual artifacting mostly seen on the earliest revisions of the console. (There are at least 4 versions of the hardware internally)
I have a super Famicom that is from 1990 and shows the problem quite strongly nearly all the time, but then I have a PAL system which is a much later revision (1994 I think), and while the effect is still there, it's all but invisible except on very dark backgrounds. (especially black).
I've taken both apart so I know that they are completely different hardware revisions...
Definitely noise of some kind... But I'm still not entirely sure what the source is.
That's the first thing I thought of too when I watched the video!
Both of you are correct. It's coupled noise from the DRAM refresh pin.
Super cool, thanks man