HAM scrolling

[TEG]

I was wondering, do we have a game or a demo showing HAM scrolling ?


Thanks in advance.

[fryguy]

Maybe Pioneer Plague http://hol.abime.net/1068 but the background doesn't seem to have many colors.

[TEG]

To clarify what I'm searching for, it is full screen HAM scrolling.

I found some HAM text scrolling but no full screen. And yes, Pioneer is not convincing.

[Gorf]

Originally Posted by TEG

I was wondering, do we have a game or a demo showing HAM scrolling ?

How about Kang Fu?

[ Show youtube player ]

[Solo Kazuki]

Olo Fight

[ Show youtube player ]

[Gorf]

Originally Posted by Solo Kazuki

Olo Fight

looks more like a static (non scrolling) HAM background

[Solo Kazuki]

All game is in HAM, And far background is also scrolling (but a little).

Some more

[ Show youtube player ]

[dodke]

Olo Fight does not look like it's HAM at all, how did you come up with that? It's AGA so possibly 256 colours which is plenty.

[TEG]

At least Kang Fu show it's technically possible. I forgot about this game. Thanks.

But we can see that the result of objects with few colours on a background with a lot of colours is not very graceful :-/

We can see too, that picture with gradient is used to minimized HAM artefacts.

And using blobs would create a lot artefacts. Do you think using sprites as a mask to hide blob artefacts would be doable ?

[Solo Kazuki]

What? It looks very HAMish because HAM artifacts are visible and game has over 3000 colours on screen NOT 256.

http://aminet.net/package.php?packag...o/OloFight.lha

The game uses a lot of colours, more than is usually available on an AGA screen (early previews made claims of using the HAM-8 mode with 262 144 colours, which would be a world first)

https://www.mobygames.com/game/olofight

[StingRay]

Bplcon0 is set to $0211 in Olo Fight so no HAM used at all.

[britelite]

Originally Posted by StingRay

Bplcon0 is set to $0211 in Olo Fight so no HAM used at all.

...but, but it has over 3000 colors on screen!

[chb]

AFAIK in Pioneer Plague the background solely consists of the 16 palette colors HAM6 mode offers, and modified colors are only used in the BOBs. Bill Williams used this scheme to avoid fringing both from scrolling and object plotting - you do not need any special handling compared to normal modes, just let your BOBs always start with a palette color on the left edge and you are fine.

Horizontal HAM scrolling is tricky because of fringing on the left screen edge. You might start a line with a modified color that changes a color that wasn't shown before, resulting in a modified background color instead until a palette color is displayed. One way to avoid this is preparing your image so that there's never more than e.g. 16 pix horizontally between two pixels with palette color (it doesn't have to be regularly every 16th pixel), and covering 16 pixels on the left edge with a sprite in background color. However, I do not know of any HAM converter which has an option for such an format.

[TEG]

Originally Posted by chb

Horizontal HAM scrolling is tricky because of fringing on the left screen edge. You might start a line with a modified color that changes a color that wasn't shown before, resulting in a modified background color instead until a palette color is displayed.

I made a quick test with Amos and I can confirm that the result is worst than expected. I mean, the number of horizontal pixels impacted, for the start of one single line, is more important than expected. I get very ungraceful green artefacts. I will try to see if I can change faulty pixels to palette ones on the fly.

[ross]

First idea that came to my mind.
Use only 15 base colors for the image (ADPro allows it, from 0 to 14).
Set the color 15 on each line with the copper so that is the first pixel and the one that allows the next to be right (logically it must be calculated for each line).
Eventually cover this first pixel with a sprite.
No more fringes

[chb]

@ross: That's a very nice idea, however determining the first visible pixel's RGB value could be quite costly - depending on the picture and the scroll value you will need to parse a lot of pixels to its left, in an not-so-convenient planar HAM format. That might not be doable for a 50 Hz scroll. One way to get around this is storing the picture* in 12 bit chunky in a separate buffer so you can directly look up its RGB value. Needs quite a bit of memory, but it does not need to be in chip RAM.

EDIT: I think you do not need to cover the first pixel with a sprite - if you set it to the RGB value it would have in the unscrolled image, it and all the following pixels will have correct color. But I think you'd need the blitter to make the first pixel color 15 on every line? Or changing background color (color 0) and covering the artifact with a sprite?

*actually only the pixels that can be scrolled to xpos = 0 (first pixel)

[TEG]

Yes, this my idea too: to recalculate the first pixel and see the feasibility. Precalculated method you proposed Chb, is interesting too.

In fact, when I started the thread, I forgot that in HAM mode, a whole line can depend of the first pixel of this line. I was in the idea it was only true for 8 pixels or so (HAM is far away in my memory). And so the sprite trick is useless.
So I will maintain a precalculated set of data representing the x+1 column of pixels which approximated the real ones by using the palette ones and apply it to the image, after the image was scrolled by one pixel to the left.

Do someone know what algorithm I can use to take the most appropriated pixel from a 16 colours palette when coming from a potential 4096 colours pixel?

[chb]

Originally Posted by TEG

So I will maintain a precalculated set of data representing the x+1 column of pixels which approximated the real ones by using the palette ones and apply it to the image, after the image was scrolled by one pixel to the left.

Do someone know what algorithm I can use to take the most appropriated pixel from a 16 colours palette when coming from a potential 4096 colours pixel?

For color difference: You could simply calculate the square of the Euclidean difference (R1-R2)**2 + (G1-G2)**2 + (B1-B2)**2, maybe with a higher weight for green to incorporate the sensitivity of the human eye. Or if you need better results, the standard CIE _Delta E (which probably is overkill for your purpose). Be aware, however, that the HAM palette colors may be a very bad match for a lot of your image colors - the ham palette does not need to represent the image colors, it needs to be a good base for modification. This depends on your picture (and converter). I think the approach Ross proposed is more powerful and not much more complicated, the only downside being the loss of one color.

[TEG]

Thanks Chb, help appreciated.

If I understand well what Ross proposed, is to convert the image to a 15 colours picture as a simple method to precalculate the colour of the pixels that will need to be modified. Is it that?

[ross]

Ok, my idea in full.
You can avoid heavy calculation making a 'partial' pre-calculated 12bit RGB chunky for the pixel color 15, to store in copper every line (if you store this in chip ram you can use the blitter to fill the copper, else CPU).
Partial because only the left scrolled part need to be stored.

Bitplanes for the HAM image in consecutive planar memory region, and not interleaved.
This to fill the first pixel with only two blitter pass:
- first pass for the 00 on mode selection bits/planes (op. D=A&B, B=$7FFF)*
- second pass for the 1111 on CLUT planes (color 15) (op. D=A|B, B=$8000)*

And yes, with the proper RGB you do not need sprite cover

EDIT: *mask is dynamic logically, this is only an example for the MSB bit