The Non-Exhaustive Restriction Guide

[ptoing]

The Non-Exhaustive Restriction Guide

What is this about?
Why Restrictions?
Restricted systems and graphic modes

CGA
EGA

Commodore C64
Sinclair Spectrum ZX
Amstrad CPC

Commodore Amiga500

Nintendo Gameboy/Gameboy Color


What is this about?

I am trying to make a little guide for everybody so that we do not always have to repeat the same stuff all over the place but have it in one neat thread with a nice TOC. My aim is to make this as understandable as possible, so I will refrain from overly technical jibber jabber which is not really relevant for people having a shot at these old graphic modes. After all most people wont be working on the real hardware but just do it for the fun and challenge. I encourage everybody to post links to infos about interesting old machines which I have so far not listed, and help me digest it into a nicely readable manner. I will keep updating the main post from time to time.


Why Restrictions?

One might ask, "Why should I restrict myself? I am living in the digital age and I don't need to adhere to weird restrictions."
That is of course correct, but if you are doing pixelart you are restricting yourself right there, one could argue. Why pixel in the first place, when you can use Photoshop to paint.
Pixelart at the same time restricts and gives control. We have more control over the atom of the computer image, the pixel, in every aspect. It's very easy to edit colours quickly. Usually things are small enough to change them quite fast as well. But we are restricted in our use of colour, simply because using loads of colours makes things complicated. Not that it would not be possible.

If you look at art outside the digital realm you will find that you are restricted a lot as well. You can't just pick your colour from a magical colourwheel paintbucket and paint away. Traditional art relies on the building of a good base palette to mix colours from and thus is limited. Usually something like 6-10, sometimes more, sometimes less, base colours should be enough to paint a picture with a good range and at the same time keep the palette unified. Of course you could use way more different colours, but it is not economical and things start looking garish very quick if you use too many straight from the tube colours. The same thing actually also applies to digital painting. Only selecting a bunch of well chosen colours which suit your scenario and then sticking tho those to blend new colours from will usually make for a nicer looking end result than just picking a new colour from the colourwheel every time you think you might need one.
Now with pixelart this is even more apparent since we actually have to handpick the colours we use anyway, so why not try doing this in an efficient way. I for my part can say that due to the practise of using tight palettes and also experimenting with given restricted palettes helped me to gain a better grip on colour over the years.

Restrictions are of course not just limited to colours when I am speaking of pixelart, most old machines have some more or less complicated way of handling graphical data and how the artist and programmers have to prepare it so that the machine can actually use it as intended. Now again some might ask "Why should I do this kinda stuff?" And again, no one should feel obliged to do this, pixelart can be enjoyed without adhering to restrictions. But, restrictions can also nurture creativity. When working with a given ruleset, especially if it is not overly simple will make you think about how you approach your work in a very direct way. There will be something like a dialogue between the art and the artist in a way that the restrictions will say, "No, this wont work, try again"
This, if you stick with it,, will automatically make you think about different ways of solving problems, ones you would normally not have chosen to take in an unrestricted environment. And this will also help your overall skill with pixelart, because many things you learn when working under restrictions can be transferred over to unrestricted work. Additionally you might find new stylistic choices which you would otherwise not have come up with as well.

So now let's have a look at some restricted systems and graphic modes which have been around for a while.

Restricted systems and graphic modes

CGA

Palette

CGA has a palette of 16 colours.



This palette works similar to the one of the ZX Spectrum, tho arguably it is a lot nicer, what with the extra grey, tweaked brown and generally a bit less eyesore.
The brown was actually a hardware hack in monitors back then which made that colour look nicer.
On some displays which did not support this it looked like this


Graphic Modes

CGA has some 2 textmodes which are in general not very interesting for graphics. In these modes you either could have 40x25 or 80x25 8x8 characters which came from a predefined ASCII set of symbols which each could have a unique foreground and background colour out of any of the 16 colours.
The resolutions of these modes are 320x200 and 640x200 respectively.

In the 80x25 mode it is feasible to tweak the display so that only 2 pixels of each character are shown which quadruples the vertical resolution to 100 characters. This combined with the use of characters which are half foreground/half background colour you could get a 16 colour "graphics mode" with 160x100 "pixels" resolution.

The other 2 graphics modes were a bit more interesting for everyday uses, mainly because of the higher resolution.

There is a high resolution mode with 640x200 pixels (tallpixels) which has black as fixed background colour and can use one other of the 16 colours. 2 colours total. Not very exciting.

The mainly used CGA mode is the one where you can choose from three 4-colour palettes with 2 intensities each (making 6 palettes) at a resolution of 320x200

Palette 1 is what most people probably remember as CGA from back in the days.


Palette 0 is what most people probably remember as CGA from back in the days.


And lastly a palette which was not official and only worked on RGB monitors (but is pretty nice)


When using one of these 6 palettes you can also change the black to any of the other 16 colours, which also affects the border area around the main drawarea.


EGA

The "main" EGA mode has a resolution of 640x350 pixels (you have to remember that this, as well as the 320x200 resolutions are displayed at 4:3)
with 16 colours, which can be picked from a 6 bit RGB222 palette



The mode which was mostly used was 320x200 with the 16 CGA colours which now could be used freely.


Commodore C64

Screen

The Commodore C64, short just C64, has a native resolution of 320x200 pixels, which is segmented into 40x25 characters (tiles).



There is also a border around the main screen area which can be any of the 16 colours. There are also way more tricks possible with the border, but this would be too much for this simple guide.


Palette

Like most old 8-bit computers the C64 has a predefined 16 colour palette.
The interesting thing about the C64 palette is that it is not a digital palette, meaning there are no predefined digital bits used to set the colours. It is analogue and was handmade. This results in way less garish looking colours than for example the ZX Spectrum palette or CGA/EGA.

Since no one really knows the real RGB values of the C64 palette (there are no RGB values the C64 would have stored anywhere) someone with the handle Pepto sat down with some data, measuring tools and used science to find out good what would be a good representation of the C64 colours to RGB. How he did this you can read about here.

In order of brightness.


The respective grey values (what you would see if you turned the colour dial on your monitor/TV all the way down), note the pairs of equal value, more on this later.


In order of colourcodes. Each colour has a hexnumber from 0 to F in this order. This is important for some of the graphic modes as well.


I personally use a lighter version of the pepto palette which I adjusted myself when I save images for display on anything else than the real thing.



Let's have a closer look at the palette and why (I think) it is so nice.

Here are examples of some simple and straightforward ramps.


And here some ramps using greys as buffercolours.


If you look at other fixed 16 colour palettes you will see that they don't have as many greys, which is due to their binary nature (as opposed to being handpicked). You can see that greys are interchangeable with other colours to form different ramps and branch off into different colours.

Here are some more examples of miniramps showing which colours can be bridged using the different greys. Of course not all of these work equally well, but they all do their job at least alright.



So in any case, no matter if you just wanna draw with this palette or adhere to some proper C64 restrictions, it's quite nice and challenging to work with.

Screen Modes

The C64 basically has 2 times 2 screenmodes. Hires (also called Singlecolour) and Multicolour being the resolutions and Character or Bitmap mode being the way things are arranged in RAM and so on. Hires bitmap and Mcol bitmap are mutually exclusive while in charmode they can be combined (with some limitations)

Character mode
Character mode is more restricted but more economical in RAM usage (thus it is often used for applications and games, where bitmal mode would be overkill on resources)

There is only space for 256 characters allocated in memory and there is one global background colour chosen from any of the 16 colours.

In hires the full resolution of 8x8 pixels per character is available but only one other colour aside from the background. If hires char mode is being used on it's own (not combined with mcol) the extra colour per tile can be any. If it is combined with Mcol it can only be chosen from the first eight colours 0-7.

In mcol the resolution is halfed resulting in 4x8 widepixels per character. At the cost of pixel resolution colour resolution is gained.
Each char can have 4 colours. This sounds nice, but is limited. One colour, as already stated is the background colour, then there are 2 more global colours which can be picked from any of the 16, plus one colour which can be unique per character but is again can only be picked from the first eight colours 0-7.

A very nice example of char mode are these Metroid mockups by vierbit



The hud could be done using a screensplit so that there are basically 2 parts of the screen which can have completely different colours if you want. (Tho this is not something that is readily available and has to be specifically coded)

Bitmap mode

In bitmap mode the artist has more freedom with colours and no restrictions with the amount of characters used. Each one of the 1000 chars on screen can be different.

Hires bitmap mode has the full 8x8 resolution per char and can have 2 colours per character chosen from any colour. There is no global background colour in hires bitmap mode.

Multicolour bitmap mode is a bit more complex. Here there resolution is again halved to 4x8 widepixels per character. In Mcol bitmap there still is a global background colour which can be chosen from any of the colours. On top of this each char can have 3 unique colours. You can imagine the background colour being the paper colour and the other 3 colours being what you can draw on top of this.

In general it is a good idea to use either one of the greys or the colour you use most in your picture as the background colour, althought black, white and most of the colours at the 2 ends of the value range are not as good. This is because you can not reuse them as widely. Greys can be used to aa or buffer, same with cyan for example if you have a very blue picture. With black or white you can never do this. So using black or white for the background should be avoided unless you have a very good reason for it.

[example pics]

Sprites

The C64 has hardware sprites which come in very handy for games, since they are faster than software ones. Again the sprites come in 2 flavours, hires and multicolour, and they are very similar to how stuff works in character mode.

Instead of a background colour one colour is reserved for transparency.
Hires sprites are 24x21 pixels big and are 1 colour, chosen from any.
Mcol sprites are 12x21 widepixels and have 3 colours, 2 of these colours are global, chosen from any, and one colour is unique, also chosen from any.

Technically the amount of sprites at once is 8, but with multiplexing there can be 8 per scanline.
It is to note that a sprite always occupies it's full size, no matter how big the non-transparent content is.

Sprites can also be stretched on the X and/or Y axis do double them in size.

[some pictures]


Sinclair Spectrum ZX

Screen

The Sinclair Spectrum ZX, short ZX, Spectrum or Speccy, has a resolution of 256x192, segmented into 32x24 8x8 characters, also called attribute cells.
There is also a border which can be changed to one of the 8 basic colours.



Palette

The Speccy consists of 8 colours which come in two intensity variants - basic/dark and bright.



Graphic Modes

By design the Speccy does not have multiple different gfx modes, just one. In this mode you can have 2 colours per attribute cell and each cell is either dark or bright, meaning you can not mix colours with different intensities in the same cell. Notable is also that there is a flash bit which can be set for each cell. If this is set the background and foreground colour of the cell will alternate in a blinking fashion.

With programming it can be achieved to have 8x1 sized attribute cells over half the width of the screen or 8x2 sized attribute cells over the full width.


Amstrad CPC

Palette

The original Amstrad CPC, short CPC has a palette of 27 colours. Later improved models sported a 12 bit RGB444 palette resulting in 4096 colours to choose from



Graphic modes

There are 3 graphic modes:

Mode 0: 160x200, 16 colours. Widepixels
Mode 1: 320x200, 4 colours. Square pixels
Mode 2: 640x200, 2 colours. Tall pixels

There are ways to increase resolution by reprogramming the video controller


Commodore Amiga500

12 bit RGB444 palette (4096 colours). This basically means you only have 16 instead of 256 choices per RGB channel.
On modern PCs this basically would be all values 00, 11, 22, 33, 44... up to FF.

Graphic Modes

There are 2 graphic modes in 2 subflavours.

Normal:
Lowres: 320x256 PAL / 320x200 NTSC - 32 colours
Highres: 640x256 PAL / 640x200 NTSC - 16 colours - tallpixels

Interlaced:
Lowres: 320x512 PAL / 320x400 NTSC - 32 colours - widepixels
Highres: 640x512 PAL / 640x400 NTSC - 16 colours
On the original machine the interlace modes flicker quite a bit unless flicker fixer hardware was installed.

Confusingly the modes are also often called: Lores, Medres, Interlaced and Hires.

There is something called Overscan which can achieve higher resolutions (wip)

Also there are 2 special modes Extra HalfBrite (EHB) and HoldAndModify (HAM).

In EHB you get the normal 32 colourslots to populate and the machine automatically generates 32 half als bright versions of these colours.
The values get rounded down, ie. 3 would become 1 and F (15) would be 7.

HAM is quite complicated and not feasible without special graphics programs which can handle it.
Basically the user gets 16 colours to choose and each pixel can either be one of these 16 colours or can inherit 2 of the RGB values of the pixel left to it and change the third value to something new. So if you would change a pixel all pixels to the left of it can potentially change colour. I am not sure if this wraps around scanlines, probably does.


Nintendo Gameboy/Gameboy Color

Screen

The screen of the both the GB and GBC are 160x144 pixels, segmented into 20 x 18 8x8 characters/tiles.



Palette

The original Gameboy has a monochrome 4 colour palette of which there are no reliable RGB values, which also has to do with the fact that you can adjust the brightness. For all intents and purposes any more or less straight ramp from a very light to a very dark value will do.

The Gameboy Color has a full 15 bit RGB555 palette, 32768 colours to choose from.

Tile and sprite restrictions

On the GBC there are eight definable palettes for each the sprites and the tiles.

Tile palettes can have 4 colours, sprites effectively have 3 colours, because one of the 4 slots is reserved to transparency.

[robotriot]

Kleincomputer KC85

The KC85 was a computer produced in the 1980s in the GDR. The computers made use of a palette of 16 foreground colours (actually only 14) and 8 background colours and their screen resolution was 320x256.

Foreground palette (white and black are duplicated):



Background palette:



On the KC85/2, the screen was divided into 4x8 pixel rectangles. Each rectangle could contain 1 background colour and 1 foreground colour.



The later model KC85/4 had the rectangle size reduced to 1x8, but still the same limitations.



A hires mode was available for the KC85/4 as well: it had the same resolution like the standard graphics mode, but four colours of a fixed palette could be freely used without further restrictions.

Hires palette:



Sources (in German only):
http://de.wikipedia.org/wiki/KC85
http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=1430

[Ai]

Re: amiga:

s/4098 colors/4096 colors

[ptoing]

silly typo, thanks

[Ai]

NP

re: CPC
1
2

Since you've added info on the CPC+, I should mention:

* CPC+ has 16 hardware sprites of size 16x16 pixels, which have a shared  palette of 15 colors+transparency [and are zoomable by 1x,2x, or 4x, independently for each axis (X,Y).. This is actual hardware resolution-mixing where elements in one resolution can be overlaid on another in a different res, not just like split screen. Dunno why you'd WANT to do this other than saving ram, buuut...] That bumps the total color count up to 17, 19, or 31 IIRC. (plus border color, which we typically won't care about). These sprites can be displayed anywhere on the screen, including on top of each other (later numbered sprites are drawn atop earlier ones) Magnification is relative to the 640x200 resolution, so for 'square-ish' pixels, you would use a Y magnification of 2x, and an X of 1x

* CPC+ also has a programmable raster interrupt controller, which automatically generates a hardware interrupt at the end of a specified scanline. (typically if you used this at all, it would be reprogrammed twice a frame: once to define the start line, then again to define the end line.. see below)
 In non-techy terms: Mode splits and palette splits can be done readily, without any need for highly tuned timing or ludicrously optimized code.

* The above features can be combined to display many more sprites onscreen. (replacing the graphic data was slooow, though.. but we probably don't care about that unless we're programming an actual CPC+ game.
(3)


re:CGA

you could also reprogram the CGA to work in 160x200, 16 colors, if you were using a card that supported composite output.
see these examples..
Pretty much like a wide-pixel EGA.

this is actually a 'method' for getting intermediate coloring by interleaving two colors and depending on composite display blurring to average them. but functionally, it works as a 160x200x16color display, IMO.


Also, SMS restrictions seem like they might be fun for mockups etc..
I haven't yet managed to get specs that are complete enough.
Here's what I do have..

1
2

* 256x192, 256x224, or 256x240 (for GameGear: 160x144)
* 32 colors onscreen, chosen from a 64-color master palette similar to EGA.
.R,G,B intensities are [00, 40, 80, C0] rather than EGA's [00, 55, AA, FF].
GameGear master palette is larger (4096 colors, 16 levels of R/G/B. [00, 10, 20... d0,e0,f0]) but the number of onscreen colors is the same.
* Background tiles can use any of the colors in the entire 32-color display palette.
* Sprites are only allowed to use colors 16-31 (the second bank of 16 colors in the palette). [UNCONFIRMED] Each sprite can use 15 of those colors, plus transparency..
* 64 8x8 sprites may be displayed simultaneously; max 8 per scanline.

[Kasumi]

Spoiler: An Opening Chat/Disclaimer

NES' power could be "expanded" by extra hardware in the cartridge. One could get more RAM, more space for tiles, and many other kinds of things.

It seems easy to simply write a guide that ignores this, but way more of the NES library had some kind of expansion than did not. It doesn't help that certain graphical effects can effectively make others impossible. Using ROM vs RAM to store tiles is an example, which usually can't even be switched mid game.

The thing to take away is that even though all NES games run on the same console, they didn't all have the same hardware resources available to them. With enough electrical engineering knowledge, many "NES limitations" can be overcome and that makes a guide like this hard to write. I aim to cover limitations I feel are a decent average of what you could get without overwhelming people. If you know the exceptions, the guide's not for you.

For some fun examples:

A cartridge with over 20 minutes of "actual" audio (i.e., not chiptunes): https://www.youtube.com/watch?v=3w8atFA2fk0
A cartridge that allows the NES to play Game Boy cartridges: https://www.youtube.com/watch?v=kLwEkSyFSm8

For people who aren't familiar with pixelation.org, clicking images zooms them. This is why the images are so small, rather than scaled up.
Nintendo Entertainment System
Quick Reference:


The Nintendo Entertainment System, or NES, has a display resolution of 256x240 pixels.

Tiles In Memory
Its tiles are 8x8, and allow for 4 colors (1 of the 4 colors is always transparent).

The NES has access to two sets of 256 tiles at a time. Normally one set is used for sprites, and one set is used for background tiles. However one can use the same 256 tiles for both sprites and the background if one desires.

Here are the 256 background tiles used for all of Super Mario Bros.:

Here are the 256 sprite tiles used for all of Super Mario Bros.:


Palette
The NES has a 64 color palette in theory, but several of the colors are actually the same. There are actually two more fully black columns to the right of the 56 colors below. And there are even two whites and two blacks in the palette image below. That's... just how it is.

A "perfect" set of RGB values for the palette doesn't exist and many strange things can influence the colors. The one above is from this palette generator that attempts to recreate in software how the hardware generates the colors.

Background Limitations
If your game does not scroll, you can imagine the screen as being divided into 32x30 tiles.

It is further divided into 16x16 "palette regions". (Alternating red/blue sections below.)

The screen is first cleared with any color one wants from the palette. (Simplified.) We'll call this color the "clear color" or the "universal color".

Then, the four tiles in each palette region are drawn with the 4 colors in the "palette set" associated with that region.

There are 4 palette sets of 4 colors each available for the background. (1 of the 4 colors is always transparent). This effectively means that one color from every set is the "clear color".

Changing the color changes it in all palettes, hence why it is sometimes called the "universal color".

With the universal color and the 3 other colors from the 4 palette sets, you can display up to 13 colors using only the background. Each of the 13 can be any chosen arbitrarily from the palette, but the colors cannot be placed arbitrarily because only four colors from any one set are allowed in each 16x16 area of the screen.

For a more visual explanation of this, see this post.

If your game is meant to scroll, you can imagine the grid as repeating endlessly.

(There are some caveats if your game can scroll both vertically and horizontally in the same frame, but nothing to lose sleep over.)

Background tiles cannot be flipped by the hardware so symmetrical tiles don't save room in your tileset. You may as well make them nice and asymmetrical.

You can usually have 256 background tiles on screen at once, and the screen is 32x30=960 tiles. This means less than 27% of what's displayed at once can be unique. Think about that. 

Hardware Sprite Limitations
The NES can display 64 hardware sprites at once.

There are 4 palette sets of 4 colors each reserved for sprites. (1 of the 4 colors is always transparent). Unlike with the background, the transparent entry is NOT effectively the "universal color". It's really transparent.

With 3 opaque colors from 4 palette sets, you can display up to 12 colors using only sprites. The colors can be chose arbitrarily, but each hardware sprite must use only the colors from ONE set.

Each of the 64 hardware sprites has its own:
*Screen Position
*Choice of tile
*Choice of palette set
*Background Priority. (Simplified, whether it is drawn in front of or behind the background.)
*Orientation (Flipped horizontally, flipped vertically, not flipped, or flipped horizontally AND flipped vertically)

Hardware sprites can be 8x8 (one tile from the sprite tileset), or 8x16 (two tiles from the sprite tileset). It seems like one should just always use 8x16 sprites, but how they use the tileset makes for some strange trade offs I won't get into. The 64 hardware sprite limit keeps anything you do in a static mockup from being impossible to display, though.

Note that all 64 hardware sprites must be 8x8, or all 64 hardware sprites must be 8x16 for any given frame.

Sprite Flipping in Practical Terms
Most things people today call a "sprite" would be made of many hardware sprites on NES. This frame of big Mario uses eight 8x8 hardware sprites and eight 8x8 sprite tiles.


Sprite flipping allows you to use fewer tiles in the sprite tileset. (You only have 256 in memory at once!)

If it wasn't allowed, you'd need 16 tiles in the set to draw the big Mario frame facing left and right instead of 8.

And because big Mario is made up of many hardware sprites, check out how tiles are saved in this frame:


His head uses 4 tiles, but his lower body only uses 2 that are flipped. So that frame of big Mario  still uses eight 8x8 hardware sprites, but only six 8x8 sprite tiles.

Flipping allows a horizontally and vertically symmetrical 16x16 object to be drawn with only one unique tile from the sprite tileset. Because 4 hardware sprites can all flip that same tile differently, it can be used for all four corners. (This assumes 8x8 sprites)


You can similarly draw a horizontally and vertically symmetrical 16x32 object using 8x16 hardware sprites.

While the above may make it seem like sprite rotation is possible, it is not. Here is Mario's face flipped.

The four tiles on the top left can be used to make all the faces on the bottom left.
The four tiles on the top right can be used to make all the faces on the bottom right. You'd need all eight tiles on the top in the set to display all eight faces on the bottom.

Hardware Sprite Transparency in Practical Terms
In addition to keeping your characters from being blocky, each hardware sprite having its own position and transparency allows one to stack hardware sprites using different palette sets on top of each other. This technique is called "Sprite Overlaying".


You still only get 3 colors (and transparent) per hardware sprite, but what most people call a "sprite" these days could be 12 colors (and transparent) if you really wanted.

Just keep in mind it takes away more from both the 64 sprite limit and the 8 sprites per scanline limit, and uses extra sprite tiles from the 256 set when they're overlaid. And that you still only get 4 palette sets on any given screen. The character above uses 3 of the 4!

Mega Man uses sprite overlays to make his face a different color than his suit, but it's only one extra sprite.


You'll notice in both examples, multiple palettes share colors. If black weren't in every palette, you'd need two sprites (and two tiles) for everything that needed a black outline and used colors from the three palettes that didn't use black.

In the specific case of Mega Man, he'd need an extra black hardware sprite (and sprite tile) for his pupils and mouth if black wasn't in the "face" palette".
Flickering
There can only be 8 hardware sprites on a scanline. A scanline is a row of pixels on the screen. If more than 8 sprites occupy a scanline, it doesn't draw the extras at all.

Note that even fully transparent parts of sprites count as being on a scanline. The top and bottom moving sprites are positioned exactly the same. Check out this case:

Even though the bottom of the top sprite is transparent, it still keeps the rightmost sprite from being drawn.

To get around this, games simply drew the sprites in a different order every frame, which resulted in a different set of 8 sprites every frame. Here's what the above case would look like with and without flickering, showing the sprites in memory:
With: https://i.imgur.com/5MikjRD.gif
Without: https://i.imgur.com/CqyXnqA.gif
And since the benefit there might be hard to see, here is what flickering looks like in an actual game (slowed down): https://i.imgur.com/CfntLCl.gif

Extra Information
Kickstarted NES homebrew with updates talking in depth about its development: https://www.kickstarter.com/projects/1101008925/lizard/updates
Here's an update from the above that covers much of this post in more depth: https://www.kickstarter.com/projects/1101008925/lizard/posts/1582636

My own devlog of an NES game: http://skullgirls.com/forums/index.php?threads/indivisible-on-nes-playable-rom-inside-image-heavy.8488/

The NESDEV wiki (More technically oriented): http://wiki.nesdev.com/w/index.php/Nesdev_Wiki

A program I wrote that will turn a PNG (or PNG sequence) made with NES background restrictions into a ROM (or mark errors): https://kasumi.itch.io/ichr

A program that will allow you to create NES backgrounds and enforce limitations while you make it (Get NES Screen Tool from the link): https://shiru.untergrund.net/software.shtml


An imgur album with many effects used in actual NES games: https://imgur.com/a/XJmb7

Be careful! While everything in there is possible, if you try replicate an effect without understanding its tradeoffs you may create something that won't work. It's also worth noting some things are simply hard to do, or wouldn't work during a gameplay section of the game.

[saimo]

Great job, ptoing!

Just a few things about the Amiga...

12 bit RGB444 palette (4096 colours). This basically means you only have 16 instead of 256 choices per RGB channel.
On modern PCs this basically would be all values 00, 11, 22, 33, 44... up to FF.

000 ... FFF

Graphic Modes

There are 2 graphic modes in 2 subflavours.

Normal:
Lowres: 320x256 PAL / 320x200 NTSC - 32 colours
Highres: 640x256 PAL / 640x200 NTSC - 16 colours - tallpixels

Interlaced:
Lowres: 320x512 PAL / 320x400 NTSC - 32 colours - widepixels
Highres: 640x512 PAL / 640x400 NTSC - 16 colours
On the original machine the interlace modes flicker quite a bit unless flicker fixer hardware was installed.

Confusingly the modes are also often called: Lores, Medres, Interlaced and Hires.

There is something called Overscan which can achieve higher resolutions (wip)

Unfortunately things aren't that easy because the screen width/height is entirely programmable. The sizes you listed are just the most common ones, but the combinations possible are way too many to list (f.ex., nothing forbids creating a 336x267 screen, just to mention an odd one). Of course there were some limits, but sadly I can't remember them (too much time has passed) and it wouldn't be easy to describe them here anyway (just to give an idea: the left border could only vary between a certain range and at 8 or maybe 16 pixels multiples).

You were not totally incorrect, though, as modes do exist - it's just that they don't refer to the amount of pixels, but rather to the dimensions of the pixel itself:
 * LORES mode: 140 ns pixel, which is the biggest and most common one;
 * HIRES mode: 70 ns pixel, which is the kind of pixel here usually referred to with "tallpixel", since its height is twice its width (in practice, it's equivalent to a half LORES pixel);
 * interlace mode: activates the well-known odd/even-lines-only plus vertical offset effect to give the impression that the pixels height is half the normal size; it can combine freely with LORES and HIRES modes.

(The times expressed in ns refer to the time the raster beam takes to draw the pixel on screen.)

Another mode is the dual-playfield, which paired the even and odd bitplanes to form 2 overlayed, indipendent "screens", so the total amount of colors per "screen" is at most 8 for the background one and 7 (plus transparency) for the foreground one.

With the ECS/AGA chipsets things got even more complicated, but that's another story...

I am not sure if this wraps around scanlines, probably does.

I can't be 100% sure because I hated HAM and thus I never used it, but the memory of the very common tearing/bleeding problems of HAM suggests that it doesn't wrap around.


Then, let's not forget sprites
Here is some information:
 * there were 8 sprites, each of which had 3 colors + transparency;
 * each sprite could have a maximum width of... mmm... probably 16 pixels; height could be... lemme think... probably 256 pixels, but with vertical multiplexing the height could be virtually any;
 * sprites could be combined (by pairs: 0+1, 2+3, 4+5, 6+7) to form 15-color + transparency sprites;
 * if my memory doesn't fail me, colors were taken from these palette slots (sprites: colors): 0, 1: 17, 18, 19; ... 6, 7: 29, 31 (the pattern is: the colors from 16 to 31 are divided into banks of 4 colors, which are assigned progressively to the sprite pairs; the first color of each bank is irrelevant because of transparency); the AGA chipset had the ability to relocate the banks, but I can't remember whether it applied to OCS and ECS chipsets (probably no);

Finally, a little note: colors could be dinamically changed by the CPU or the Copper* so that the total amount of actually colors shown could be easily much higher than the number of colors in the palette. This is relevant to pixelling only when producing the graphics for a game or demo, of course.

*Actually this applies to most of the chipset registers, so that it was not uncommon having on the monitor multiple screen modes at once.

[Helm]

Hehe hence the constant Amiga sidescroller artifact of Copper gradient skies.

[saimo]

Hehe hence the constant Amiga sidescroller artifact of Copper gradient skies.

Precisely. That's indeed one of the easiest effects to achieve. (And I personally think it's been overused, often with terrible results - programmers tended to adopt highly saturated colors that ended up burning the eyes - I've done that mistake myself!)

[Helm]

Yeah, I can imagine a few good examples, like how the tiles were gradient-hued in Lionheart on the first stage...