This was my most complex video I ever made, and I'm thankful for all the positive feedback. Side note: Some of the live action audio sounds bad because I was using some brand new crappy lavalier microphone.
I remember finding that out when I used the ancient NES emulator Nesticle back in the DOS days. Utterly useless and archaic by today's standards, but the best (and somewhat only) option for NES emulation back in the day. It had a graphics editor that would let you edit the graphics of the game live as it was running and see the effects. I remember trying to edit the bushes and noticing that the same effects were being applied to the clouds...
@@idran7096 Yup, he had a sort of "company mascot"/avatar called "shitman" that was literally what it sounds like, they made some DOS games too under the name "Bloodlust Software". I recall there was also a Genesis emulator at the time called Genecyst. Incidentally after retiring for about 30 years the creator of Nesticle came back working on another emulator called MetalNES that is supposed to be transistor-level accurate.
@@Cyber_Akumaloopynes was a good one. My old computer from 1998 broke, so I had to use a Windows 3.11 computer that my parents got from the trash. I assume it was from 1993. Nesticle lagged on it. LoopyNes ran at full speed.
7:18 No, the music was not created in a tracker. Trackers weren't even around back in 1985. Most video game sound programmers back then coded their music directly in assembly, manually typed hex code, or some form of MML.
3:12 That's actually the CIC chip, which was used to prevent unlicensed games from being played (and the identical one inside the console was the cause of the infamous "blinking red light").
@@josephrcarroll7336 Me too I always thought the version/anti piracy crap was built in the software and these chips were just also some kilobyte of RAM as a buffer for the ROMs. but nope, it's really a dumb rebranded logic gate that determines if you have the right to play the game you own.
@@Diamond_Tiara It's actually a Sharp SM590 4-bit microcontroller (basically a tiny computer with a CPU, RAM, ROM, and I/O all in one chip) running the 10NES program. The CIC chip in the console and the one in the cartridge communicate with each other at start up, and if there is any issue in that communication, the chip in the console will reset the NES every second. Because no third parties had access to Nintendo's Copyrighted code running on the CIC chip, it was extremely difficult to make a pirate/unlicenced cart without resorting to more exotic methods of circumnavigation (ex. causing a voltage spike to knock the CIC chip in the console out, using lock-on technology to piggyback a licenced game's CIC, or even reverse engineering the CIC such as with Tengen's "Rabbit" chip.)
@@zynidian @Zynidian Sweet Celestia... so it's closer to a cryptoprocressor by todays standards, a thing that will bring logic necessary to run a software. it was an era when chips on visa/mastercards were not even common. And yes the secu on arcade games was even more insane, keeping even parts of the code on S-RAM, or invent methods close to encryption of the software, I mean, not even a several thousands dollar Oracle Server software comes with such bullshit to validate thre license. EA or Ubisoft mostly can't run without an internet access anyways.
3:54 "While the game never changes vertical axes" That's actually part of the reason why Super Mario Bros. 3 has the miscolored band of tiles on the right side of the screen; because the game has vertical scrolling, it has to load in more at a time, so it has little troubles like that.
Sadly I haven't seen a concise answer yet on how they managed to limit the color banding in Kirby's Adventure (as a late-life NES title) to the left side of the screen where it can be masked using the PPU.
It's not that the game has vertical scrolling, but that it has BOTH vertical and horizontal scrolling at the same time. Games that only did one could generally hide that effect because the NES basically let you keep two copies of the screen into memory to prevent new objects loading in from being visible, but if you scrolled in both directions then you was using up that "off-screen" space for what was actually on screen. Even even back then on CRT screens the overscan was not enough to prevent it from showing up completely. If the overscan could take care of it then it would not have been a concern to have that whole double-screen feature.
Even before then, Super Mario Bros. 2 (aka Doki Doki Panic, kind of, yet also kind of not, but let's not get into that) went out of its way to have a lot of vertical falling and climbing in its levels in contrast to the first SMB. Though you can tell literally the moment you start the game, which begins with falling a pretty substantial drop out of the sky, that it lags a bit every time it has to vertically scroll compared to how seamless horizontal scrolling is.
I feel like this really only said 2 tricks they did to reduce the memory of the ROM, and the rest was just technical info on the NES itself. I was hoping to learn something specific about SMB but it was almost all facts that were true for any NES game
I think the point is that smb was the revolutionary early example which first used the techniques that would then be used for almost any nes game. But I see what you mean
True but I enjoyed watching a young person actually being interested enough to even bother noticing how insane fitting it all in 40K is, and then bothering to find out some things about how the old console worked, and THEN bothering to make an entertaining explanation about it.
The assembly code displayed at 05:26 is actually a Linux program for the Intel x86 family of processors. It prints "Hello world!" to STDOUT, and exits. I think it will probably work on any BSD kernel based operating systems if the two syscalls are the same (such as OS X). I'm too lazy right now to look the syscall numbers up. (I used to do a lot of x86 assembly programming, so I instantly recognized this.)
The entire Mother series is like 40MB. Edit: I swear to god stop replying to my old ass comment! Edit 2: So you people wanna reply, huh? Then I'll give you a little question. Who is my favorite Toaru girl?
@Eren Yıldırım actually mother 3 probably is the bulk of that size, considering SNES cart sizes were a max of 6MB, and earthbond is probably within the normal 4mb limit
@Eren Yıldırım and the standerd size for a GBA ROM is 32MB i belive. and even in modern times, DS games normal cart size was 128MB, though some bargan bin ones came in 64. the 256 one was a commonly used large cart, while the 512mb one is seldom used, most famously for the BW2 games
Mostly correct it was more meant to lockout games not made by nintendo. They where afraid if low quality games would enter the market the video game market would crash again
@@bartvandeloo1255 Not true at all. The chip was made so that Nintendo could control how many games could be released on the console by a single company on a short period of time (5 games per year). It had nothing to do with the quality of the games.
@@Octolicia the point I meant is that nintendo could control what games released. The reason is not officially known but is thought to be to prevent every small company just being able to make and release bad games made in 4 hours in the basement. Bad quality games with good box art crashed the market back than. That is also why the early NES box art is so basic to not mislead customer. So they don't get disappointed
There is a sort of default layout that keeps being drawn, which is affected by various objects, which can spawn runs of blocks into that default as you move. So when you see a bunch of "?" blocks for example, usually it's just a single object that spawns the entire row or column of blocks. There are objects to change the "default" layout to another one, which is most notably used in the underground and castle levels.
CORRECTION: The "black" color of the palettes can be easily changed just like the other slots of the palettes. However, only *one* background color; more than one would require changing it while the screen is being rendered, whoch some games indeed do If that wasn't the case, the sky in SMB1 would be black at all times.
@@func_bolillo The game sets the palettes, as chosen by the developers. Colors in palettes can be changed even when they're in use. It's used in this game to give coins and ? blocks their glowing effect.
The "black" colour of each palette is really simply transparent, but cell 0 of the palette memory holds the background colour, which is used on every pixel that is transparent on both layers.
Esch color 0 of the 4 bg palettes is mapped to one and only background color. So if you set color 0 of palette 2 to red, then all colors 0 in palettes 0, 1 and 3 will also be red. That is, if for some reason, you read them back....
I am actually a sophomore in college taking computer engineering and it is mandatory that we learn how to properly program a 6502 with assembly language and seeing all of the cool things done with it back then is cool, too bad it isn’t used much now.
3:12 that's the 'key' for the NES-10 lockout chip on the NES motherboard. It was designed to prevent third party games from running, though it was eventually circumvented and is primarily a source of annoyance these days as any dust between the NES-10 cartridge pins and the lock would result in a blinking power light and the game not booting.
Atari 2600 game programmers DREAMED of having the power of the NES back in the day. _They're_ the ones who deserve to be admired. Actually, before RAM became affordable and processors became much faster, all those old systems had to make compromises and use different methods to stretch that RAM and lack of processor speed as far as they could. This resulted, most of the time, in games that focused on game play rather than eye-candy since game play was all they had. The best example I can think of for a programmer squeezing every last drop of processing power out of a game system is David Crane's "Pitfall!" for the Atari 2600. This game was 4k, yes FOUR kilobytes, which is 1/10th the size of Super Mario Brothers ROM, yet it contained 256 screens and has many different aspects such as scorpions, rolling logs, swinging vines, alligators, treasures to capture and much more. Here's David himself talking about how he did it! ua-cam.com/video/MBT1OK6VAIU/v-deo.html
@@palmberry5576 Yep. David Crane is a legend. In that lecture linked above he talks about how he originally only gave the player ONE Pitfall Harry to complete the mission, but when his co-workers talked him into giving the player 3 lives it took David another several weeks to optimize his code even further to insert that feature (he had used 100% of the available ROM space already).
@@palmberry5576 4k reminds of demoscenes which are dying out , people managing to create full 3d scenes and intros with in just 4kb size limitations etc using windows existing resources. Also kkrieger which is full 3d FPS game demo under 100kb! Unlike today devs reslly tried to be efficient.
As a kid i never really understood how tiny amount of information 40-70kb of data was. As an adult i am simply baffled by how they were able to pull this off. So many tricks used to reuse assets. Also we have been spoiled today by storage space, its almost not even a factor anymore. So using MP4s and images is more common as theyre richer and easier to work with than raw data.
Honestly, 40-70 kb isn't that little data in the first place. 40 kb is 40,000 bytes. That's 320,000 binary flags. The smallest common encoding for English characters is 1 byte per character, meaning 40,000 bytes is 40,000 characters. English is typically about 6 characters per word inc. spaces and punctuation, so that's 6667 words, which is around 3 chapters of a novel. That's not a ton of data, but it's also not nothing either. In contrast, games these days are regularly like 100 gb. 100 gb is enough to store around 300,000 novels worth of data. That's insane.
@@seigeengine The things that take the most space is sound and images, so yes, it is frankly quite a little data. Even when compressed heavily, image data is the biggest easy. You are comparing it to words, which is a bad comparison.
They don't really have to though. An image, without compression, can have as little as 1 bit per pixel. With compression, I have images that are large even on current displays that are only a couple kb in size. That's before you get into things like tiles, which effectively reduce the resolution of the display. Sound is more outside the scope of my knowledge, but it's similar. Strongly disagree. Text is the best way to discuss data size, as it's the most intuitive way of conceiving of stored data to an average person. @@SioxerNikita
Game developers back then utilized a lot of techniques to reuse data that took up a lot of space several times. Graphical data uses indexed colors with palettes usually not having counts in the double digits, audio was usually very simple, and often made using audio samples that could be reused easily or sometimes made procedurally. An interesting example of asset reuse is classic DOOM's textures. While the classic doom engine already uses paletted textures for everything, it also has a system for combining multiple textures together to make a new one.
fun fact, only the first image of assembly is MOS 6502, the other one is intel x86. Also, in the 6502 one, the CLC line is superfluous since the sum is always $66 and won't set the carry flag and the code doesn't even check for it anyways.
I want to note that the context of the release of Super Mario Bros. in Japan is pretty important and notes how the game was crammed in a tiny cartridge in 1983 Nintendo released the Family Computer or Famicom fot short and for the first 2 years of the consoles life you really only saw very simple arcade like games for several reasons, one of those being hardware limitations and Super Mario Bros. on the Famicom absolutely pushes the limit on what you can do with just the stock hardware heck that's partially the mindset the development team had when creating Super Mario Bros. a little later after Super Mario Bros. released in Japan Nintendo would launch the Disk System add-on for the Famicom which at the time was more capable of storing a lot more data than cartridges but advancements in technology soon after made the Disk System obsolete couple that with piracy being a problem and the disks themselves being at risk of not working you can see why an NES release was scrapped Nintendo and other companies would create new mapper chips for future cartridge games which literally added in hardware inside of the cartridge that the system can use this video doesn't really go into this context and as a result I don't think it properly explains why they even had to do all of this
03:12 No, this is not RAM. It's Nintendo's lockout chip, an anti-competitive measure to prevent competitors from making games for Nintendo's console. There's a counterpart chip inside the console that talks to this chip and performs a handshake during reset. If the keys don't match, it sends the CPU a permanent reset signal. 03:33 No. It's a tile map. The tile set (or the character set) is what's held in the cartridge ROM and contains the definition of each tile that can be used. The tile map is the way the console organizes the image on the screen, dividing it into tiles (characters). Then it can store just the numerical index of the tile that should be displayed at a particular place of the grid on the screen. The tile map stores those indexes, it maps the tiles onto the screen. 03:36 Wrong again. Tile sets are collections of _tiles_ , not _pixels_ . Each _tile_ is a collection of pixels. 04:00 Nope. Each TILE had that limitation, not a TILE SET. The tile set doesn't care about colors. Each tile made of pixels just stores the indexes of one of four colors from the palette, but it doesn't specify what particular colors are they. The information about those colors are stored in the palette, and there's a couple of different palettes the PPU could choose from when rendering the tile map. The number of the palette has been stored for every tile in the tile map, so each 8×8 box on the screen could use only those 4 colors from one particular palette, but another 8×8 box nearby might have used a different palette of 4 different colors. So overall, there might have been more than 4 colors on the entire screen, but not within a single tile. 05:12 Yeah, figures… :q So WHY DO YOU MAKE A VIDEO ABOUT IT IN THE FIRST PLACE?! :P Next time you decide to "explain" anything to your viewers, make sure that you understand it yourself well enough. Otherwise, all you do is just spread misinformation and make fools of your viewers and yourself. And if anyone wants to know how graphics worked on NES consoles, there are much better videos out there, like "How old-school graphics worked" (2 parts) by The 8-Bit Guy, "NES Graphics Explained" by NesHacker, or the series of videos on Retro Game Mechanics Explained. I recommend you to watch _that_ instead. You'll learn much more, and more correctly. This is probably where the author of this video learned about all of this (and understood less than half of it). I even recognize some of the pictures. E.g. the one about the sound channels is directly copied from The 8-Bit Guy's video titled "How Oldschool Sound/Music worked". Plagiarism is not cool :q You could at least draw your own picture.
@@deemster4249 - Yeah, he just dubbed over the dialogue parts. You can hear it when the music plays and his recording microphone fuzz cuts out. I saw the video it came from again about a month ago, so I was able to remember it.
Very familiar for those of us who started years earlier on the Atari 800 or similar 8-bit system. There was roughly a four year gap between when the Atari 8-bit computer (and 5200 console) and Famicom chip sets were engineered. This meant Nintendo's engineers had a significantly larger transistor budget, though the amount was a rounding error by today's standards. This allowed for greater sprite counts and displayed color depth and more complex audio but one can also see some difference in the basic choices the two groups made. Atari placed an emphasis on color range, supporting a palette of 128 colors in the original CTIA chip and 256 in the later GTIA upgrade. (You could directly replace the socketed chip to upgrade.) This allowed for some tricks the NES cannot reproduce. Also, the Atari didn't have sprites in the traditional sense but rather four pairs of what were called player-missiles. A player was an 8 pixel wide band that ran the entire height of the screen. These were mono colored, so the pixels in the band were either visible or transparent, allowing for one player to appear to be several objects in different vertical locations. The missile was a 2 [pixel wide version of that vertical band. The missiles were actually a fifth player divided up to provide and adjunct missile to each player. This was a compromise from the transistor count that would have been needed to have a full 8 player objects. The later Amiga systems, which had some of the same engineers involved, had similar full screen height objects but also had for the time powerful hardware functionality that allowed moving software defined objects around well enough to do things well beyond what sprites provided. Up until then there was a division of having lots of hardware support for character or tile mapped displays or doing everything in software on bit mapped displays like the Apple ][. Combing the two changed a lot of the rules for developers, which is why the Amiga was the platform of choice for for young developers for many years. Later, when those developers were married with families to support, the platform of choice was the one that came with a steady paycheck.
I recently discovered your animation channel...and then found out you left it...but guess what? I love this new type of content more than animation! So I subscribed!
I just realized, what is funny is that we're likely to return to cartridges again. The storage density of an SD Card is tremendous compared to Blu Ray, you can easily get 128GB for just $10.
Btw that third small chip is the CIC. It provided copy protection for the console. Modern vintage gamer has done at least one video covering it. There's a matching chip inside the NES. They use some lock and key type thing. Look it up, it's pretty fascinating.
4:51 recent 3d games will use 10 different 3d models with hundreds of textures to have sprites (npc/objects) have different colors, this is one reason why today's games are soooo huge. Hope they learn to use tricks like the early days.
To answer your question, "how did they compress mario into one cartridge with huge scrolling levels," they stored level data as a collection of vertical 32px wide strips (the chunk that they load in on the fly for scrolling) and they reuse them A LOT. Thats how
Nice video. Just a note. 6:05, this is not a standard scheme. E.g. Metroid uses two 16 kb banks, one fixed, and the other switchable, in order to access the rest chuncks of the ROM. This is because Metroid is a 128 kb ROM, and it doesn't fit in 32 kb. But Super Mario Bros can access the whole code and data without any switching.
Man you have a good style of humor Wanna know a sad part In the philliphines most kids didnt even know what a console was which was sad and now 2020 I only see kids having "bootleg" consoles And the dumb part is they didnt knoe their consolr is fakr
Idk about that i did own a Fake Famicom as a kid but Theres 2 Family here in our neighborhood including ours that has a PS4 and im not even from the City.
i live in the phillipines and was born there, and now ive had a switch for 2 years, and when i was like 2 years old, my 2 brothers and my 1 sister got gameboy advance sp's and my 2 brothers's game was Pokemon Emerald, and my sisters game was Pokemon Ruby. we also bought the sims the gameboy game, and super mario advance. my parents had the nes. so we never had a bootleg console. it was always nintendo.
Exactly. This entire video feels like it was made by ChatGPT. By that I mean it's nothing more than a surface-level analysis. This video just skims over a couple of tactics used to save a bit of data. There is very little explained about how exactly an entire 8 world video game was crammed into 40 kb. He spends more time building up to the video than actually explaining how the ENTIRE game was crammed into 40 kb. Sure, meta tiles and assembly are neat. But he didn't even fucking explain how all of that data was crammed into 40 kb. The point about "tracker music" was complete fucking bogus too. Trackers weren't even a thing back then. Did he get all of his information from a dream he had or some shit? This video was a complete and utter waste of my time.
The video was extremely educational, while also being simple enough for everyone to understand. Also, the edits were amazing, it'd been a while since I'd seen someone put so much work into that. Great job dude!
Back then developers had to figure out how to fit all the data with such small storage, but now developers have to figure out how to afford to use all the hardware since the files are huge.
I think that’s a bit insulting. Scott is certainly awesome, and Joseph is cool in his own way. I don’t think he was ever trying to copy Scott. Very different styles!
@@Brinta3 didn't mean to give off that I thought he was copying. More along the lines of inspired or influenced in some way. Rewatching it now though, the differences are clearer to me.
Nice video! You can actually access all 32KB of data, it's the bigger games where the "bank switching" comes in and you have to move chunks of data around. Also, there are emulators with wonderful step-through debuggers like Mesen. Glad to see stuff like this though =)
it is also amazing that if you just want to create a text file addressing all the tiles in the game, you'll still wouldnt be able to fit it in a 40kb rom. They needed to split each stage into numerous pages with basic stats each, so you replicate those pages with tweaks for extra blocks, enemies, etc.
"NES game developers were [...] the early pioneers of game development" Er...not really, no. Videogames existed long before the NES did. Not even console stuff, but computer games too.
They certainly set the standard for what games would be for years to come. Previously, games were just electronic toys to distract you for an afternoon. Consoles like the NES really expanded the possibilities and made games more of a pastime or a hobby and not just a toy.
Short answer is reusing assets, midframe memory swaps and reducing and reusing the lines of code to the minimum to still accomplish what they needed to do. It really is impressive what they were able to do back then with so little to work with.
this doesn't really explain anything about how the game fits into 40kb... it was more of a showcase of NES hardware. the game does many optimisations like reusing graphics and audio, as well as writing very versatile code to handle a lot of things through the same code. SMB1 also saves a lot of resources by saving levels in pages, with ceiling and floor heights, as well as objects that tell the level loader to place tiles in the background layer (another example of reusing the objects system to not just be entities!). many other games simply stored tilemaps, which were huge. enemies also shared the same code, the game just checking what the type number is for doing enemy-specific things like moving faster and changing the sprite to be a shell when jumped on, or changing to a flattened goomba sprite when jumped on. powerups, instead of being all separate objects (requiring more code to be stored), simply were just one singular object, where the game would change the appearance of the powerup sprite depending on mario's current powerup status (and mario's behaviour depending on that status). interacting with the powerup sprite would just cause mario's powerup status to increase by 1. the game also reused certain levels (such as 1-3 and 5-3 being the same), just using different enemies.
Thank you. Half of the information in this video was blatantly false. You have clearly done much more research than this drooling knuckledragging zoomer. I learned much more from your comment than this drivel that calls itself an "educational video".
While a really good quality production, sadly it was full of miss-leading information and even mistakes. I highly recommend you have someone knowledgeable in the details review your completed video next time, so you can fix bad info before a final version. This way they can make sure you understood the important details right and simplified correctly.
@@BlueRS123 For starters, kB not KB. Capitol ‘K’ is Kelvin while lowercase ‘k’ is Kilo. Here are a few examples of incorrect information: * Atari 2600’s largest game was 32kB, not 8kB. * CDs are not “that” sensitive. It employed Cross-Interleaved Reed-Solomon Forward Error Correction such that you’d need thick, long scratches or a lot of rather dirty fingerprints to stop it working. * There where 4 background palettes and 4 sprite palettes, not 4 total. 25 simultaneous colours. * The “black” is actually a shared common (any) colour for the background palettes, but worked as 1-bit transparency on sprite palettes. The big reason why the games were so small back then was because of the architecture. There was very little overhead and was very little waste. Unity (popular modern game engine), by comparison, is very bloated because it needs to cater for so much. Also that mystery chip is the 10NES lockout chip.
@@NikodAnimations My point isn’t about it being confusing to anyone, but rather the the standard. Many people and organisations, such as Google, also write KB instead of kB. It is however not strictly correct.
3:11 That chip is the "Lockout chip". It communicates with another chip on the NES' circuit board, and if it doesn't return a specific input, it forces the console to infinitely reset. This was an early attempt at DRM, although the Lockout chip can easily be defeated by snipping the reset pin on the NES' chip so it is unable to send the reset signal.
Just looking at the Yandere code made my eyes bleed. Should have just used enums instead of strings, with the Flags attribute for stuff like what is witnessed.
@Commodore X If I understand correctly, this is why I suggested an enum. It would store the thing witnessed as a single number while giving a name to each value so the programmer doesn't have to remember what each value represents. You could check if a student witnessed a murder with something like: if (someRandomStudent.Witneseed == WitnessedAction.Murder) 1 - It's easier to use than strings since most IDEs support suggestion/auto-completion of enum types 2 - The memory allocated to the enum value is no more than the enum's underlying type. YandereDev might even be able to define the enum as char, only using 1 byte per value You may have also noticed a student can have witnessed multiple things. In YandereDev's string-based approach, this is done by addind the word "and" between the names of witnessed actions. An enum value can also contain multiple values with a binary approach. By assigning each enum value to a power of 2, each value can be represented as a single bit being set. You can then set multiple bits to represent multiple enum values. To write multple values, assuming the enum is defined proprely, you can do something like someRandomStudent.Witnessed = WitnessedAction.Murder | WitnessedAction.CarryingIllegalItem; or someRandomStudent.Witnessed |= WitnessedAcion.Murder; if you want to add a value without affecting the rest To read individual values, you can add the Flags attribute to the enum type, allowing you to use the HasFlag method on a given value. When compiled, all enum values are replaced with the equivalent numerical value, so it would be the same as yourr suggestion regardless. The reason I suggest an enum instead is to not have to remember the meaning of each value.
Ok so to be clear, that code we see in the vid and that has been going around the net was generated by a decompiler and is not the actual source code. Switch statements are translated into if... else if... else statements on the byte code level most of the time (there are also some special cases not worth the time going into), so when the decompiler reads that byte code, he doesn't see the original switch statement. You can also tell that it was decompiled for the massive usage of the "this" keyword, which is typical of code written by a program. You'll see the same kind of shit in designer source files if you use a .Net ide for example. Also, it shows that youtuber who did this vid knows nothing about programming - both retro and modern programming.
@@doigt6590 decompilers don’t change the basic implementation. If it decodes as string comparisons it was string comparisons. If it used anything better (and anything would have been better) it would decompile accordingly. Best case it was comparing against string constants but that is still horribly inefficient code. You can’t decompile lipstick on a pig 🐷
@@A_Random_Person324 he compared what the games have to offer, botw with only 14 GB gives you a massive map, hundreds of side quest, and thousands of things you can do during the game before fighting Ganon, Tf2 on the other hand has a really entertaining concept, but I feel like Valve could have made the game by saving AT LEAST 7 GB.
6:29 as a game developer, this isn't a mess rather it is organized. also as long as it works we don't care how it looks. well we do, but only to the point we can understand it.
Okay, so I have 2 POVs: small JS dev and Luau dev. Since your youtube username is "Nooby", I'm guessing you're a Luau dev only. So JS (and some other programming languages) have what's called a switch statement. Luau does not have this. Switch statements in JS and other languages are much faster than ifelse. Instead of the script having to constantly check "Is this equal to this? If not, is it equal to this?" it can just go "Okay, let's just see if only this argument checks out and if not run default." And in the long run, this is much faster than checking if every statement is true. Since you're a luau dev, think of it like this: local input = {["Hello world!"] = function() print("Hello world!") end, ["Hello2"] = function() print("Helloworld2") end} local meta = { __index = function(self,input) return function() -- default function end end } setmetatable(input,meta) local hello="Hello world!" input[hello]()
Amazing video. I’m a child of the 80’s and NES remains the only system I have in my living room to this day. Also, I am a visual effects compositing artist by trade, and technical limitations and time are always present no matter what the budget of the project is. Doing my job as a comp artist, you constantly have to problem solve to get the results the client is looking for, without crashing the workstation as well as the final render. So I can fully appreciate and respect the NES dev teams who were up against crazy limitations, and still produced amazing games. It’s all about thinking outside of the box to find those creative tricks to get the job done.
Another amazing storage-related thing was how gamefreak managed to fit the entirety of johto _and_ kanto on a single gameboy (color) cartridge. This was thanks to the one and only satoru iwata. May he rest in peace
i actually have very severe time limitations with a modern computer: i want to program a good chess engine (>2k), and i managed to code all the pieces rules in a very optimal way (about 10ns on average). Calculating an attack map to determine if castling is legal (or if you're in check, but that doesn't have to be implemented, because i can use pseudo-legal moves anyway) is already suboptimal (69.04ns/move), and move generation (seeing where each individual piece can go) is beyond slow (109.94ns for about 10 pieces on board). And considering that these calculations will have to be performed millions of times, i would really like to target something along the lines of 5ns/piece for my pseudo-legal move generation function.
I'm only recently realising how quickly you need to move bits in order to produce pixels fast enough for the measly resolution of the NES. You need to output about 6 million pixels per second to keep up with a 240p 60Hz NTSC signal at that horizontal resolution. Designing the NES PPU to shift that amount of data that fast was a neat trick given the constraints at the time, and the limitation on the number of sprites per line really falls out of that naturally. Each line of pixels was being stitched together on the fly depending on which sprites were on that line.
The pace is nice, and the tone entertaining. But you have to double check your hardware spec. I understand that some stuff must be simplified to explain, but some things are just plain wrong in this video. Also, sorry, but the game pioneers were probably the Atari2600 guys. They had a much more restricted hardware and hacked a lot of it. But I understand what you meant, the NES was the first wildly spread console with sufficient performances to be considered as a versatile gaming platform.
I’ve spent 1,300+ hours in tf2, I could 100% BOTW in ~40 hours. I still haven’t gotten every achievement in TF2, and hell, I haven’t gotten every weapon
If you only compare the base relases of each game, Tf2-07 - Botw no Dlc his statement makes slightly more sense. But trying to quantify the return on time/ unique game assets for either game is moot when: they're different genres that came out in different eras with one being a single player titan with a prestigious pedigree and the other a hyper focused role based multiplayer experience. Idk bout csgo
3:12 That is actually the lock out, ( cic ) chip used by Nintendo to make it where only games officially licensed by them for the system would play, although some companies still manage to find ways around it at the time.
This was my most complex video I ever made, and I'm thankful for all the positive feedback.
Side note: Some of the live action audio sounds bad because I was using some brand new crappy lavalier microphone.
you did great!
This was really good
Minecraft was rebuilt in 4 kilobytes...
40 K isn’t impressive.
The Chip you pointed at and didnt know what it did is most likely a Copy Protect chip.
Boeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
Another interesting thing to note is that the bushes and clouds use the same sprite. That was kinda mind blowing when I heard it the first time.
I remember finding that out when I used the ancient NES emulator Nesticle back in the DOS days. Utterly useless and archaic by today's standards, but the best (and somewhat only) option for NES emulation back in the day. It had a graphics editor that would let you edit the graphics of the game live as it was running and see the effects. I remember trying to edit the bushes and noticing that the same effects were being applied to the clouds...
@@Cyber_Akuma huh, Nesticle, it's creator had a good sense of humor
@@idran7096 Yup, he had a sort of "company mascot"/avatar called "shitman" that was literally what it sounds like, they made some DOS games too under the name "Bloodlust Software". I recall there was also a Genesis emulator at the time called Genecyst. Incidentally after retiring for about 30 years the creator of Nesticle came back working on another emulator called MetalNES that is supposed to be transistor-level accurate.
@@Cyber_AkumaI've used genecyst through mame on some online emulator site lol
@@Cyber_Akumaloopynes was a good one. My old computer from 1998 broke, so I had to use a Windows 3.11 computer that my parents got from the trash. I assume it was from 1993.
Nesticle lagged on it. LoopyNes ran at full speed.
7:18 No, the music was not created in a tracker.
Trackers weren't even around back in 1985.
Most video game sound programmers back then coded their music directly in assembly, manually typed hex code, or some form of MML.
Bassically, they put "partitures" and the console would read that.
@@Shrek_es_mi_pastor ?
@@zzco stay cool
@@evarose1870 lol hi there, but what the heck is a "partiture"?
@@zzco code tabulature
3:12 That's actually the CIC chip, which was used to prevent unlicensed games from being played (and the identical one inside the console was the cause of the infamous "blinking red light").
Thanks for letting me know, I was wondering what that chip was for.
@@josephrcarroll7336 Me too I always thought the version/anti piracy crap was built in the software and these chips were just also some kilobyte of RAM as a buffer for the ROMs. but nope, it's really a dumb rebranded logic gate that determines if you have the right to play the game you own.
@@Diamond_Tiara It's actually a Sharp SM590 4-bit microcontroller (basically a tiny computer with a CPU, RAM, ROM, and I/O all in one chip) running the 10NES program. The CIC chip in the console and the one in the cartridge communicate with each other at start up, and if there is any issue in that communication, the chip in the console will reset the NES every second. Because no third parties had access to Nintendo's Copyrighted code running on the CIC chip, it was extremely difficult to make a pirate/unlicenced cart without resorting to more exotic methods of circumnavigation (ex. causing a voltage spike to knock the CIC chip in the console out, using lock-on technology to piggyback a licenced game's CIC, or even reverse engineering the CIC such as with Tengen's "Rabbit" chip.)
@@zynidian @Zynidian Sweet Celestia... so it's closer to a cryptoprocressor by todays standards, a thing that will bring logic necessary to run a software. it was an era when chips on visa/mastercards were not even common.
And yes the secu on arcade games was even more insane, keeping even parts of the code on S-RAM, or invent methods close to encryption of the software, I mean, not even a several thousands dollar Oracle Server software comes with such bullshit to validate thre license. EA or Ubisoft mostly can't run without an internet access anyways.
it's basically DRM
3:54 "While the game never changes vertical axes" That's actually part of the reason why Super Mario Bros. 3 has the miscolored band of tiles on the right side of the screen; because the game has vertical scrolling, it has to load in more at a time, so it has little troubles like that.
Which is really only a problem on modern displays. Back then it was hidden by the overscan.
Mega man 4 also does this
Sadly I haven't seen a concise answer yet on how they managed to limit the color banding in Kirby's Adventure (as a late-life NES title) to the left side of the screen where it can be masked using the PPU.
It's not that the game has vertical scrolling, but that it has BOTH vertical and horizontal scrolling at the same time. Games that only did one could generally hide that effect because the NES basically let you keep two copies of the screen into memory to prevent new objects loading in from being visible, but if you scrolled in both directions then you was using up that "off-screen" space for what was actually on screen. Even even back then on CRT screens the overscan was not enough to prevent it from showing up completely. If the overscan could take care of it then it would not have been a concern to have that whole double-screen feature.
Even before then, Super Mario Bros. 2 (aka Doki Doki Panic, kind of, yet also kind of not, but let's not get into that) went out of its way to have a lot of vertical falling and climbing in its levels in contrast to the first SMB. Though you can tell literally the moment you start the game, which begins with falling a pretty substantial drop out of the sky, that it lags a bit every time it has to vertically scroll compared to how seamless horizontal scrolling is.
I feel like this really only said 2 tricks they did to reduce the memory of the ROM, and the rest was just technical info on the NES itself. I was hoping to learn something specific about SMB but it was almost all facts that were true for any NES game
I think the point is that smb was the revolutionary early example which first used the techniques that would then be used for almost any nes game. But I see what you mean
Same as the Blake Stephenson guy.
True but I enjoyed watching a young person actually being interested enough to even bother noticing how insane fitting it all in 40K is, and then bothering to find out some things about how the old console worked, and THEN bothering to make an entertaining explanation about it.
1:04 Yo what is the AVGN doing there?
He’s gonna take you back to the past
@@UrAvgDMGTo play some shitty games that suck ass
To play the shitty games that sucked ass
The assembly code displayed at 05:26 is actually a Linux program for the Intel x86 family of processors. It prints "Hello world!" to STDOUT, and exits. I think it will probably work on any BSD kernel based operating systems if the two syscalls are the same (such as OS X). I'm too lazy right now to look the syscall numbers up.
(I used to do a lot of x86 assembly programming, so I instantly recognized this.)
who asked?
@aptro7855 I asked.
@@liviasilva3333🤯
@@aptro7855 we did.
@@aptro7855me
The entire Mother series is like 40MB.
Edit: I swear to god stop replying to my old ass comment!
Edit 2: So you people wanna reply, huh? Then I'll give you a little question. Who is my favorite Toaru girl?
@Eren Yıldırım actually mother 3 probably is the bulk of that size, considering SNES cart sizes were a max of 6MB, and earthbond is probably within the normal 4mb limit
@Eren Yıldırım ......
Mother3 takes a whole memory for most of it. Mother1 on NES's just 512KB.
We take it all for granted
@Eren Yıldırım and the standerd size for a GBA ROM is 32MB i belive.
and even in modern times, DS games normal cart size was 128MB, though some bargan bin ones came in 64. the 256 one was a commonly used large cart, while the 512mb one is seldom used, most famously for the BW2 games
3:11 I believe that chip is the 10-NES Lockout chip that made sure only licensed games fro the right region were played.
Mostly correct it was more meant to lockout games not made by nintendo. They where afraid if low quality games would enter the market the video game market would crash again
All games that went through Nintendo Approved Seal (or however it was called) had it
@@bartvandeloo1255 Not true at all. The chip was made so that Nintendo could control how many games could be released on the console by a single company on a short period of time (5 games per year). It had nothing to do with the quality of the games.
@@fucku2b Nintendo's Seal of Approval.
@@Octolicia the point I meant is that nintendo could control what games released. The reason is not officially known but is thought to be to prevent every small company just being able to make and release bad games made in 4 hours in the basement. Bad quality games with good box art crashed the market back than. That is also why the early NES box art is so basic to not mislead customer. So they don't get disappointed
"And unlike today" *shows game from 10 years ago*
thanks for making me realize how old i am
Guess im old now thanks
Portal's graphics really hold up to this day
portal 3 is a lie
wait what
Title: 40 kilobites
Image: 41 kilobites
Me: *visible confusion
@@BinglesP R/Wooosh
@@BinglesP r/woooosh
@@Gryn990 pls stop
@@minceraft8720 guy deleted a comment saying "Its caLLeD roUNdinG NuMBerS"
@@EvanDurda he's wrong, it's that windows literally adds a kilobyte to every file in the explorer unless you view properties
You didn't even explain how the levels are compressed to fit on the ROM, thats what I came here for.
It's encoded on per-screen basis as two bytes per run of blocks.
There is a sort of default layout that keeps being drawn, which is affected by various objects, which can spawn runs of blocks into that default as you move. So when you see a bunch of "?" blocks for example, usually it's just a single object that spawns the entire row or column of blocks. There are objects to change the "default" layout to another one, which is most notably used in the underground and castle levels.
@@vuurniacsquarewave5091 It works this way in Super Mario World, too.
CORRECTION:
The "black" color of the palettes can be easily changed just like the other slots of the palettes. However, only *one* background color; more than one would require changing it while the screen is being rendered, whoch some games indeed do
If that wasn't the case, the sky in SMB1 would be black at all times.
you mean it changes the colors in the palette slot like, in code while on run-time, or in design-wise?
@@func_bolillo The game sets the palettes, as chosen by the developers.
Colors in palettes can be changed even when they're in use. It's used in this game to give coins and ? blocks their glowing effect.
@@MuffledSword That's really amazing and clever. I didn't even knew that was a possibility.
The "black" colour of each palette is really simply transparent, but cell 0 of the palette memory holds the background colour, which is used on every pixel that is transparent on both layers.
Esch color 0 of the 4 bg palettes is mapped to one and only background color. So if you set color 0 of palette 2 to red, then all colors 0 in palettes 0, 1 and 3 will also be red. That is, if for some reason, you read them back....
I am actually a sophomore in college taking computer engineering and it is mandatory that we learn how to properly program a 6502 with assembly language and seeing all of the cool things done with it back then is cool, too bad it isn’t used much now.
3:12 that's the 'key' for the NES-10 lockout chip on the NES motherboard. It was designed to prevent third party games from running, though it was eventually circumvented and is primarily a source of annoyance these days as any dust between the NES-10 cartridge pins and the lock would result in a blinking power light and the game not booting.
No wonder the top loader model got rid of it.
Atari 2600 game programmers DREAMED of having the power of the NES back in the day. _They're_ the ones who deserve to be admired. Actually, before RAM became affordable and processors became much faster, all those old systems had to make compromises and use different methods to stretch that RAM and lack of processor speed as far as they could. This resulted, most of the time, in games that focused on game play rather than eye-candy since game play was all they had.
The best example I can think of for a programmer squeezing every last drop of processing power out of a game system is David Crane's "Pitfall!" for the Atari 2600. This game was 4k, yes FOUR kilobytes, which is 1/10th the size of Super Mario Brothers ROM, yet it contained 256 screens and has many different aspects such as scorpions, rolling logs, swinging vines, alligators, treasures to capture and much more. Here's David himself talking about how he did it! ua-cam.com/video/MBT1OK6VAIU/v-deo.html
Dang, pitfall is 4k?? That’s really impressive ngl
@@palmberry5576 Yep. David Crane is a legend. In that lecture linked above he talks about how he originally only gave the player ONE Pitfall Harry to complete the mission, but when his co-workers talked him into giving the player 3 lives it took David another several weeks to optimize his code even further to insert that feature (he had used 100% of the available ROM space already).
is this guy a fucking wizard what the fuck how’d he do that
@@absoultethings4213He's a very clever guy.
@@palmberry5576 4k reminds of demoscenes which are dying out , people managing to create full 3d scenes and intros with in just 4kb size limitations etc using windows existing resources. Also kkrieger which is full 3d FPS game demo under 100kb! Unlike today devs reslly tried to be efficient.
As a kid i never really understood how tiny amount of information 40-70kb of data was. As an adult i am simply baffled by how they were able to pull this off.
So many tricks used to reuse assets.
Also we have been spoiled today by storage space, its almost not even a factor anymore. So using MP4s and images is more common as theyre richer and easier to work with than raw data.
Modern devs could definitely learn a thing or two about compression
@@robuxyyyyyyyyyy4708mp3s and pngs are compressed
Honestly, 40-70 kb isn't that little data in the first place.
40 kb is 40,000 bytes. That's 320,000 binary flags.
The smallest common encoding for English characters is 1 byte per character, meaning 40,000 bytes is 40,000 characters.
English is typically about 6 characters per word inc. spaces and punctuation, so that's 6667 words, which is around 3 chapters of a novel.
That's not a ton of data, but it's also not nothing either.
In contrast, games these days are regularly like 100 gb. 100 gb is enough to store around 300,000 novels worth of data. That's insane.
@@seigeengine The things that take the most space is sound and images, so yes, it is frankly quite a little data.
Even when compressed heavily, image data is the biggest easy. You are comparing it to words, which is a bad comparison.
They don't really have to though.
An image, without compression, can have as little as 1 bit per pixel.
With compression, I have images that are large even on current displays that are only a couple kb in size.
That's before you get into things like tiles, which effectively reduce the resolution of the display.
Sound is more outside the scope of my knowledge, but it's similar.
Strongly disagree. Text is the best way to discuss data size, as it's the most intuitive way of conceiving of stored data to an average person.
@@SioxerNikita
Game developers back then utilized a lot of techniques to reuse data that took up a lot of space several times. Graphical data uses indexed colors with palettes usually not having counts in the double digits, audio was usually very simple, and often made using audio samples that could be reused easily or sometimes made procedurally. An interesting example of asset reuse is classic DOOM's textures. While the classic doom engine already uses paletted textures for everything, it also has a system for combining multiple textures together to make a new one.
fun fact, only the first image of assembly is MOS 6502, the other one is intel x86. Also, in the 6502 one, the CLC line is superfluous since the sum is always $66 and won't set the carry flag and the code doesn't even check for it anyways.
3:12 Congratulations,that is a CIC Lock-up Chip
@Fernan Schouffoer anyway no way he could confuse it with 2KB of RAM...
@@araigumakiruno It's not exactly obvious to those not in the know, isn't it?
I want to note that the context of the release of Super Mario Bros. in Japan is pretty important and notes how the game was crammed in a tiny cartridge
in 1983 Nintendo released the Family Computer or Famicom fot short and for the first 2 years of the consoles life you really only saw very simple arcade like games for several reasons, one of those being hardware limitations and Super Mario Bros. on the Famicom absolutely pushes the limit on what you can do with just the stock hardware
heck that's partially the mindset the development team had when creating Super Mario Bros.
a little later after Super Mario Bros. released in Japan Nintendo would launch the Disk System add-on for the Famicom which at the time was more capable of storing a lot more data than cartridges
but advancements in technology soon after made the Disk System obsolete couple that with piracy being a problem and the disks themselves being at risk of not working you can see why an NES release was scrapped
Nintendo and other companies would create new mapper chips for future cartridge games which literally added in hardware inside of the cartridge that the system can use
this video doesn't really go into this context and as a result I don't think it properly explains why they even had to do all of this
Micromages
*Allow me to introduce myself.*
03:12 No, this is not RAM. It's Nintendo's lockout chip, an anti-competitive measure to prevent competitors from making games for Nintendo's console. There's a counterpart chip inside the console that talks to this chip and performs a handshake during reset. If the keys don't match, it sends the CPU a permanent reset signal.
03:33 No. It's a tile map. The tile set (or the character set) is what's held in the cartridge ROM and contains the definition of each tile that can be used. The tile map is the way the console organizes the image on the screen, dividing it into tiles (characters). Then it can store just the numerical index of the tile that should be displayed at a particular place of the grid on the screen. The tile map stores those indexes, it maps the tiles onto the screen.
03:36 Wrong again. Tile sets are collections of _tiles_ , not _pixels_ . Each _tile_ is a collection of pixels.
04:00 Nope. Each TILE had that limitation, not a TILE SET. The tile set doesn't care about colors. Each tile made of pixels just stores the indexes of one of four colors from the palette, but it doesn't specify what particular colors are they. The information about those colors are stored in the palette, and there's a couple of different palettes the PPU could choose from when rendering the tile map. The number of the palette has been stored for every tile in the tile map, so each 8×8 box on the screen could use only those 4 colors from one particular palette, but another 8×8 box nearby might have used a different palette of 4 different colors. So overall, there might have been more than 4 colors on the entire screen, but not within a single tile.
05:12 Yeah, figures… :q So WHY DO YOU MAKE A VIDEO ABOUT IT IN THE FIRST PLACE?! :P
Next time you decide to "explain" anything to your viewers, make sure that you understand it yourself well enough. Otherwise, all you do is just spread misinformation and make fools of your viewers and yourself.
And if anyone wants to know how graphics worked on NES consoles, there are much better videos out there, like "How old-school graphics worked" (2 parts) by The 8-Bit Guy, "NES Graphics Explained" by NesHacker, or the series of videos on Retro Game Mechanics Explained. I recommend you to watch _that_ instead. You'll learn much more, and more correctly. This is probably where the author of this video learned about all of this (and understood less than half of it). I even recognize some of the pictures. E.g. the one about the sound channels is directly copied from The 8-Bit Guy's video titled "How Oldschool Sound/Music worked". Plagiarism is not cool :q You could at least draw your own picture.
The guy who made this clearly is more interested in engaging editing than making a worthwhile video
The guy who made this clearly is more interested in engaging editing than making a worthwhile video
he should have just said "tile" instead of tileset
5:41 "Y'know those debuggers to know exactly what problems you have so you can easily fix them?" No. No I do not.
Happened to notice that the portion of the video explaining the NES Soundware was directly ripped from "8 bit guy"
I knew it seemed familiar!
@@deemster4249 - Yeah, he just dubbed over the dialogue parts. You can hear it when the music plays and his recording microphone fuzz cuts out.
I saw the video it came from again about a month ago, so I was able to remember it.
This makes me realize how far technology has gone
Very familiar for those of us who started years earlier on the Atari 800 or similar 8-bit system. There was roughly a four year gap between when the Atari 8-bit computer (and 5200 console) and Famicom chip sets were engineered. This meant Nintendo's engineers had a significantly larger transistor budget, though the amount was a rounding error by today's standards. This allowed for greater sprite counts and displayed color depth and more complex audio but one can also see some difference in the basic choices the two groups made. Atari placed an emphasis on color range, supporting a palette of 128 colors in the original CTIA chip and 256 in the later GTIA upgrade. (You could directly replace the socketed chip to upgrade.) This allowed for some tricks the NES cannot reproduce. Also, the Atari didn't have sprites in the traditional sense but rather four pairs of what were called player-missiles. A player was an 8 pixel wide band that ran the entire height of the screen. These were mono colored, so the pixels in the band were either visible or transparent, allowing for one player to appear to be several objects in different vertical locations. The missile was a 2 [pixel wide version of that vertical band. The missiles were actually a fifth player divided up to provide and adjunct missile to each player. This was a compromise from the transistor count that would have been needed to have a full 8 player objects.
The later Amiga systems, which had some of the same engineers involved, had similar full screen height objects but also had for the time powerful hardware functionality that allowed moving software defined objects around well enough to do things well beyond what sprites provided. Up until then there was a division of having lots of hardware support for character or tile mapped displays or doing everything in software on bit mapped displays like the Apple ][. Combing the two changed a lot of the rules for developers, which is why the Amiga was the platform of choice for for young developers for many years. Later, when those developers were married with families to support, the platform of choice was the one that came with a steady paycheck.
1 megabyte back then feel like 10 terrabyte 🗿
I recently discovered your animation channel...and then found out you left it...but guess what? I love this new type of content more than animation! So I subscribed!
What is the name of his animation channel?
@@WhySoPrettyJinsoul. ua-cam.com/users/Kabloosh
@@nivedh2894 thanks
@@WhySoPrettyJinsoul. np
1:27
My man actually dissed my child. As a crying child once said:
"STO-OP!!! HE'S ALREADY DEAD!"
*slaps down cardboard NES
"sorry, I don't have the real thing"
You, sir, have earned a sub.
1:23 there's a Pipe bomb in your mailbox
Now a days a picture a single frame is a thousand times bigger than a whole game
1:28 Trust me, it takes a lot more time to master tf2 than you might think
7:46 That’s the DankPods song that makes me remember him every time I hear it.
Same omg
Bring forth the audio judge, the huh duh six hundgeos by ol' mate senny
*Auxiliary mode*
3:17 that is the NES lockout chip, anti-piracy measure that worked pretty well, until it didn't
A weird 4-bit microcontroller to be precise.
Crazy that there were huge ass MACHINES just for a few kb of a game
The chip you're not sure about is actually the CIC, that was used to verify the card was authorized to run on the console.
Meaning u can't play a Japanese version of the game on a united states nes console?
I just realized, what is funny is that we're likely to return to cartridges again. The storage density of an SD Card is tremendous compared to Blu Ray, you can easily get 128GB for just $10.
Btw that third small chip is the CIC. It provided copy protection for the console. Modern vintage gamer has done at least one video covering it. There's a matching chip inside the NES. They use some lock and key type thing. Look it up, it's pretty fascinating.
I genuinely love this new channel from Joseph!
*:D*
@@o.rbi.t ?
4:51 recent 3d games will use 10 different 3d models with hundreds of textures to have sprites (npc/objects) have different colors, this is one reason why today's games are soooo huge. Hope they learn to use tricks like the early days.
To answer your question, "how did they compress mario into one cartridge with huge scrolling levels," they stored level data as a collection of vertical 32px wide strips (the chunk that they load in on the fly for scrolling) and they reuse them A LOT. Thats how
Nice video. Just a note. 6:05, this is not a standard scheme. E.g. Metroid uses two 16 kb banks, one fixed, and the other switchable, in order to access the rest chuncks of the ROM. This is because Metroid is a 128 kb ROM, and it doesn't fit in 32 kb. But Super Mario Bros can access the whole code and data without any switching.
what amazes me more is that mario bros 3 is under 400kb and managed to run on the nes
Man you have a good style of humor
Wanna know a sad part
In the philliphines most kids didnt even know what a console was which was sad and now 2020
I only see kids having "bootleg" consoles
And the dumb part is they didnt knoe their consolr is fakr
Idk about that i did own a Fake Famicom as a kid but Theres 2 Family here in our neighborhood including ours that has a PS4 and im not even from the City.
What's sad?
I guess because they're expensive.
I really want a switch so bad
i live in the phillipines and was born there, and now ive had a switch for 2 years, and when i was like 2 years old, my 2 brothers and my 1 sister got gameboy advance sp's and my 2 brothers's game was Pokemon Emerald, and my sisters game was Pokemon Ruby. we also bought the sims the gameboy game, and super mario advance. my parents had the nes. so we never had a bootleg console. it was always nintendo.
Having a 12 year old say, "remember cartridges?" Is like Benjamin Button saying "hello, fellow kids!"
This really feels like you understand nothing of what you are talking about
Exactly. This entire video feels like it was made by ChatGPT. By that I mean it's nothing more than a surface-level analysis.
This video just skims over a couple of tactics used to save a bit of data. There is very little explained about how exactly an entire 8 world video game was crammed into 40 kb. He spends more time building up to the video than actually explaining how the ENTIRE game was crammed into 40 kb.
Sure, meta tiles and assembly are neat. But he didn't even fucking explain how all of that data was crammed into 40 kb. The point about "tracker music" was complete fucking bogus too. Trackers weren't even a thing back then. Did he get all of his information from a dream he had or some shit? This video was a complete and utter waste of my time.
I think it's alright
Why does this man have an NES controller but not an actual NES
It's a usb controller
The video was extremely educational, while also being simple enough for everyone to understand. Also, the edits were amazing, it'd been a while since I'd seen someone put so much work into that. Great job dude!
Gee, thanks! :)
@@LieutenantVague Nope
The bushes in Super Mario Bros are just the clouds tinted green
NOOOO
The sound part was referenced from The 8-bit guy's video, previously known as the ibook guy, the visuals from his video
I lost my freaking mind when you pointed out that a screenshot of the game took more file space than the game itself
Back then developers had to figure out how to fit all the data with such small storage, but now developers have to figure out how to afford to use all the hardware since the files are huge.
Nice! Loving the new channel. I can definitely sence the Scott The Woz vibe, if that's what you're going for.
KeiserAnimates hi
@KeiserAnimates hi!
I think that’s a bit insulting. Scott is certainly awesome, and Joseph is cool in his own way. I don’t think he was ever trying to copy Scott. Very different styles!
@@Brinta3 didn't mean to give off that I thought he was copying. More along the lines of inspired or influenced in some way. Rewatching it now though, the differences are clearer to me.
Nice video! You can actually access all 32KB of data, it's the bigger games where the "bank switching" comes in and you have to move chunks of data around. Also, there are emulators with wonderful step-through debuggers like Mesen. Glad to see stuff like this though =)
Thanks for clarifying this. That was my hunch too regarding the 32kB code ROM in non-mapper carts.
It feel like this video is gonna have millions of views in like 5 years, I guess...
2:28 My Favorite but most accurate part!
2:33 The best censor i ever heard my life :D
3:13 that is the lockout chip (copy protection)
it is also amazing that if you just want to create a text file addressing all the tiles in the game, you'll still wouldnt be able to fit it in a 40kb rom. They needed to split each stage into numerous pages with basic stats each, so you replicate those pages with tweaks for extra blocks, enemies, etc.
"NES game developers were [...] the early pioneers of game development"
Er...not really, no. Videogames existed long before the NES did. Not even console stuff, but computer games too.
Early is relative. 3rd gen console vs current 9th gen
They certainly set the standard for what games would be for years to come. Previously, games were just electronic toys to distract you for an afternoon. Consoles like the NES really expanded the possibilities and made games more of a pastime or a hobby and not just a toy.
Short answer is reusing assets, midframe memory swaps and reducing and reusing the lines of code to the minimum to still accomplish what they needed to do. It really is impressive what they were able to do back then with so little to work with.
this doesn't really explain anything about how the game fits into 40kb... it was more of a showcase of NES hardware.
the game does many optimisations like reusing graphics and audio, as well as writing very versatile code to handle a lot of things through the same code.
SMB1 also saves a lot of resources by saving levels in pages, with ceiling and floor heights, as well as objects that tell the level loader to place tiles in the background layer (another example of reusing the objects system to not just be entities!). many other games simply stored tilemaps, which were huge.
enemies also shared the same code, the game just checking what the type number is for doing enemy-specific things like moving faster and changing the sprite to be a shell when jumped on, or changing to a flattened goomba sprite when jumped on.
powerups, instead of being all separate objects (requiring more code to be stored), simply were just one singular object, where the game would change the appearance of the powerup sprite depending on mario's current powerup status (and mario's behaviour depending on that status). interacting with the powerup sprite would just cause mario's powerup status to increase by 1.
the game also reused certain levels (such as 1-3 and 5-3 being the same), just using different enemies.
Thank you. Half of the information in this video was blatantly false. You have clearly done much more research than this drooling knuckledragging zoomer.
I learned much more from your comment than this drivel that calls itself an "educational video".
This channel is really underrated
It’s kind of like getting a table from ikea. To save space, the table comes disassembled with instructions to put it together.
Did i watch it? Yes
Did i understand anything? No
Am i still gonna rewatch this 10 more times? Yes
While a really good quality production, sadly it was full of miss-leading information and even mistakes.
I highly recommend you have someone knowledgeable in the details review your completed video next time, so you can fix bad info before a final version. This way they can make sure you understood the important details right and simplified correctly.
I believe you, but can you provide a few examples?
@@BlueRS123 For starters, kB not KB. Capitol ‘K’ is Kelvin while lowercase ‘k’ is Kilo.
Here are a few examples of incorrect information:
* Atari 2600’s largest game was 32kB, not 8kB.
* CDs are not “that” sensitive. It employed Cross-Interleaved Reed-Solomon Forward Error Correction such that you’d need thick, long scratches or a lot of rather dirty fingerprints to stop it working.
* There where 4 background palettes and 4 sprite palettes, not 4 total. 25 simultaneous colours.
* The “black” is actually a shared common (any) colour for the background palettes, but worked as 1-bit transparency on sprite palettes.
The big reason why the games were so small back then was because of the architecture. There was very little overhead and was very little waste. Unity (popular modern game engine), by comparison, is very bloated because it needs to cater for so much.
Also that mystery chip is the 10NES lockout chip.
@@CoolJosh3k that CD part was obv a joke
@@CoolJosh3k Not sure who thinks KB means "Kelvin B" or something like that
@@NikodAnimations My point isn’t about it being confusing to anyone, but rather the the standard. Many people and organisations, such as Google, also write KB instead of kB. It is however not strictly correct.
3:11 That chip is the "Lockout chip". It communicates with another chip on the NES' circuit board, and if it doesn't return a specific input, it forces the console to infinitely reset. This was an early attempt at DRM, although the Lockout chip can easily be defeated by snipping the reset pin on the NES' chip so it is unable to send the reset signal.
7:18 No. even though we do that today, back then, there were no trackers! Everyone just coded the music in assembly.
I think about this a lot whenever i go to update my apps and something like youtube has a 30MB update that doesnt actually change anything
Video: 40
Thumbnail: 41
I have been tricked, backstabbed and quite possibly bamboozled
Trckstabbed
As a Gameboy Homebrewer I love this video.
3:10 the smaller chip is a piracy lockout chip which talks to a similar chip in the console to block unofficial games.
2:24 if you throw a Nokia 3310 on the wall, the entire house would shatter
Just looking at the Yandere code made my eyes bleed. Should have just used enums instead of strings, with the Flags attribute for stuff like what is witnessed.
@Commodore X If I understand correctly, this is why I suggested an enum. It would store the thing witnessed as a single number while giving a name to each value so the programmer doesn't have to remember what each value represents. You could check if a student witnessed a murder with something like:
if (someRandomStudent.Witneseed == WitnessedAction.Murder)
1 - It's easier to use than strings since most IDEs support suggestion/auto-completion of enum types
2 - The memory allocated to the enum value is no more than the enum's underlying type. YandereDev might even be able to define the enum as char, only using 1 byte per value
You may have also noticed a student can have witnessed multiple things. In YandereDev's string-based approach, this is done by addind the word "and" between the names of witnessed actions.
An enum value can also contain multiple values with a binary approach. By assigning each enum value to a power of 2, each value can be represented as a single bit being set. You can then set multiple bits to represent multiple enum values.
To write multple values, assuming the enum is defined proprely, you can do something like
someRandomStudent.Witnessed = WitnessedAction.Murder | WitnessedAction.CarryingIllegalItem;
or
someRandomStudent.Witnessed |= WitnessedAcion.Murder; if you want to add a value without affecting the rest
To read individual values, you can add the Flags attribute to the enum type, allowing you to use the HasFlag method on a given value.
When compiled, all enum values are replaced with the equivalent numerical value, so it would be the same as yourr suggestion regardless. The reason I suggest an enum instead is to not have to remember the meaning of each value.
Ok so to be clear, that code we see in the vid and that has been going around the net was generated by a decompiler and is not the actual source code. Switch statements are translated into if... else if... else statements on the byte code level most of the time (there are also some special cases not worth the time going into), so when the decompiler reads that byte code, he doesn't see the original switch statement. You can also tell that it was decompiled for the massive usage of the "this" keyword, which is typical of code written by a program. You'll see the same kind of shit in designer source files if you use a .Net ide for example.
Also, it shows that youtuber who did this vid knows nothing about programming - both retro and modern programming.
@@doigt6590 decompilers don’t change the basic implementation. If it decodes as string comparisons it was string comparisons. If it used anything better (and anything would have been better) it would decompile accordingly. Best case it was comparing against string constants but that is still horribly inefficient code. You can’t decompile lipstick on a pig 🐷
I never said that decompilers change the basic implementation, that's in your head...
You can fit the entire N64 catalogue on a Switch cartridge...
6:57 Wait isn't that from the 8-Bit Guy
edit: nevermind it is I wasn't looking when he displayed the message on screen
It is
You can get a nonfunctional Lego NES for twice the price of the actual console.
What a time to be alive.
2:23 And that the Nokia 3310 vs IPad Pro
I wish modern game devs optimized their game's file size
1:26 you will now get smited by the all might gaben, god of steam, bringer of unusuals and CS:GO skins and the Half-god (3) himself.
Mhm
I mean, why compare SMB to TF2 or CSGO? One's a singleplayer kinda game, and the other are multiplayer FPS games
@@A_Random_Person324 Half life easily has a better story than BOTW, yet it was made 10+ years before BOTW, but he didn’t mention that game.
@@A_Random_Person324 he compared what the games have to offer, botw with only 14 GB gives you a massive map, hundreds of side quest, and thousands of things you can do during the game before fighting Ganon, Tf2 on the other hand has a really entertaining concept, but I feel like Valve could have made the game by saving AT LEAST 7 GB.
6:29 as a game developer, this isn't a mess rather it is organized. also as long as it works we don't care how it looks. well we do, but only to the point we can understand it.
Okay, so I have 2 POVs: small JS dev and Luau dev.
Since your youtube username is "Nooby", I'm guessing you're a Luau dev only.
So JS (and some other programming languages) have what's called a switch statement.
Luau does not have this.
Switch statements in JS and other languages are much faster than ifelse. Instead of the script having to constantly check "Is this equal to this? If not, is it equal to this?" it can just go "Okay, let's just see if only this argument checks out and if not run default." And in the long run, this is much faster than checking if every statement is true.
Since you're a luau dev, think of it like this:
local input = {["Hello world!"] = function() print("Hello world!") end, ["Hello2"] = function() print("Helloworld2") end}
local meta = {
__index = function(self,input)
return function()
-- default function
end
end
}
setmetatable(input,meta)
local hello="Hello world!"
input[hello]()
A little more data?
Going from 4 kb to 40 kb is HUGE.
Amazing video. I’m a child of the 80’s and NES remains the only system I have in my living room to this day. Also, I am a visual effects compositing artist by trade, and technical limitations and time are always present no matter what the budget of the project is. Doing my job as a comp artist, you constantly have to problem solve to get the results the client is looking for, without crashing the workstation as well as the final render. So I can fully appreciate and respect the NES dev teams who were up against crazy limitations, and still produced amazing games. It’s all about thinking outside of the box to find those creative tricks to get the job done.
Another amazing storage-related thing was how gamefreak managed to fit the entirety of johto _and_ kanto on a single gameboy (color) cartridge. This was thanks to the one and only satoru iwata. May he rest in peace
I love this kind of content!
i actually have very severe time limitations with a modern computer: i want to program a good chess engine (>2k), and i managed to code all the pieces rules in a very optimal way (about 10ns on average). Calculating an attack map to determine if castling is legal (or if you're in check, but that doesn't have to be implemented, because i can use pseudo-legal moves anyway) is already suboptimal (69.04ns/move), and move generation (seeing where each individual piece can go) is beyond slow (109.94ns for about 10 pieces on board). And considering that these calculations will have to be performed millions of times, i would really like to target something along the lines of 5ns/piece for my pseudo-legal move generation function.
I'm only recently realising how quickly you need to move bits in order to produce pixels fast enough for the measly resolution of the NES. You need to output about 6 million pixels per second to keep up with a 240p 60Hz NTSC signal at that horizontal resolution. Designing the NES PPU to shift that amount of data that fast was a neat trick given the constraints at the time, and the limitation on the number of sprites per line really falls out of that naturally. Each line of pixels was being stitched together on the fly depending on which sprites were on that line.
0:39 BOOTLEG NES
The pace is nice, and the tone entertaining.
But you have to double check your hardware spec.
I understand that some stuff must be simplified to explain, but some things are just plain wrong in this video.
Also, sorry, but the game pioneers were probably the Atari2600 guys.
They had a much more restricted hardware and hacked a lot of it.
But I understand what you meant, the NES was the first wildly spread console with sufficient performances to be considered as a versatile gaming platform.
"Than what tf2 offers" ..impossible, perhaps your archives are incomplete
Tf2 has like 100 maps, 1000 hats, 200 weapons, mvm and halloween.
And not to mention, community servers. Literally infinite possibilities, with sub games
I’ve spent 1,300+ hours in tf2, I could 100% BOTW in ~40 hours. I still haven’t gotten every achievement in TF2, and hell, I haven’t gotten every weapon
If you only compare the base relases of each game, Tf2-07 - Botw no Dlc his statement makes slightly more sense.
But trying to quantify the return on time/ unique game assets for either game is moot when: they're different genres that came out in different eras with one being a single player titan with a prestigious pedigree and the other a hyper focused role based multiplayer experience.
Idk bout csgo
@@strange9922 you 100% BOTW in 40 hrs? I haven't even beaten ganon in 80. You're very focused when it comes to gaming I guess
I love downloading NES roms lmao. Takes like three seconds on a crappy Wi-Fi connection on a low powered pc and they run perfectly on anything lol.
3:12 That is actually the lock out, ( cic ) chip used by Nintendo to make it where only games officially licensed by them for the system would play, although some companies still manage to find ways around it at the time.
That one chip you couldnt tell in the cartridge was the lockout chip. it was used to prevent unlicensed games as they had problems with that in japan.
FAMICOM MUTICARTS COMING
I thought this was gonna be more about compression
No compression in this game, just lean, efficient code.
Nice video 💯
8:08
me: all of the above
I once programmed an entire game in less 496 bytes. It was a very simple lock and key puzzle game. It was like zelda1