English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 22 March 2020, 09:12   #1
TroyWilkins
Registered User

TroyWilkins's Avatar
 
Join Date: Jan 2015
Location: Tasmania, Australia
Posts: 445
More then 4096 colours on OCS/ECS possible?

I know that technically it isn't possible, but I know that a technique has been used where they rapidly cycled between 2 of the "normal" colours, and because of persistence of vision, another colour appears to be on the screen which is a mix of the 2 colours.

While I don't think that this technique could be used in HAM mode, could it be used in say 16 colour mode to simulate colours that aren't possible with the 12-bit colour pallette on OCS/ECS, or am I overlooking something obvious, in which case, I apologise.
TroyWilkins is offline  
Old 22 March 2020, 11:13   #2
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 688
Quote:
Originally Posted by TroyWilkins View Post
While I don't think that this technique could be used in HAM mode, could it be used in say 16 colour mode to simulate colours that aren't possible with the 12-bit colour pallette on OCS/ECS, or am I overlooking something obvious, in which case, I apologise.

It's certainly possible - I've done this myself, alternating two copperlists to make a gradient smoother.


It can be done with images too, but it gets more resource intensive then, since you need two copies of the image! (If you have the RAM to spare there's no reason why you couldn't use it to improve a HAM image, either.)
robinsonb5 is offline  
Old 22 March 2020, 11:31   #3
no9
Registered User

no9's Avatar
 
Join Date: Feb 2018
Location: Poland
Posts: 68
Lionheart game uses this for backgrounds.
no9 is online now  
Old 22 March 2020, 19:34   #4
alexh
Thalion Webshrine
alexh's Avatar
 
Join Date: Jan 2004
Location: Oxford
Posts: 12,269
The intro screen to Thalion's leaving teramis also simulates more colours using interlaced dithering
alexh is offline  
Old 24 March 2020, 12:18   #5
TroyWilkins
Registered User

TroyWilkins's Avatar
 
Join Date: Jan 2015
Location: Tasmania, Australia
Posts: 445
Quote:
Originally Posted by robinsonb5 View Post
It can be done with images too, but it gets more resource intensive then, since you need two copies of the image! (If you have the RAM to spare there's no reason why you couldn't use it to improve a HAM image, either.)
Could it be done by just changing the colours in the CLUT (Colour Look Up Table), and so only needing to be done with the colours you want to change, thus saving on the RAM needed to have two copies of the image? Obviously this couldn't work for all display modes, but I can't see why it couldn't work for say a 32 colour low res non interlaced screen.

I apologise if this is a stupid idea, as I admit I'm not much of a programmer.
TroyWilkins is offline  
Old 24 March 2020, 14:43   #6
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 223
This not stupide it will works: you will have 32 colors that are not in the 4096 palette
But you will still have only 32 colors on screen so not much usefull

If you use the technique with 2 HAM pictures you will have new colors too but also more colors on screen: anyway finding a good algorithm to generate those 2 HAM pictures wont be easy
thellier is offline  
Old 24 March 2020, 19:32   #7
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 223
I had thought a few about the 2 ham pictures méthode
With ocs/ecs we have 16 levels of red,16 of green,16 of blue so 16x16x16 RGB colors
So if we were using a color like R 4 G 6 B 8
And want a more precise non existing color like
R 4.5 G 5.5 B 8
We can average (alternate the pictures) those colors (and obtain the new color)
R 4 G 6 B 8 and R 5 G 5 B 8
But due to HAM limitations it is not sure we can generate exactly those 2 pixels/color at this place on the screen
It is a very complex problem so I doubt that this 2xHam method was ever used...
thellier is offline  
Old 24 March 2020, 20:47   #8
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 688
Quote:
Originally Posted by thellier View Post
It is a very complex problem so I doubt that this 2xHam method was ever used...

It's an interesting puzzle, isn't it?
Where it might actually be useful, is in reducing HAM fringing, since by overshooting each correction it would potentially be possible to correct two channels per pixel rather than just 1.
robinsonb5 is offline  
Old 25 March 2020, 04:52   #9
TroyWilkins
Registered User

TroyWilkins's Avatar
 
Join Date: Jan 2015
Location: Tasmania, Australia
Posts: 445
Quote:
Originally Posted by thellier View Post
This not stupide it will works: you will have 32 colors that are not in the 4096 palette
But you will still have only 32 colors on screen so not much usefull

If you use the technique with 2 HAM pictures you will have new colors too but also more colors on screen: anyway finding a good algorithm to generate those 2 HAM pictures wont be easy
Yes, but my interest is in seeing colours that wouldn't otherwise exist on that hardware.

Quote:
Originally Posted by thellier View Post
I had thought a few about the 2 ham pictures méthode
With ocs/ecs we have 16 levels of red,16 of green,16 of blue so 16x16x16 RGB colors
So if we were using a color like R 4 G 6 B 8
And want a more precise non existing color like
R 4.5 G 5.5 B 8
We can average (alternate the pictures) those colors (and obtain the new color)
R 4 G 6 B 8 and R 5 G 5 B 8
But due to HAM limitations it is not sure we can generate exactly those 2 pixels/color at this place on the screen
It is a very complex problem so I doubt that this 2xHam method was ever used...
Yes, this would be very interesting.

I think I may have to try some experiments in deluxe paint...
TroyWilkins is offline  
Old 25 March 2020, 11:04   #10
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 223
Quote:
Originally Posted by robinsonb5 View Post
It's an interesting puzzle, isn't it?

Yes really :-)


If you have the first picture then obtaining the second is simple
for example if you have a pixel with red 5 and want red 5.5 then the second one must be red 6
But you can also choose an other value as red 2 so red 9 that will give red 5.5 too ... but with blinking ... but giving more latitude for choosing pixels in both pictures
In fact if you choose 2 pixels with an r g b distance of 1 then then 2 pixels must be in color cube of 2x2x2 that surround the wanted color value
So giving 8 possibilities for pixel1 and 8 for pixel 2
So 64 combinations to choose
If the r g b distance can be 4 without too much blinking then 4x4x4 cube so 4096 combinations ...arghh
thellier is offline  
Old 25 March 2020, 13:55   #11
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 688
Quote:
Originally Posted by thellier View Post
Yes really :-)


If you have the first picture then obtaining the second is simple
for example if you have a pixel with red 5 and want red 5.5 then the second one must be red 6

Yes indeed, however with HAM the error of 0.5 you get from wanting 5.5 is probably smaller than the error you get from not being able to adjust green and blue at the same time. So a more interesting possibility here is, for example:
You currently have red 4 and want red 5. Set red to 6 in the first frame and leave it at red 4 for the second. The two frames now average to red 5, and you're free to adjust green or blue in the second frame!
robinsonb5 is offline  
Old 25 March 2020, 14:35   #12
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 223
Of course
From my own experiments propagating the RGB error (error=error + wantedRGB - obtainedRGB) give the better results for HAM: i mean reducing the colors to 4096 or Floyd dithering it before the conversion to HAM proved to ne a bad idea
http://aminet.net/package/gfx/conv/DatatypeToHam
Anyway having .5 value for a R G B component would mâle sense for gradients in a single RGB direction
Typically photos with sky gradient (so in blue) may looks better
thellier is offline  
Old 25 March 2020, 14:40   #13
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 223
Note: even if we obtain 0.5 colors it will be only a 8192 colors picture so far away from true colors
thellier is offline  
Old 26 March 2020, 10:00   #14
TroyWilkins
Registered User

TroyWilkins's Avatar
 
Join Date: Jan 2015
Location: Tasmania, Australia
Posts: 445
Quote:
Originally Posted by thellier View Post
Note: even if we obtain 0.5 colors it will be only a 8192 colors picture so far away from true colors
Yes, well, less than that, but even still, I think in this case the law of diminishing returns applies. What do I mean by that? Well, lets compare the difference that just increasing the number of colours, without changing resolution. If we go from 16 colours up to 256, it can make a HUGE difference. If we then go up to 4096 it makes a difference again, but it's not as huge as the difference between 16 and 256. Once we get up to 16-bit vs 24-bit the difference is even smaller.

If we can get colours in between the 4 bit colours in the OCS/ECS palette and gain a few more colours with this method, it will make a difference, depending on the picture of course.
TroyWilkins is offline  
Old 26 March 2020, 10:13   #15
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 733
Quote:
Originally Posted by thellier View Post
Note: even if we obtain 0.5 colors it will be only a 8192 colors picture so far away from true colors

I don't think this is correct. You can get twice as many shades of each R, G, and B component. This means that instead of a 12 bit palette we should get a 15 bit palette, hence, 32768 colours which is Mac hicolor. I suspect the eye will be able to spot the flickering of the green component, though, as the eye is most sensitive for greens.
grond is offline  
Old 26 March 2020, 10:38   #16
TroyWilkins
Registered User

TroyWilkins's Avatar
 
Join Date: Jan 2015
Location: Tasmania, Australia
Posts: 445
Quote:
Originally Posted by grond View Post
I don't think this is correct. You can get twice as many shades of each R, G, and B component. This means that instead of a 12 bit palette we should get a 15 bit palette, hence, 32768 colours which is Mac hicolor. I suspect the eye will be able to spot the flickering of the green component, though, as the eye is most sensitive for greens.
Good point. Also perhaps we could get a 0.25 increment by using more than a single increment or decrement. So maybe 0000FF and 0000CC, which should give something like 0000E3 in theory, although the chance of flicker being more perceivable with a larger difference between the two colours being alternated between.
TroyWilkins is offline  
Old 26 March 2020, 13:45   #17
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 733
Quote:
Originally Posted by TroyWilkins View Post
Also perhaps we could get a 0.25 increment by using more than a single increment or decrement.

I'm not sure what you mean. All possible differences between two 4bit values are either odd or even. The even differences will always average to one of the original 4bit values and no new value. The odd differences will bring the one extra bit of precision. However, many odd differences will coincide in the same output value. E.g. 5 and 6 will be averaged to 5.5 but so would 4 and 7. Hence you only get the one extra bit of precision per colour channel.


However, in theory you could use some PWM scheme with a higher temporal resolution. E.g you could create four different colours out of the colour values 5 and 6 if you used three consecutive frames: 5,5,5 (old); 5,5,6 (new); 5,6,6 (new); and 6,6,6 (old). Obviously with just 50 or 60 Hz framerate this would visibly flicker and not really blend.
grond is offline  
Old 26 March 2020, 13:55   #18
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,710
Flashing between two colours every frame is an oft-used technique in the C64 world to add extra perceivable colours to the palette. On the C64, there are 136 combinations you can make based on the 16 base colours. Many of those cause a large amount of visible flicker.

However, colours that are close (better yet: identical) in luminance fare a lot better. Colours that are also close in chroma value get best results, with in some cases barely perceivable flicker.

The question is mostly whether or not it's worth it on the Amiga. On the C64, these kind of effects where best suited for smaller areas of the screen (such as a few sprites here and there). Though there were some exceptions (Dragon Breed on the C64 famously uses a non-existent colour using this technique for the big dragons you fly past on level 3). It also tends to look better on a real CRT as in many cases the phosphors will blend together between frames ever so slightly.

My guess is that doing this full-screen will be a lot more distracting that choosing to do it for some smaller elements. Then again, on the Amiga the differences between two colours can be made a lot smaller than on the C64, which might mitigate most of the flicker.
roondar is offline  
Old 26 March 2020, 14:24   #19
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 688
Quote:
Originally Posted by roondar View Post
The question is mostly whether or not it's worth it on the Amiga.

My guess is that doing this full-screen will be a lot more distracting that choosing to do it for some smaller elements. Then again, on the Amiga the differences between two colours can be made a lot smaller than on the C64, which might mitigate most of the flicker.
I did try it once with a chequerboard floor fading to a fog colour - I used 6-bit colour resolution, mapping bits 5:2 to the Amiga's standard 3:0 bits, then mapping bit 1 to a pixel-based dither and bit 0 to a temporal dither. It looked OK on real hardware (as long as that hardware's fast enough to run the demo at 50Hz!) but obviously looks awful on a emulator that's not frame-synced.

Last edited by robinsonb5; 26 March 2020 at 20:26.
robinsonb5 is offline  
Old 26 March 2020, 17:05   #20
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 223
Yes you are right it will give a 15 bit palette, hence, 32768 colors
Even if I am not sure this method can access all those colors as the second picture can only Modify (HAM) a single R G B channel at a time
I mean
to obtain RGB 4.5 8.5 2.5
with
pixel pic1 RGB 4 8 2
and
pixel pic2 RGB 5 9 3
is probably not possible and certainly we will have only
pixel pic2 RGB 4 9 2 due to ham limitations ...

Perhaps a (not so complicated) method to create those 2 pictures would be to use an error propagation method to create simultaneously pic1 and pic2 pixels

for each pixel add the pic1 error to pic2 error to compensate in pic2 what have missed in pic1
thellier is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
OCS and ECS Enemy AI support.Games 5 27 November 2019 12:22
OCS/ECS Playfields - blitting objects using colours 16-31? Marle Coders. Blitz Basic 6 03 October 2018 20:19
OCS/ECS 3D shooters? Borgy support.Games 6 13 April 2018 18:46
ECS screen mode colours. redblade support.Hardware 10 28 June 2010 06:30
ECS and OCS antonvaltaz Amiga scene 6 09 April 2010 12:50

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:53.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.08606 seconds with 14 queries