Perfect fade out (24bit) on Amiga 1200

[rsn8887]

Some games have these perfect 24-bit fade outs, for example in Jurassic Park AGA the credit images after the Ocean logo.

I don't understand anymore why the Amiga 500 couldn't do such perfect 24 bit fade outs. Is there a technical reason? Does the AGA chipset allow for more fine-grained RGB values somehow?

EDIT: I got it. The Amiga 500 could select colors out of 4096, the Amiga 1200 could select colors out of 16.7 million.

[Cris1997XX]

What are you even talking about? The colors don't matter at all...

[Karlos]

Originally Posted by Cris1997XX

What are you even talking about? The colors don't matter at all...

Well, the precision matters. With AGA, you get 256 steps from white to black. Otherwise you get 16. That's the differentiating factor.

[alexh]

OCS/ECS has 12-bit pallet registers giving 4096 colours
AGA has 24-bit pallet registers giving 16 million colours.

OCS/ECS can use 6 bitplanes (64/4096 colours per screen)

AGA can use 8 bitplanes (256/16M colours per screen)

[pandy71]

You can increase perceived numbers of levels by applying temporal dithering - this assume of course some time required to average perceived level.

[alexh]

Does that work with fades? I imagine fading to black it flickers even more?

[hitchhikr]

Take a look at this (OCS) intro: http://dekadence64.org/dkd-twce.lha

[CCCP alert]

I don't know if there are any palette interlacing apps for OCS like with C64 iFLI and Atari ST Quantum Paint tools. This wouldn't help for fades but if you only change RGB values by 1 between the 2 colours you would get a significant increase in perceived colours on a good CRT. Good luck using it in HAM but for PCHG images it would be fine.

[lmimmfn]

Originally Posted by CCCP alert

I don't know if there are any palette interlacing apps for OCS like with C64 iFLI and Atari ST Quantum Paint tools. This wouldn't help for fades but if you only change RGB values by 1 between the 2 colours you would get a significant increase in perceived colours on a good CRT. Good luck using it in HAM but for PCHG images it would be fine.

If im understanding you correctly, HAM would be fine as would be fading per interleaved full lines so wouldn't artifact

[CCCP alert]

Originally Posted by lmimmfn

If im understanding you correctly, HAM would be fine as would be fading per interleaved full lines so wouldn't artifact

I am thinking of palette interlacing so every alternate field you would swap between say RGB 1:1:15 and 2:2:15 to simulate a 13bit palette. For indexed colours it works fine but not sure about the HAM6 colours and how you would do this to prevent fringing. EHB and a palette swap every 50/60fps and a new palette definition every scanline would give you potential worth pursuing, don't fancy the quantising maths to render down a 24bit PNG of today though. Maybe the author of JAVA HAMconvert would be interested

[lmimmfn]

Originally Posted by CCCP alert

I am thinking of palette interlacing so every alternate field you would swap between say RGB 1:1:15 and 2:2:15 to simulate a 13bit palette. For indexed colours it works fine but not sure about the HAM6 colours and how you would do this to prevent fringing. EHB and a palette swap every 50/60fps and a new palette definition every scanline would give you potential worth pursuing, don't fancy the quantising maths to render down a 24bit PNG of today though. Maybe the author of JAVA HAMconvert would be interested

Is it not the case that you would need twice the number of bitplanes as colours shown to achieve this effect?, e.g. 16 colour image, even lines using entries 0-15(original pic colours) and odd lines using 16-31(slightly darkened).

Of course the copper could be used to change the palette every line and would be close to maxing DMA much the same as that HiTek hires mode.

Fading can be done in HAM, there are a few demo's but looks like it needs bits for the non base 16 colours so probably can't have the copper changing the palette every other line due to dma bottleneck.

It's an interesting idea, would be cool to see if it makes a fade smoother.

Another effect used would be a double buffer images, frame 1 with higher intensity colours, the 2nd with lower intensity colours, show frame 1 for 100 ms, swap between 1 and 2 continuously for 100ms, then frame 2 only for 100 ms etc.

That swapping between colours very quickly was used in 8 bit games to create additional colours, I think dragon breed C64 was one of them(had dragon in the name of the game if not that one) to create a golden colour for a dragon.

[CCCP alert]

You would just swap between two colours every 50/60hz for each palette colour, and if you change the palettes every scanline too you would get some cool images. I don't personally use it on the ST or C64 but apart from some RAM and CPU/Copper time the biggest problem is writing the routines to calculate the extra colour shades to fit the technical limitations of which 32/16 colours per scanline you might want, like for a graduated sky etc. HAMconvert does some awesome data processing using modern CPUs of today, that is really the problem. Anything Quantum Paint on the STFM did with CPU/Shifter is going to be a walk in the park for even an A1000 but the results are only as good as the data processing of source images.

More for static images, maybe if the fade is like 2 or 4 frames displayed between changes to palette colours displayed but ideally just as something like Qauntum Paint for STFM picture files

[remz]

Originally Posted by lmimmfn

Fading can be done in HAM, there are a few demo's but looks like it needs bits for the non base 16 colours so probably can't have the copper changing the palette every other line due to dma bottleneck.

I implemented fullscreen fade in/fade out in HAM in Hamulet which you can see in the intro: [ Show youtube player ]
As you say, it implies the blitter because just changing the palette would not be enough in HAM. In order to make the speed reasonnable on A500/OCS, I fade every other scanline, and alternate each frame. Instead of 16 steps, it approximates a 32 step fade. It is not perfect but the illusion works.
(Interesting fact: the color palette is not modified during the fades, and the copper is not doing anything. The cpu and blitter are doing the math.)