Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
While the Original Chip Set (OCS) and Enhanced Chip Set (ECS) Amiga computers had the 32 x 2 colour EHB (Extra Half-Brite) and 4096 colour HAM (Hold And Mofify) screen modes, where these ever used outside paint programs, for instance in games?
If so, was there any interactive animation/movement with these screen modes?
For example, a game that uses EHB (Extra HalfBrite) mode during the game action (i. e. ingame) is Pinball Dreams. In my example run of the Beat Box table I can find the following in the copper list:
$00D6EA WAIT $4211FFFE
$00D6EE MOVE #$6200,BPLCON0
I. e. it waits for raster line $42 (66) and uses BPLCON0 to set the number of bitplanes to 6 without the HAM bit set, which means EHB mode.
Cannon Fodder uses EHB for some of its still pictures. I'm not sure if it uses it ingame, but I consider it unlikely.
A newer game, Nemac IV, presents you with a screen mode selection at the beginning, offering EHB mode as an option. It can then render its ingame 3D graphics to an EHB mode display. However, it requires a machine more powerful than a stock Amiga 500.
The way HAM (Hold And Modify) mode works makes it unsuitable for ingame animation in most cases. I used to be unaware of any game that uses it for gameplay. (Update: There were at least 2 games using HAM for their animated action. See robc's answer.)
Fury of the Furries uses HAM for its still images, for example the title image and the images that are displayed before entering a new world (each consisting of a set of levels).
The reason why it is unfeasible to use HAM for animated action is that you will either have to tolerate so-called color bleeding to the right of pixels or you will need to employ sophisticated algorithms to counteract the color bleeding, which timing constraints may forbid or which are just not worth it to come up with.
In HAM mode you usually use 6 bitplanes (you can also use it with 5 bitplanes, but there's not much point to that). That's 64 possible values per pixel. Values 0 to 15 select a full RGB color from the 16 color palette, the same way other normal screen modes would. However, value sets 16 to 31 (modify blue component), 32 to 47 (modify red component) and 48 to 63 (modify green component), respectively, each just change one of the color components relative to the color of the previous pixel. The other two color components remain unchanged from the previous pixel.
Say you set the color to palette entry 8 in column 100. Say also that this palette entry is $0333, i. e. a very dark gray. So the pixel in column 100 will appear gray.
Then, lacking a matching color in the palette, you modify the red component in column 101 to $6 (using a pixel value of $26 = 38). The resulting pixel in column 101 will now have a color equivalent to $0633, which is a dark unsaturated red.
Next, again lacking a matching color in the palette, you modify the green component in column 102 to $7 (using a pixel value of $37 = 55). The resulting pixel in column 102 will now have a color equivalent to $0673, which is a brown-greenish color.
Finally, lacking a matching color in the palette once more, you modify the blue component in column 103 to $6 (using a pixel value of $16 = 22). The resulting pixel in column 103 will now have a color equivalent to $0676, which is a dark gray with a very slight shimmer of green.
note that each differently colored square represents 1 pixel
So far so good, but say you now want to blit an animated character onto the bitmap. Say the rightmost pixel of that character ends up in column 100 and it is a bright white, palette value $0FFF. What this means is that the white will bleed into the next 2 pixels:
Due to modifying just the red component, the visible color in column 101 will be $06FF, a bright cyan.
Due to modifying just the green component, the visible color in column 102 will be $067F, a bright blue.
Only in column 103 will you have modified all three color components and the apparent pixel color will be the same $0676 as the original one before blitting.
note that each differently colored square represents 1 pixel
Depending on how many and which color components you consecutively modify, the color bleeding can affect more or less pixels and depending on how different the colors are to the originally intended colors, the artifacts can be more or less visible.
note that I scaled the image by a factor of 2 to make the artifacts easier to see
To counteract the bleeding, you would have to design a routine that figures out which pixels to the right of a blit to adjust and which pixel values are the optimal ones that let the apparent pixel colors match the original ones as closely as possible. You won't get completely rid of the artifacts, but they might now be unnoticeable unless you take a closer look.
Many OCS/ECS Amiga games use more than 32 colours.
There are some cases of games using Extra Half Bright (EHB) mode like Universe (see this thread for more info on that game: How to obtain 256 arbitrary colors with limitation of 64 per line in Amiga (ECS)?).
However, the most usual way of achieving more than 32 colours in a frame is using Copper tricks. The Copper is a coprocessor which runs in sync with the video beam, and can modify some of the custom chips registers. The programs executed by the Copper are made of 3 different instructions (wait, move, skip). Such programs are called copperlists. You can easily build a copperlist which waits for certain video beam positions and changes some colour palette registers. There are lots of well known games using this technique: Pang, Lionheart, Agony, etc.
Of course, you can animate graphic objects (BOBs or sprites) using any of this techniques.
Shadow of the Beast uses dual play field mode (of 3 bitplanes each) and some crazy sprite reuse to get its color on the screen. Have a look at this breakdown:
http://www.codetapper.com/amiga/sprite-tricks/shadow-of-the-beast/
I've not actually played it to confirm how well it does it, but Pioneer Plague claims to run in HAM mode, but I've not actually given it a whirl to see how well it runs in comparison.
Someone has recorded some gameplay footage and put it up here though, so you can get an idea - though I believe to be emulated, so YMMV :)
Given that the present answers are all over the place and seem to completely miss the point here is an attempt to answer your questions properly:
[HAM and EHB] where these ever used outside paint programs, for instance in games?
Yes!
HAM and EHB modes have been used many times, mostly for static images such as loading and story telling screens.
The Hall Of Light (HOL) site which lists most known Amiga games offers a method to list them by graphic mode: HAM games, and EHB games.
If so, was there any interactive animation/movement with these screen modes?
Yes, definitely. ;)
Some of the games linked to above also used these modes during dynamic screens. HAM games:
EHB games:
