25 July 2024, 22:59 | #1 |
Registered User
Join Date: Oct 2006
Location: USA
Posts: 1,067
|
Perfect fade out (24bit) on Amiga 1200
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. |
26 July 2024, 00:21 | #2 |
Registered User
Join Date: Oct 2022
Location: Roma
Posts: 374
|
What are you even talking about? The colors don't matter at all...
|
26 July 2024, 00:26 | #3 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,918
|
|
26 July 2024, 08:56 | #4 |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,642
|
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) Last edited by alexh; 26 July 2024 at 09:02. |
26 July 2024, 22:17 | #5 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,919
|
You can increase perceived numbers of levels by applying temporal dithering - this assume of course some time required to average perceived level.
|
26 July 2024, 23:29 | #6 |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,642
|
Does that work with fades? I imagine fading to black it flickers even more?
|
27 July 2024, 01:18 | #7 |
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 549
|
Take a look at this (OCS) intro: http://dekadence64.org/dkd-twce.lha
|
27 July 2024, 11:59 | #8 |
Registered User
Join Date: May 2023
Location: essex
Posts: 637
|
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.
|
27 July 2024, 12:21 | #9 | |
Registered User
Join Date: May 2018
Location: Ireland
Posts: 725
|
Quote:
|
|
27 July 2024, 13:10 | #10 |
Registered User
Join Date: May 2023
Location: essex
Posts: 637
|
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
|
27 July 2024, 14:05 | #11 | |
Registered User
Join Date: May 2018
Location: Ireland
Posts: 725
|
Quote:
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. |
|
27 July 2024, 16:15 | #12 |
Registered User
Join Date: May 2023
Location: essex
Posts: 637
|
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 |
27 July 2024, 17:32 | #13 | |
Registered User
Join Date: May 2022
Location: Canada
Posts: 149
|
Quote:
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.) |
|
27 July 2024, 22:13 | #14 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,919
|
Why not? fade take some time so you can average perceived level with altering CLUT - for fast fades usually 4 bit per component is not significant limitation - eye is too slow anyway, for slow fades where you can easily distinguish between 4 bit component values temporal dithering may add quality. Smaller quantization level = less perceived flicker for ST or even less bit depth flickering may be indeed severe but Amiga 4 bit is not bad - 5 bit is in many cases OKeish so you have per 50fps flickering 25Hz but between two nearest quantization levels (1/16)...
|
29 July 2024, 01:36 | #15 |
Registered User
Join Date: May 2023
Location: essex
Posts: 637
|
CRTs are quite forgiving but I think 2x2 frames 50th/60ths of a second is the fastest I would use and a max of +/- 1 for the RGB values myself.
|
29 July 2024, 23:08 | #16 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,919
|
Quote:
Key to less perceived flicker is to use lowest possible delta - normally 4 bit with temporal 1:1 will give 5 bit almost fine, 6 bit is in normal conditions just fine...anything more i would not take a risk... |
|
01 August 2024, 05:32 | #17 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,678
|
How did scala achieved its own superimpose? THAT was terrific
|
02 August 2024, 20:40 | #18 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,758
|
Definitely don't modify bitmaps to fade. Or I should say this only works with a few special subset palettes. You must do it for HAM pictures.
HAM fade can work, but requires setting up a special case for the picture, or prerendering some frames of the bitplanes. If PCHG dither is ever implemented, it can work by HAMLab's way of picking colors per scanline. 12-bit fade will always be choppy with the dark colors. You can achieve smoothness in pictures containing dark colors by fading out quickly... Dithering works best for still (non-fading) images. If you ever fade a picture with dithered colors, you will end up with uneven boundaries between steps where the same RGB value is repeated twice, which is a big no-no. These are my tips from quite a lot of work with this. and yes AGA fades smoothly, that's excellent and a great benefit of the chipset |
03 August 2024, 00:44 | #19 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,919
|
Technically to get smooth perceived change you need to perform fade in linear space and convert this to gamma corrected space, temporal dithering may help on this (but probably you need precalculate values anyway).
|
04 August 2024, 06:47 | #20 |
Registered User
Join Date: Oct 2006
Location: USA
Posts: 1,067
|
Say I have a perfectly red screen and want to fade it perfectly and slowly to black over time over several seconds. On OCS/ECS I can only do this in sixteen steps because there are only 16 values of Red to choose from, given that G and B are zero, unless I introduce dithering or flickering. On AGA I can do this in 256 steps.
It is a huge difference. Some AGA games do this kind of fade and it shows like I said for example in the Jurassic Park AGA title screen fades. You can immediately tell the fade out is so much smoother than anything ever seen on A500. The Amiga 500 palette is just super limited with only 16 values for RGB each (4096 color choices only), while AGA palettes can be constructed from 256 choices for RGB each (16.7 million color choices). It is a benefit of the AGA chipset I don’t often think about, but definitely an important benefit. On AGA, artists can choose their colors out of a pool of 16.7 million color choices. On OCS/ECS they can only choose out of a pool of 4096 color choices. 4096 colors might sound like a lot, but it only contains 16 shades of pure red for example. So it is not as much as one might think. Last edited by rsn8887; 04 August 2024 at 07:01. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
24bit Addressing | Seiya | support.WinUAE | 16 | 06 June 2021 16:15 |
Fade between palettes | MickGyver | Coders. Blitz Basic | 11 | 01 February 2020 17:42 |
Blink vs Fade | emufan | Coders. C/C++ | 4 | 06 August 2017 15:25 |
HAM without 24bit screen | killergorilla | support.Apps | 5 | 20 October 2006 21:55 |
Fade to Black - PC | Galahad/FLT | Retrogaming General Discussion | 12 | 25 July 2002 18:15 |
|
|