We had already spoken in some detail about the Amiga’s HAM mode in an article a few months ago (sorry, it’s in Italian. But you can easily translate it with DeepL, Bing, Google, etc.), dissecting (especially from a technical point of view) all the problems that beset it and, therefore, the reasons why it was rarely used, relegating it mostly to displaying static images or movies/animations.
Spirits were, however, rekindled again when, in a thread of the largest portal dedicated to the Amiga, a video of a demo in HAM was published, by the same author of the game Hamulet (which was the subject of the previous article on the subject), who showed other visual marvels:
The demo is certainly spectacular, because there is a lot of moving stuff on the screen (with a remarkable fluidity!) and everything is extremely colourful (as expected from the HAM, which allows to display up to 4096 colours compared to the maximum 64 allowed by an Amiga OCS/ECS).
It’s fair to wonder, at this point, if something has changed since the previous article that talked about Hamulet’s graphics engine and the suggestive impact that its graphics had on the minds of those who enjoyed the video with the game demo in action.
So many animations… “static”!
The thing that immediately jumps out at you is, precisely, the amount of moving objects: many, even large ones, and obviously full of colour. Technically, however, nothing has changed: the limitations of HAM that were meticulously analysed earlier are all there.
In fact, what should not be misleading is precisely the presence of the multitude of stuff moving around in different parts of the screen, which might make one think otherwise, while in reality they are still “static” parts, and more precisely background animations.
They are not, therefore, objects able to move freely like any sprite or BOB (Blitter OBject: similar to sprites, but realised using the Amiga’s graphic coprocessor par excellence: the Blitter!), but are constrained to precise positions (horizontals which are multiples of 16, to be even more precise, since graphics data on Amiga OCS/ECS are always aligned at 16 bits/pixels).
An example that clarifies the concept is the “green monster” that remains firmly in the same position on the screen, despite being thrown into a wild run:
It should flow horizontally, if it moved naturally, instead of remaining fixed in the same place. Instead it always occupies the same position, although its movements indicate that it should do otherwise.
So it is, as already mentioned, a background animation, and these have no particular problems (but if they were to take up too much space to be stored in the “Chip” memory one would have to resort to the so-called “Fast” memory, forcing the CPU to take over their display), apart, of course, from the graphical artefacts that appear when using this particular video mode of the Amiga.
The shortcomings of HAM
An example of this can be seen in the van that was taken directly from the Metal Slug 3 assets:
On the surface, it looks very colourful, but this is also and above all due to the aforementioned artefacts. This can best be seen by taking the original that was extracted from the ROMs of the game:
Apart from the fact that the graphics of the screenshot taken from the demo are much smoother (due to compression performed by YouTube), comparing the two subjects it immediately jumps out at you how the first is infested with copious variations on green (non-existent in the original), accompanied by sporadic speckles tending towards orange, and finally with the classic “streaking” that can be seen in the second flame (on the right, with several lines in green. Some also visible on the front of the vehicle).
These are, of course, the effects of the colour transitions that occur in HAM mode when, passing from one pixel to the next, the required colour is not available among the 16 of the basic/fixed palette and one must, therefore, change one of the three colour components (red, green, or blue) to try to get closer to it.
This is familiar stuff for those who know how this mode works, but needs to be clarified for the uninitiated, who may think that the 4096 of the entire colour palette made available by the Amiga can actually be used freely on the screen.
In reality, there are 16 basic colours, and all others are “derived” by changing one colour component at a time. So if a certain colour is not available, it will take up to three successive passes (one per component to be changed) in three horizontally adjacent pixels to finally have it.
Having to share the 16 basic colours with all the pixels of the screen, one can well understand where the graphic artefacts of this mode come from: one cannot please all pixels, but has to “mediate” in order to obtain the best possible compromise (which means choosing the 16 fixed colours so as to minimise colour transitions).
The example of the van fits like a glove, also because the original is not rich in colours at all: far from it! In fact, only 15 are used (one, magenta, is used to “puncture” the graphics and display the background), as is typical of Neo Geo games (and many other consoles of the time).
Few colours then, and many quite homogeneous (military green for the vehicle and orange/yellow for the flames), but which are sufficient to show the visual artefacts that are introduced by the HAM mode when it has to render the van graphics.
The other/high price to pay: space
The result, however, is not bad at all, let’s be clear, but precisely because we are talking about fixed animations (objects that in reality do not have full freedom of movement, as has already been amply illustrated), which can (and must!) be pre-calculated in order to reduce artefacts as much as possible (which, instead, would be far more visible if graphics were drawn arbitrarily on the screen, as is usually the case in games that do not use HAM).
And it is precisely because we are dealing with pre-calculated stuff that another major flaw/limit arising from the use of HAM mode comes to light: space. In fact, a lot of it is needed to contain the one of these animations, since it is necessary to store the entire rectangular area (always in horizontal multiples of 16 pixels/bits) enclosing the animated part.
This is not quite clear at first glance, because you have to think about the fundamental elements on which the graphics of a game are based: the tile and the sprites (and also the BOBs for the Amiga). The concept they have in common is that of the reuse of graphics, precisely with a view to saving precious (especially for that era: 1980s-1990s) memory, using the tiles to “compose” the background graphics and the sprites for the (generally) freely moving objects.
Now try to imagine the “green monster” mentioned above that, instead of remaining in a fixed position, moves horizontally. Let’s say its animation consists of 8 cyclically repeating frames and it moves horizontally by a certain number of pixels.
If a BOB were used to render it on the screen (sprites cannot be used because they are busy for other objects), the space required in memory for its graphics would always be the same (to simplify: 8 times the space occupied by the rectangular region enclosing it). This is because each time it is sufficient to trace the graphics of the current frame to the new screen position.
In HAM mode, however, this would generate a lot of visual artefacts, so to emulate what was achieved in the demo it would be necessary to pre-calculate all the graphics in question so as to fit the monster’s graphics with the background, smoothing the transition points from the monster’s graphics to the background, and vice versa (an operation that was done for all the animations in the new demo).
Once the rectangular blocks with the monster + background graphics merged together had been obtained, all that was needed was to copy them to the appropriate position on the screen (always in horizontal multiples of 16 pixels/bits) where they were to be displayed, and that was it!
All very simple, but the space problem arises if the object is to be moved to, say, 32 different positions on the screen. In this case, it will be necessary to repeat the operation of “merging” the 8 frames of the monster with the graphics of the 32 different positions in which they are to be displayed. Requiring, therefore, as many as 32 times the space of one frame against the 8 that would normally be needed with a BOB.
It is, in essence, a matter of generating and then using new graphics every time there is a position to be covered on the screen by a given object. This is still manageable as long as the objects are not many and the positions they cover are also few (because their movements are very fast, for example), but otherwise the space required rises too quickly, as can be seen.
Overlapping graphics and freedom of movement
The situation is exacerbated if one has to deal with objects that may also overlap each other. Again, making them coincide with precise screen positions would not be a big problem, as it would fall under the discussion above.
If, however, the movements of the two objects are not perfectly cadenced/synchronised and, therefore, may occasionally meet, then graphics would have to be generated for every possible combination between them, literally causing memory consumption to explode.
Which leads, finally, to the reason why it is literally impossible to think of being able to use BOBs for objects that can move freely on the screen (e.g. characters): one would have to memorise the graphics resulting from the combination of every animation of the object with every position in which it can be displayed!
Just take one of the bosses in Metal Slug 3 that has more freedom of movement to realise this:
Imagine having to “merge” its graphics with those of the background in all the positions it can be found in, combined with all the frames of the animations it has been equipped with, and you can already see how the space required would explode, requiring a hard disk or CD-ROM for the game!
Conclusions
Coming back down to earth again, there is no doubt that the work done with the new demo is valuable and worthy of admiration, but it remains a fairly isolated case as well as being suited to the type of game for which its graphics engine was made.
Nothing generalisable, in short, although it is certainly possible to use it in other HAM games where the following requirements can (and should) be met:
- use of sprites for all objects that move (fairly) freely;
- use of pre-calculated graphics to simulate moving objects at specific positions on the screen (the classic predefined animations) — subject to available space.
Otherwise, it is a good idea to switch off immediately, as the HAM mode brings with it inherent problems that cannot be overcome, and daydreamers should get over it once and for all…
