AuthorTopic: The Non-Exhaustive Restriction Guide  (Read 54424 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...