Ham mode

[ImmortalA1000]

Originally Posted by Samurai_Crow

HAM mode was not as useful compared to Copper shaded gradients. 32 or even 16 colors per row of pixels could already be stretched to a hundred or so, just by using different color values for some palette entries during different parts of the screen redraw.

Which is the way Universe does so many colours on Amiga, it's not HAM as some suggested.

The best games always made the best use of everything available to them, which is why Shadow of the Beast on an A1000 is so amazing on that start level.

There is a place for HAM games though I think, it's as technical a challenge for an artist as doing the graphics for C64 Law of the West was for Mimi Dogget, graphics which no other 8bit machine could ever come close to either.

[albino]

Originally Posted by ImmortalA1000

Which is the way Universe does so many colours on Amiga, it's not HAM as some suggested.

The best games always made the best use of everything available to them, which is why Shadow of the Beast on an A1000 is so amazing on that start level.

With HAM we are talking over 4000 colours....it's another level

[Megalomaniac]

HAM might have been usable for some styles of game, as implied by REMZ, but I doubt anyone could do something like Kang Fu to any quality with it, even if you had the other advantages of the A1200 such as 2Mb chip RAM and an 020. In terms of easy usability AGA was much better suited to making games with more than 64 colours (and even EHB has its limitations, most of the games made using it aren't reliant on really fast scrolling)

[Karlos]

While technically interesting, artistically Kang Fu was a bit eye stabbing. It might've been better if the backgrounds had been blurred a little.

[Karlos]

Originally Posted by albino

With HAM we are talking over 4000 colours....it's another level

Don't forget the first generation of chunky coppersceen games. While not HAM, Alien Breed 3D 1 runs in 12-bit RGB colour.

[d4rk3lf]

Originally Posted by albino

With HAM we are talking over 4000 colours....it's another level

It's not that much of a difference, as you might think.
Take some image in Photoshop, convert it to 4096 colors, then convert it to 128 or even 64 colors (or even 32 colors), and you will see it's not a difference you might be expecting, especially in the low/res images.

Gradients are most noticeable difference you will see.

Don't get me wrong. Ham is great, and I love the fact it's a unique ability on our beloved Amiga. It's just, I don't think a fantastic looking games like Elfmania, Simon the sorcerer, Pang.. etc.. would look much better (and visually much richer) with Ham.

[Megalomaniac]

Besides, the sheer memory and processor overheads required by HAM would limit what you could do on the gameplay side. I'm not convinced that the A500's more versatile standard modes were ever pushed to their limits (could you do fast scrolling action games in EHB, beyond Desert Strike?), and AGA certainly wasn't. I suspect the way HAM assigns colours, and the resultant limitations on what can happen when multiple things are moving, would mean you could do a better scrolling shooter or platformer with a standard A1200 in AGA than with even a 32Mb 75Mhz 060 in HAM.

[khph_re]

Originally Posted by Megalomaniac

Besides, the sheer memory and processor overheads required by HAM would limit what you could do on the gameplay side. I'm not convinced that the A500's more versatile standard modes were ever pushed to their limits (could you do fast scrolling action games in EHB, beyond Desert Strike?), and AGA certainly wasn't. I suspect the way HAM assigns colours, and the resultant limitations on what can happen when multiple things are moving, would mean you could do a better scrolling shooter or platformer with a standard A1200 in AGA than with even a 32Mb 75Mhz 060 in HAM.

I agree about the limitations, I think turn based, single or flick screen would be more suitable. Perhaps Point and clicks or strategy games.

Concerning memory and processor overheads, isn't it the same speed mem usage as EHB?

[Samurai_Crow]

Originally Posted by khph_re

I agree about the limitations, I think turn based, single or flick screen would be more suitable. Perhaps Point and clicks or strategy games.



Concerning memory and processor overheads, isn't it the same speed mem usage as EHB?

It uses all 6 bitplanes, so yes.

[saimo]

@coder76

Originally Posted by coder76

A platformer using HAM8 has been made for A1200/A4000/CD32. It has two scrolling layers and updates screen at 50 Hz in hires. There are some bugs though in the objects, if they overlap each other, there is some flickering. But nothing related to HAM problems.

So the extra hardware needed is AGA.

[ Show youtube player ]

I think that HAM fringing problems do not show because the game does not use HAM for the in-game graphics - by looking at the screenshots and at the video, I'd say it uses double playfield and HIRES.

[coder76]

Originally Posted by saimo

@coder76

I think that HAM fringing problems do not show because the game does not use HAM for the in-game graphics - by looking at the screenshots and at the video, I'd say it uses double playfield and HIRES.

Yes, I think you're right. The game is advertised to use dualplayfield+HAM though and over 1000 colors.
https://www.angelfire.com/amiga/greed/specs.html

The game is nowhere available to download, but I was able to find a png screenshot of first level, it has only around 230 colors. Most of them come from copper sky gradient most likely, and also more from sprites. A color reduction to just 32 colors will produce a visible reduction of image quality.

So maybe HAM mode was used only in still images and intro in the game. Pretty good use of colors and copper for background layer, if it’s only 16+16 dualplayfield, fooled at least me. But it might be that hires mode makes it look a lot better than usual lores mode.

[saimo]

Originally Posted by coder76

Yes, I think you're right. The game is advertised to use dualplayfield+HAM though and over 1000 colors.
https://www.angelfire.com/amiga/greed/specs.html

The game is nowhere available to download, but I was able to find a png screenshot of first level, it has only around 230 colors. Most of them come from copper sky gradient most likely, and also more from sprites. A color reduction to just 32 colors will produce a visible reduction of image quality.

So maybe HAM mode was used only in still images and intro in the game. Pretty good use of colors and copper for background layer, if it’s only 16+16 dualplayfield, fooled at least me. But it might be that hires mode makes it look a lot better than usual lores mode.

I've had a closer look at the screenshots. The foreground is definitely in 15+1 colors and the backgrounds, Copper aside, definitely include several tens of colors. I guess that HAM8 and DP can mix - without making tests (I can't afford them now), maybe they work like this:
* when the front playfield is transparent, HAM8 works as normal;
* when the front playfield is opaque, DP works as normal.
In the first case, the 4 most significant bits are 0, so the resulting colors should be somewhat dark and/or saturated, with minor variation coming from the lower 2 bits. The screenshots only partly seem to confirm this. I'd say it needs to be investigated. Maybe things work a bit differently (e.g. like HAM6 + DP on OCS/ECS).

[albino]

Thanks for all the replies,but i'm still wandering if an extra chip inside an cd rom addon would have boost the HAM mode witch i'm sure is a misoportunity for an1985 hardware.

[Samurai_Crow]

HAM mode wasn't very useful without wide or numerous sprites. If you wanted to add Fast RAM and a higher clocked 68000 to the A570, it would have freed up more speed on the CPU.

The ECS chipset that was standard on the CDTV and required for the A570 had plenty of features including horizontal sprite muxing using the Copper coprocessor. The problem with overusing the Copper to do that is that it ties up all the bandwidth on the chip bus leaving ZERO bandwidth for the CPU. Fast RAM is the solution for bandwith bottlenecks.

[Karlos]

Originally Posted by saimo

I've had a closer look at the screenshots. The foreground is definitely in 15+1 colors and the backgrounds, Copper aside, definitely include several tens of colors. I guess that HAM8 and DP can mix - without making tests (I can't afford them now), maybe they work like this:
* when the front playfield is transparent, HAM8 works as normal;
* when the front playfield is opaque, DP works as normal.
In the first case, the 4 most significant bits are 0, so the resulting colors should be somewhat dark and/or saturated, with minor variation coming from the lower 2 bits. The screenshots only partly seem to confirm this. I'd say it needs to be investigated. Maybe things work a bit differently (e.g. like HAM6 + DP on OCS/ECS).

Is it possible there's fewer than 256 colours in the screenshots because they've been reduced to 8-bit PNG? Probably better to take screenshots in an emulator and check the unique colours in there.

[Karlos]

As technically accomplished as Kang Fu is, it's also utterly bonkers and visually incompressible in places. It does make you wonder what could be achieved with the engine and some proper designers and artists though.

[TCD]

Originally Posted by Karlos

As technically accomplished as Kang Fu is, it's also utterly bonkers and visually incompressible in places. It does make you wonder what could be achieved with the engine and some proper designers and artists though.

I don't know what you mean:


It must be that they had a lot of placeholders in place and at one point just released the game as it was. I still marvel at the fact that there are four graphic artists listed in the credits...

[chb]

Originally Posted by saimo

I've had a closer look at the screenshots. The foreground is definitely in 15+1 colors and the backgrounds, Copper aside, definitely include several tens of colors. I guess that HAM8 and DP can mix - without making tests (I can't afford them now), maybe they work like this:
* when the front playfield is transparent, HAM8 works as normal;
* when the front playfield is opaque, DP works as normal.
In the first case, the 4 most significant bits are 0, so the resulting colors should be somewhat dark and/or saturated, with minor variation coming from the lower 2 bits. The screenshots only partly seem to confirm this. I'd say it needs to be investigated. Maybe things work a bit differently (e.g. like HAM6 + DP on OCS/ECS).

On OCS/ECS at least HAM and DP can mix, Tony wrote about it in the undocumented amiga hardware thread. No idea if it works on AGA, and there's a demo of Kang Fu on Aminet that does not mention HAM, only hires in the documentation.

OTOH, it's from the creators of the Professional File System, they clearly state on the website that it uses HAM, and I guess they knew their stuff (well, at least the technical side).

[saimo]

Originally Posted by albino

Thanks for all the replies,but i'm still wandering if an extra chip inside an cd rom addon would have boost the HAM mode witch i'm sure is a misoportunity for an1985 hardware.

There's an underlying thought which is just wrong: more colors -> better graphics. (There is a lot to say about it, but I can't do it now - actually, I shouldn't be even writing here.) Thousands of colors help with calculated/wired graphics, but are useless for pixelled graphics. Had HAM been more usable, the Amiga would have been flooded with tons of games with horrible wired (like Kang Fu's) and/or pre-rendered graphics.

[Karlos]

If HAM was implemented along the lines of Jay Miners original vision, it may have been useful for polygons. I believe that vision was that it would be the brightness and saturation that you could vary. Varying the brightness would allow for smooth Gouraud shading horizontally and being able to change the saturation would allow for specular highlighting.