AuthorTopic: The Non-Exhaustive Restriction Guide  (Read 54423 times)

Offline ptoing

  • Administrator
  • 0101
  • *
  • Posts: 3048
  • Karma: +0/-0
  • variegated quadrangle arranger
    • the_ptoing
    • http://pixeljoint.com/p/2191.htm
    • View Profile
    • ptoing bloing

The Non-Exhaustive Restriction Guide

on: August 12, 2010, 09:56:38 am
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.
« Last Edit: August 13, 2010, 09:47:09 am by Jad »

There are no ugly colours, only ugly combinations of colours.

Offline robotriot

  • 0010
  • *
  • Posts: 168
  • Karma: +0/-0
  • Tubby mechanical friend
    • View Profile
    • robotriot

Re: The Non-Exhaustive Restriction Guide

Reply #1 on: August 12, 2010, 08:28:12 pm
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
WELCOME TO BATTLE SQUADRON

Offline Ai

  • 0100
  • ***
  • Posts: 1070
  • Karma: +2/-0
  • finti
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #2 on: August 12, 2010, 11:54:09 pm
Re: amiga:

s/4098 colors/4096 colors
AA tutorial about handling irregular lines.

If you're not at least a little uncomfortable, chances are you're not learning that much.

Offline ptoing

  • Administrator
  • 0101
  • *
  • Posts: 3048
  • Karma: +0/-0
  • variegated quadrangle arranger
    • the_ptoing
    • http://pixeljoint.com/p/2191.htm
    • View Profile
    • ptoing bloing

Re: The Non-Exhaustive Restriction Guide

Reply #3 on: August 13, 2010, 06:28:26 am
silly typo, thanks :)

There are no ugly colours, only ugly combinations of colours.

Offline Ai

  • 0100
  • ***
  • Posts: 1070
  • Karma: +2/-0
  • finti
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #4 on: August 13, 2010, 09:32:10 am
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.
« Last Edit: August 14, 2010, 01:28:43 am by Ai »
AA tutorial about handling irregular lines.

If you're not at least a little uncomfortable, chances are you're not learning that much.

Offline Kasumi

  • 0010
  • *
  • Posts: 273
  • Karma: +1/-0
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #5 on: September 05, 2010, 06:01:33 am
Okay, so here's me trying to match the style of this document. I probably still talked a little too much about things a pixel artist wouldn't need to know. Sorry! :crazy: Feel free to edit it/point out errors or whatever. As well, I did my best to always say "background palette"/"sprite palette"/etc. as opposed to just "palette", since it can be misleading to say each 16x16 pixel region can have four colors from the palette. That could mean the NES palette, and then rules are being broken if those colors aren't in a background palette!

It's like "sprite" vs "hardware sprite". Megaman's sprite is five colors, but hardware sprites can only be three  ???

Edit: Guess I should throw a link to the nesdev wiki? http://wiki.nesdev.com/w/index.php/Nesdev_Wiki

Nintendo Entertainment System

Screen

The Nintendo Entertainment System, or NES, has a resolution of 256x240 pixels, which is divided into 32x30 tiles. (Alternating light and dark areas in the image.) The image is further divided into 16 x 16 pixel regions. (Alternating red and blue areas in the image) This is because, for the most part, each 16 x 16 pixel region can only use one background palette.1



An example of the 16x16 pixel palette regions can be seen here:

Note that when the textbox moves around by a single tile, sometimes what it is drawn over changes to the textbox's palette.

The NES Palette

The NES has a 64 color palette that can be slightly tweaked by setting or clearing three RGB "color emphasis bits" for eight possibilities. As well, the colors on NTSC and PAL systems are different. The way the NES displays color is far beyond me, but as I understand it there are no true RGB values of the NES palette.

This is a tool that will generate an NES palette using various settings. The top four rows are the "default" palette, while each set of four rows below that represents a different combination of the emphasis bits being set.

This is the Default PAL Palette that Nintendulator uses:



I can't say how close it is, but I have heard the PAL palette is much more vibrant!  :lol:

Tiles In Memory

The NES has access to two sets of 256 8x8 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 backgrounds if one desires.


Background Tiles

Tiles that are drawn to the background CANNOT be flipped horizontally or vertically. Using symmetrical background tiles does NOT save some of the 256 tiles allocated to the background, so you may as well make them nice and asymmetrical!

Sprites

The NES can have 64 hardware sprites on screen at once.

Tiles used for sprites can be flipped horizontally and vertically, but cannot be rotated.

The NES has two different sprite modes:
8x8 Sprites - These use only the set of 8x8 tiles that are designated for use with sprites in the program.
8x16 Sprites - Each one of these is drawn using two tiles from one set above, and are described a bit more below. One only needs to worry about it if there are more than 64 8x8 sprites on screen in one's mockup.

8x16 Sprites Continued:

Sprites with an even tile number use the first set of tiles in memory. The top half (8x8) of the sprite uses the tile specified from the first set. The bottom half (8x8) of the sprite uses the tile whose number is one greater than the tile specified from the first set.

Sprites with an odd tile number use the second set of tiles in memory. The top half (8x8) of the sprites uses the tile specified from the second set (technically one less than the tile specified). The bottom half (8x8) of the sprite uses the tile whose number is one greater than the tile specified from the second set.

What does this mean? One HAS to dedicate two tiles to every sprite when using 8x16 sprites. So each time you want a different 8x8 projectile in a game that uses 8x16 sprites, you have to waste the tile next to it by making it entirely transparent.

Background Palette Restrictions

The NES allows for four background palettes of four colors each. One color must be in all four background palettes, meaning you can get only 13 colors on screen at once using only background tiles.2 All 13 colors must be chosen from ONE of NES' "eight" 64 color palettes displayed above. One can't have a color from the default NES palette, and a color from the red emphasized NES palette on screen at once, basically.2

Each 16x16 pixel background area can only use the four colors from any ONE of the four background palettes.1

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

Sprite Palette Restrictions

The NES allows for four sprite palettes of three colors each. (There is a fourth space in each of the sprite palettes, but it is always drawn transparent.) You can get only 12 colors on screen at once using only sprites.2 All 12 colors in the four sprite palettes must be chosen from ONE of NES' "eight" 64 color palettes displayed above. One can't have a color from the default NES palette, and a color from the red emphasized NES palette on screen at once, basically.2

Each sprite drawn can be drawn with any ONE of the four sprite palettes.

8 Sprites Per Scanline and Flickering

The NES will only draw eight sprites on a scanline. This is what goes on:



At the top we have eight sprites. When we introduce a ninth, one of them is not drawn on all the horizontal lines all nine sprites occupy. Even fully transparent parts of sprites are counted as occupying the scanline, as one can see at the bottom of the image. Parts of the first sprite below the red line are not drawn, because the white sprite's transparent bits are occupying those scanlines.

To get around this, many games swap sprite priorities every frame. You'll still only see eight per scanline each frame, but the same sprite won't always be the one that doesn't get drawn causing flickering. Flickering is not automatic, and must be programmed into a game.

Other things to know:

Sprites can be overlaid using their transparency. This is how the Megaman series appears to use five colors per sprite, but in reality it is still using three per hardware sprite.



One can also overlay sprites over the background to add a little color if needed, as well.

NES only has one background layer. It's possible to set the scroll of say, the top and bottom of the screen to different values to create a sort of parallax effect. It is NOT something that should be used to split the screen a lot of times if you want something viable looking for a game. This is how HUDs are drawn to the screen so they don't scroll in games like Kirby's Adventure, though.

Exceptions:

1 NES cartridges sometimes had hardware in them to expand the capabilities of the system. Some games provided more RAM, some provided other things. There is a cartridge type that allows one to use any one of the four 4 color background palettes for each 8x8 tile drawn to the background instead of sharing one choice between four tiles. This cartridge was EXPENSIVE to produce, and very few games used it. Cost was a factor in determining what cart to use. If you're going for NES style, many more games had to deal with the 16x16 limitation. If all you want is something that would be POSSIBLE on NES, I guess different background palette choices for each 8x8 tile drawn to the background is technically okay.  :'(

2 Well... not entirely true. One can change the palettes every scanline, really. It's just really difficult to do, and not exactly game viable. One can actually do a BUNCH of crazy things per scanline, but a lot of it is stuff you wouldn't see in an actual game. Tech demos do it a lot though. *shrug*

To explore the NES restrictions, you can try a native graphics editor written by Tepples. It doesn't support sprites, but lets you edit and place tiles and attributes.

It can be found here as "Graphics Editor". You'll need to run it in an emulator.
« Last Edit: October 02, 2015, 05:19:32 pm by Kasumi »
I program NES games. Thus, I'm the unofficial forum dealer of too much information about the NES.

Offline saimo

  • 0010
  • *
  • Posts: 164
  • Karma: +1/-0
    • View Profile
    • RETREAM

Re: The Non-Exhaustive Restriction Guide

Reply #6 on: September 17, 2010, 02:17:49 pm
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


Quote
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...


Quote
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.
« Last Edit: September 17, 2010, 05:53:14 pm by saimo »

Offline Helm

  • 0110
  • *****
  • Posts: 5142
  • Karma: +0/-0
    • View Profile
    • Asides-Bsides

Re: The Non-Exhaustive Restriction Guide

Reply #7 on: September 17, 2010, 04:00:13 pm
Hehe hence the constant Amiga sidescroller artifact of Copper gradient skies.

Offline saimo

  • 0010
  • *
  • Posts: 164
  • Karma: +1/-0
    • View Profile
    • RETREAM

Re: The Non-Exhaustive Restriction Guide

Reply #8 on: September 17, 2010, 05:55:53 pm
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!)

Offline Helm

  • 0110
  • *****
  • Posts: 5142
  • Karma: +0/-0
    • View Profile
    • Asides-Bsides

Re: The Non-Exhaustive Restriction Guide

Reply #9 on: September 17, 2010, 09:18:22 pm
Yeah, I can imagine a few good examples, like how the tiles were gradient-hued in Lionheart on the first stage...

Offline saimo

  • 0010
  • *
  • Posts: 164
  • Karma: +1/-0
    • View Profile
    • RETREAM

Re: The Non-Exhaustive Restriction Guide

Reply #10 on: September 17, 2010, 09:28:28 pm
Yeah, I can imagine a few good examples, like how the tiles were gradient-hued in Lionheart on the first stage...

Definitely a good example, although, IMHO, negatively counter-balanced by the saturated purple of the sky - I'd wouldn't be surprised if the sky colors weren't chosen by Henk (and viceversa).
« Last Edit: September 17, 2010, 09:30:43 pm by saimo »

Offline ptoing

  • Administrator
  • 0101
  • *
  • Posts: 3048
  • Karma: +0/-0
  • variegated quadrangle arranger
    • the_ptoing
    • http://pixeljoint.com/p/2191.htm
    • View Profile
    • ptoing bloing

Re: The Non-Exhaustive Restriction Guide

Reply #11 on: September 17, 2010, 09:36:44 pm

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


Yeh I know on Amiga it is just 000...FFF but on PC that would translate to 00 and FF in the case of the Amiga I think because you often see old pics converted F0F0F0 which does not look right. From what I gather the Amiga had the full range of brightness, as opposed to the Atari ST where F0 seems to be the right way to convert stuff.

There are no ugly colours, only ugly combinations of colours.

Offline saimo

  • 0010
  • *
  • Posts: 164
  • Karma: +1/-0
    • View Profile
    • RETREAM

Re: The Non-Exhaustive Restriction Guide

Reply #12 on: September 17, 2010, 10:12:26 pm
Yeh I know on Amiga it is just 000...FFF but on PC that would translate to 00 and FF in the case of the Amiga I think because you often see old pics converted F0F0F0 which does not look right. From what I gather the Amiga had the full range of brightness, as opposed to the Atari ST where F0 seems to be the right way to convert stuff.

Ah, wait... so you were talking about single channels? If so, sorry, what you said is correct :y:: in fact, AGA Amigas, when programmed to work in 12-bit mode, automatically mirror the higher 4 bits in the lower 4 bits (because the palette is 24-bit anyway), basically doing the 0 ... F -> 00 ... FF conversion you indicated.
Well, maybe that passage could use some rewording ;)

Offline ilkke

  • 0010
  • *
  • Posts: 234
  • Karma: +0/-0
  • pix off
    • iLkKke
    • http://pixeljoint.com/p/9270.htm
    • View Profile
    • 'daily' art blog

Re: The Non-Exhaustive Restriction Guide

Reply #13 on: February 22, 2012, 10:55:47 am
Just realized I could add some info for Amiga500.

Overscan mode allows drawing the image on the screen border. It does not increase the resolution in the sense of making pixels smaller, instead it makes the page bigger. Used whenever you want to avoid the screen border being coloured with whatever is in palette index 0.

There is a third 'special' (6-bitplane) mode on amiga, in addition to extra-halfbright (EHB) and hold-and-modify (HAM). It is called dual-playfield, and allows the bitplanes to be combined in 2 3-bitplaned layers, each with 8 colors (3bp). The advantage is that these can be scrolled by hardware independently with great speed. Some games use this (chuck rock 2, bubba & stix, turrican 2 intro). Hardware sprites can be used to hide the limitations of DPF mode, as well as copper splits.

On the topic of copper splits, it is commonly known that copper can change the entire palette each horizontal line. What is less known is that it can change a single colour index every 8 pixels (or was it 16?). This theoretically enables use of extra colours.

It is also perhaps worth noting that Amiga could easily switch between PAL and NTSC frequencies on the fly (you only needed to poke one register), thus for example stretching the 320x200 ntsc image to fullscreen that would be 320x256 in PAL. The only visible difference would be more prominent scanlines in NTSC, but in turn the clock would increase to 60hz from 50hz.

(*copper = one of amiga's 2 graphic coprocessors)
i

Offline Ai

  • 0100
  • ***
  • Posts: 1070
  • Karma: +2/-0
  • finti
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #14 on: February 27, 2012, 02:07:58 pm
You guys might find this interesting -- CPC modes 5 and 6
These are actually invented modes that are adequately restricted to be interesting:
Quote
1.- Mode 5: Is a cpc mode 1(320x200x4) using rasters, in this mode you have
one ink fixed for all the screen, two inks fixed for each line and the
fourth ink can change each 48 pixels, the screen size is 288 x 256 pixels.
The palette is storage in the next order: Fixed colour, the two colours
fixed for the first line, the six variable colours for the first line, the
two colours fixed for the second line, the six variable colours for the
second line,...

2.- Mode 6: Is a cpc mode 2(640x200x2) using rasters, in this mode you have
one ink that is fixed for each line and the other ink can change each 96
pixels, the screen size is 672 x 256 pixels. The palette is storage in the
next order: Fixed colour for the first line, the seven variable colours for
the first line, the fixed colour for the second line, the seven variable
colours for the second line,...

It is possible to display on a real CPC, with sufficiently optimized raster code.
AA tutorial about handling irregular lines.

If you're not at least a little uncomfortable, chances are you're not learning that much.

Offline Ryumaru

  • Moderator
  • 0100
  • *
  • Posts: 1639
  • Karma: +0/-0
  • to be animated soonly
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #15 on: March 14, 2012, 11:08:47 am
Great post; I think showing some pieces that go with the restrictions would be nice as well. Can you list any of the games that used that expensive cartridge for the NES? And did the artists use that extra bit of freedom well?

Offline Kasumi

  • 0010
  • *
  • Posts: 273
  • Karma: +1/-0
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #16 on: March 14, 2012, 12:46:36 pm
There are several expensive cart setups for NES. I guess MMC5 is the main one I specifically don't like.  :)

Here's a list of all the MMC5 games.

I honestly haven't played too many of them, as most are japan only/no one talks about them enough for me to care to dig them up. Most have heard of Castlevania III, though. I haven't gone over it with a fine tooth comb, but from what I remember from it... no. The artists didn't really take advantage. In fact, they may not have actually used the extended attributes (what allows for a different palette per 8x8 region instead of 16x16) at all, they may have chosen MMC5 for any of the other cool coding things it offers. I've seen "regular" NES games that look much better. Look at these backgrounds! All with "regular" graphical limitations.

Have you heard of Retro City Rampage? The game was actually initially developed as an actual NES game under a different name and it used MMC5. It's actually the best use of the different background palette per 8x8 tile I've seen. Here's a video. The difference is pretty subtle. At 0:56 and 1:33 in the video, you can see a hospital building. Two of those orange signs on the building are 8x8 and a different palette than what surrounds them. (At least... I THINK they're 8x8. A rom was never released, and it's hard to count pixels on a scaled youtube video.  :crazy:) Then again, they could just as easily be sprites. I say they're tiles, because all four sprite palettes are also on that screen and while one contains orange, it's not the shade of the signs. Plus the signs are "on the grid" and they wouldn't need to be if they were sprites.

That game is actually also super smart with its palette use. It may have been able to look more or less as good without MMC5, but MMC5 also lets you do a lot of neat coding the game probably couldn't have lived without. MMC5 also extends the audio, giving you two extra sound channels to work with.

Once again, I haven't looked super closely, but I think even the non NES Retro City Rampage doesn't break the MMC5 graphical limitations for its game world. It uses a higher resolution than NES, and it may or may not display more than 64 sprites at once, but it seems to keep to four background palettes on screen at once, 1 palette per 8x8 tile, with one color (it chose black) being the same in all four palettes. Look for some videos of it, not only is it filled with NEStalgia, but it looks amazing and is definitely close enough to pull inspiration about what's possible from it.

For other expensive cart setups, there's VRC7 which as far I know know doesn't extend graphics in a way that's particularly exciting. (It allows very small parts of its tileset to be swapped out rather than entire page, but some other less expensive boards have things like this). What makes VRC7 special is the audio expansion it provides. It's why Gimmick is able to sound so good.

VRC7 cover of this song. I generally even avoid famitracker songs made with any kind of audio expansion, but maybe it's because I'm salty that I can't use that stuff in my own game.

In any case, if you decide to look for neat artistic stuff in that MMC5 game list please post about anything good you find. I'd honestly love to see it as well, but I'm busy coding and tend to only go out of my way to indulge myself in cool NES stuff I can actually use for what I'm doing at the moment. Sorry!

As always, my post ended up super long. Sorry 'bout that.

tl;dr, I don't have screenshot examples of good use of MMC5's extended attributes, but look at Retro City Rampage! LISTEN TO GIMMICK! WOW!
« Last Edit: March 14, 2012, 01:23:09 pm by Kasumi »
I program NES games. Thus, I'm the unofficial forum dealer of too much information about the NES.

Offline HughSpectrum

  • 0010
  • *
  • Posts: 283
  • Karma: +0/-0
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #17 on: March 14, 2012, 01:49:34 pm
Quote
I honestly haven't played too many of them, as most are japan only/no one talks about them enough for me to care to dig them up. Most have heard of Castlevania III, though. I haven't gone over it with a fine tooth comb, but from what I remember from it... no. The artists didn't really take advantage. In fact, they may not have actually used the extended attributes (what allows for a different palette per 8x8 region instead of 16x16) at all, they may have chosen MMC5 for any of the other cool coding things it offers. I've seen "regular" NES games that look much better. Look at these backgrounds! All with "regular" graphical limitations.
That's because the Japanese version of Castlevania III didn't actually use MMC5, I believe.  Instead it had a special chip to greatly improve the music quality.

Offline Kasumi

  • 0010
  • *
  • Posts: 273
  • Karma: +1/-0
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #18 on: March 14, 2012, 02:13:01 pm
You're right! The japanese version is VRC6, which provides extended audio. MMC5 provided some of the same audio things. I guess they wouldn't have bothered making the graphics better just for localization. Too bad.
I program NES games. Thus, I'm the unofficial forum dealer of too much information about the NES.

Offline Trihook

  • 0001
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile

Re: The Non-Exhaustive Restriction Guide

Reply #19 on: May 11, 2016, 02:10:45 pm
Sega Genesis/Mega Drive

The regular genny without the CD or 32x add-ons:

H40 mode
screen size: 320x224
Sprite pixels per scanline (this includes transparent pixels): 320
Sprites per scanline: 20
Sprites per screen: 80

H32
screen size: 256x224
Sprite pixels per scanline (this includes transparent pixels): 256
Sprites per scanline: 16
Sprites per screen: 64

Interlace mode
Same as normal modes, except the vertical resolution is doubled, for the tiles and sprites both. This makes the pixels appear wide. Tiles in this mode are 8x16 instead of the regular 8x8 px. This will take the same screen space as regular mode 8x8 tile. Using these double tiles will eat up ram that much faster, so the number of unique tiles is halved. Some emulators will not display this mode correctly.

Master System mode
Compatibility mode for Master System games, see the Master System post for more details.

Colors
Global palette is 9bit RGB ( https://en.wikipedia.org/wiki/List_of_monochrome_and_RGB_palettes#9-bit_RGB )
You can use 4 palettes of 16 colors each, the first index of each palette is considered transparent. The palette is applied per tile or sprite. One border color can be picked out of these 4 palettes, and it will be displayed for screen space out of the regular resolution, and also in case every pixel on the same spot is transparent. Picking one of the transparent indexes from the 4 palettes as this border color will show that particular color.

Extra colors
The genny can display shadow and higlight colors. The mechanics are a bit convoluted, so I'll just quote the original source
"This mode is kind of a mess. Essentially, tiles are either "shadowed" or "normal" based on whether or not their priority bit is set. Note that a transparent high priority pixel can make the opaque low-priority pixel below it "normal" rather than shadowed. On top of this, sprite colors $3E and $3F will modify the shadow highlight state of the pixels below them rather than displaying as normal, allowing you to set shadow or highlight status on a per-pixel basis. There are 15 distinct voltage levels for each channel. Normal mode maps the 8 values evenly over this range. Shadow scrunches them down to the bottom half and highlight pushes them up to the top half. There is exactly one level that overlaps between shadow and highlight."

The shadow and highlight palette taken from sega retro: http://segaretro.org/images/2/28/Mega_Drive_Palette.png

Sprites
Sprites are either 8x8, 16x16 or 32x32 pixels in size. It is allowed to mix sprite sizes.

Memory
The video ram can be configured as you wish more or less, with a regular count of 1296 tiles available for backgrounds. With on the fly loading from the cart and configurable ram allocation, the number of unique tiles is more or less a non issue. The tiles can have a flip by x and/or y flag set, so they can be flipped vertically and/or horizontally to save ram. Most carts are 512kb to 2Mb. Largest old commercial cart is 5Mb (Street Fighter 2), while today some use larger carts, like Pier Solar (8MB).

Layers
The genny can display 2 BG layers, 1 sprite layer and one window layer. The window layer substitutes the BG layer A where shown. It is non scrollable thus usually used for status bars and such. Each tile and sprite has a priority flag that can be set or unset, so it is possible with some scene arrangements to have the screen show what appears to be multiple background planes. If you look at some genny game videos, you can see that the different scrolling "planes" are actually only 2 BG layers that are separated from each other so that different parts of the same BG layer don't overlap.

Scrolling
BG layers can be scrolled at different speeds horizontally by pixel (those old skool wavy effecdts) or by tile. With some scene arrangements, this can be used to simulate many backgorund layers and fake 3d. Vertically, the BG layers can only be scrolled at different speeds in 16px (2 tile) increments. There is no hardware supported rotation.

Raster Splits
You can have raster splits on the genny, and change palettes on the fly to show more colors on screen at once, but the raster split has artifacts, so this is usually masked by sprites (sonic 1 water level is a good example).

As a side note, the genny has 2 gamepad ports, and a standard gamepad has a d-pad and 4 buttons (A B C + Start). Later on the genny got a controller with more buttons (I suspect Street Fighter 2 had something to do with this), which has a d-pad, 6 main button ( 2 rows of 3 buttons named A, B, C, x, y, z), a right shoulder button named mode and a centrally positioned START button. I'm not sure about light guns, wheels and multi taps, but I'm certain some games (Pete Sampras Tennis) had 2 extra gampad ports on the cart itself. Some sonic games used the so called "lock-on" technology which enabled players to plug a cart into a cart for extra features.

Take care not to use the top and botom row of tiles for anything important, the same as the first and last 2 column of tiles in any given screen, due to some TV screens cutting them off at some point or shifting the screen horizontally by some margin of pixels, depending on the TV manufacturer and the TV standard (PAL/NTSC).

Here's a link to a youtube video showing off some of the genesis more impressive gfx feats: https://www.youtube.com/watch?v=MjkDq02Apyw
« Last Edit: May 11, 2016, 04:19:35 pm by Trihook »