Examples of games I know: Mode 0: Yoshi's Island (Intro and corridor before the last boss). Super Mario Kart (Only the backgrounds. The track was Mode 7 - they could change modes at the end of each scanline.) Final Fantasy IV (Japan) II (USA) (Only the Menu) Mode 1: Basically every game. Mode 2: Yoshi's Island (The part shown in the video and the wavy lava level.) Star Fox. Chrono Trigger (Title Screen) Mode 3: Doom Dirty Trax FX Stunt Race FX I've heard there are title screens using this mode, but I don't know any. Mode 4: Puzzle Bobble (I'm not sure) Mode 5: RPM Racing Secret of Mana (Menu) Mode 6: no game
How does Mario Kart use Mode 0 in the backgrounds if the backgrounds only every seem to show at most two overlapping layers? When do any of the backgrounds use four layers? I'd really like to know this so I can check it out. I'm now wondering if there's some cool way to use Mode 6 in a game too. . . .
@@inceptional BG 1 is disabled. I believe there wasn't any memory left, since mode 7 was using it for the track. BG 2 is the hud BG 3 is the front background (trees) BG 4 is the one in the back (mountains)
@@dbdist1 Strange, because if they only ended up using 3 of the available backgrounds anyway then I wonder why they didn't just use Mode 1 and then they could have had more colours in the background layers. It seems Street Racer did it much better and actually used the three available layers of Mode 1 for the backgrounds with much more overlapping parallax and in higher colour too.
You can think of the SNES graphics chip as having 3 distinct components that only sort of interact. First there's backgrounds, second there's sprites, and finally there's post-processing. The background modes really just seem to come down to having a certain set of features, and deliberately limiting which you can use at the same time. My guess is the reason the particular limits were chosen was because they represent the most you can do at once with the VRAM bandwidth available. Every mode pretty much seems to work out to needing the same amount of bandwidth... So that seems probable. You have 4 backgrounds, all of which can do 3/4 colour per tile mode. Backgrounds 1, 2 and 3 can do 15/16 colour per tile mode, and background one can also do 256 colour per tile mode. But each extra background layer used requires the equivalent of 2 bits per pixel to access the tilemap, then the tiles themselves are equivalent to 2 bits per pixel for 4 colours, 4 bits for 16, and 8 for 256. If you look at the modes, you see this generally ads up to 16 bits. Eg. Mode 0: 4 layers, 4 colours per tile for each layer -> 4x2 bits accessed for tilemaps, 4x2 accessed for tile data. -> 16 bits Mode 1: 3 layers, first two get 16 colours per tile, the third gets 4 colours per tile. -> 3x2 bits accessed for tilemaps, 2x4 for layers 0 and 1, and 1x2 for layer 3. -> total: 6 + 8 + 2 = 16 bits Mode 3: 2 layers, first gets 256 colours per tile, second gets 16 -> 2x2 bits for tilemaps, 1x8 for layer 0, 1x4 for layer 1 -> Total 4 + 8 + 4 = 16 bits. Etc. So basically the modes are set up so that you only ever access 16 bits of memory for every pixel drawn onscreen. The offset per tile modes (2, 4 and 6) are the strangest, and you might wonder what they are. They are all equivalent to the mode one down from them (1, 3 and 5), but with a layer missing; instead, they have the equivalent of another tilemap, but rather than specifying tiles for a layer it specifies the translation in x and y for that specific tile. X is only accurate to whole tile boundaries (8 pixels), but Y is accurate to single pixels. If you're wondering what on earth you'd ever need that for... Well there are a lot of creative potential uses, but the most obvious is a game like tetris - using offset per tile, you can make the blocks drop down without using any sprites - the pieces can be background elements. Lots of complex effects can be done like this - it's just a mode that sounds very strange if you can't quite wrap your head around it. High resolution mode... Well, you double the horizontal resolution. That should be pretty simple to understand. Though it has some quirks because sprites don't get doubled resolution. You can also double the vertical resolution, but to do so you end up switching everything to interlaced mode, which causes screen flicker and halves the framerate... These modes all make sense when you think about them long enough. But most are niche cases, or have some problems in practice. - Mode 0 is basically if you want a lot of background layers. Though it's main purpose was for NES backwards compatibility that ended up never happening. - Mode 1 is your standard mode that you use if you have no special needs of any kind. - Mode 2 is mode 1 but with offset per tile (eg for tetris or similar games, or special effects) - you do lose the third background to make this happen Mode 3 is high colour mode - RAM limits make it a bit hard to use effectively, but it's pretty good for static stuff like title screens. - Mode 4 is mode 3 with offset per tile. It combines the features of modes 2 and 3, but is probably impractical for most purposes because of it. You also lose some colour depth in your second background layer for this. - mode 5 is high resolution mode. It's rarely used because some bugs and memory limitations make it complex to deal with. However, several late era games used it to draw text in higher quality. (something made easier because you can swap modes midframe, so the main game window can be say mode 1, while the text box is mode 5) - mode 6 is mode 5 with offset per tile. Possibly the single most impractical mode around, considering even using mode 5 is already really challenging. And of course, mode 7... Which is quite unlike the other background modes in any way. All the others have features and minor details in common. Mode 7 does not. But, it does allow you to rotate and scale the single background layer. The infamous perspective effect results from changing the scaling matrix on every scanline. (changing things on every scanline is one of the most common graphics tricks the SNES uses. Many, many, MANY different effects are done due to this - it even has special hardware to help specifically with doing so - H-DMA) It's an interesting set of abilities...
Just imagine different region versions of supermarioworld,donkeykong country,aladdin etc,,, wich run at a different mode per region basis,such as mode 0,mode 5,mode 6 and mode 7, that means that in some modus, the amount of colors is limited, and the only way to get around that is using color dithering & blurring and blending or use the color HAM trick to get around that ,while in other modus such as mode 6 & 7 ,line scrolling, tile updates and/or the use of 128 sprites can be used to mimmick an extra BG layer, Mode 6 will require both color tricks & scanline, tile updates and sprite tricks to get around those limitations, With those graphical tricks in mind for each used mode, you can make different versions of identical games running each in a different mode ,but still graphically close to eachother and they all still would just run on the same system, that would be so interesting,just to see how game devs could get around those limitations in each graphical mode, Am mean blended 16 colors vs 256 colors = no problem to me, 1 single layer background with line scrolling, tile updates along with sprites vs 4 scrolling background layers = again no problem to me, This is definitely interesting stuff, it’s almost like porting a game to different systems, But it’s also as if the snes could run in nes,pc engine and sega genesis mode, And last but not least back then we tout that the snes could do all stuff like this atonce ,since nintendo was agressively overstating those capabilities of the snes by saying “ it could do mode 7, 256 colors on screen, it has a resolution of 512x448 pixels making it look more sharper then other systems,it could do 4 background layers and it also has 8 different modus” it all sounded cool on paper but they didn’t tell that the snes could not do it all atonce(aaarrrggg) that probably would,ve require a 32bit gpu and more ram, and those overhyped 8 modes were just restrictives modes so that’s the thing, Now you might could bypass those 8 different modes by doing everything in software such as sprite scaling etc,,, but this can harm the cpu in speed,but Non the less the snes is still my favorite and a great system trough !!!
I wonder why someone then hasn't done some kind of hack to use Mode 0 to let people play NES games on the SNES or something? Or maybe I'm just under-thinking this.
@@inceptional The problem is the sound system. The CPU, PPU, and Controller interface are all compatible, in theory, but the sound chipset is a complete departure. I also don't know if the interfaces all line up in the right way to allow a Famicom ROM to boot, even if the sound chip was replaced with something compatible.
As a child i never know each mode has it’s own restrictions ,that’s because nintendo just overhyped & overstated their snes to be ‘very powerful’ by saying; it can generate graphics at 512x480 at 256 colors with multi scrolling backgrounds, and it could do pretty much cd quality,, but the reality is, it can only do 1 of those things atonce but sadly not all atonce no, They did tell you that hich res costs you high color depth, while a low-res give you high color dept etc,,, And for near cd quality sound that would cost you all the ram and cpu power sothat there was nothing left to run a game. Well if the snes did had more ram and a fast 42bit cpu,then it could,ve use & push all those snes chipsets to it’s max all atonce, but yeah a more powerful cpu would,ve added extra costs to it, so it is what it just is, those restrictions per mode were made with the slow 16bit and limited ram in mind, no wonder!!!.
Great video and really interesting topic. I would have loved more examples of games utilizing the different modes. It was a little bit difficult to understand the purpose of all the features.
mode 0: two and a half NESes mode 1: you know, like super mario world mode 2: the entire screen is elevators mode 3: a picture and a normal layer mode 4: a picture and a status bar. also the screen is elevators mode 5: double your resolution or no down payment mode 6: double your resolution and the entire screen is elevators, also you only get one layer.
These series of videos make me appreciate how such geniuses the game directors who could create masterpieces on the SNES were. Having to work with such restrains and being able to pull off stuff like A Link to the Past, Super Mario World, Super Metroid, FF VI, and many others is nothing short of incredible. True artists and geniuses in my opinion.
I always wondered the rest of the modes, only hearing of mode 7, but the rest? and the only thing I found was that were layers and that's all. Finally I can understand it. Great video!
This is a great video. I'm especially impressed by the way you visualized and separated out the different layers as you went through each mode. Well done.
Great video, I really love how detailed your explanations are. Just wish that you had used some more examples showing of the features you explained. That kind of demonstration would really help show how all these features are combined.
It's because there literally aren't any. I'm not aware of a single game that uses Modes 4 or 6, and Mode 5 is, no joke, used in less than 5, with the game on-screen being the only one to use it outside of menus.
The only example for Mode 5 that comes to mind is Seiken Densetsu 3. In that game, the inventory menu uses high-res mode to display both the text AND the background. Interlacing, however, is not used (either that or my emulator doesn't support it)
Wow, very nice videos. Just finished watching parts 1 through 4. Some of this I knew only written down in spec documents, but your visualisations make it very awesome!!! I can hardly wait for the next one. Though seeing the timestamps I'm going to have to find something to do in the mean time :D. Top notch videos! :D Good luck with future ones.
This is a wonderful series, and I especially like it when these technical things are demonstrated using examples from real SNES games. I wish there were more of those, however, as they really help demonstrate to me how all these technical things work in practice.
Thank you very much for explaining so many retro mechanics, many of them are extremely interesting, just to know how much innovation they had to do back in the day. Request : Next you should explain Blast Processing. :P j/K
When I get further in my ComSci and Engineering courses and want to start making Homebrew software, I'm going to come back to this video as a starting reference. Thanks!
I was just thinking about this very subject the other day and wondering whether a video exists on this subject matter. Never did search it, and now I don't have to. Thanks!
I love it, great job explaining all the modes. Could we get a part 2 with a few more examples? Is there a way to tell on emulator what mode you are in?
Depends on the emulator. It's usually pretty easy to discern what mode is being used by looking at how many background layers there are onscreen and judging the color depth of each tile.
Thank you. I've been wondering why Super Donkey, a certain prototype, was using four layers, and I realized that it was also cleverly using three/four colors on each layer's tiles.
The amount of detail and technical achievement on the SNES hardware is amazing, all to maximize the graphical capabilities of the console. Today, with the amount of video memory available, you can just throw in whatever shit you want on screen, regardless of how huge or complicated, and let the hardware do the trick anyway.
Today that's mostly true, but a framebuffer is not a panacea. Before high-speed VGA cards came along, there wasn't enough bandwidth on the bus to change whole screens at once. Tile based graphics can get around this by having much bigger tilemaps than the system can render, but the PC didn't have that. It was a surprise when ID software proved you could make a scrolling platformer work on an EGA card without a low framerate, hideous glitching or a juddering playfield.
I liked it when you showed game examples of the diffrent modes and what they'd be used for. Like with mode one you did the layers with the Aladdin game and the one layer being used for the status bar. Wish you had given more examples like that with the other modes. IE: shown a game that used each of the modes and why. Still, great work.
Interesting and well explained, but i wish you put mode7 subject in this video because i hate to have wait another couple of month's and then forget about it,and i am sure i am not the only one here . But still great video.
I'm here again to learn the difference between modes 1 and 2. I'm currently hacking Aladdin and my pause menu is unable to draw on BG3 during the final boss fight. Now I know that BG3 is not supported. Thanks again for your amazing content!
I think you're wrong about offset per tile being the only method to divide the screen horizontally - you can use the window masks as well. If you use at least two background layers, and set one to be inside the mask, and one outside of it, you can also get the effect of a horizontal split. However you sacrifice the available background layers to do it of course, since the two halves need at least one unique background layer to make this kind of split mean anything. (if you have 3 layers though there's nothing stopping you from making the third layer a shared one though.)
Great video, but I'd love to see more examples. It would be great to see clips from games to see each of the modes in action to better visualize how they work.
A nice random tip of the day: If you have a modified PAL (Super Nintendo) or NTSC-J (Super Famicom) Snes which can play games from any region - but have noticed that American NTSC (Super Nintendo) cartridges are a little too wide to fit into the console, then do the following: 1. Open up an NTSC game cartridge, and take out the circuit board. 2. Open up a PAL game cartridge, and take out the circuit board. 3. Put the NTSC circuit board into the PAL (or indeed the NTSC-J Famicom) cartridge game case. 4. Be happy you didn't have to buy and adaptor, and play as many NTSC games as you want on your PAL console! Note: all circuit boards fit in any region case, but no matter what shape the circuit boards are - if you are swapping out FX games (with the additional contacts either side of the main connector) - then likewise, swap the corresponding game cases to match!!! Have a 'Super' day! ;)
Thank Nintendo for the slow-ass VRAM. The reason all of these modes exist is to try and alleviate this. For example, the GBA, which has much faster VRAM, only has 3 tiled modes vs. 8 on the SNES; one mode with 4 8bpp layers, one mode with 2 8bpp layers and an 8bpp "Mode 7" layer, and one mode with 2 8bpp "Mode 7" layers.
wow the SNES was really complex! I am trying to program it using assembly for a game idea that I have.. but it will probably take me years yo get something tangible
"Part 4b - Higher Resolutions: *coming soon*" In the description should be updated to: "Part 4b - Higher Resolutions: ruclips.net/video/AnEuk8Vj3w0/видео.html" Incredible series. I've been having a blast
4:01 - 4:13 distracted me from what you were saying cause I wanted to see if the player was going to get the potential x10 chain combo there. Hell, even if it ended at the x7 combo, the player just won as there's no way Easy Lakitu would be able to chip away at a Garbage Block that size in time to save his cloud ass. Sorry, I was an avid Tetris Attack player back in my misspent youth and used to be able to beat Bowser on Extra Hard mode with fair regularity.
That's, uh, very interesting. But I kinda don't remotely understand what most of those features would be useful for in practice. I'm sure they're useful for _something,_ I just lack the technical knowledge to grok _what._
Timothy McLean They're not; most of these features are just a waste of silicon that would be better used for more sprites or palette entries. Hires mode in particular is a waste; there's not near enough VRAM bandwidth or VRAM in general to make it practical.
Well, you have to remember the SNES suffers from some last minute cost cutting as far as I can tell. Both high colour and high res modes are far more practical when you remember that the PPU is designed to address 128 kilobytes of VRAM, not 64. That the upper 64 kilobytes is missing speaks to some kind of cost cutting. I also did some calculations on just how fast VRAM has to be, and it comes out pretty much the same for every graphics mode. (though highres mode seems slightly above average) Regardless of mode, the graphics chip needs to read about 2 bytes per pixel drawn. (averaged out, because it doesn't draw individual pixels), to draw the backgrounds, and another byte or so to draw the sprites. (the high res backgrounds seem to imply 10 bits per pixel drawn, but obviously you have twice the number of pixels now) When you do the calculations in relation to the framerate you quickly realise total memory bandwidth has to be in the region of at least 10 megabytes a second. It DOES use two independent memory channels though. (16 bits per memory read, but the upper and lower bytes can be individually addressed - as far as I can tell while this functionality no doubt has secondary uses it primarily exists to make mode 7 possible.) Considering that DMA bandwidth is only equivalent to 2.68 megabytes per second, it's not the video memory bandwidth limiting things. And for the actual internal functioning of the PPU itself, it really isn't wanting for memory bandwidth. It has what it needs. No more, no less. The whole thing seems balanced to do whatever combination of features can fit into that kind of bandwidth. Also worth noting you can switch modes midframe, which is how most of the known uses of hi-res mode are being used. Sprite performance is most likely limited by VRAM performance, though it's hard to say exactly. Adding more sprite entries wouldn't accomplish much since the CPU in the system already struggles to keep up with drawing considerably less than 128 sprites. (sure highly optimised code could do it, but actual game developers rarely have the time or patience for those level of optimisations.) Extra palette entries would require redesigning the entire way that backgrounds and sprites function. At best you could take the functionality of mode 0 (where each background has a unique set of 24 possible colours) and extend it to the other modes. (which would imply multiple backgrounds each having 120 colours to themselves.) But when you start messing around with stuff like this, you quickly run into that 64 kilobytes of VRAM... That's where they really dropped the ball. The system can handle a weak CPU - they demonstrated about half a dozen workarounds. But towards the end of it's life, that missing 64 kilobytes of VRAM probably hurt a lot. What the SNES needed, if it really needed improvement is the full 128 kilobytes of VRAM, and especially a faster DMA controller that can write into VRAM at a higher rate. All those late era games such as the SuperFX titles are more than likely DMA limited. High resolution and high colour mode use was limited due to lack of VRAM... IF you look at what the registers in the PPU allow, and calculate the RAM involved you see just how much that cripples the chip - all the higher end functionality works out decently with 128 kilobytes to work with, but with just 64 you run into a LOT of limitations, because it's very easy to blow your VRAM budget...
By the way, I doubt most of those features are using that much silicon. They probably just implemented a bunch of things then worked out what they could reasonably combine together. The high resolution mode in particular... That's really not a huge deal to implement - the only thing you need to be able to do to implement high resolution mode is run the pixel clock at double the speed. Output 512 pixels per line rather than 256. Given the rest of the logic the mode uses, I highly doubt it does anything more than that - it just re-uses the existing functionality from other modes, but doubles the pixel clock while doing so. The functionality to support interlaced graphics is enabled in all 8 modes, though only the high resolution modes do anything to support it. (really all they need to do is perform a one pixel offset every other frame, and skip every other line of a regular background on a single frame) Even the sprites support interlaced mode... I don't think the high resolution modes have any huge implementation cost. Removing them wouldn't gain you much. High colour mode on the other hand, requires being able to address 8 bitplanes instead of 4. Though functionally speaking the hardware already has to be able to read 10 bitplanes of pixel data and 3 tilemaps just to support the system's core feature set used by 99% of games. eg. Mode 1 I highly doubt they did much beyond link together the functional blocks already present for other reasons with the minimum amount of glue logic they possibly could. My guess is High colour and high resolution modes follow naturally from abilities the hardware has for other reasons, could be implemented cheaply, and were therefore added just because they could without much consequence. The real resource hog in the PPU design is Mode 7 - supporting that requires a completely different rendering logic to any other mode, and I'm fairly sure it also pushes the memory bandwidth harder than any other mode there is. The Memory bandwidth was almost certainly chosen with mode 7 in mind and then the other modes were defined by looking at which functional blocks could operate together within that amount of bandwidth. (and which combinations might actually be useful.) I wouldn't expect there to be massive amounts of wasted silicon to support niche features. Rather, I suspect the niche features exist because they represented a minor addition to functionality that was already there.
A large chunk of the complexity afaik is the sprite rendering, which requires a buffer to render the all the sprites together on each scanline (takes up as much space as the whole palette registers I think), plus the spite registers (another large register file), plus a sizable portion of vram bandwidth and a complex scanning mechanism. And it's all totally worth it.
lol@ this guy saying the system needed a memory bandwidth of 2mb/s, when the absolute largest game was only 6mb, and most were sitting at 2-4. surrree. its totally running its entire program through the ram at all times. fucking idiot.
KJSJKS Raramente comento, quando consigo tu me acha. kek Venho acompanhando, e é excelente! Esse vídeo aqui inclusive era algo que eu planejava fazer a muito tempo. lol
Sim, estou admirado pela qualidade do conteúdo desse canal. :D Acho que seria uma boa você fazer um vídeo sobre isso em português no seu canal. É bem interessante e se encaixaria perfeitamente com seus outros vídeos informativos.
I think this video needed more practical examples and comparisons. I was able to keep up with everything in your other videos, but this one had me scratching my head a few times.
How the heck is direct color able to use the extra 3 bits that were used for palette selection? Do you just choose a small section of the RGB color space for the entire character to follow? Because what's throwing me is that the bits are in completely different places: one in VRAM(tilemap), one in wherever characters are defined in.
The least significant that isn't zero. That is, the entire color is 0bbB00gggG0rrrR0 where bbgggrrr is the character data and BGR is the palette index data.
In Mode 0, does every 4 colour palette absolutely have to basically throw away one of the colours for transparency (effectively reducing the overall single background layer colours to 24 and the amount per 8x8 tile to 3)? Or, if you don't want to use any transparency on say the backmost background layer for example, can you set it so most of the palettes for that layer don't waste one of the colours on transparency, and then you can get access to the full four colours of the palette for the most part?
Maybe I missed something, but it's not immediately clear why (using Mode 1 as an example) a 4 bit-per-pixel background would have access to 128 colors. Naively, I would think it would have access to only 15 + transparency (as there are 16 distinct 4-bit combinations). But you multiply that by 8 because each tile can have a separate palette?
I never understand these, but that's likely because of my general ignorance with the field of graphical programming. I still find them really interesting to watch and the animations are really well done even if I have no idea what in hell is going on haha
Well you just need to know the SNES is a hardcoded hardware picture displayer that doesn't control individual pixels by sotware. It has a custom picture procesing unit that outputs frames always based on 1 to 4 backgrounds and some sprites. So the actual game graphic programming is just first upload the background graphics data and then just change the X and Y coordinates (and doing the similar for the sprites). It's hard coded in it's circuit. Hope this helps people that are completely lost haha.
What's the name of the font you use for the list at the beginning of the video and for some of the graphics? It looks really cool and I think it fits this video's style a lot.
I was thinking that for XAMPLE if only 1 background can be used for 256 colors, and we want to ellusionize extra backgrounds, then we can use line scrolling & tile updates to give that ellusion of extra backgrounds,,, But what if we want to use 4 backgrounds but we are only limited to 16 colors per background thus 4x 16 = 64, well in order to ellusionize extra colors, we can do use colors swaps to simulate 256 colors onscreen. If we want to use the full resolution of the snes but have to deal with only 4 colors, then we can do use once again the color swap/mid-frame scanline trick to fake extra colors onscreen. This to VIRTUALY get around these limitations.
Yeah same after watching videos where people show off older dev kits and sdk's for retro consoles I'm totally interested in trying to make a game on a retro game console.
What's the advantage of Mode 4 over Mode 3? It just seems like everything is more limited in Mode 4. What benefit does having access to direct colour offer (not that I actually know what "direct colour" really means) if any game using it can't show as many colours in this mode anyway and can't do quite as good column scrolling either? Do you have an actual use case where it would be better to use Mode 4 over Mode 3?
It was used as a 8bpp + 2bpp combo in some games, like the cutscenes of Adventures of Indiana Jones, Toy Story and an actual offset-per-tile use in Super Genjin 2 title screen.
Does the SNES background layer 1/2/3/4 priority work similar to the Genesis Plane A/B priority for effects that create the illusion of far more overlapping background layers, such as seen in the cloud level of Thunder Force IV on Genesis for example, or can only the Genesis movie Planes viusally in front of and behind each other depending on how the priority is set?
I don't know about layer 4, but you can definitely make individual tiles from layer 1, 2 and 3 appear in front of each other. The Aladdin example does this: BG2 high priority > BG1 > BG2 low priority. BG3 is using the exclusive absolute priority bit. You can also do this by changing the mainscreen/subscreen setup middle screen with HDMA.
@@maxwelseven Yeah, I found out in Mode 0 it's slightly different: You can switch tile priorities between layers 1 and 2, and you can switch tile priorities between layers 3 and 4, but you can't switch tile priorities between say layers 2 and 3. What you can do though it use the main and sub screens to move layer 2 above layer 3 for example. So, in a slightly fiddly way, it's possible to mix most of the layer priorities around.
Alessandro Cussino The Gameboy Advance is considerably less complicated, although much more powerful due to having much faster VRAM; it only has 3 tiled modes vs. 8 on the SNES. All layers can be either 4bpp or 8bpp in all modes, ("Mode 7" layers are forced to be 8bpp) so 2bpp is no longer an option, and the way the modes go is Mode 0 has four regular layers, Mode 1 has two regular layers and one "Mode 7" layer, and Mode 2 has two "Mode 7" layers.
Horizontal hi-res is 60fps, yes. Interlace mode is also 60fps, but only one field is drawn per frame (half of the vertical resolution). And yes everything works just as you would expect normally in hi-res mode other than color math.
![[WR] Asterix & Obelix XXL 2 Remastered | 57:00 (Loadless) | Any% PC](http://i.ytimg.com/vi/ac2-Fmgu9bo/mqdefault.jpg)
You know, I've heard of Mode 7 a lot, but I never realised that meant there were lesser numbered modes...
Mode 7 is insane.
7 is the best mode
Yeah, I always wondered why it was called that.
Reminds me of drive C:
where's A: and B:
@@arielsproul8811 A and B are floppy drives
Examples of games I know:
Mode 0:
Yoshi's Island (Intro and corridor before the last boss).
Super Mario Kart (Only the backgrounds. The track was Mode 7 - they could change modes at the end of each scanline.)
Final Fantasy IV (Japan) II (USA) (Only the Menu)
Mode 1:
Basically every game.
Mode 2:
Yoshi's Island (The part shown in the video and the wavy lava level.)
Star Fox.
Chrono Trigger (Title Screen)
Mode 3:
Doom
Dirty Trax FX
Stunt Race FX
I've heard there are title screens using this mode, but I don't know any.
Mode 4:
Puzzle Bobble (I'm not sure)
Mode 5:
RPM Racing
Secret of Mana (Menu)
Mode 6:
no game
How does Mario Kart use Mode 0 in the backgrounds if the backgrounds only every seem to show at most two overlapping layers? When do any of the backgrounds use four layers? I'd really like to know this so I can check it out.
I'm now wondering if there's some cool way to use Mode 6 in a game too. . . .
@@inceptional
BG 1 is disabled. I believe there wasn't any memory left, since mode 7 was using it for the track.
BG 2 is the hud
BG 3 is the front background (trees)
BG 4 is the one in the back (mountains)
@@dbdist1 Strange, because if they only ended up using 3 of the available backgrounds anyway then I wonder why they didn't just use Mode 1 and then they could have had more colours in the background layers. It seems Street Racer did it much better and actually used the three available layers of Mode 1 for the backgrounds with much more overlapping parallax and in higher colour too.
You can think of the SNES graphics chip as having 3 distinct components that only sort of interact.
First there's backgrounds, second there's sprites, and finally there's post-processing.
The background modes really just seem to come down to having a certain set of features, and deliberately limiting which you can use at the same time. My guess is the reason the particular limits were chosen was because they represent the most you can do at once with the VRAM bandwidth available. Every mode pretty much seems to work out to needing the same amount of bandwidth... So that seems probable.
You have 4 backgrounds, all of which can do 3/4 colour per tile mode. Backgrounds 1, 2 and 3 can do 15/16 colour per tile mode, and background one can also do 256 colour per tile mode.
But each extra background layer used requires the equivalent of 2 bits per pixel to access the tilemap, then the tiles themselves are equivalent to 2 bits per pixel for 4 colours, 4 bits for 16, and 8 for 256.
If you look at the modes, you see this generally ads up to 16 bits.
Eg. Mode 0: 4 layers, 4 colours per tile for each layer -> 4x2 bits accessed for tilemaps, 4x2 accessed for tile data. -> 16 bits
Mode 1: 3 layers, first two get 16 colours per tile, the third gets 4 colours per tile. -> 3x2 bits accessed for tilemaps, 2x4 for layers 0 and 1, and 1x2 for layer 3. -> total: 6 + 8 + 2 = 16 bits
Mode 3: 2 layers, first gets 256 colours per tile, second gets 16 -> 2x2 bits for tilemaps, 1x8 for layer 0, 1x4 for layer 1 -> Total 4 + 8 + 4 = 16 bits.
Etc. So basically the modes are set up so that you only ever access 16 bits of memory for every pixel drawn onscreen.
The offset per tile modes (2, 4 and 6) are the strangest, and you might wonder what they are. They are all equivalent to the mode one down from them (1, 3 and 5), but with a layer missing; instead, they have the equivalent of another tilemap, but rather than specifying tiles for a layer it specifies the translation in x and y for that specific tile. X is only accurate to whole tile boundaries (8 pixels), but Y is accurate to single pixels.
If you're wondering what on earth you'd ever need that for... Well there are a lot of creative potential uses, but the most obvious is a game like tetris - using offset per tile, you can make the blocks drop down without using any sprites - the pieces can be background elements.
Lots of complex effects can be done like this - it's just a mode that sounds very strange if you can't quite wrap your head around it.
High resolution mode... Well, you double the horizontal resolution. That should be pretty simple to understand. Though it has some quirks because sprites don't get doubled resolution.
You can also double the vertical resolution, but to do so you end up switching everything to interlaced mode, which causes screen flicker and halves the framerate...
These modes all make sense when you think about them long enough.
But most are niche cases, or have some problems in practice.
- Mode 0 is basically if you want a lot of background layers. Though it's main purpose was for NES backwards compatibility that ended up never happening.
- Mode 1 is your standard mode that you use if you have no special needs of any kind.
- Mode 2 is mode 1 but with offset per tile (eg for tetris or similar games, or special effects) - you do lose the third background to make this happen
Mode 3 is high colour mode - RAM limits make it a bit hard to use effectively, but it's pretty good for static stuff like title screens.
- Mode 4 is mode 3 with offset per tile. It combines the features of modes 2 and 3, but is probably impractical for most purposes because of it. You also lose some colour depth in your second background layer for this.
- mode 5 is high resolution mode. It's rarely used because some bugs and memory limitations make it complex to deal with. However, several late era games used it to draw text in higher quality. (something made easier because you can swap modes midframe, so the main game window can be say mode 1, while the text box is mode 5)
- mode 6 is mode 5 with offset per tile. Possibly the single most impractical mode around, considering even using mode 5 is already really challenging.
And of course, mode 7... Which is quite unlike the other background modes in any way. All the others have features and minor details in common. Mode 7 does not. But, it does allow you to rotate and scale the single background layer.
The infamous perspective effect results from changing the scaling matrix on every scanline. (changing things on every scanline is one of the most common graphics tricks the SNES uses. Many, many, MANY different effects are done due to this - it even has special hardware to help specifically with doing so - H-DMA)
It's an interesting set of abilities...
Sorry But I don’t have the time to read it
My stomach hurts
Just imagine different region versions of supermarioworld,donkeykong country,aladdin etc,,, wich run at a different mode per region basis,such as mode 0,mode 5,mode 6 and mode 7, that means that in some modus, the amount of colors is limited, and the only way to get around that is using color dithering & blurring and blending or use the color HAM trick to get around that ,while in other modus such as mode 6 & 7 ,line scrolling, tile updates and/or the use of 128 sprites can be used to mimmick an extra BG layer,
Mode 6 will require both color tricks & scanline, tile updates and sprite tricks to get around those limitations,
With those graphical tricks in mind for each used mode, you can make different versions of identical games running each in a different mode ,but still graphically close to eachother and they all still would just run on the same system, that would be so interesting,just to see how game devs could get around those limitations in each graphical mode,
Am mean blended 16 colors vs 256 colors = no problem to me,
1 single layer background with line scrolling, tile updates along with sprites vs 4 scrolling background layers = again no problem to me,
This is definitely interesting stuff, it’s almost like porting a game to different systems,
But it’s also as if the snes could run in nes,pc engine and sega genesis mode,
And last but not least back then we tout that the snes could do all stuff like this atonce ,since nintendo was agressively overstating those capabilities of the snes by saying “ it could do mode 7, 256 colors on screen, it has a resolution of 512x448 pixels making it look more sharper then other systems,it could do 4 background layers and it also has 8 different modus” it all sounded cool on paper but they didn’t tell that the snes could not do it all atonce(aaarrrggg) that probably would,ve require a 32bit gpu and more ram, and those overhyped 8 modes were just restrictives modes so that’s the thing,
Now you might could bypass those 8 different modes by doing everything in software such as sprite scaling etc,,, but this can harm the cpu in speed,but
Non the less the snes is still my favorite and a great system trough !!!
I wonder why someone then hasn't done some kind of hack to use Mode 0 to let people play NES games on the SNES or something? Or maybe I'm just under-thinking this.
@@inceptional The problem is the sound system. The CPU, PPU, and Controller interface are all compatible, in theory, but the sound chipset is a complete departure. I also don't know if the interfaces all line up in the right way to allow a Famicom ROM to boot, even if the sound chip was replaced with something compatible.
Would have loved to see examples of when each mode was used, and why it used the mode that it did.
As a child i never know each mode has it’s own restrictions ,that’s because nintendo just overhyped & overstated their snes to be ‘very powerful’ by saying; it can generate graphics at 512x480 at 256 colors with multi scrolling backgrounds, and it could do pretty much cd quality,, but the reality is, it can only do 1 of those things atonce but sadly not all atonce no,
They did tell you that hich res costs you high color depth, while a low-res give you high color dept etc,,,
And for near cd quality sound that would cost you all the ram and cpu power sothat there was nothing left to run a game.
Well if the snes did had more ram and a fast 42bit cpu,then it could,ve use & push all those snes chipsets to it’s max all atonce, but yeah a more powerful cpu would,ve added extra costs to it, so it is what it just is, those restrictions per mode were made with the slow 16bit and limited ram in mind, no wonder!!!.
I'm a simple man. I see video on retro game mechanics, I like.
Can't wait to see the glorious mode 7! .
Mode 7 is legendary epic algebra nonsense crammed every 1/60s.
Every raster line, so about 256x as frequent
Basically Mode 7 is a mode where a background layer can be skewed and scaled.
Great video and really interesting topic. I would have loved more examples of games utilizing the different modes. It was a little bit difficult to understand the purpose of all the features.
mode 0: two and a half NESes
mode 1: you know, like super mario world
mode 2: the entire screen is elevators
mode 3: a picture and a normal layer
mode 4: a picture and a status bar. also the screen is elevators
mode 5: double your resolution or no down payment
mode 6: double your resolution and the entire screen is elevators, also you only get one layer.
Thank you for this.
Rarely ever do games use modes outside of 1, 3, and 7, and 3 is really only ever used for title screens.
These series of videos make me appreciate how such geniuses the game directors who could create masterpieces on the SNES were. Having to work with such restrains and being able to pull off stuff like A Link to the Past, Super Mario World, Super Metroid, FF VI, and many others is nothing short of incredible. True artists and geniuses in my opinion.
I always wondered the rest of the modes, only hearing of mode 7, but the rest? and the only thing I found was that were layers and that's all. Finally I can understand it. Great video!
All the videos in this series are absolutely packed with information. It's making me want to try working on the snes a bit. Thank you!
This is one of my favorite RUclips channels. Keep up the good work!
1:51 Kudos for showing SOS! Criminally underrated game right there
This is a great video. I'm especially impressed by the way you visualized and separated out the different layers as you went through each mode. Well done.
This series is so amazing! Learned a lot. I'd love to see a tutorial on how you make these. The layer splitting animations are especially cool
You're easily one of my most favourite channels on RUclips. Keep it up.
Great video, I really love how detailed your explanations are. Just wish that you had used some more examples showing of the features you explained. That kind of demonstration would really help show how all these features are combined.
Awesome video thou a few more example pictures of the mode in action would have been helpfull.
helpful*
agree, there are only example for the first modes only.
Giovanni Nigro Virtually nothing use Modes outside of 1, 3, and 7.
*+Drew Sebastino* Secret of Mana uses Mode 5 for it’s menus.
you cant just tell me about vertical tile shifting while also showing a really good chain in tetris attack thats just too much at once
Emulators HATE this one mode, click now to find out which one!
Mode 5... Saved you a click
The Link
Except I still had to click "Show Replies" to see that, so you really didn't...
This one WEIRD mode that will save you money!
but WHY mode 5 and early mode 2
SA-1 (The Emulator Who Hates It is ZSNES)
Excellent video but i was hoping for more exemple to see what those feature really do in game. :)
Cool video. Wish the later modes has more in game examples. The first few did and made it easy to understand
It's because there literally aren't any. I'm not aware of a single game that uses Modes 4 or 6, and Mode 5 is, no joke, used in less than 5, with the game on-screen being the only one to use it outside of menus.
The only example for Mode 5 that comes to mind is Seiken Densetsu 3. In that game, the inventory menu uses high-res mode to display both the text AND the background. Interlacing, however, is not used (either that or my emulator doesn't support it)
Wow, very nice videos. Just finished watching parts 1 through 4. Some of this I knew only written down in spec documents, but your visualisations make it very awesome!!!
I can hardly wait for the next one. Though seeing the timestamps I'm going to have to find something to do in the mean time :D.
Top notch videos! :D Good luck with future ones.
This is a wonderful series, and I especially like it when these technical things are demonstrated using examples from real SNES games. I wish there were more of those, however, as they really help demonstrate to me how all these technical things work in practice.
Thank you very much for explaining so many retro mechanics, many of them are extremely interesting, just to know how much innovation they had to do back in the day. Request : Next you should explain Blast Processing. :P j/K
I can explain it. The Genesis' processor was nearly 3 times faster than the SNES'.
When I get further in my ComSci and Engineering courses and want to start making Homebrew software, I'm going to come back to this video as a starting reference. Thanks!
My brain is melting, but it's a good kind of melting! Really like the immense information density! (:
im currently trying to make a game in unity that's completely faithful to the snes hardware. this series has helped a ton so thank you
I was just thinking about this very subject the other day and wondering whether a video exists on this subject matter. Never did search it, and now I don't have to. Thanks!
I love it, great job explaining all the modes. Could we get a part 2 with a few more examples?
Is there a way to tell on emulator what mode you are in?
Depends on the emulator. It's usually pretty easy to discern what mode is being used by looking at how many background layers there are onscreen and judging the color depth of each tile.
Man I was waiting for this! Sweet!
Thank you. I've been wondering why Super Donkey, a certain prototype, was using four layers, and I realized that it was also cleverly using three/four colors on each layer's tiles.
Once again you made another totally awesome and incredible video! Thank you!
Alot of that went over my head lol but still appreciate ya effort, might have to watch again! Cheers m8!
awesome as always!
vaen dryl why does it say your comment is from one day ago
Makes sense come to think of it
This is really fascinating, but I did myself quite confused without any examples.
Amazing as always
The amount of detail and technical achievement on the SNES hardware is amazing, all to maximize the graphical capabilities of the console. Today, with the amount of video memory available, you can just throw in whatever shit you want on screen, regardless of how huge or complicated, and let the hardware do the trick anyway.
Today that's mostly true, but a framebuffer is not a panacea. Before high-speed VGA cards came along, there wasn't enough bandwidth on the bus to change whole screens at once. Tile based graphics can get around this by having much bigger tilemaps than the system can render, but the PC didn't have that. It was a surprise when ID software proved you could make a scrolling platformer work on an EGA card without a low framerate, hideous glitching or a juddering playfield.
Love this. Thank you so much. Could you show games which use each mode so we can get a visual of each tradeoff?
Stellar video, as always! ❤️❤️❤️👏👏👏
I liked it when you showed game examples of the diffrent modes and what they'd be used for. Like with mode one you did the layers with the Aladdin game and the one layer being used for the status bar. Wish you had given more examples like that with the other modes. IE: shown a game that used each of the modes and why. Still, great work.
Interesting and well explained, but i wish you put mode7 subject in this video because i hate to have wait another couple of month's and then forget about it,and i am sure i am not the only one here .
But still great video.
I'm here again to learn the difference between modes 1 and 2. I'm currently hacking Aladdin and my pause menu is unable to draw on BG3 during the final boss fight. Now I know that BG3 is not supported. Thanks again for your amazing content!
I think you're wrong about offset per tile being the only method to divide the screen horizontally - you can use the window masks as well.
If you use at least two background layers, and set one to be inside the mask, and one outside of it, you can also get the effect of a horizontal split.
However you sacrifice the available background layers to do it of course, since the two halves need at least one unique background layer to make this kind of split mean anything.
(if you have 3 layers though there's nothing stopping you from making the third layer a shared one though.)
thanks! I really like your videos.
Great video, but I'd love to see more examples. It would be great to see clips from games to see each of the modes in action to better visualize how they work.
Why am I loving this series I’m not even developing an emulator or something
waiting for my mode
cool vid! well explained
Great as usual!
A nice random tip of the day:
If you have a modified PAL (Super Nintendo) or NTSC-J (Super Famicom) Snes which can play games from any region - but have noticed that American NTSC (Super Nintendo) cartridges are a little too wide to fit into the console, then do the following:
1. Open up an NTSC game cartridge, and take out the circuit board.
2. Open up a PAL game cartridge, and take out the circuit board.
3. Put the NTSC circuit board into the PAL (or indeed the NTSC-J Famicom) cartridge game case.
4. Be happy you didn't have to buy and adaptor, and play as many NTSC games as you want on your PAL console!
Note: all circuit boards fit in any region case, but no matter what shape the circuit boards are - if you are swapping out FX games (with the additional contacts either side of the main connector) - then likewise, swap the corresponding game cases to match!!!
Have a 'Super' day! ;)
I live for this shit. You're a good boy.
Awesome video, very well explained
I love his videos... Even if I don't understand a single word on it.
So many hardware limitations.
Yeah. But it is 28-year old hardware. Amazing capabilities for the time.
Thank Nintendo for the slow-ass VRAM. The reason all of these modes exist is to try and alleviate this. For example, the GBA, which has much faster VRAM, only has 3 tiled modes vs. 8 on the SNES; one mode with 4 8bpp layers, one mode with 2 8bpp layers and an 8bpp "Mode 7" layer, and one mode with 2 8bpp "Mode 7" layers.
Impressive, showing actual gameplay footage all split up like that.
wow the SNES was really complex! I am trying to program it using assembly for a game idea that I have.. but it will probably take me years yo get something tangible
RUclips recommended part 4 to me. Fun.
damm! i really wanted to see mode 7 :/ great video BTW keep this awesome content going please! ;)
Cliffhanger. ;)
Wait you're doing this research just for fun? The quality and depth is just mindboggling.
2:00 Mode 1 (I know mode 0 is the first one but this is a bookmark for my favorite mode)
Very nice video, more examples for each mode would have been nice though, I lost the thread at mode 5 lol
SNES was a beast.
"Part 4b - Higher Resolutions: *coming soon*"
In the description should be updated to:
"Part 4b - Higher Resolutions: ruclips.net/video/AnEuk8Vj3w0/видео.html"
Incredible series. I've been having a blast
Thank you!
4:01 - 4:13 distracted me from what you were saying cause I wanted to see if the player was going to get the potential x10 chain combo there. Hell, even if it ended at the x7 combo, the player just won as there's no way Easy Lakitu would be able to chip away at a Garbage Block that size in time to save his cloud ass.
Sorry, I was an avid Tetris Attack player back in my misspent youth and used to be able to beat Bowser on Extra Hard mode with fair regularity.
what comes after the snes? i would like to know about the nes or the n64, but you are the creator of these awesome videos.
3:27 I finally know how the fuck they did that in Yoshi's Island
I can't wait!
Mode 7 is going to rule!!!
I can't wait to see mode 7!!!!
Awesome work. ;)
That's, uh, very interesting. But I kinda don't remotely understand what most of those features would be useful for in practice. I'm sure they're useful for _something,_ I just lack the technical knowledge to grok _what._
Timothy McLean They're not; most of these features are just a waste of silicon that would be better used for more sprites or palette entries. Hires mode in particular is a waste; there's not near enough VRAM bandwidth or VRAM in general to make it practical.
Well, you have to remember the SNES suffers from some last minute cost cutting as far as I can tell.
Both high colour and high res modes are far more practical when you remember that the PPU is designed to address 128 kilobytes of VRAM, not 64.
That the upper 64 kilobytes is missing speaks to some kind of cost cutting.
I also did some calculations on just how fast VRAM has to be, and it comes out pretty much the same for every graphics mode. (though highres mode seems slightly above average)
Regardless of mode, the graphics chip needs to read about 2 bytes per pixel drawn. (averaged out, because it doesn't draw individual pixels), to draw the backgrounds, and another byte or so to draw the sprites.
(the high res backgrounds seem to imply 10 bits per pixel drawn, but obviously you have twice the number of pixels now)
When you do the calculations in relation to the framerate you quickly realise total memory bandwidth has to be in the region of at least 10 megabytes a second.
It DOES use two independent memory channels though. (16 bits per memory read, but the upper and lower bytes can be individually addressed - as far as I can tell while this functionality no doubt has secondary uses it primarily exists to make mode 7 possible.)
Considering that DMA bandwidth is only equivalent to 2.68 megabytes per second, it's not the video memory bandwidth limiting things.
And for the actual internal functioning of the PPU itself, it really isn't wanting for memory bandwidth. It has what it needs. No more, no less.
The whole thing seems balanced to do whatever combination of features can fit into that kind of bandwidth.
Also worth noting you can switch modes midframe, which is how most of the known uses of hi-res mode are being used.
Sprite performance is most likely limited by VRAM performance, though it's hard to say exactly.
Adding more sprite entries wouldn't accomplish much since the CPU in the system already struggles to keep up with drawing considerably less than 128 sprites. (sure highly optimised code could do it, but actual game developers rarely have the time or patience for those level of optimisations.)
Extra palette entries would require redesigning the entire way that backgrounds and sprites function.
At best you could take the functionality of mode 0 (where each background has a unique set of 24 possible colours) and extend it to the other modes. (which would imply multiple backgrounds each having 120 colours to themselves.)
But when you start messing around with stuff like this, you quickly run into that 64 kilobytes of VRAM...
That's where they really dropped the ball.
The system can handle a weak CPU - they demonstrated about half a dozen workarounds.
But towards the end of it's life, that missing 64 kilobytes of VRAM probably hurt a lot.
What the SNES needed, if it really needed improvement is the full 128 kilobytes of VRAM, and especially a faster DMA controller that can write into VRAM at a higher rate.
All those late era games such as the SuperFX titles are more than likely DMA limited.
High resolution and high colour mode use was limited due to lack of VRAM...
IF you look at what the registers in the PPU allow, and calculate the RAM involved you see just how much that cripples the chip - all the higher end functionality works out decently with 128 kilobytes to work with, but with just 64 you run into a LOT of limitations, because it's very easy to blow your VRAM budget...
By the way, I doubt most of those features are using that much silicon. They probably just implemented a bunch of things then worked out what they could reasonably combine together.
The high resolution mode in particular... That's really not a huge deal to implement - the only thing you need to be able to do to implement high resolution mode is run the pixel clock at double the speed.
Output 512 pixels per line rather than 256.
Given the rest of the logic the mode uses, I highly doubt it does anything more than that - it just re-uses the existing functionality from other modes, but doubles the pixel clock while doing so.
The functionality to support interlaced graphics is enabled in all 8 modes, though only the high resolution modes do anything to support it. (really all they need to do is perform a one pixel offset every other frame, and skip every other line of a regular background on a single frame)
Even the sprites support interlaced mode...
I don't think the high resolution modes have any huge implementation cost. Removing them wouldn't gain you much.
High colour mode on the other hand, requires being able to address 8 bitplanes instead of 4.
Though functionally speaking the hardware already has to be able to read 10 bitplanes of pixel data and 3 tilemaps just to support the system's core feature set used by 99% of games. eg. Mode 1
I highly doubt they did much beyond link together the functional blocks already present for other reasons with the minimum amount of glue logic they possibly could.
My guess is High colour and high resolution modes follow naturally from abilities the hardware has for other reasons, could be implemented cheaply, and were therefore added just because they could without much consequence.
The real resource hog in the PPU design is Mode 7 - supporting that requires a completely different rendering logic to any other mode, and I'm fairly sure it also pushes the memory bandwidth harder than any other mode there is.
The Memory bandwidth was almost certainly chosen with mode 7 in mind and then the other modes were defined by looking at which functional blocks could operate together within that amount of bandwidth.
(and which combinations might actually be useful.)
I wouldn't expect there to be massive amounts of wasted silicon to support niche features.
Rather, I suspect the niche features exist because they represented a minor addition to functionality that was already there.
A large chunk of the complexity afaik is the sprite rendering, which requires a buffer to render the all the sprites together on each scanline (takes up as much space as the whole palette registers I think), plus the spite registers (another large register file), plus a sizable portion of vram bandwidth and a complex scanning mechanism. And it's all totally worth it.
lol@ this guy saying the system needed a memory bandwidth of 2mb/s, when the absolute largest game was only 6mb, and most were sitting at 2-4. surrree. its totally running its entire program through the ram at all times. fucking idiot.
That's very clever of Nintendo that they put together eight different background modes for the Super NES.
I love you
Cacete! Acabei de descobrir esse canal uns dias atrás e já te encontro aqui! XD
KJSJKS Raramente comento, quando consigo tu me acha. kek
Venho acompanhando, e é excelente! Esse vídeo aqui inclusive era algo que eu planejava fazer a muito tempo. lol
Sim, estou admirado pela qualidade do conteúdo desse canal. :D
Acho que seria uma boa você fazer um vídeo sobre isso em português no seu canal.
É bem interessante e se encaixaria perfeitamente com seus outros vídeos informativos.
@@NintendoFan What the hell is wrong with you?
I'm quite curious what mode each of the most popular SNES games have used (A Link to the Past, Super Mario World, Star Fox, etc.)
I think this video needed more practical examples and comparisons. I was able to keep up with everything in your other videos, but this one had me scratching my head a few times.
Great video! Your motion graphics are very well done. Please can I ask what software do you use? Thx
How the heck is direct color able to use the extra 3 bits that were used for palette selection? Do you just choose a small section of the RGB color space for the entire character to follow? Because what's throwing me is that the bits are in completely different places: one in VRAM(tilemap), one in wherever characters are defined in.
Yes, those 3 bits apply to the entire character at once.
Would they be like the most significant R G and B bit then? Or least significant?
The least significant that isn't zero. That is, the entire color is 0bbB00gggG0rrrR0 where bbgggrrr is the character data and BGR is the palette index data.
Okay, thank you!
Have you ever seen a SNES game with direct color mode applied?
2:35 there's a weird white pixel anomaly on the right side of the screen
Read the first person on the patron list.
In Mode 0, does every 4 colour palette absolutely have to basically throw away one of the colours for transparency (effectively reducing the overall single background layer colours to 24 and the amount per 8x8 tile to 3)? Or, if you don't want to use any transparency on say the backmost background layer for example, can you set it so most of the palettes for that layer don't waste one of the colours on transparency, and then you can get access to the full four colours of the palette for the most part?
Color 0 of each palette must be transparent, there's no getting around it.
Maybe I missed something, but it's not immediately clear why (using Mode 1 as an example) a 4 bit-per-pixel background would have access to 128 colors. Naively, I would think it would have access to only 15 + transparency (as there are 16 distinct 4-bit combinations). But you multiply that by 8 because each tile can have a separate palette?
Each tile can use one out of eight palettes.
i can see the potential in mode 2 + hdma to render doom graphics
Mode 7 makes Mario Kart look 3D, even though the map is just a big 2D picture.
Cannot hit the like button enough times!
I never understand these, but that's likely because of my general ignorance with the field of graphical programming. I still find them really interesting to watch and the animations are really well done even if I have no idea what in hell is going on haha
Well you just need to know the SNES is a hardcoded hardware picture displayer that doesn't control individual pixels by sotware. It has a custom picture procesing unit that outputs frames always based on 1 to 4 backgrounds and some sprites. So the actual game graphic programming is just first upload the background graphics data and then just change the X and Y coordinates (and doing the similar for the sprites). It's hard coded in it's circuit. Hope this helps people that are completely lost haha.
i love it
What's the name of the font you use for the list at the beginning of the video and for some of the graphics? It looks really cool and I think it fits this video's style a lot.
It is called "ModeNine"
Thank you!
I was thinking that for XAMPLE if only 1 background can be used for 256 colors, and we want to ellusionize extra backgrounds, then we can use line scrolling & tile updates to give that ellusion of extra backgrounds,,,
But what if we want to use 4 backgrounds but we are only limited to 16 colors per background thus 4x 16 = 64, well in order to ellusionize extra colors, we can do use colors swaps to simulate 256 colors onscreen.
If we want to use the full resolution of the snes but have to deal with only 4 colors, then we can do use once again the color swap/mid-frame scanline trick to fake extra colors onscreen.
This to VIRTUALY get around these limitations.
aww hell, he finna go mode 7 on em
cannot wait to see mode 7 broken down :)
After watching these videos it sounds like you have the SDK for the SNES. If so that is awesome.
Ryu Ramasama I want to eventually own one, I want to own an SDK for everything
Yeah same after watching videos where people show off older dev kits and sdk's for retro consoles I'm totally interested in trying to make a game on a retro game console.
Do you know what Mode 0 could be used for?
Games with Gameboy/NES-like color limitations.
Mariann Mariann yeah, so ports
What's the advantage of Mode 4 over Mode 3? It just seems like everything is more limited in Mode 4. What benefit does having access to direct colour offer (not that I actually know what "direct colour" really means) if any game using it can't show as many colours in this mode anyway and can't do quite as good column scrolling either? Do you have an actual use case where it would be better to use Mode 4 over Mode 3?
It was used as a 8bpp + 2bpp combo in some games, like the cutscenes of Adventures of Indiana Jones, Toy Story and an actual offset-per-tile use in Super Genjin 2 title screen.
5:39 Also slightly yellow.
Does the SNES background layer 1/2/3/4 priority work similar to the Genesis Plane A/B priority for effects that create the illusion of far more overlapping background layers, such as seen in the cloud level of Thunder Force IV on Genesis for example, or can only the Genesis movie Planes viusally in front of and behind each other depending on how the priority is set?
I don't know about layer 4, but you can definitely make individual tiles from layer 1, 2 and 3 appear in front of each other. The Aladdin example does this: BG2 high priority > BG1 > BG2 low priority. BG3 is using the exclusive absolute priority bit.
You can also do this by changing the mainscreen/subscreen setup middle screen with HDMA.
@@maxwelseven Yeah, I found out in Mode 0 it's slightly different: You can switch tile priorities between layers 1 and 2, and you can switch tile priorities between layers 3 and 4, but you can't switch tile priorities between say layers 2 and 3. What you can do though it use the main and sub screens to move layer 2 above layer 3 for example. So, in a slightly fiddly way, it's possible to mix most of the layer priorities around.
Did Super Gameboy use Mode 0? Or probably not due to the GUI/frame thingy.
*sees in recommendations, clicks instantly, forgets what he was doing*
Great work !!!
It's possible to have the Game Boy Advance version of this kind of video ?
Alessandro Cussino The Gameboy Advance is considerably less complicated, although much more powerful due to having much faster VRAM; it only has 3 tiled modes vs. 8 on the SNES. All layers can be either 4bpp or 8bpp in all modes, ("Mode 7" layers are forced to be 8bpp) so 2bpp is no longer an option, and the way the modes go is Mode 0 has four regular layers, Mode 1 has two regular layers and one "Mode 7" layer, and Mode 2 has two "Mode 7" layers.
Can you do a series on MSX series and X68000 series graphics modes? Thank you!
Are the high-res modes only 30fps vs the other modes that are 60fps?
And, is tile flipping allowed in these high-res modes?
Horizontal hi-res is 60fps, yes. Interlace mode is also 60fps, but only one field is drawn per frame (half of the vertical resolution).
And yes everything works just as you would expect normally in hi-res mode other than color math.
What Mode did Super Metroid's intro use?
Borka223 It is.