NOTE: If you have noticed that the quality of this video seems way worse than normal, it's not just you! TH-cam changed something regarding how videos are compressed, and no matter what I do I can't get the same quality I used to. I've tried rendering the video probably 20+ different ways, including changing bitrate/format and removing/brightening the background texture, but it all looks bad. If this problem is fixed in the future, I will reupload this video to recover the quality.
Im not sure what they changed this time, but i remember a few years ago when GTA5 was just released, it would show immense compression artifacts! (on the tubes) i found the only way to combat this was to upscale the video to 4k or higher (using avidemux) and then it would look pretty much normal if played back in 1080p. I dont remember if there was a setting to make youtube convert it to 1080p or maybe there was some setting later to just disable 4k playback... all i remember was that we had to upscale it to 4k before uploading lol
experimental video encoders.. i wonder if youtube changes the encoder profile based on server loads... or maybe channel subscribers?!... maybe you should do a video "modern video encoders explained" after you do the video "how blast processing works".. anyway i don't mind the video quality just the content quality... so is perfect.
@@raafmaat This was one of the things I haven't tried yet, mainly cause I really doubt it would work. But I can give it a shot since a few people have mentioned it to me now.
@@docwhogr I think it's a dynamic thing. It looks absolutely fine to me even at full screen. I have noticed at times that YT can look horrible. I think they do send lower res video when overloaded and just lie about the resolution.
raafmaat the tubes looked terrible because they had loads of high frequency luma and colour content… pretty much all video compression works best with low frequency content, i.e. smooth gradients and little movement. Only one I can think of that doesn’t is quicktimes Animation compression but that’s gone the way of the dodo. Shame.
@@sl1pz369 The entire point of this channel is to explain to the average layperson what the devs were already intimately familiar with. It just seems to be a weird complaint.
Yeah, when you start reading the documentation it's easy to get lost in it all. Especially if you then compare it to a Mega Drive. That has it's own areas of complexity (highlight + shadow mode being especially odd), but it doesn't come close to how complicated this is...
@@KuraIthys It's very interesting to contrast the system philosophies of the SNES and Mega Drive. SNES had a really puny CPU, but it had lots of fancy hardware assist features. The advantage is that the hardware is much faster, but the hardware is fixed, it can only do exactly what it was designed to do. The Mega Drive had a much beefier CPU, but much less hardware to aid the CPU. The MD could do all these effects and more, so it was more flexible, but it was limited by that fact that the CPU can only do so much, so especially large full-screen effects are extremely difficult to pull off.
The Mega drive can't really be said to be capable of all these effects. Except insofar as ANY computer can do them, if it has enough processing power (see, the PC). A bunch of things that the Mega Drive struggles with because of the nature of it's graphics hardware. Also I wouldn't call the SNES CPU puny as such. There's a quote from Steve Wozniak in relation to the Apple IIGS vs the Macintosh. (aka 65816 vs 68000) where in his opinion a 65816 running at 8 mhz was equivalent to a 68000 running at 16 mhz. You can see evidence of this in the fact that for instance the 816 accesses memory on every cycle, while the 68000 accesses it on every 4. Taking into account it being a 16 bit access this still means that for any given clock speed the '816 actually has twice the memory bandwidth. Of course, the MD's CPU runs at 7.16 mhz and the SNES' at 3.58... Which on paper should make them broadly equivalent. Except of course, the RAM in a SNES (and ROM in early game cartridges) is actually only rated for 2.68 mhz, which slows the system down by 25% (this also contributes to why later games seem more capable than older ones - it's not just better coding.) So where they may have been equivalent in theory, the forced slowdown due to memory that's too slow makes the SNES roughly 25% slower even hypothetically. Having said that, the SNES has a problem when using the CPU to do work, which the Mega Drive does not - Mega Drive graphics are packed pixel (all the bits for a single pixel are adjacent in memory, so you can update them with a single write to memory), while the SNES is based on bitplanes (each byte contains a single bit of data for 8 different pixels). In the worst case (256 colour graphics) this forces a SNES to update 8 bytes to draw a single pixel. (the Mega Drive can update 1 byte in the same situation. - a BIG difference.) This makes it much harder to use the CPU to do anything, and may be why the SNES seems underpowered, when the CPU isn't as weak as people generally think it is. That's not to say nobody ever drew graphics on the CPU of course - I recently saw a lecture from GDC that discussed the SNES port of lemmings 2. And the lemmings in that aren't sprites, but rather they're drawn by the CPU... (meaning they use no hardware acceleration at all.) Of course, Lemmings was originally an Amiga game, and the Amiga has the same limitation (bitplane based graphics), so if anyone's going to know how to deal with this it'd be an experienced Amiga programmer. XD Still, I would summarise the difference between the two systems more like this: MD: - small feature set, but you can use almost all those features together in any combination. SNES: - large feature set but many conflict with one another, and you need to think about what you're trying to use together quite a bit more. Also the SNES sprite engine is a disaster. Which also didn't help games much. MD sprites: Any multiple of 8 size from 8x8 to 32x32 is possible, including uneven sizes such as 8x32 or 24x16 - All possible sprite sizes can be onscreen at the same time. SNES sprites: Square sprites only, in 8x8, 16x16, 32x32 or 64x64 pixels. Only 2 sizes can be active at any given time. It might not be immediately obvious what's so bad about the SNES sprite system, but it quickly forces you to make some really difficult (and limiting) choices about how to deal with sprites.
@@KuraIthys Yeah, the planar format complicates bitmap emulation which is one of the reasons why enhancement chips like SA-1 (character conversion DMA) and Super FX (pixel plotting) were created. I wonder if that was the result from a split VRAM chip as the mode 7 GFX format also is linear (which, tbf, had to be done to quicken the linear transformation) but also puts the graphics and tilemap into seperate chips/interlaces them.
@@KuraIthys I'm sure you know this but i want to add that the SNES CPU did have less registers which mean there was some shuffling overhead compared to the 68000. I personally like working with the mega drive more because it's easier but I feel like what mattered more was the graphics capabilities than CPU and the SNES was able to keep up as you said.
So you have a bunch of layers. You mask them and send them to 2 output images, and then you can blend those two output images together to create effects. That's the TL:DR for everyone who got steamrolled by the circuit diagram. Personally, I think everything about this is fascinating. There's no avoiding how complicated the diagram is because all of this impressive compositing is being accomplished in hardware, so it's all controlled with a bunch of on-off switches. I prefer seeing all the details because it shows WHY it works this way.
Kind of, but in actuality not really. Most of the blending and masking math is scanline based and doesn't apply to all elements. Sprites can only be affected in a limited way. For example, they can't be really used for HDMA effects such as scanline manipulation or palette alterations midframe.
@@inceptional Yup, just make sure you have a) enabled windowing for all layers (non-inverted) b) enable the main and subscreen mask for all enabled layers (though they're usually set to the same value as the main and subscreen registers anyway) c) don't "prevent color math" i.e. the subscreen window doesn't turn the subscreen black
This is what TH-cam should have more of. High production value educational videos that manage to be entertaining at the same time - all while maintaining a calm and laid back atmosphere. And the uploader doesn't even condescendingly push the viewers to like the video or subscribe. Those like are truly deserved.
@@MaxOakland It now only has a few modes. One is a blend mode where you assign different planes to A and B targets and a simple multiplier for them (so final color = color in A * weight A + color in B * weight B). The other two are blend to white and blend to black respectively. Though you can put backgrounds, sprites and windows in the mix to alter the area where the blend is applied.
@konakonaa It's because you missed one key point: That sprites with the palettes 8 to B don't get affected by colour maths if they're on the main screen but if they're put on the subscreen, they are. Or in other words: Ever wondered why Mario (and a couple other sprites like feathers, etc.) don't get affected by the darkness in SMW (which *does* use your method)? It's exactly this reason and Rare chose the more complicated (but necessary!) method to avoid that!
You don't understand because of the way it's explained. He not a teacher, just talking to about what's in his brain. Teaching is a skill. This is no different than reading a boring book. Shame as this is really good stuff in the right hands
@@Tangobaldy I'm aware of this, I know it's not *teaching* but it's still informative, and it's enjoyable either way. I'm in the process of learning about a lot of this myself and I still find the content super informative. No matter what background you have, if you have an interest in this kind of thing, it's by no means a useless watch. This kind of content is open to everyone and it may even spark new interest in some.
@@Tangobaldy i disagree. I don't know a lot about computer science but if i listen in i can still understand a lot of it. I feel like he really does teach. Maybe not the most useful subject, but still.
When I first watched this video it sounded so cryptic and complex to me. Now I'm watching it the third time, while (re-)writing parts of my PPU for my SNES emulator, and this thing is just a piece of beauty, and so great to follow, to write really compact, logical code from it. Thank you so much for this!!
Love love loooove these videos. Don't understand a whole lot, but thank you for explaining the inner workings of the SNES in such great detail. Maybe do the N64 Next? Be sure to crap on them for the tiny texture cache!
They cut down on texture cache so they could actually get a 'cheap' R5000 CPU in there. They even used RDRAM which was very expensive at the time. It would've been nice to get more but that would've raised the price of the console significantly.
@@asp-uwu It's actually pretty fascinating how they even managed to get 3D platformers working on the system at all! You can see it struggling most of the time with polygons jittering and textures warping all over the place, but they did it. Insomniac should be given more credit for making the Spyro games look as good as they did on the system. There's a reason so many games on playstation have a fixed camera with pre-rendered backgrounds. That's why I find it more interesting. I think the n64's shortcomings have been discussed enough.
@@anactualmotherbear The N64's graphical advancements, not its shortcomings, should be focused on. It was effectively the first game console with a modern architecture for its 3D graphics. Custom microcode could create something like our modern shaders for lighting, and the clever use of mipmaps allowed for two textures per triangle. This was way beyond the PS1.
For me it's like Spanish where. I can understand some of it but then there are some words I don't know. I keep watching in hopes that I will learn to understand it all
The motivation behind shaders is to make GPU programmable instead of being depend on and limited by fixed set of features, this is also reason why consoles are nothing special now days because what can be programed on PC GPU can be also done on Console and there not much room to go beyond that those unique GPU features is what elevated consoles over PC.
While watching this, I was surprised you didn't mention how windows can have their shapes altered while the screen was being drawn, but then I suspected that you probably already explained that in the video right before this one, and... yup!
Could you please, in a future video, explain how different consoles stored background tiles and sprites? People like me usually get to know how it is in the NES, but how do the SMS, Genesis, etc. did it?
I like how the Genesis and GBA store their tile graphics data. Both of them store it linear or chunky as some would call it, with each byte having two pixels. The only difference is which nibble is the left pixel.
My intuition is that they differ mostly in some minor technical aspects and the complexity they allowed. Focusing on one console lets RGME go in-depth on how that console works, and ensures he won't repeat much the same information repeatedly.
I wonder how many developers are just wishing this video series was available back in 1991. How many people are kicking themselves for the hours they spent in frustration and the days of lost productivity while they were trying to learn how to program on the SNES, and here's this video that explains everything so clearly and easily.
Huh. I mean, I know this isn't a straightforward process to explain, and your examples are great at highlighting what this can accomplish... But somehow you make this sound even more complex than I remember it actually being in practice... XD
I found that it seemed more complicated to me too. I think the main reason is that it is not very common in practice for every single thing explained in this video to be used at the same time. It is also more likely that only one or two is used at once. While it is true that all of this stuff is happening all the time, most of the time, most of it can be ignored.
Fantastic production, as always. I think it's possible that you have a more complete understanding of some of these systems than even the people that were developing games back then. Did you learn all of this just form the developer documentation?
The developer docs helped a lot, but there is a lot more, easier to read documentation online by other people who have done more primary research than I have.
The window pipeline seems pointlessly complicated. In the end, all it's doing for each of the six outputs is selecting some boolean function of the two (layer-independent) window masks. Since there are 16 two-operand boolean functions, this choice could have been encoded in 4 bits (per layer). Instead they encode the same information in 6 bits spread across two registers, and along the way manage to only support 15 out of the 16 possible boolean functions.
In fact, if you add the main/subscreen window switches, then it's 8 bits (10 bits for the final masks) to two select two boolean functions (one for the main screen, one for the subscreen) of the window masks, except it only has encodings for 43 (60 for the final masks) out of all 256 possibilities. I feel like using six pairs of independent window function selectors (4 bits each) and placing each pair into a single register, would have been more flexible, more convenient for the programmer, and easier and more efficient to implement in hardware.
This is the best channel that I have no understanding of on TH-cam. I look at these videos the way your dog looks at you when you try to explain your relationship problems to it.
Wow, so apparently Donkey Kong Country did it the hard way. They could have just drawn the flashlight to the sub-screen and subtracted that from the main screen, but instead they subtracted an inverted version of everything else from the flashlight to get the same result. Very clever... but unnecessary.
Their method allows the unlit portion to be darker than it otherwise could be since the value would go negative and get clamped to zero, and become transparent/ignored instead of being pure black. They get around that by making black color a high value instead of 0. In the SMW example, it never gets darker than a dark gray color.
Keep in mind that this resulted in a dark room effect where not all sprites are dark similar to SMW's dark rooms (ever noticed how Mario, the feather, score and sprite coins are always bright in these rooms?) due to the limitation where only half of the sprites can perform colour maths.
@@ddud4966 After one year, I now understand your explaination. And it really bugs me as this explaination is just plain wrong. SNES graphics are a bit like a GIF i.e. indexed colours. To denote a tile to draw nothing, you give a pixel the colour index 0. One example are the firefly rooms in Super Metroid which use colour maths on layer 2 (not palette animations as one might assume) for the darkness effects. The more fireflies you kill, the darker the rooms become until layer 2 becomes completely black (well, almost as the brightest colours such as white would still be visible but Super Metroid uses rather dark colours). If going by your theory, you would be able to see Samus at full darkness but on the actual SNES, Samus is actually still obstructed by the foreground.
I loved my SNES when I was young, and I love that you have taken the time to go through and explain how every feature of the machine works. That being said, your videos are a bit like being held by the ankles over a precipice: you think, "Okay, this is sounding a little fun, and then wHOOP-" your language immediately becomes impenetrable as you shift your grip, and I am left to doubt my capability to stay on. I have tried to watch the series several times to catch what you mean sometimes, but its become obvious that these videos are for people who already have a rather healthy understanding of programming and system architecture. Thank you for your gift, though! It is rare that someone opens up and explains just how something you used to take for granted actually works, kinda like my dad explaining to me how his truck was put together when I was young.
I was able to mostly follow the explanations up until about now. You use a lot of technical jargon that doesn't make much sense to me, like what is a subscreen or a main screen? What is cold data? Theough main or sub register? The TMW and other stuff that I don't really understand. You mention Windows 1 and 2 or subwindows and whatnot, but what's a window? I thought it meant the screen or something or maybe a window like how if you click and pull a tab from your browser it makes it a separate window, but it doesn't seem to be the case based on how it's being used here. Is there a explanation for dummies you could recommend on how computer chips work or whatever this stuff is referring to? Every tutorial I find for the SNES or programming in general already assumes I know computer jargon or how it works on a basic level and its frustrating because I don't and can't find anywhere where it can explain it.
10:49 That makes so much more sense, every time you said a Link to the Past, I was some reason mixing it up with A Link between Worlds, which is interesting since I never played A Link between Worlds.
Photoshop and Illustrator for making the graphics, After Effects to animate them, Audition for recording voice over, and Premiere to sync the voice over to the animations.
How did anyone ever figure this out? Unless there was some kind of documentation included with dev kits. I don’t see how anyone could reverse engineer this.
I do have a question though. You say when both windows are disabled, the pixels will be treated as "inside the window" by default - but how is that handled in the schematic? Both W1 and W2 would remain false up to the Muxing with WinLog, which usually is set to OR, and then still output false, finally resulting in disabling the pixel. What am I missing?
I’ve never owned a snes, don’t know much about programming or computers in general. Yet I can still follow along with most of this. Really interesting and engaging stuff!
@@jefflinahan5853 When you get the key in smw and put it in the keyhole the black stencil of a keyhole scales up then scales back down all while the background is still displayed. I think it was explained it in a later video on this channel that is works similar to the metroid 3 light.
Scaling outside of Mode 7 on its own isn't an issue on the SNES, really. Heck, ALttP even uses dynamic graphics for the triforce and crystals. The issues about scaling graphics mostly come from the complicated graphics format (case point: neither SA-1 nor Super FX would be as effective if the were stored in the same format as on the SNES) but windowing, which doesn't use pixels, only start and end, doesn't have this issue.
The keyhole effect works by changing the window 1 left and right borders, per scanline , and per frame, manually. So in everyframe it should be doing calculations to get the two results for every scanline ( it's like being software renderered )
The SNES graphic chip capability was quite impressive for its time, even without support from the Super FX chip. Even though a SNES was far slower than a PC of its era, its games usually ran slowly because of how complex the graphics chip was to emulate... And then, 30 years later, its entire graphics pipeline could be coded in a single pixel shader running on my smartphone.
I love the intricacy of this pipeline... I'm wondering, maybe I didn't get it, but what is the advantage of the Donkey Kong flashlight method versus the Super Mario disco ball method?
Request:Nasha Gibelli's program for the NES version of the Final Fantasy series Explained. According to the information heard on the net, He was good at a large-scale interrupt routine, but I heard that there were many bugs because of the interrupt routine.
I watched and understood all of your videos mere days ago, yet even I had no idea what these windows are. The beginning of the video makes no sense until 8:25 at which point the windows and the subscreen are FINALLY explained. Especially considering that "window" normally means some sort of a rect with coordinates, width and height.
7:47 _click-clack_ if the half flag... :D Edit: There are some more clacks after that even. I do not have any complaints about the video quality however. Maybe the reprocessing actually worked?
I unsubcribed so I could subscribe a second time...I still don't get it how cat videos can get millions of views and something like this is missed by most people...
Can’t wait to move on to the sound part. All i know is that in high-res mode, the snes could only run in 1bit or 2bit color mode due the limited processing power & limited ram ,it’s no surprise that nintendo implemented 8 FIXED modes rules inside in the snes to prevent comflictsbugs,slowdowns and crashings etc,,that way to help game devs to make stable games, just imagine if nintendo allowed game dev’s to run a snes in high-res,high color mode and 4 BG layer mode all atonce, sure the snes would had run at 0,0000000000000,1fps, so sadly nintendo’s ads at the early 90’s were somewhat MISLEADING!!!
The SNES does not natively support 1bpp graphics and hires mode does have a 4bpp layer as well as a 2bpp layer. However, this is still less than mode 1's two 4bpp layers and 2bpp layer, and in addition, sprites are still low res in hires mode. This limitation has nothing to do with the CPU, but rather vram bandwidth. There is no way to increase PPU (GPU) capabilities by lowering framerate because the SNES graphics hardware renders the screen as the TV is drawing the picture; it doesn't have a framebuffer like a computer or modern game system.
There is actually an unused level mode in SMW that would have allowed for transparent water. I have no idea why it was never used, since it's fully functional.
The problem isn't lack of knowledge (in fact, Nintendo knew how colour maths even works) but there is a technically problem, namely that SMW usually puts layer 1, 3 and the sprites on the mainscreen and layer 2 on the subscreen but if you want to make the water transparent, you would have to move layer 1 and the sprites to subscreen. The problem is that layer 2 has got a similar priority as layer 1 in background modes 0 and 1 so if a sprite like Mario moves behind layer 1, he'll also disappear behind the background. Unlike the unused level modes 1E and 1F (the former which makes layer 1 transparent and the latter which is a layer 2 level except layer 2 is transparent), level mode 0E makes layer 3 transparent to the rest of the layers but it's only used for the Ghost House entrance.
Looking back into the comment, there is one solution to the problem: Put layer 1 and objects on main- _and_ subscreen. The idea is that if you enable layer 1 and objects for main- and subscreen, you can have sprites which "always" go in front of layer 2 and still have them affected by colour maths. On the mainscreen, nothing would be different from the tide since the mainscreen register didn't change but on the subscreen, layer 1 and objects usually are obstructed by their mainscreen counterparts. Now the trick: When the latter go underwater, below layer 3, they disappear. If you enable colour maths on layer 3, they still disappear but at the same time, you can see the subscreen i.e. layer 1, 2 and objects so it looks like the former and latter haven't been visually obstructed at all. It's a bit difficult to put that in words and images would help for that. But for that, you need another level mode which is one of the lesser problems since there are a couple unused numbers. The real issue is that this trick doesn't really work for Mondo, the special world level with the rising tide since at high tide, it obstructs layer 1 and objects on the mainscreen so any object (e.g. Mario, powerups from ?-blocks) which goes behind the foreground also go behind the background at high tide.
Amazing quality as always! Why did DK use the inverse method to do shades instead of going for a system like MW? Is it because it's less easy to encounter color clipping, which might happen more due to the more "realistic" palette of DK due to the prerendered nature?
It's because of the colour maths limitation on sprites as only half of the sprite palettes are effected. Take a look at SMW's dark room: If you look at Mario, score, sprite coins or a feather (all which use palettes 8 to B), you'll notice that they're unaffected by the darkness unlike the enemies, mushrooms and fire flower (which use palettes C to F). The negative avoids this issue.
NOTE: If you have noticed that the quality of this video seems way worse than normal, it's not just you! TH-cam changed something regarding how videos are compressed, and no matter what I do I can't get the same quality I used to. I've tried rendering the video probably 20+ different ways, including changing bitrate/format and removing/brightening the background texture, but it all looks bad. If this problem is fixed in the future, I will reupload this video to recover the quality.
Im not sure what they changed this time, but i remember a few years ago when GTA5 was just released, it would show immense compression artifacts! (on the tubes) i found the only way to combat this was to upscale the video to 4k or higher (using avidemux) and then it would look pretty much normal if played back in 1080p. I dont remember if there was a setting to make youtube convert it to 1080p or maybe there was some setting later to just disable 4k playback... all i remember was that we had to upscale it to 4k before uploading lol
experimental video encoders.. i wonder if youtube changes the encoder profile based on server loads... or maybe channel subscribers?!... maybe you should do a video "modern video encoders explained" after you do the video "how blast processing works".. anyway i don't mind the video quality just the content quality... so is perfect.
@@raafmaat This was one of the things I haven't tried yet, mainly cause I really doubt it would work. But I can give it a shot since a few people have mentioned it to me now.
@@docwhogr I think it's a dynamic thing. It looks absolutely fine to me even at full screen. I have noticed at times that YT can look horrible. I think they do send lower res video when overloaded and just lie about the resolution.
raafmaat the tubes looked terrible because they had loads of high frequency luma and colour content… pretty much all video compression works best with low frequency content, i.e. smooth gradients and little movement. Only one I can think of that doesn’t is quicktimes Animation compression but that’s gone the way of the dodo. Shame.
I bet devs would have killed to have this series on a vhs back in the day.
Back in th day devs had meetings, slides, and conferences about hardware functioning.
Or on a series of Video CDs.
@@sl1pz369 what are you on about
@@sl1pz369 The entire point of this channel is to explain to the average layperson what the devs were already intimately familiar with. It just seems to be a weird complaint.
@@DraGon72097 I dunno, it seems awfully techy to me.
I never realized the snes had so much versatility in how literally any pixel on screen could be drawn
Yeah, when you start reading the documentation it's easy to get lost in it all.
Especially if you then compare it to a Mega Drive.
That has it's own areas of complexity (highlight + shadow mode being especially odd), but it doesn't come close to how complicated this is...
@@KuraIthys It's very interesting to contrast the system philosophies of the SNES and Mega Drive. SNES had a really puny CPU, but it had lots of fancy hardware assist features. The advantage is that the hardware is much faster, but the hardware is fixed, it can only do exactly what it was designed to do. The Mega Drive had a much beefier CPU, but much less hardware to aid the CPU. The MD could do all these effects and more, so it was more flexible, but it was limited by that fact that the CPU can only do so much, so especially large full-screen effects are extremely difficult to pull off.
The Mega drive can't really be said to be capable of all these effects.
Except insofar as ANY computer can do them, if it has enough processing power (see, the PC).
A bunch of things that the Mega Drive struggles with because of the nature of it's graphics hardware.
Also I wouldn't call the SNES CPU puny as such. There's a quote from Steve Wozniak in relation to the Apple IIGS vs the Macintosh.
(aka 65816 vs 68000) where in his opinion a 65816 running at 8 mhz was equivalent to a 68000 running at 16 mhz.
You can see evidence of this in the fact that for instance the 816 accesses memory on every cycle, while the 68000 accesses it on every 4. Taking into account it being a 16 bit access this still means that for any given clock speed the '816 actually has twice the memory bandwidth.
Of course, the MD's CPU runs at 7.16 mhz and the SNES' at 3.58...
Which on paper should make them broadly equivalent.
Except of course, the RAM in a SNES (and ROM in early game cartridges) is actually only rated for 2.68 mhz, which slows the system down by 25% (this also contributes to why later games seem more capable than older ones - it's not just better coding.)
So where they may have been equivalent in theory, the forced slowdown due to memory that's too slow makes the SNES roughly 25% slower even hypothetically.
Having said that, the SNES has a problem when using the CPU to do work, which the Mega Drive does not - Mega Drive graphics are packed pixel (all the bits for a single pixel are adjacent in memory, so you can update them with a single write to memory), while the SNES is based on bitplanes (each byte contains a single bit of data for 8 different pixels). In the worst case (256 colour graphics) this forces a SNES to update 8 bytes to draw a single pixel. (the Mega Drive can update 1 byte in the same situation. - a BIG difference.)
This makes it much harder to use the CPU to do anything, and may be why the SNES seems underpowered, when the CPU isn't as weak as people generally think it is.
That's not to say nobody ever drew graphics on the CPU of course - I recently saw a lecture from GDC that discussed the SNES port of lemmings 2. And the lemmings in that aren't sprites, but rather they're drawn by the CPU... (meaning they use no hardware acceleration at all.)
Of course, Lemmings was originally an Amiga game, and the Amiga has the same limitation (bitplane based graphics), so if anyone's going to know how to deal with this it'd be an experienced Amiga programmer. XD
Still, I would summarise the difference between the two systems more like this:
MD: - small feature set, but you can use almost all those features together in any combination.
SNES: - large feature set but many conflict with one another, and you need to think about what you're trying to use together quite a bit more.
Also the SNES sprite engine is a disaster. Which also didn't help games much.
MD sprites: Any multiple of 8 size from 8x8 to 32x32 is possible, including uneven sizes such as 8x32 or 24x16 - All possible sprite sizes can be onscreen at the same time.
SNES sprites: Square sprites only, in 8x8, 16x16, 32x32 or 64x64 pixels. Only 2 sizes can be active at any given time.
It might not be immediately obvious what's so bad about the SNES sprite system, but it quickly forces you to make some really difficult (and limiting) choices about how to deal with sprites.
@@KuraIthys Yeah, the planar format complicates bitmap emulation which is one of the reasons why enhancement chips like SA-1 (character conversion DMA) and Super FX (pixel plotting) were created. I wonder if that was the result from a split VRAM chip as the mode 7 GFX format also is linear (which, tbf, had to be done to quicken the linear transformation) but also puts the graphics and tilemap into seperate chips/interlaces them.
@@KuraIthys I'm sure you know this but i want to add that the SNES CPU did have less registers which mean there was some shuffling overhead compared to the 68000.
I personally like working with the mega drive more because it's easier but I feel like what mattered more was the graphics capabilities than CPU and the SNES was able to keep up as you said.
So you have a bunch of layers. You mask them and send them to 2 output images, and then you can blend those two output images together to create effects.
That's the TL:DR for everyone who got steamrolled by the circuit diagram.
Personally, I think everything about this is fascinating. There's no avoiding how complicated the diagram is because all of this impressive compositing is being accomplished in hardware, so it's all controlled with a bunch of on-off switches. I prefer seeing all the details because it shows WHY it works this way.
I got steamrolled by the diagram, even if I wrote a SNES renderer for PlayStation and NDS. It's more confusing than actually seeing it in action.
...except you don't actually do it with entire images but pixel-by-pixel.
Kind of, but in actuality not really. Most of the blending and masking math is scanline based and doesn't apply to all elements. Sprites can only be affected in a limited way. For example, they can't be really used for HDMA effects such as scanline manipulation or palette alterations midframe.
@@Kawa-oneechan irrelevant
@@inceptional Yup, just make sure you have
a) enabled windowing for all layers (non-inverted)
b) enable the main and subscreen mask for all enabled layers (though they're usually set to the same value as the main and subscreen registers anyway)
c) don't "prevent color math" i.e. the subscreen window doesn't turn the subscreen black
The level of detail and explanation is insane. Amazing work.
2:49
Him: "the six flags-
Me, never being able to follow for more than two minutes at a time:
WE
LIKE
TO
P A R T Y
This is what TH-cam should have more of. High production value educational videos that manage to be entertaining at the same time - all while maintaining a calm and laid back atmosphere. And the uploader doesn't even condescendingly push the viewers to like the video or subscribe. Those like are truly deserved.
If we want more we have to support it!
The color math hardware in the SNES is so complex it actually got simplified down in GBA and NDS.
What did Nintendo do to simplify it for the GBA?
@@MaxOakland It now only has a few modes. One is a blend mode where you assign different planes to A and B targets and a simple multiplier for them (so final color = color in A * weight A + color in B * weight B). The other two are blend to white and blend to black respectively. Though you can put backgrounds, sprites and windows in the mix to alter the area where the blend is applied.
the dk flashlight part was actually really clever.
that way you can make pixels turn true black while having a value different than 0
@konakonaa Hey, you want all sprites being affected by the darkness instead of half of them!
@konakonaa It's because you missed one key point: That sprites with the palettes 8 to B don't get affected by colour maths if they're on the main screen but if they're put on the subscreen, they are.
Or in other words: Ever wondered why Mario (and a couple other sprites like feathers, etc.) don't get affected by the darkness in SMW (which *does* use your method)? It's exactly this reason and Rare chose the more complicated (but necessary!) method to avoid that!
@@MarioFanGamer659so ghost sprites < 8
@@ArneChristianRosenfeldt wdym by that?
@@MarioFanGamer659 I just wanted to expand on this nice thread a bit and explain why we need to have translucent and opaque sprite objects.
Ayyyyy I've been waiting for another one of these! They're always super interesting even though I don't understand a lot of it
You don't understand because of the way it's explained. He not a teacher, just talking to about what's in his brain. Teaching is a skill. This is no different than reading a boring book. Shame as this is really good stuff in the right hands
@@Tangobaldy I'm aware of this, I know it's not *teaching* but it's still informative, and it's enjoyable either way. I'm in the process of learning about a lot of this myself and I still find the content super informative. No matter what background you have, if you have an interest in this kind of thing, it's by no means a useless watch. This kind of content is open to everyone and it may even spark new interest in some.
@@Tangobaldy i disagree. I don't know a lot about computer science but if i listen in i can still understand a lot of it. I feel like he really does teach. Maybe not the most useful subject, but still.
@@coldcoffeegaming2798 I want to listen but he can't engage me. Shame really.
@@Tangobaldy Welcome to /r/iamverysmart, I hope you enjoy your time here
When I first watched this video it sounded so cryptic and complex to me. Now I'm watching it the third time, while (re-)writing parts of my PPU for my SNES emulator, and this thing is just a piece of beauty, and so great to follow, to write really compact, logical code from it. Thank you so much for this!!
Love love loooove these videos. Don't understand a whole lot, but thank you for explaining the inner workings of the SNES in such great detail. Maybe do the N64 Next? Be sure to crap on them for the tiny texture cache!
I'd rather a video discussed Playstation's complete lack of a z-buffer and its texture warping. :3
@@anactualmotherbear A 3D system without a z-buffer? That's... impressive.
They cut down on texture cache so they could actually get a 'cheap' R5000 CPU in there. They even used RDRAM which was very expensive at the time. It would've been nice to get more but that would've raised the price of the console significantly.
@@asp-uwu It's actually pretty fascinating how they even managed to get 3D platformers working on the system at all! You can see it struggling most of the time with polygons jittering and textures warping all over the place, but they did it. Insomniac should be given more credit for making the Spyro games look as good as they did on the system. There's a reason so many games on playstation have a fixed camera with pre-rendered backgrounds. That's why I find it more interesting. I think the n64's shortcomings have been discussed enough.
@@anactualmotherbear The N64's graphical advancements, not its shortcomings, should be focused on. It was effectively the first game console with a modern architecture for its 3D graphics. Custom microcode could create something like our modern shaders for lighting, and the clever use of mipmaps allowed for two textures per triangle. This was way beyond the PS1.
You ever just watch a video in straight-up Chinese just because you're pretty sure something amazing is being talked about?
what
For me it's like Spanish where. I can understand some of it but then there are some words I don't know. I keep watching in hopes that I will learn to understand it all
The SNES had some incredible built in special features that allowed it to get alot of bang for only a little computing buck!
I'm sorry for everyone who had to make an SNES emulator.
This is what we'd use a pixel shader for nowadays.
The motivation behind shaders is to make GPU programmable instead of being depend on and limited by fixed set of features, this is also reason why consoles are nothing special now days because what can be programed on PC GPU can be also done on Console and there not much room to go beyond that those unique GPU features is what elevated consoles over PC.
Yup, these were the early versions of shaders.
Or just do it all in software on the CPU
While watching this, I was surprised you didn't mention how windows can have their shapes altered while the screen was being drawn, but then I suspected that you probably already explained that in the video right before this one, and... yup!
Please write a book! This in paper form would be super cool
Could you please, in a future video, explain how different consoles stored background tiles and sprites?
People like me usually get to know how it is in the NES, but how do the SMS, Genesis, etc. did it?
I like how the Genesis and GBA store their tile graphics data. Both of them store it linear or chunky as some would call it, with each byte having two pixels. The only difference is which nibble is the left pixel.
My intuition is that they differ mostly in some minor technical aspects and the complexity they allowed. Focusing on one console lets RGME go in-depth on how that console works, and ensures he won't repeat much the same information repeatedly.
Amazing, the pure engineering that goes into something like this. Still my favorite game system, almost 30 years later!
I normally understand your video's but this one just flew right over my head, might just be because I'm tired.
so how long did it take all of you to get completely lost? i made it to 5:54 after seeing $2105.3 as a value in money
I wonder how many developers are just wishing this video series was available back in 1991.
How many people are kicking themselves for the hours they spent in frustration and the days of lost productivity while they were trying to learn how to program on the SNES, and here's this video that explains everything so clearly and easily.
Huh. I mean, I know this isn't a straightforward process to explain, and your examples are great at highlighting what this can accomplish...
But somehow you make this sound even more complex than I remember it actually being in practice... XD
I found that it seemed more complicated to me too. I think the main reason is that it is not very common in practice for every single thing explained in this video to be used at the same time. It is also more likely that only one or two is used at once. While it is true that all of this stuff is happening all the time, most of the time, most of it can be ignored.
You always explain things in ways I still can't understand, but I assume it's the closest I'll come.
Hah! That's it in a nutshell.
I didn't understand the stuff explained in this video but I still watched it to feel smart.
you videos are among the best videos for retro programming i have ever seen! ... thx so much for the effort and the clear explanations!
And still the Saturn can't do transparency...
It can, but only to this degree, unlike the PS1 or N64. This is far more limitting than alpha blending in a modern 3D system.
I see these videos, I get excited! I also reserve these for my bigger PC monitor, vs on my phone's tiny screen!
Thanks for all this wonderful detail!
Why has this channel not blown out of proportion yet? There is so much quality information on this channel.
Are you working up to making a game for the snes?
>effectively disabled
just like me
This is so helpful for SMW rom hacking.
As an artist who somehow got stranded here, my brain just froze in a blue screen of death.
Fantastic production, as always. I think it's possible that you have a more complete understanding of some of these systems than even the people that were developing games back then. Did you learn all of this just form the developer documentation?
The developer docs helped a lot, but there is a lot more, easier to read documentation online by other people who have done more primary research than I have.
One pixel...I thought this would be easy. Why are you learnt all this?
This channel is really my absolute favorite on TH-cam! Thank you for doing these videos!
The window pipeline seems pointlessly complicated. In the end, all it's doing for each of the six outputs is selecting some boolean function of the two (layer-independent) window masks. Since there are 16 two-operand boolean functions, this choice could have been encoded in 4 bits (per layer). Instead they encode the same information in 6 bits spread across two registers, and along the way manage to only support 15 out of the 16 possible boolean functions.
In fact, if you add the main/subscreen window switches, then it's 8 bits (10 bits for the final masks) to two select two boolean functions (one for the main screen, one for the subscreen) of the window masks, except it only has encodings for 43 (60 for the final masks) out of all 256 possibilities. I feel like using six pairs of independent window function selectors (4 bits each) and placing each pair into a single register, would have been more flexible, more convenient for the programmer, and easier and more efficient to implement in hardware.
@@MatthijsvanDuin Excellent point
I understood... Some of those words. I think it's been too long since I've watched your other videos on this topic.
This is the best channel that I have no understanding of on TH-cam. I look at these videos the way your dog looks at you when you try to explain your relationship problems to it.
Wow, so apparently Donkey Kong Country did it the hard way.
They could have just drawn the flashlight to the sub-screen and subtracted that from the main screen, but instead they subtracted an inverted version of everything else from the flashlight to get the same result. Very clever... but unnecessary.
Their method allows the unlit portion to be darker than it otherwise could be since the value would go negative and get clamped to zero, and become transparent/ignored instead of being pure black. They get around that by making black color a high value instead of 0. In the SMW example, it never gets darker than a dark gray color.
Keep in mind that this resulted in a dark room effect where not all sprites are dark similar to SMW's dark rooms (ever noticed how Mario, the feather, score and sprite coins are always bright in these rooms?) due to the limitation where only half of the sprites can perform colour maths.
This is it! Sprites on the main screen using palettes 0-3 cannot participate in color math, but all sprites on the sub screen can!
@@ddud4966 After one year, I now understand your explaination. And it really bugs me as this explaination is just plain wrong. SNES graphics are a bit like a GIF i.e. indexed colours. To denote a tile to draw nothing, you give a pixel the colour index 0. One example are the firefly rooms in Super Metroid which use colour maths on layer 2 (not palette animations as one might assume) for the darkness effects. The more fireflies you kill, the darker the rooms become until layer 2 becomes completely black (well, almost as the brightest colours such as white would still be visible but Super Metroid uses rather dark colours). If going by your theory, you would be able to see Samus at full darkness but on the actual SNES, Samus is actually still obstructed by the foreground.
Dear God, what a gasworks!
Holy hell, that's complicated
3:37 caption fix: unaffected, rather than "uneffected"
Are you going to do nes videos? I was wondering since I'm working on a nes game
Why it is soooo complicated!...
I loved my SNES when I was young, and I love that you have taken the time to go through and explain how every feature of the machine works.
That being said, your videos are a bit like being held by the ankles over a precipice: you think, "Okay, this is sounding a little fun, and then wHOOP-" your language immediately becomes impenetrable as you shift your grip, and I am left to doubt my capability to stay on.
I have tried to watch the series several times to catch what you mean sometimes, but its become obvious that these videos are for people who already have a rather healthy understanding of programming and system architecture.
Thank you for your gift, though! It is rare that someone opens up and explains just how something you used to take for granted actually works, kinda like my dad explaining to me how his truck was put together when I was young.
I'd love a video on how color math works in the high resolution mode(s)
Cool great video I love the amount of detail that you put in all of your videos
Fantastic work, I appreciate the incredible effort that goes into your vids :-) Love the tricks like inversion that get a great end result.
I watch your videos to go to sleep at night.
I was able to mostly follow the explanations up until about now.
You use a lot of technical jargon that doesn't make much sense to me, like what is a subscreen or a main screen? What is cold data? Theough main or sub register? The TMW and other stuff that I don't really understand. You mention Windows 1 and 2 or subwindows and whatnot, but what's a window? I thought it meant the screen or something or maybe a window like how if you click and pull a tab from your browser it makes it a separate window, but it doesn't seem to be the case based on how it's being used here.
Is there a explanation for dummies you could recommend on how computer chips work or whatever this stuff is referring to? Every tutorial I find for the SNES or programming in general already assumes I know computer jargon or how it works on a basic level and its frustrating because I don't and can't find anywhere where it can explain it.
You think you might be getting lost but then it all comes back together in the end. Thanks for the lesson!
10:49 That makes so much more sense, every time you said a Link to the Past, I was some reason mixing it up with A Link between Worlds, which is interesting since I never played A Link between Worlds.
You probably get this a lot, but may I ask what software combination did you use to create this video? Everything looks amazing and smooth!
Photoshop and Illustrator for making the graphics, After Effects to animate them, Audition for recording voice over, and Premiere to sync the voice over to the animations.
cool :D always good videos
Amazing Video, as always, keep it up.
Yay a random video that i have no clue how youtube got me here but i like!
How did anyone ever figure this out? Unless there was some kind of documentation included with dev kits. I don’t see how anyone could reverse engineer this.
Must be the dev kits for the most part; but also some reverse-engineering, as he sometimes discusses bugs, etc.
"6 flags"
*gets copyright banned*
Oh boy, a new video! Time to _totally not understand_ most of it!
Dots really are cool.
p
I see what you did there.
Always love listening to/watching these videos.
When the appendix is longer than the main video X3
amazing work, cant wait for the next one, its so interesting
2 years ago 2 years ago 1 year ago *2 months ago* 1 year ago
I do have a question though. You say when both windows are disabled, the pixels will be treated as "inside the window" by default - but how is that handled in the schematic? Both W1 and W2 would remain false up to the Muxing with WinLog, which usually is set to OR, and then still output false, finally resulting in disabling the pixel. What am I missing?
I’ve never owned a snes, don’t know much about programming or computers in general. Yet I can still follow along with most of this. Really interesting and engaging stuff!
I always wanted to know how the keyhole effect in smw worked, it seems to use scaling as well which I didn't think was possible.
What's the keyhole effect?
@@jefflinahan5853 When you get the key in smw and put it in the keyhole the black stencil of a keyhole scales up then scales back down all while the background is still displayed. I think it was explained it in a later video on this channel that is works similar to the metroid 3 light.
Scaling outside of Mode 7 on its own isn't an issue on the SNES, really. Heck, ALttP even uses dynamic graphics for the triforce and crystals. The issues about scaling graphics mostly come from the complicated graphics format (case point: neither SA-1 nor Super FX would be as effective if the were stored in the same format as on the SNES) but windowing, which doesn't use pixels, only start and end, doesn't have this issue.
The keyhole effect works by changing the window 1 left and right borders, per scanline , and per frame, manually. So in everyframe it should be doing calculations to get the two results for every scanline ( it's like being software renderered )
@@intron9 very interesting, megadrive and gameboy have a window layer but can only show 1 side
Huh, so it’s kinda like 2D ray tracing... in a way...
the whole video in 5 words, basically
It's a fixed-function pipeline. Pixel shaders replaced this technique.
That's a quite complex little boy.
The SNES graphic chip capability was quite impressive for its time, even without support from the Super FX chip. Even though a SNES was far slower than a PC of its era, its games usually ran slowly because of how complex the graphics chip was to emulate... And then, 30 years later, its entire graphics pipeline could be coded in a single pixel shader running on my smartphone.
I love the intricacy of this pipeline... I'm wondering, maybe I didn't get it, but what is the advantage of the Donkey Kong flashlight method versus the Super Mario disco ball method?
Request:Nasha Gibelli's program for the NES version of the Final Fantasy series Explained.
According to the information heard on the net, He was good at a large-scale interrupt routine, but I heard that there were many bugs because of the interrupt routine.
Professor Farnsworth: I’m afraid that we’re gonna have to use...
*COLOR MATH!*
I watched and understood all of your videos mere days ago, yet even I had no idea what these windows are. The beginning of the video makes no sense until 8:25 at which point the windows and the subscreen are FINALLY explained. Especially considering that "window" normally means some sort of a rect with coordinates, width and height.
7:47 _click-clack_ if the half flag... :D
Edit: There are some more clacks after that even. I do not have any complaints about the video quality however. Maybe the reprocessing actually worked?
I unsubcribed so I could subscribe a second time...I still don't get it how cat videos can get millions of views and something like this is missed by most people...
I never in my Life clicked that notification so fast.
Now that I own my own original Super Nintendo and have played games on it, these videos have become even more interesting than before.
I'm sure if you did the same breakdown for some of the FFVI megaspell effects it would take a whole separate 12-minute video
At 6:34 what's going on with those memory addresses that have a period and numbers after them?
These are the bits of a given address so e.g. $2130.6 means bit 6 of $2130.
Hey do you think you can do a video explaining the crazy color glitch that happens when Mario hits the goaltape offscreen?
Can’t wait to move on to the sound part.
All i know is that in high-res mode, the snes could only run in 1bit or 2bit color mode due the limited processing power & limited ram ,it’s no surprise that nintendo implemented 8 FIXED modes rules inside in the snes to prevent comflictsbugs,slowdowns and crashings etc,,that way to help game devs to make stable games,
just imagine if nintendo allowed game dev’s to run a snes in high-res,high color mode and 4 BG layer mode all atonce, sure the snes would had run at 0,0000000000000,1fps, so sadly nintendo’s ads at the early 90’s were somewhat MISLEADING!!!
The SNES does not natively support 1bpp graphics and hires mode does have a 4bpp layer as well as a 2bpp layer. However, this is still less than mode 1's two 4bpp layers and 2bpp layer, and in addition, sprites are still low res in hires mode. This limitation has nothing to do with the CPU, but rather vram bandwidth. There is no way to increase PPU (GPU) capabilities by lowering framerate because the SNES graphics hardware renders the screen as the TV is drawing the picture; it doesn't have a framebuffer like a computer or modern game system.
Question is, DOES IT APPLIES TO SUPER MARIO MAKER 2?
I was about to ask if subtract+halving was useful and then mario's disco ball came in
I don’t understand anything you’re saying but I love your voice
Subscreen still goes over my head.
So if ALttP could have transparent water, why not SMW? Could they just not figure out how in time for release?
There is actually an unused level mode in SMW that would have allowed for transparent water. I have no idea why it was never used, since it's fully functional.
The problem isn't lack of knowledge (in fact, Nintendo knew how colour maths even works) but there is a technically problem, namely that SMW usually puts layer 1, 3 and the sprites on the mainscreen and layer 2 on the subscreen but if you want to make the water transparent, you would have to move layer 1 and the sprites to subscreen. The problem is that layer 2 has got a similar priority as layer 1 in background modes 0 and 1 so if a sprite like Mario moves behind layer 1, he'll also disappear behind the background.
Unlike the unused level modes 1E and 1F (the former which makes layer 1 transparent and the latter which is a layer 2 level except layer 2 is transparent), level mode 0E makes layer 3 transparent to the rest of the layers but it's only used for the Ghost House entrance.
Looking back into the comment, there is one solution to the problem: Put layer 1 and objects on main- _and_ subscreen. The idea is that if you enable layer 1 and objects for main- and subscreen, you can have sprites which "always" go in front of layer 2 and still have them affected by colour maths. On the mainscreen, nothing would be different from the tide since the mainscreen register didn't change but on the subscreen, layer 1 and objects usually are obstructed by their mainscreen counterparts. Now the trick: When the latter go underwater, below layer 3, they disappear. If you enable colour maths on layer 3, they still disappear but at the same time, you can see the subscreen i.e. layer 1, 2 and objects so it looks like the former and latter haven't been visually obstructed at all. It's a bit difficult to put that in words and images would help for that.
But for that, you need another level mode which is one of the lesser problems since there are a couple unused numbers. The real issue is that this trick doesn't really work for Mondo, the special world level with the rising tide since at high tide, it obstructs layer 1 and objects on the mainscreen so any object (e.g. Mario, powerups from ?-blocks) which goes behind the foreground also go behind the background at high tide.
Amazing quality as always! Why did DK use the inverse method to do shades instead of going for a system like MW? Is it because it's less easy to encounter color clipping, which might happen more due to the more "realistic" palette of DK due to the prerendered nature?
It's because of the colour maths limitation on sprites as only half of the sprite palettes are effected. Take a look at SMW's dark room: If you look at Mario, score, sprite coins or a feather (all which use palettes 8 to B), you'll notice that they're unaffected by the darkness unlike the enemies, mushrooms and fire flower (which use palettes C to F). The negative avoids this issue.
windows 10
This is so cool. I wish I understood it.
This one is too esoteric for me, couldn't watch it
what
at the outro:
**did i just see dan salvato?**
Amazing visualization! What did you use to produce all the diagrams? It was PowerPoint, was it? Thanks
I use After Effects to create all the animations. In this particular video I used Illustrator to make the large diagram of the rendering system.
@@RGMechEx That's a dedication! Thanks for letting me know
Oh baby my fastest click of the day!
MOAR.
Wow, I didn't even got notification lol