Has any scener attempted a HAM6/8 fade in/out?

[Foebane]

Most Amiga demos that use HAM6 or HAM8 never ever fade the pictures in and out, even on high-end machines like 68060. I'm sure it's possible to do so, and quite efficiently and effectively, but I can't for the life of me code such stuff myself.

So come on, Sceners, how would you go about taking a HAM picture and fading it in from black and back to black, like a normal palette fade? Or show us examples if you've already done so.

[ross]

Originally Posted by Foebane

Most Amiga demos that use HAM6 or HAM8 never ever fade the pictures in and out, even on high-end machines like 68060. I'm sure it's possible to do so, and quite efficiently and effectively, but I can't for the life of me code such stuff myself.

So come on, Sceners, how would you go about taking a HAM picture and fading it in from black and back to black, like a normal palette fade? Or show us examples if you've already done so.

I'm pretty sure the HAM6 fade was done (using blitter for subtractive operations in data planes).
I don't know for HAM8 but it's technically possible in the same manner.

But it's not trivial.
So, you can try to do it, should be an interesting exercise

[robinsonb5]

Yes, fading out is possible - and can look quite nice. I suspect in HAM8 it would be a bit slow, though. Here's a HAM6 example (using AMOSPro of all things!) I'm pretty sure there was an extension for AMOS that could do something similar, but this demo does it without extensions.
http://retroramblings.net/?p=25

I daresay fading in could be done, but it would be trickier.

[Foebane]

Originally Posted by robinsonb5

I daresay fading in could be done, but it would be trickier.

I know what you mean: with fading out, all the code has to do is to reduce the R, G and B values by one until they are 0 and keep them there, so that code is simple. However, with fading in, there would need to be a copy of the final image in memory so the routine would know when to stop increasing the RGB values by one. I guess I never thought of that before.

[ross]

Originally Posted by Foebane

I know what you mean: with fading out, all the code has to do is to reduce the R, G and B values by one until they are 0 and keep them there, so that code is simple. However, with fading in, there would need to be a copy of the final image in memory so the routine would know when to stop increasing the RGB values by one. I guess I never thought of that before.

Nope
A proper fade works like this:
http://eab.abime.net/showthread.php?t=86561

[dodke]

Although it's not a proper fade I've found on OCS fading to black by subtracting 1-15 from the original components to me at least looks better because the components are so inaccurate. For a slower fade I tend to change green in one frame and red and blue in the next.

On OCS doing multiple full screen blitter operations while 6 bitplanes are active would be quite slow but you could always try it.

I had a simple fade swipe in this demo for a few ham6 images:
http://www.pouet.net/prod.php?which=65364

It simply uses a grey scale palette and shifts the image data excluding control bits to lower bitplanes with some line dithering.

On AGA there are obviously many demos that fade effects and images in the resolution they use for effects. For higher resolution images ham isn't really that necessary since 256 colours with dithering can look fine at hires interlaced.

[ross]

In fact, considering the OCS colors space granularity, you are right