|
  time! Yes, it's an effort post in a no-effort thread!I've worked with the NES quite a bit and am familiar with the restrictions. First thing to note: Shovel Knight does not look remotely like an NES game. Yes, some of the colors are from the same palette, but it breaks far too many restrictions to even come close to looking like an NES game. It's a personal pet peeve of mine so I get unreasonably annoyed when people try to claim games have a certain look when they don't, so bear in mind. The NES look is more than just color palette, and it has to do with the hardware restrictions. The NES graphics system is basically divided into two components: tiles and sprites. Tiles are 8x8 four-color paletted images, where one color is always the same between all palettes (usually black, but you can change it and some games did). You can have up to four background palettes at the same time. The NES graphics unit has space for two 32x30 tiled background screens (two 256x240 screens), and you can smoothly scroll either horizontally or vertically between the two. They also wrap. This is what makes smooth scrolling possible on the NES: you set up the first bit on one screen, then continue building onto the right until you hit the rightmost edge of that one, then you start over on the left of the first screen and the PPU will scroll and wrap appropriately. Tiles are specified as indexes into the pattern table. There's not a lot of space in the pattern table, so the number of different tiles you can have on screen is limited. But there is an additional complication: although there are 32x30 pattern references on each screen, there are only 16x15 attributes. Think of it as grid of 16x16 pixel, or 2x2 tile, squares across the screen. Attributes are what controls what palette that particular square uses. This means that each 16x16 square on the screen has to share the same palette, so you will never see more than 4 background colors in one 16x16 space. Now, pixel artists back then were very creative and did all sorts of trickery to hide this fact from players, and came up with some amazing looking scenes despite these restrictions. You can see it if you know what you're looking for, though. There is no such thing as layers in an NES game. Parallax scrolling (as done in Shovel Knight) is not possible without clever trickery, and even then it's very limited.  Here's a screenshot from TMNT! There are four palettes: one greenish with white highlights for ceilings and floors, an orange-and-red one for the wall, a blue one for the water, and a white/red/blue one for the HUD below there. Note how each 16x16 square only uses a single palette. Leonardo there is something else. He's a sprite - several sprites, actually. Sprites are 8x8 images (usually - you can do 8x16 sprites as well), just like tiles, but they are not constrained to a grid and can be independently positioned anywhere on the screen (almost). 8x8 is quite small, so you'd pretty much always put several together to form a larger character. You have four additional palettes for sprites which are independent of the background palettes. Additionally, index 0 of a sprite palette is always the transparent color, so in practice what you have is three colors + transparency. Note how Leonardo uses exactly that: A light green, a darker green for contours, and blue for his bandanas. You can have up to 64 sprites on screen at once, which sounds like a lot until you realize you may need 4-16 sprites for a moderately sized character. Additionally, you can only have up to 8 sprites on a single horizontal line at a time! The PPU will simply not render any more than that on a single horizontal line. This is why NES games flicker when there's a lot going on - too many 8x8 sprites horizontally level with each other, and some of them are going to not render for one frame or another. There are more quirky details to talk about, but this is getting long and you probably don't care (but I'll elaborate if you want). The upshot of it all is that what I, at least, think of as the "NES look" is a direct result of these restrictions and all the clever things artist and programmers did within those restrictions. They really did some amazing things and made things that are beautiful precisely because they couldn't just do whatever. Relaxing the restrictions too much - as was done in Shovel Knight - robs the product of that special look and makes it look... well, I'm not saying it's bad, but it's also not like an NES game. It really makes you appreciate the lengths they went to in order to make gorgeous games like Vice Project Doom or Batman. 
Hyper Crab Tank fucked around with this message at 14:29 on Nov 21, 2015 |
#
¿
Nov 21, 2015 12:45
|
|
|
|
| # ¿ May 15, 2024 06:40 |
|
|
anilEhilated posted:I always felt the biggest difference between "retro" games and old games was in size. Shovel Knight is about 200 megs which is tiny by today's standard, but weren't NES cartridges something like 1024 kb? Most NES games were much smaller. Dragon Quest IV is 1024 kb (a.k.a. 1 mb), and there are a few bigger ones (like Kirby's Adventure), but most were in the range of 128-256 kb. Anyway, that was more by necessity than anything else, and it doesn't even have the grace of being a necessity that has interesting implications (like the graphics stuff). Unless you're the kind who's really awed by the marvels of compression, bank switching and other engineering tricks, which don't get me wrong, you might be, but I bet most people aren't.
|
|
#
¿
Nov 21, 2015 12:56
|
|
|
Well, just to be super clear, I'm not saying Shovel Knight looks bad. I'm just saying it looks nothing like an NES game, and that disappoints me a little because I so love (can you tell?) the actual NES look.TooMuchAbstraction posted:One neat thing about Shovel Knight though is that the music actually would be playable on an NES -- that is, it uses the same sound channels that the NES had available to it. Oh yes, the NES sound chip, despite its simplicity (2x square wave channel, 1x triangle wave channel, 1x noise channel, 1x DPCM channel) was capable of producing a surprising amount of really great-sounding music. Some cartridges (tragically only released in Japan) even extended the sound capabilities, such as Castlevania 3/Akumajou Densetsu. The music in the Japanese version has twice the number of sound channels available to it, and the music sounds really fantastic. Shame the one we got wasn't quite as full featured... sadly the VRC6 chip was not compatible with the western NES, so we got a trimmed-down version without those features.
|
|
#
¿
Nov 21, 2015 17:38
|
|
|
Can we just agree to disagree on that? I don't want this to turn into a weird thing. Shovel Knight is a good game, aight?
|
|
#
¿
Nov 21, 2015 19:13
|
|
|
Choco1980 posted:Question--You say that the backgrounds in that TMNT spot are all their own tiles arranged to look like one cohesive world while still following the 4-color rule, but what about the drain waterfall on the wall? Am I just vastly overestimating the size of a tile, or was some trickery used there? You mean this? I've highlighted the central 16x16 pixels with green there. As you can see, that whole spot uses the blue palette.  This is a good example of simpler kinds of trickery. They got up to some really sophisticated stuff later on in the console's lifecycle, such as by cutting it real close to the edges of things and duplicating colors across palettes, all the way to fake parallax backgrounds. EponymousMrYar posted:Betting it's a sprite. I remember weird artifacts popping up on those when I played the game an age ago. The falling water at least, it's about the same height as the turtles. It was indeed also common to use sprites for background elements. It's not the case here, though.
|
|
#
¿
Nov 21, 2015 23:05
|
|
|
Choco1980 posted:Did any other games feature multiple direction scrolling like SMB3 did with its extra processor chip? I want to say it popped up in one of the later Mega Man games... Sure. I'm not so sure about Mega Man - I think they all only scroll in one direction at a time - but a few others come to mind. Zen: Intergalactic Ninja, Street Fighter 2010, RC Pro AM, all three Wizards & Warriors games and Isolated Warrior off the top of my head. e: Oh, and the game that never was, Bio Force Ape.  vvv I especially adore La-Mulana for nailing the perfect MSX look, including most or even all of its restrictions. It's wonderfully nostalgic. Hyper Crab Tank fucked around with this message at 23:40 on Nov 21, 2015 |
|
#
¿
Nov 21, 2015 23:20
|
|
|
Bio Force Ape was an MMC3 game, same as Super Mario Bros. 3... as to how they managed to get it so fast-paced, I don't know, but I'm guessing it's because there's so little going on besides the main character jumping on things. Bio Force Ape has an amazing backstory, too; it was first mentioned in a magazine, I think Nintendo Power, back around 1990, but then SETA shut down production on the game and it disappeared. Until someone claimed to have a prototype of it and posted a bunch of (fake) screenshots. It was all revealed to be a prank in the end... until a few years later, when a real prototype copy surfaced, was auctioned off, and ROM dumped.
|
|
#
¿
Nov 22, 2015 00:42
|
|
|
Mega Man is really impressive that way. His face is the yellow-white-black palette, and the body is the black-blue-blue palette. This means they can just change the body palette whenever Mega Man equips a new weapon, and additionally, they can use that palette for whatever the projectile that weapon launches is. The yellow palette, meanwhile, is also used for Mega Man's normal bullets and his health bar. The weapon bar uses the body palette again. This leaves only two palettes (six colors) for enemies at the same time on any on screen, which seems like very little, doesn't it? Economizing with palettes and figuring out ways to reuse them cleverly was a big part of it. The later Mega Man games in particular have some of the best graphics on the NES, bar none.     Look at how organic those trees are, and how well they hide the 16x16 grid nature of the game. That dragon is particularly interesting. It is made mostly out of background tiles; there is no way to have a sprite that big, though some of the details are sprites. Yet it looks flowing and dynamic, and the edges between colors (and thus color palettes) are so seamless. How they did that is pretty amazing, actually. Hyper Crab Tank fucked around with this message at 11:18 on Nov 22, 2015 |
|
#
¿
Nov 22, 2015 10:30
|
|
|
They went pretty hog wild with title screens sometimes, since they could just devote all four palettes (plus sprites) to making it look kickass without having to worry about what it would look like in motion or sprite flickering or whatever. The title screen to Bad Dudes, for example, has a lot of stuff going on, although I myself have a weakness for the cleaner, more stylish ones like Ninja Gaiden 3.   But, yeah, the Shovel Knight people clearly knew what they were doing, ain't never said anything else. But I think the departures they chose to make were critical ones; scrolling backgrounds in particular stick out so much as to make the product profoundly non-NES. Whether you feel that is an improvement or not is up to you. I think the game came out well, though I clearly don't agree with some of the closing statements in that article. That article mentions another really cool game, though... Summer Carnival '92: Recca, which as you can tell from the date was developed very late in the NES's lifecycle. Here's a video of it in action; now, this game is extraordinary in the lengths they must've had to go to in order to make it look and run the way it does. It's hard to appreciate just why, but just the sheer number of sprites on screen and the speed at which everything happens should tell you a bit. It is also tough as balls and I've never gotten anywhere in it. Hyper Crab Tank fucked around with this message at 15:42 on Nov 22, 2015 |
|
#
¿
Nov 22, 2015 15:38
|
|
|
Choco1980 posted:Does this have extra chip power inside it? In a sense, all NES games do! Okay, so the NES itself basically consists of three units: the CPU, the PPU, and the APU. The CPU is your general purpose central processor unit (specifically, a Ricoh 2A03/2A07) and handles general stuff, game logic and so on. The PPU does all the graphics stuff I mentioned above, and translates it all into an NTSC or PAL signal. The APU does audio synthesis and mixing. Each has its own set of registers and RAM. The NES CPU can map up to 64 kilobytes of memory, but it only has 2 kb of actual RAM. Many memory addresses actually refer either to the same blocks of RAM, or to things that aren't RAM at all. For instance, communicating with the PPU is done by writing memory to a few specific memory addresses which are mapped onto an internal bus shared between the PPU and CPU. The PPU has its own address space and its own dedicated RAM, which is not directly accessible from the CPU, so instead you write specific values to these memory mapped registers in order to make the PPU do what you want. Other parts of the memory space are mapped to the game cartridge itself, which can contain not just program ROM, but RAM and even more sophisticated components. Furthermore, because the NES cannot address more than 64K, there is a bank switching mechanism that can map new areas of cartridge ROM or RAM onto the CPU's memory space. If all this is mumbo-jumbo to you, the upshot is this: NES cartridges are not just ROM chips with data on them. They actively interact with the main system architecture. The simplest and earliest cartridges used technology called NROM. Super Mario Bros. is an example of this. NROM cartridges are very simple, they have only program data (PRG-ROM) and some graphics data (CHR-ROM). PRG-ROM is addressable by the CPU and is where program code resides, CHR-ROM is addressable by the PPU (but not directly by the CPU) and contains tiles, sprites etc. With NROM, these are mapped at fixed places in the memory map and never change. They're basically just soldered straight in. This quickly proved inadequate for more complex games, so new chips called UxROM (actually two variants, UNROM and UOROM) were made and used for games like the original Mega Man, Castlevania and more. UxROM is capable of bank switching, and therefore supports bigger games. The next evolution from Nintendo's side was called MMC1. MMC1 was a chip setup that existed in various configurations collectively referred to as SxROM. Besides bank switching, MMC1 supported PRG-RAM in addition to PRG-ROM - in other words, it extended the amount of available work memory above the 2kb the NES had internally. Some SxROM boards also featured battery backup, allowing for persistent save games! Examples are Legend of Zelda, Final Fantasy, and many more. MMC1 was wildly popular and many games used it. MMC2 was an improvement that, to my knowledge, was only used in Punch-Out!!, and was soon superceded by MMC3, which was also extremely popular. Super Mario Bros. 3, Mega Man 3 and onward, and many more use this mapper. Other companies had their own proprietary mappers, too, like Konami's VRC series and Namco's Namco-163. Most used one of Nintendo's aforementioned mappers, though; it was cheaper and easier that way. The fact that NES games are not just code, by the way, makes the job for emulators more difficult since they don't just need the program ROM, but also need to know the details on all the other crap the cartridge was doing that the program code depended on. The prevalent ROM format for NES games, iNES, contains this information in the header, but the emulator needs to have specific support for the mapper a particular game uses. Recca uses MMC3, and is thus hardware-wise on the same level as Super Mario Bros. 3. Phew, that's a lot of text. Enough for now. There's way more could I tell though and I want to write a post about scrolling at some point. Maybe I should make a video about it..? Hyper Crab Tank fucked around with this message at 12:54 on Nov 24, 2015 |
|
#
¿
Nov 24, 2015 12:49
|
|
|
I figure the thing to do in spirit is to actually play a Japan-only Famicom game for the thread (yes I know I already have an LP going, screw it), so here we go, complete with shamefully foreign English and Japanese: I found trying to talk about the technical details while playing to be too hard, so here's the technical spiel in text form instead: Remember what I said about tiles? Well, the NES PPU has space for two screen-sized blocks of tile references, called nametables. The cart can configure the system either lay these out horizontally or vertically; so you have your choice of a "left/right" setup or a "top/bottom" setup. Either way, you can set the PPU to scroll within this space with pixel precision. Every scanline, the PPU fetches a scroll offset from memory and uses that to figure out what tiles to draw. Sprites are unaffected by this system entirely and are always positioned in screen space. There is another important thing going on: mirroring. Imagine a 2x2 grid of screen-sized blocks. Now imagine that you have set the system up in left/right mode; those two screens occupy the top left and top right blocks of the 2x2 grid. What's in the other two slots? The same screens! The same goes the other way around, if you configure the system that way. Scrolling works across this mirror boundary, so that if you scroll past the end of the screen it will appear to wrap around. This has important implications for scrolling. You see, as long as you're scrolling within the two screens that are available to you normally, you can scroll perfectly smoothly and wrap around when you reach the edge and everything will look fine the whole way around. This is how games that only scroll in a single direction work, like Super Mario Bros. Games that need to scroll in more than one direction can't do this for both axes. They have to choose one axis to be the "smooth" one, and the other was, well, the ugly one. What do I mean by that? Look at this screenshot from the video:  See those weird artifacts at the top of the screen? Those are caused by the fact that the top of the screen is the same memory as the bottom of the screen, since Getsu Fuuma Den is a horizontally scrolling game. Thus, the top and bottom of the screen share palettes, and there's nothing you can do about that other than try to hide it. The programmers on this game didn't try very hard. You can see the same artifact in games like Super Mario Bros. 3 and Little Nemo on the left and right sides of the screen, or games like Final Fantasy on the top and bottom.  Some games hide it better... for example, the top and bottom 8 pixels are typically not displayed on an NTSC television (the NES is 256x240, but the effective visible area is 256x224 due to overscan), so if you're smart with your palette management (again, unlike Konami with this game) you can hide artifacts on those edges pretty well. You'll also note that the leftmost 8 pixels in that screenshot are all black; that's a feature most games enabled that simply shuts off rendering for the leftmost 8 pixels to hide artifacts like this and allow sprites to slide smoothly in from off-screen. There is no such feature for the right side, though, so hiding artifacts on that side is much harder. Hyper Crab Tank fucked around with this message at 22:39 on Nov 26, 2015 |
|
#
¿
Nov 26, 2015 22:21
|
|
|
|
| # ¿ May 15, 2024 06:40 |
|
|
Hi, thread. I got too busy to post more NES videos, and I'm currently stuck without access to my recording equipment, but I wanted to write more general NES chat. So we're going to talk more about scrolling. The NES has support for horizontal screen splits (i.e. into a top and bottom half) via the same mechanism that does scrolling. This is used to display things like status bars and dialog windows, or doing things like big-rear end bosses made of tiles (like in Mega Man's Wily stages) while still keeping a "floor" part unmoving on the bottom of the screen. Basically, whenever the PPU has finished emitting a single scanline of video, it re-reads the scroll offset before continuing to the next line. This means that if you re-write a new scroll offset in the middle of PPU processing, you can display a different part of the nametable below the point where you did that, thus splitting the screen. One problem: your timing has to be clutch. There is no way to tell the PPU to split on a particular scanline; you have to wait for the right moment to write the new scroll offset, and the window for doing so is very small. Fortunately, the PPU is clocked at exactly 3 times faster than the CPU, so the ratio of CPU instructions to PPU cycles is entirely predictable. Furthermore, the PPU will signal the CPU when it's done rendering a single frame and has entered what's known as "vblank". Now, this sounds like you could just wait for vblank, then spin in place for a known number of cycles and splitting the screen. Technically, you can do that... but practically, you desperately need those CPU cycles to do actual game logic. Furthermore, vblank time is precious: there are certain kinds of communication with the PPU that you can only do during vblank, so you want to use the opportunity for that stuff. If you don't know exactly how many cycles you spent on that stuf, you can't accurately predict how long to wait to get the split in the right place.too Nintendo's engineers did work out a solution: the Sprite Zero Hit. The very first time the PPU renders the sprite in slot #0 (out of 64 total), it will set a particular flag that you can read. This comes with a few caveats - the sprite has to be opaque, for instance - but it does provide a consistent way to detect when the PPU is on the right scanline to do the split on. Every NROM, UxROM and MMC1 game that does split screen has to do it this way. In Super Mario Bros, for instance, there is a sprite hidden behind the coin indicator in the hud. In Getsu Fuuma Den, it's behind your life bar. The flow comes down to something like this: 1. Wait for vblank 2. Do vblank-critical processing 3. Wait for sprite zero hit 4. Write new nametable offset to split the screen 5. Do as much game logic for this frame as you can 6. Goto 1 Now, time between 2 and 3 are wasted CPU cycles. You want to minimize that. As a result, most NROM, UxROM and MMC1 games have the screen split near the top of the screen, where they don't have to wait as long; look at Castlevania or Getsu Fuuma Den, for instance. The status bar being on top is not just an aesthetic choice, but a technical one - cool, huh? There are a few exceptions, like Gradius. That game basically starts game logic immediately after vblank and then tries to estimate how many more object updates it can do before it needs to wait for the sprite zero hit. One of MMC3's improvements was adding a programmable interrupt generator that could be used to generate an interrupt on the right scanline, rather than having to busy wait. This is how games like Super Mario Bros. 3 effortlessly did bottom of the screen splits. It was also easier and more convenient than the sprite zero hit method. Hyper Crab Tank fucked around with this message at 16:14 on Dec 21, 2015 |
|
#
¿
Dec 21, 2015 16:07
|
|