what does 8 bit graphics mean

Pointless rant.

I have issues with the phrase "8 bit graphics". like, how are we measuring bits?

the NES has 2 bits per pixel. vs SNES max 8 bits per pixel, or 4 bits per pixel standard. by that the NES is 1/4 as good. Technically, gameboy is 2bpp, and it clearly has worse graphics than NES.

Maybe color palette?

NES has 6 bits 0-3f of color to choose from...oh let's say 4 bits of palette 0-f, vs SNES has 15 bits of color on a (what is it ?) 7 bits of palette. that would mean SNES is far more than NES, but NES isn't really 8 bits of graphics...only 6 at most. Gameboy still just the 2 bits of color. That part makes a little sense.

But, some people might refer to Gameboy as 8 bit graphics, I would argue less.

If we're talking CPU bits (I know we are). That would mean Atari 2600 has 8 bit graphics. But it's not even in the same ballpark as NES. Only 40 pixels wide, and severe color limits. And look at TurboGrafx 16. If we're talking CPU bits, it only has 8, but claims to be 16 bit graphics.

Apparently, it's able to display more than 256 colors at once, but only 482...that can fit in 9 bits. If it's "colors at once" then technically NES can only do (without tricks) 25 colors at once, which fits in 5 bits.

NES is really 5 bit graphics.

Brief off-topic pedantry:

160 pixels. The playfield is limited to 40 pixels, but most games don't really quantize much to the playfield because 40 pixels is just too few.

A total of 32 15-color palettes, plus two shared colors (overscan and backdrop, I think?). But also a R3G3B3 DAC.

I was looking at some CGA technical information, and they refer to that as "4-bit graphics"...having only 16 possible colors.

Game Boy Color has eight 4-color background palettes and eight 3-color sprite palettes, and these are practical to rewrite during horizontal blanking. Each color is 15-bit, just like on Super NES.

Perhaps "8-bit game graphics" means 1-chip VDCs that were common at the same time as 8-bit CPUs in game consoles. Or it could mean graphics that don't require reading more than 8 bits per pixel across all of tilemap, background tile data, and sprite tile data. NES and Game Boy fetch patterns read about 4 bits per pixel; Master System reads about 8.

It means many things.

In some broad usage it just seems to mean "pixellated".

For some it means pixellated, maybe with some weak colour restrictions like SNES or Genesis.

For some it means that it fits the restrictions of a particular set of consoles, especially those that are themselves commonly referred to as "8-bit" (NES, Atari 2600, etc.)

It almost never means 8-bit colour depth, unless someone is specifically talking about an image format in a very technical context.

It's hard to talk about what the CGA was really capable of.

In early games, it almost always used artifact colors, because no-one would spring for a digital monitor. So the resolution was very approximately 16 color and very approximately 320 pixels wide. In practice, because NTSC, every 2 (nominal 320 source pixels) or 4 (nominal 640 source pixels) pixel wide group of pixels would specify its own color.

It later games, almost everyone was using EGA or VGA cards and monitors with legacy compatibility, and so CGA support was your choice of one of six ugly 4 color palettes, not all of which were widely used.

I think it means graphics matching those of the consoles that belonged in the 8-bit category in the console wars era (sega vs nintendo). Forget technical aspects, this is a cultural discussion. The consoles that were known as 8-bit were mainly the NES and the Sega Master System. So 8-bit graphics are graphics that look like (or at least how people remember them to be) the graphics in those console's games.

Yeah, “8-bit” in layman’s terms is a bit of a misnomer. People knew the NES was an 8-bit console, but not fully understanding what that meant, assumed it had to do with the graphics, since as the consumer that’s reall all you’re supposed to know about. It wasn’t until I actually learned what bits were and what color depth was, that I started to make the connection. Though before I got involved in NES development I just assumed the NES had a 256 color palette.

For me, 8-bit equates to 256 colors, like mode 13h on DOS. You can’t really change the way people talk, though. It just kinda is what it is.

It's a modern digital art style inspired by old pixel art, with loose restrictions.

This is basically how "normal people" define it knowingly or not, and since it's vague by definition it's pointless to try defining the term on the basis of old computer technical specs al gusto (I know this is Nesdev but still).

8-bit graphics, to me, refers to:

• An athesthetic of art or graphic that retains limitations of 8-bit games (in arcade or home console form; may also include certain home computers) of the past, usually 80s to early 90s
• Tend to have limited palettes, both in colour range/selection, as well as total on-screen colour count. I do not set explicit limits on this, but "in general" it tends to be a maximum of 4096 colours (range), with an on-screen limitation <= 64 (though as I said, there is some wiggle room)
• Isn't explicitly about CPU register size as much as it is about the graphical capabilities, but there are some exceptions (ex. Atari 2600 which has no actual PPU, IIRC (if I'm wrong, please correct me!))
• Primarily pixel-based (e.g. bitmap), with the exception of some things (ex. vector arcades, Vectrex)

From this list, I exclude:

• Demos or "system show-off" ROMs (example: blargg's palette test for NES) -- these are not games, and are intended to show off technical capabilities
• Some arcade ports -- see "blurry line" below
• Games which use text modes or general ANSI-like glyphs or layout/style

Valid examples: River Raid (Atari 2600), Dig Dug (Atari 7800), Ice Hockey (NES), Castlevania 3 (NES), Golvellius (SMS), Below the Root (Apple II), Impossible Mission (C64), Super Mario Land (GameBoy), Asteroids (arcade vector), Burger Time (arcade bitmap)

Invalid examples: Neutopia (PC Engine), Super Mario World (SNES), Sonic the Hedgehog (Genesis), Black Tiger (arcade bitmap), Street Fighter 2 (arcade bitmap), Dragon Wars (Apple IIGS), Descent (PC DOS), Gauntlet Legends (arcade 3D), Retro City Rampage (PC etc.)^[1], Shovel Knight (PC etc.), Cave Story (PC etc.), Undertale (PC etc.)^[2], Binding of Isaac (PC etc.), Dwarf Fortress (PC), Fez (PC etc.), Hyper Light Drifter (PC etc.)

I'm really looking forward to cheeky bastards coming along to:

• Give counterexamples to my classification system (read: I do not care -- OP asked for people's opinions, this is mine. If you disagree, awesome! If you agree, awesome!)
• Find "holes" in my classification system (again: do not care)
• Mention popular systems I'm not familiar with (esp. European systems) (read: I'm not ashamed that I lack familiarity with every computer/console in the history of mankind -- I don't have the time or interest to go trying out everything under the sun just to find out if it falls into this classification or not)
• Mention incredibly obscure systems (like weird bar/pub poker games, weird shit from Hong Kong, etc.)

There is a (pun intended) somewhat blurry line in this type of classification. For example, I consider these to be valid 8-bit graphical games which happen to be arcade ports: Contra (NES; fairly close to the arcade), Bionic Commando (NES; totally different than the arcade), Jackal (NES; fairly close to the arcade), Castlevania (essentially a port of Haunted Castle (arcade)), Space Harrier (SMS; similar to arcade), etc.. I've seen some arcade ports to the Apple II, for example, that I guess would fall under 8-bit graphics, but the ports are really terrible and almost shameful (read: nobody is mimicking this aesthetic; I could say the same of Ikari Warriors NES). It shouldn't come as a surprise that some of the more blurry allowances are all games made by companies who did both home console games *and* arcade games (Konami, Capcom, Sega, etc.).

Likewise, I will mention that it's very hard to remind myself of these limitations due to... well... age and timing. For example: Black Tiger is a System 16 arcade game (PPU is 320x224 with 15-bit colour, w/ 4096 to 6144 colours on-screen total; CPU is 68K; APU is Z80) that came out in 1987 -- so around the time I got my NES. As such, my brain really wants to classify it as "an 8-bit graphical game", even though nearly everything about the system is 16-bit. Sometimes I slip and will say "oh yeah, that's a totally 8-bit game", even though it isn't.

Shovel Knight, BTW, does not fall under the "blurry line" classification: it could be ported to the NES but with some definite decreases in visual quality/experience. Just because Kaufman composed it in Famitracker w/ VRC6 doesn't mean it fits into the 8-bit graphics category -- sorry.

^[1] -- This one is is a toughie for me given the extremes Brian went to in attempt to adhere to NES limitations, but in the end couldn't. It deserves special mention though.
^[2] -- There are some areas/parts that adhere to the classification, but overall the game does not (it's definitely one to be classified as 16-bit, e.g. SNES-like).

I definitely wouldn't claim that Stella is a PPU—it has just enough state to hold one scanline's worth of data—but it is a processor specifically designed to draw single scanlines in the video encoding for the region.

I'm curious why you exclude this? Or maybe why you felt a need to call it out?

For me, it's basically whatever you can do on a computer that happens to have an 8-bit data bus. TG16 is my grayzone, mostly based on feelings and associations.

It kind of makes me cringe a bit when someone is using "8 bit art" to describe anything they've done that happens to be low resolution, low colour depth, or something that simply looks a bit 80/90s gamey. But i guess the point is that the piece is meant to be "in the likeness of 8-bit aesthetics", which is still sort of true. It's just that not enough seem to actually care about the certain degree of likeness as long as it draws on associations of something that feels "retro". I'd prefer to just call it pixel art or computer revisionism, depending on (not all pixel art draws on nostalgia).

re: text/ascii art based games. Yeah, for me text based adventures etc are very much part of the 8-bit experience as (most?) systems of the time weren't really up for the task of action games the way SMS or NES were. I'd much rather play a text adventure than Q*bert on the VIC-20, and that was still a game-centered computer. So many games (most forgotten by now) relied on text based input/output; not just the adventures. Things like moon lander simulators, tactical troop deployment games, etc etc.

People who use the term "8-bit graphics" have no idea what 8 bit means. It's a pet peeve of mine, too. Like when Curse of the Moon was announced and you see all these people going "Why is this an 8-bit game? Why not a 16-bit game?". Why even use those terms when neither apply to what is probably a Unity game or something.

If you mean "looks like an NES game", just say that. Not that COTM really looks like an NES game of course.

Of all the modern games created with a pixelated retro look inspired by 8-bit consoles, Shovel Knight is one of the only ones I can think of (along with games like Mega Man 9, Issyos, and Oniken) that is actually consciously designed with NES limitations in mind.
Maybe not with the object of keeping within those limitations, but respecting it to the point where it thoroughly affects the entire visual (and gameplay) feel of the game. If Shovel Knight doesn't qualify into the common misnomer of "8-bit graphics" used with modern indie games, then no games do.

For contrast, see aforementioned Curse of the Moon which definitely calls back to a bunch of NES aesthetics (especially in terms of it color use), but breaks them whenever it feels like it just doesn't bother, which is almost constantly, and as a result doesn't really feel close to as much as an NES experience as Shovel Knight does.

I have more of a pet peeve with people who call every chip in a system a "processor" as if you can't just make circuitry that does it's specific job by itself and has to execute code. Nowadays pretty much every chip is a processor of some kind, but back in the 80s and 90s, that wasn't the case.

Using "processor" for sufficiently stateful ASICs was already common by the mid-1980s.

• Open up your ColecoVision, CreatiVision, or SG-1000 and find a Texas Instruments TMS9918 family picture generator, described in its datasheet as a Video Display Processor.
• Open up your Sega Master System or MSX2 and find a TI-derived Video Display Processor.
• Open up your Nintendo Entertainment System and find a TI-inspired Picture Processing Unit.

Maybe i'm reading you too literally, but i think it's still not the case. Operational amplifiers, logic gates, sensors, shift registers, memory and timers in the form of a separate ic package are everywhere, which naturally don't execute code.

I guess they were always called processors, even though they're not programmable. I still wonder how the general population think old systems work. Somebody should get a bunch of people together and ask them to each draw a diagram of how they think the system works, and it will be interesting to compare and contrast their designs with both the real thing, and each others diagrams. I wonder if there would be brothers who have been talking about technical stuff for years, suddenly realized they understood each other differently this entire time.

Spun off this thread: viewtopic.php?f=5&t=17428

All computing can be reduced to IPO, its a computer if it does IPO. Input Process Output. So any ASIC/CPLD/FPGA is a processor, as it will take some form of input, "process" it and then form an output. It does not even need a Clock let alone an Instruction set to be a processor. You can make a Processor board from discrete components as well. That is how computers were made before the invention of the IC, and then before and well still after the invention of the Microprocessor. My microwave oven proudly boasts that it is Microprocessor based, and that it is LSI ( yeah not even VLSI )

For me 8-bit graphics relies upon the rough resolutions and in turn amount of items one would see as possible for an 8 bit based computer to process. Its not just well is 320x240 16 colour and then its 8-bit, if it has screen high objects moving around and 25 other things moving then its not running on an 8-bit processor. The graphical limits refer more to "what it can update" rather than what it can "render". I.e Mayhem in Monsterland can be considered to be 16bit graphics, as the graphical fidelity makes you question "are you sure this is not an A600".
So for me, Shovel Night is not 8bit, Bloodmoon also not 8bit. Undertale is 8bit ( I think it even goes as far as having attribute clash ). Rock Bashers yeah 8bit. Aqua Kitty, Scott Pilgrim vs the World 32 bit.

8bit does not need to be 4:3 most home computers of the era are 16:10.

8bit bit pallets formats need a second param to specify the bit depth of the palette. So
8/12 if you have a 256 colour image on an Amiga
8/15 if you are mode 7 on a SNES
8/555 or 8/565 if you are on early PC adapter
8/24 is the "new standard 8 bit palette"

There is a GDC talk where a person talks about 8bit graphics and starts at EGA (/)_. which is 16bit graphics. the comment thread is "fun"

To me, "8-bit graphics" means 256 colours are possible; that is different to what a "8-bit computer" is, which (depending on the computer) may have "4-bit graphics" or whatever, since that is separate.

You mean like a Recca boss and the bullets flying around?


Could you cite video timestamps of parts of that C64 game that can't be done practically in, say, a Tiny Toon Adventures game on an NES or Master System? The technique of layering a hires outline sprite over a multicolor sprite is clever, but it's aesthetically roughly the same as the face layering in Mega Man series.


That depends on the pixel aspect ratio, and for most of these old platforms, it isn't square because it isn't 6.136 MHz, the rate at which 240p pixels are square. Namco arcade platforms, Nintendo 64, and Neo Geo come closest to that ideal rate. But Commodore 64 pixels are exactly 3/4 of an NTSC scanline wide (hires) or 3/2 (multicolor). This means a plane of 320x200 hires pixels or 160x200 multicolor pixels has the same width as 240 scanlines and thus a display aspect ratio of 6:5.

This shows 3 C64 sprites in a row (not counting Mayhem's overlay). That's 72 pixels of sprite on the same scanline. The NES and SMS (with unzoomed sprites) can only manage 64 sprite pixels on the same scanline. Am I correct?

Then again, look at Mayhem's statusbar. Half of it lives in the scrolling area of the screen and it's all made of sprites.

Actually, I would be genuinely interested to know if there are any NES/SMS games that manage something like Mayhem's title screen.

For very roughly the first five years, most VGA/SVGA cards/clones were runtime-selectable 4/666 or 8/666. The 565 depth was exclusively for the directcolor mode, without a palette involved.
For easier comparison, we should use the same convention for everything. PC Engine was 9/333; SMD was 6/3332. EGA was 4/222, SMS was 5/222; NES was 5/h4s0l2

The IBM 5151 monitor doesn't display a 4:3 picture. Things running on a Hercules card with it don't display at a PAR of 2:3 but instead closer to 3:4 (makes the dials circular in the last version of MS Flight Simulator to support Hercules). Personal measurement shows the active area of the glass is roughly 3:2, which is consistent. (EGA-on-5151 uses a slower dot clock; PAR there is closer to .85)

@Hojo_norem:

It's true that you can't have more than 8 sprites per scanline, but you can make them appear as having a wider coverage circumstantially with strategic placement.


You could perhaps approach something like the status bar on the scrolling area on the NES if:

a)your cartridge mapping allows for chr banking

b)you know for sure that the background on that row is going to be very limited in its content variance; maybe mostly monocoloured clouds, a dusky sky in a horizontal scroller.

c)make use of the 8 sprites you've got to cover for some of the content. If the information needs to be dynamically updated; better use the sprites mainly for that.

d1)You can then prerender each possible outcome for a limited selection of letters/symbols.

d2)optionally, and if you have chr-ram, upload them to chr-ram as needed so they don't take up too much active tile space.

I agree that you can make larger meta-sprites by spreading out the hard-sprites, but that still does not address the fact that the NES/SMS have a maximum of 64 hard-sprite pixels per line as opposed to the C64's 192 (unexpanded) pixels. I can't see this being worked around practically without flickering on the NES/SMS.


Mayhem (and probably many other C64 games) has complex moving GFX behind complex stationary GFX. Again, while I accept that these approaches are possible, I can't imagine that they are practical from a CPU time or hardware cost (probably more CPU than anything, especially on NTSC).

Thing is, if the C64 had the same sprite size limitations as the NES, Mayhem probably wouldn't have scrolling background behind the status bar. I'd just set a raster IRQ to go off just above it and reset X scroll to zero. Seeing that Mayhem uses a VSP type scroller, I may have to store the status area in a different video bank, but that's no real inconvenience.

The stock NES doesn't have a real programmable raster IRQ generator, but the SMS does. I don't know if it can change scroll positions outside of VBLANK though.

Anyways, all of this only addresses the status bar, of which the top half is actually made from X-expanded sprites, meaning there are still enough sprite pixels for Mayhem himself (with overly) and a couple of enemies. Speaking of sprite pixel counts, the NES has a total of 8192 hardware sprite pixels (8x16x64) per frame, not counting the 64 pixel per line limit. The C64 has 4032 (24x21x8), but these can easily multiplexed in software. I've heard some games manage 24 sprites... that's 12096 pixels! Here's some more of them being put to use.

Indeed, that's what you have to do. My favourite examples are bubble bobble in general and the long whip in castlevania. These games rely on sprite priority cycling for their design to function interactively at all.


I don't think CPU time or presence of IRQ:s have too much to do with it for the mentioned trick to work. If your game pak allows for chr-paging, you're ever only one write oer frame away from animating tiles, which opens up the possibility a broad selection of features. Mass scale tile animation, parallax distortion of the playfield without need for timers, or, to a very limited extent, sprite-like appearances. Cost is not much of a problem these days, either. It perfectly feasible to use 32kB:s of external RAM for graphics, which gives you more than plenty of room for these tricks. The drawback is that you have to design your stage accordingly, ie, ideally make sure that all the letters need access to the same page of scroll-triggered animation. Else you need to dynamically update the contents of the pages, which would take some cpu time. Still, some games do update the chr table continously. Solstice, for example. So it's certainly feasible for *some* game designs.

For clarity, i'm not arguing whether a straight port of Mayhem as-is would be possible (you have to accept drawbacks). I'm just interested in what can be done, homebrew-wise.

If you'd make a new game with a steady title over a scrolling background, you'd need sprites to cover all edges and 8 banks of chr-rom/ram to flip between; each with a scroll-compensated tileset for the logotype itself whereas the rest is identical across all banks. Some clever shadowing using the common background splash colour would make it easier, but it's not necessary. You don't see this in old commercial games because it was a waste of expensive storage, but these days..

The NES PPU not being able to multiplex its sprites is a bit of a drawback, but on the other hand, 64 is quite plenty to keep track of given the available time to update the OAM and the rest each frame. I feel the number of sprites (quite generous at the time) were a conscious design choice in regards to that the old way of doing it (multiplexing) wasn't on the table.

"Jupiter Scope 2: Operation Europa" in one of the Action 53 volumes has a title screen with a large title over a scrolling background, similar to Mayhem. It draws half the sprites in even frames and the other half in odd frames, creating a semitransparent effect. This is effective because the background is mostly dark, and it might not be quite as effective with high-contrast cartoon backgrounds like those of Mayhem.

Now if horizontal sprite coverage without flicker determines what is and isn't 16-bit, Game Boy is 16-bit. It has 50% coverage with just sprites, not even counting what can be done with a "window" background. (See Prehistorik Man.)

The Master System can change horizontal scroll in mid-draw. The NES can change both horizontal and vertical scroll in mid-draw.

So
Mayhem in Monsterland has a 320x208 full screen with unique colour per 8x8 char, with 24 enemy sprites + 4 for Mayhem + sprite status screen. It can scroll at 1 char per frame. It can also use colour splits for graphical effect.

https://youtu.be/ldo2ewLBt3Y?t=1912 Note the hires pixels in the circles, note that mayhem is behind some of them. Also note the birds outline is black, but the fish is dark blue, watch as it crosses the water line and switches to black.
https://youtu.be/ldo2ewLBt3Y?t=1865 note how mayhem is between things in front of the pink and (would be purplish mountains on a crt) but behind the green and the trees. Also note how the eyes on some trees follow while others don't. Then watch as he collects the invulnerability pickup and sparkles.
https://youtu.be/ldo2ewLBt3Y?t=1968 hi res parallax scrolling and more water splits
https://youtu.be/ldo2ewLBt3Y?t=2857 Waterfall + that enemy and then there are still more enemies on the same line with mayhem and then at the end he gets invun which he could go back and visit the monster again.
https://youtu.be/ldo2ewLBt3Y?t=571 also sprites

To do this game on a NES or SMS you would have to drop the enemies and mayhem to 16x16 and drop the world to 256x224 which is going to completely change the dynamics of the game. You would also have to rearrange the sprite and enemy placement to avoid flicker.
the graphics is not the only thing that makes you say "is that an Amiga?" because his animation - he has over 50 frames, and the smoothness of his movement and momentum are also quite high for an 8bit machine - they are not perfect, but very high for an 8 bit. There is also 3 tunes per level, and 3 track music with up to 2 sfx played.

For large scrolling "background layer" see
Hawkeye which has a fixed background https://youtu.be/ASoRpGQ6zfo?t=603
Fimbo's Quest which has a scrolling background https://youtu.be/SiCxXMquPKs?t=157

I looked at your Mayhem examples from a "how'm I gonna port this to NES?" point of view.


Both NES and Master System can do that effect using sprite-to-background priority.


In that particular scene, there appear to be two enemy palettes from the NES-ist point of view: one for submerged enemies and one for enemies above the water line.


Crouch for five seconds on a white block in Super Mario Bros. to see a similar effect.


Artistically yes, it's attention to detail, but technically not more difficult than the "some pumpkins are decoys" rule in Haunted: Halloween '85.


Or Sonic in 8-bit Sonic the Hedgehog.


It's a repeating 16x16 pixel pattern shifted as a second repeating background layer. I've seen that sort of effect in Battletoads, and I've implemented it before. In a CHR ROM game, you'd instead do like MetalStorm, use 4 BG + 2 OBJ switching, and devote one of the 4 background windows to parallax tiles for this effect.


Yes, that's a large enemy, and I concede it'd probably the first thing to start flickering.


You mean those spinning star-shaped coin things? Compare to the spinning round coin things in the background of Super Mario Bros. 3.


Or 16x24 (Balloon Fight size), which would maintain roughly the same size given the pixel aspect ratio difference. A sprite that's 24 C64 pixels wide is 24*3/4 = 18 square pixels wide, and a sprite that's 16 NES pixels wide is 16*8/7 = 18 square pixels wide.


There are about 50 frames in each player character in The Curse of Possum Hollow as well.


But not much color depth, nor much frame rate on the background.


That one's impressive. But again, not much frame rate on the background.

True, but in others you have more enemies below and above and bullets, which is probably going to cause you to palette out. ( there is only 4 right for sprites? that is probably going to be an issue in a lot of places )


My understanding of NES priority is that you are in front of, or behind everything but background. Not Between colours? so Mayhem being in front on pink and blue, but behind green, brown and yellow is beyond nes spec. sms too?

?? Megadrive sonic sure but SMS sonic is a single star that flashes around him badly https://youtu.be/Psami7Mm_aU?t=20


No it was the 2 large moles down the bottom, which are 48px wide each, + 24 for mayhem + 16 for smoke + 24 for sparkles on a single line. the large black monster is 70 pixels wide.

Yes the parallax is just a 16x16 that is rolled, however it is hires But again its not also just one individual piece its all of them combined.

NES and SMS differ on where the priority is set. NES sets it on each sprite; SMS sets it on each tilemap entry in the background. In either case, color 0 allows the sprite to show through, and the blue in the dots in that example is color 0.

There's also "impossible triangle" priority on NES, where sprite A with the behind bit appears in OAM before sprite B without the behind bit. This causes any pixel of A that overlaps an opaque background pixel to appear as the background pixel, covering pixels of B. SMB3 uses this to put mushrooms behind the blocks they sprout from. RHDE: Furniture Fight uses it to put the player's units behind tall furnis in a house. The Curse of Possum Hollow uses it to put Donny behind telephone poles.


OK, then the smoke from Thwaite. Being 8-bit doesn't rule out particles, particularly if they're drawn in alternate frames.


The moles would be 32 pixels wide based on the PAR difference. You'd get 16 for Mayhem, 32 for a single mole, and 16 left for smoke/sparkles that can cover 32 if drawn in alternate frames. On Game Boy Color (which has 8x8 and 8x16 sprites, 10 sprites per line, and 160 pixels per sprite), you'd get 16 for Mayhem, 48 for two moles at 24 each, and 16 left for smoke/sparkles that can cover 32 if drawn in alternate frames.

C64 can do a few effects that NES cannot do. But vice versa as well, and art direction for each console would play to its strengths. What makes the C64's advantages over the NES more reminiscent of 16-bit platforms than the NES's advantages over the C64?

My understanding of C64 sprite / background priorities is that for multicolour characters sprites will always have priority over colour 01 while the background priority bit affects colours 10 and 11. Carefully drawn GFX will allow sprites to simultaneously be behind and in front of background GFX.

The C64 also has a similar bug, we call it "cookie cutter" it was mostly famously used in Caren and the Tangled Tentacles.


You have gone through every leaf on the trees and found them all to be 8bit leaves and to which you will say its doesn't look 16bit as all of it can be done on an 8-bit. yes this is true, as it was actually done on an C64. And you have valiantly defended the NES's honor ( not that it was being attacked ) by finding an instance of each of MIM leaves in some games on the NES, and then SMS when the NES didn't quite do it. However you have missed the forest, the point is all the leaves are in MIMs forest and 25 years ago when we played it on a CRT we all said "Mate your pulling my chain, you put an A600 in the case didn't you...", it doesn't look 16 bit explicitly, it feels 16 bit, the high colour, the insane full screen scroller, the full music, the moving eyes on the trees, the way he accelerates, the way he launches of the top of slopes at full speed the way he looks down and worried when he gets to the end of the platform, the way his eyes go up and then down as he jumps, the way it has more than the fixed palette of 16 colours on screen, the smoothness of his jump, and his turn around. Since then it has been determined that it would actually be mostly possible on an A500 at EAB, but it would need some compromises, to be fair to the A500, less than the NES would need

Its a lot harder for the NES to look 16bits due to 3 crippling factors.
1.) Teeny tiny VBlank update, its really hard to push enough data through to add more animation, change the background etc. To make this worse you can't even access VRAM but have to spend even more time sending data through a tiny pigeon hole.
2.) RAM, tiny amounts of RAM, which limits the amount the game can remember or the size of the world it can update.
3.) 64 sprite pixels per line, flicker is decidedly cheapening and a key thing of the SNES was it got rid of most of it ( unless you were Konami )

I'm not saying (and have never said) that no NES game can be so high polish and update the wold and avoid sprite flicker to make you think you are playing something that is 16bit. I don't know of any examples but I didn't really own a NES, my friends had it. I started at SNES. I would imagine the NES could make a pretty decent shoot-em-up that would rival some 16bit platforms.

Correct, allowing the careful artists to get a "dual-planefields" effect, there is also the cookie cutter bug that allows you to use a sprite to cut another sprite.

Being 8-bit doesn't rule out particles.

You have me curious now, what does rule out 8-bit;what "is 16-bit" ?

I feel the same way about people who call everything a "card". Talking about the NES "sound card" for example is one of those mistakes that drives me up the wall the most.

I gotta admit I have never heard that one.

I had a long talk with someone recently who insisted that the NES has a framebuffer though.
Probably a question of definition of course, but I have a hard time thinking of the PPU RAM as a "framebuffer".

(and before anyone else jumps in, yeah, I'm aware of games/demos that use off-screen nametables as actual buffers )

When someone says NES "framebuffer", I immediately think of Videomation and Oeka Kids, which are designed to store a full screen framebuffer in CHR RAM. After that, I think of pseudo-framebuffers as used in Qix, Hatris, the Block Out prototype, 3D Block, and the like.

If I'm not mistaken, it could refer to the fact the NES has the 2kB CIRAM (or all the various types of memory available to the PPU) for drawing the next frame, whereas say the Atari 2600 does not.

The NES has enough video memory to draw an entire frame without CPU intervention, while the 2600 only has memory for one (or half of one) scanline, and needs constant intervention in order do display anything meaningful. Maybe that's what the person was referring to.

Also Greg Norman's Power Golf consructs the entire screen from scratch using WRAM at $6000, and copies to VRAM. I find this example much more impressive than Qix.

Yeah I think that was the official explanation, but that's not what a "buffer" is in my world. I think the person just accidentally applied a more "modern" mindset to an older console and tried to somehow defend the statement.
The discussion started out of a supposed "inherent input lag" in the hardware of older consoles like NES and SNES.

In the lag sense, the NES indeed has a set of buffers that the PPU uses to emit a frame. It just isn't organized as a stream of pixels.

Input lag on Atari 2600: .5 field
Controller is read at start of vblank before field T
Result displayed on field T

Input lag on ColecoVision and its successors (MSX, SG-1000, NES, Master System, TG16, Genesis, Super NES): 1.5 fields
Controller is read at start of field T
Changes calculated during field T pushed during vblank before field T+1
Result displayed on field T+1

Input lag on most polygon-based systems: at least 2.5 fields
Controller is read at start of field T
Changes calculated during field T into a display list
GPU executes display list during field T+1, collecting pixels into a frame buffer
Result displayed on field T+2

Game Boy behaves like NES.
The ColecoVision and Game Boy Advance, with their tall vblank, may behave like NES or Atari 2600 depending on game loop structure. The Game Boy Player accessory adds more fields of lag.