Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
14 crawler(s) on-line.
 75 guest(s) on-line.
 1 member(s) on-line.


 zErec

You are an anonymous user.
Register Now!
 zErec:  1 min ago
 amigakit:  16 mins ago
 matthey:  17 mins ago
 Kronos:  22 mins ago
 Mobileconnect:  33 mins ago
 kriz:  37 mins ago
 vox:  1 hr 11 mins ago
 bhabbott:  1 hr 26 mins ago
 zipper:  1 hr 30 mins ago
 towo2099:  1 hr 55 mins ago

/  Forum Index
   /  Amiga Gaming
      /  No, the limits of HAM have not vanished!
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 Next Page )
PosterThread
Hans 
Re: No, the limits of HAM have not vanished!
Posted on 6-Feb-2024 6:05:08
#61 ]
Elite Member
Joined: 27-Dec-2003
Posts: 5088
From: New Zealand

@Karlos

Quote:
So, as I mentioned above somewhere, I experimented with YUV HAM in MC64K before just going with RGB again. The problem with YUV is that it's just not a remotely intuitive format for software colour manipulation. It might not matter if all you are doing is manipulating prerendered graphical elements on a buffer.

HAM isn't an easy format for colour manipulation either, so I don't think we lose anything.

Quote:
It was also apparent in my 5-bit version (not HAM in general) that you need greater resolution for the luminance than your desired but depth can deliver.

How bad did it look? You could use HAM8, or just accept the limitations (as you have to with HAM mode, no matter how you use it).


Quote:
They were both a part of the history, really. The demise of AGA marked the end of an era. The demise of PPC marks the end of an error.

A few days ago, I stumbled on someone claiming that AGA Amigas weren't real Amiga computers either. To him, only OCS and ECS were the real deal.

So many personal definitions of what is and isn't an Amiga computer...

Hans

Last edited by Hans on 06-Feb-2024 at 06:26 AM.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

 Status: Offline
Profile     Report this post  
Hans 
Re: No, the limits of HAM have not vanished!
Posted on 6-Feb-2024 6:18:00
#62 ]
Elite Member
Joined: 27-Dec-2003
Posts: 5088
From: New Zealand

@cdimauro

Quote:
Quote:
Yes, the base palette isn't the same as the actual pixel colour, but the average colour error is going to be a good step less than just pasting a bob on top and doing nothing (and the maximum error is greatly reduced). I can't comment on how visually annoying the remaining error would be, because I never got round to testing it out.


Maybe someone can take the chance and give a try. There are plenty of "old style coders (!)" which could find it fun.

I hope someone does, because I'd be curious as to what results you could get.

Quote:
Anyway, your method requires double the space (as you already stated) and double cookie-cut of the BOB (since you don't know where the right border of the BOB ends).

Not quite, but close. You'd start with 7 bitplanes (6 for colour, and 1 mask), and then add another 5 (4 bit-planes for the base-palette version, plus the right-edge mask).

Yes, the 2MiB chip-ram is going to feel a bit small...

Quote:
Quote:
Thinking about it a bit more, you could write a HAM dithering algorithm to generate HAM images with a rule that every colour channel must be covered at least every n
pixels (n being yet another trade-off, smaller means less fringing, but more noise in the original image).


Hum. Do you mean that if n == 3 then in 3 subsequent pixels each colour component should have been changed?

Yes, either by a base palette colour, or by individual channels. Most likely, you'd choose a larger n, though, or the image noise will probably be rather high.

Quote:
Quote:
Haha. I haven't forgotten the horrible flickering. However, interlaced TVs didn't flicker horribly due to proper antialiasing.


I don't recommend it anyway. I had my A1200 attached to a 16" TV of the time, and interlace was really horrible to sustain for long time.

The TV doesn't do anti-aliasing; it's part of the input signal. Decades ago I stumbled on a software only flicker-fixer for the Amiga. I can't remember what it was called, but I do remember that it basically did some kind of anti-aliasing between scan-lines. This really did wonders to that annoying flicker.

Quote:
I know the Graffiti. Yes, it could be implemented that way, but only in LORES (using HRES as the "master") or HRES (using SHRES as "master").

I was referring only to the way that the Graffiti plugged into the RGB port externally. YUV=>RGB conversion could be done at the screen's native resolution. Unlike the Graffiti card we're not trying to add extra colour information per pixel beyond what HAM mode provides.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 6-Feb-2024 9:59:39
#63 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4545
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Hans

Quote:
HAM isn't an easy format for colour manipulation either, so I don't think we lose anything.


This is true but you have to remember you are dealing with an intersection of problems now. HAM is fiddly sure, but at least RGB colourspace calculations for things like mixing and brightness and saturation are pretty intuitive and well understood. You can even approximate both the latter operations as a mix with 0,0,0 or mix with 1,1,1 (normalised scale). The only gotcha is the fact that gun brightness isn't linear, it's effectively proportional to x^0.5, so to get good blending you square your channel values before summing, taking the root and then dividing.

Now, while I appreciate that brightness and saturation are now just direct values you can edit in YUV but calculating how to blend a pair of colour values - especially if they are in RGB to begin with, is much more involved. The line of colours through YUV space where the saturation and value are 1.0 is probably not very well quantized into an integer value for your chroma channel, either.

Quote:
How bad did it look? You could use HAM8, or just accept the limitations (as you have to with HAM mode, no matter how you use it).


Not great, tbh. The reason I was going for 5 bit though is because I had a control bit for each channel, so in a single chunky byte pixel you can have either a palette entry (32 from RGB15), or modify any combination of the R G B values at once (5 bit precision).

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Hans 
Re: No, the limits of HAM have not vanished!
Posted on 6-Feb-2024 11:56:57
#64 ]
Elite Member
Joined: 27-Dec-2003
Posts: 5088
From: New Zealand

@Karlos

Quote:
This is true but you have to remember you are dealing with an intersection of problems now. HAM is fiddly sure, but at least RGB colourspace calculations for things like mixing and brightness and saturation are pretty intuitive and well understood. You can even approximate both the latter operations as a mix with 0,0,0 or mix with 1,1,1 (normalised scale). The only gotcha is the fact that gun brightness isn't linear, it's effectively proportional to x^0.5, so to get good blending you square your channel values before summing, taking the root and then dividing.

Now, while I appreciate that brightness and saturation are now just direct values you can edit in YUV but calculating how to blend a pair of colour values - especially if they are in RGB to begin with, is much more involved. The line of colours through YUV space where the saturation and value are 1.0 is probably not very well quantized into an integer value for your chroma channel, either.

I'm looking at this from the perspective of trying to get more colours on-screen for typical classic Amiga games using the HAM mode. They typically work almost entirely with predrawn imagery. In that context, converting everything to YUV isn't a problem because it's all calculated ahead of time.

Planar screen modes are unsuitable for real-time colour manipulation beyond changing the screen's colour palette (which won't work properly with HAM). So, if that's what you want to do, then planar modes of any type are unsuitable. Forget HAM and anything classic Amiga chipset, and switch to chunky pixels.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 6-Feb-2024 12:27:36
#65 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4545
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Hans

If it's all predrawn, I don't see any problem. Well, perhaps the one problem that 64 might not have enough resolution for chroma selection, but since our eyes are not particularly as bothered by that as they are brightness, it may not matter.

Going back though, a place where this would really work well, is what Jay originally intended - shaded polygons. You scan out your horizontal line, modulating the brightness of some starting colour for the basic lighting and modulate saturation (i.e. drive towards white) for any specular component.

Your basic 32-colour flat polygon engine now looks awesome with smooth Gouraud / shading and specular highighting, without the cost that normally comes with in RGB space.

Last edited by Karlos on 06-Feb-2024 at 12:54 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 6-Feb-2024 20:52:42
#66 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4040
From: Germany

@Hans

Quote:

Hans wrote:
@cdimauro

Quote:
Maybe someone can take the chance and give a try. There are plenty of "old style coders (!)" which could find it fun.

I hope someone does, because I'd be curious as to what results you could get.

Worst case using Python + PyGame should be easy to emulate HAM and moving such particular BOB to see what's happening.
Quote:
Quote:
Hum. Do you mean that if n == 3 then in 3 subsequent pixels each colour component should have been changed?

Yes, either by a base palette colour, or by individual channels. Most likely, you'd choose a larger n, though, or the image noise will probably be rather high.

Indeed. n == 3 is too strict, and fulfilling it will create other artifacts.
Quote:
Quote:
I don't recommend it anyway. I had my A1200 attached to a 16" TV of the time, and interlace was really horrible to sustain for long time.

The TV doesn't do anti-aliasing; it's part of the input signal. Decades ago I stumbled on a software only flicker-fixer for the Amiga. I can't remember what it was called, but I do remember that it basically did some kind of anti-aliasing between scan-lines. This really did wonders to that annoying flicker.

Never heard of something like that. But now it's too late to try it.
Quote:
Quote:
I know the Graffiti. Yes, it could be implemented that way, but only in LORES (using HRES as the "master") or HRES (using SHRES as "master").

I was referring only to the way that the Graffiti plugged into the RGB port externally. YUV=>RGB conversion could be done at the screen's native resolution. Unlike the Graffiti card we're not trying to add extra colour information per pixel beyond what HAM mode provides.

Hans

AFAIK Graffiti uses a 16 colours HRES mode to simulate a 256 colours LORES mode, because there's no other possibility by reusing what the Amiga OCS/ECS allowed.

The circuit in the box sampled the 16 possible colours of each HRES pixel and paired two of them at the time to build the 8 bit value which it then uses as an entry on the CLUT (which was sent to the box during the VBLANK, via some special commands).

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 6-Feb-2024 21:51:37
#67 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4545
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Hans

Quote:
Decades ago I stumbled on a software only flicker-fixer for the Amiga. I can't remember what it was called, but I do remember that it basically did some kind of anti-aliasing between scan-lines. This really did wonders to that annoying flicker.


MagicTV: https://aminet.net/package/util/wb/magictv2

I used to use that on a 1084 before I went RTG. It was pretty effective.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: No, the limits of HAM have not vanished!
Posted on 10-Apr-2024 11:20:30
#68 ]
Regular Member
Joined: 5-Dec-2008
Posts: 166
From: Australia

Would it have been possible to make a HAM mode that altered the Hue, Saturation, or Luminance ie. 00-Palette Colour, 01-Change Hue to, 02-Change Saturation to, 03-Change Luminance to...

I feel like if that were able to be implemented that it would almost allow the elimination of visible artifacting?

Would it have been possible to create the circuitry to change the H|S|L rather than just change the red, green, or blue?

 Status: Offline
Profile     Report this post  
Hammer 
Re: No, the limits of HAM have not vanished!
Posted on 10-Apr-2024 15:40:21
#69 ]
Elite Member
Joined: 9-Mar-2003
Posts: 5858
From: Australia

@Hans

Quote:

Hans wrote:
A few days ago, I stumbled on someone claiming that AGA Amigas weren't real Amiga computers either. To him, only OCS and ECS were the real deal.

So many personal definitions of what is and isn't an Amiga computer...

Hans

The original NTSC A1000 didn't have 6-bitplanes 64-color EHB mode. Later NTSC and PAL A1000 have 64-color EHB mode.

C= Amiga has established color display improvements since A1000. The problem is Amiga's color display evolution has stalled until AGA's release.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

 Status: Offline
Profile     Report this post  
Karlos 
Re: No, the limits of HAM have not vanished!
Posted on 11-Apr-2024 1:50:48
#70 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4545
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@gonegahgah

Try it. All you need to do is to write something that can covert an image in your hypothetical HAM format into RGB so that you can assess the results. No hardware necessary.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 14-Apr-2024 21:48:20
#71 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4040
From: Germany

@gonegahgah

Quote:

gonegahgah wrote:
Would it have been possible to make a HAM mode that altered the Hue, Saturation, or Luminance ie. 00-Palette Colour, 01-Change Hue to, 02-Change Saturation to, 03-Change Luminance to...

I feel like if that were able to be implemented that it would almost allow the elimination of visible artifacting?

HSL improves the situation compared to RGB, but fringing is here to clearly stay.

 Status: Offline
Profile     Report this post  
number6 
Re: No, the limits of HAM have not vanished!
Posted on 14-Apr-2024 22:02:03
#72 ]
Elite Member
Joined: 25-Mar-2005
Posts: 11602
From: In the village

@cdimauro

Can it be helped with an isotonic palette dropping saturation and dynamic range to the source?

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

 Status: Offline
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 14-Apr-2024 22:24:25
#73 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4040
From: Germany

@number6

Quote:

number6 wrote:
@cdimauro

Can it be helped with an isotonic palette dropping saturation and dynamic range to the source?

#6

Sorry, I don't get it. Could you please provide an example?

 Status: Offline
Profile     Report this post  
number6 
Re: No, the limits of HAM have not vanished!
Posted on 14-Apr-2024 22:32:54
#74 ]
Elite Member
Joined: 25-Mar-2005
Posts: 11602
From: In the village

@cdimauro

Granted this is 256 color mode example I made to circumvent WB palette picking, but better imagery came from this weird looking palette imo.

example image

So I just wondered if you did something similar to a ham palette could you eliminate fringing a bit?

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

 Status: Offline
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 14-Apr-2024 23:02:09
#75 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4040
From: Germany

@number6

Quote:

number6 wrote:
@cdimauro

Granted this is 256 color mode example I made to circumvent WB palette picking, but better imagery came from this weird looking palette imo.

example image

So I just wondered if you did something similar to a ham palette could you eliminate fringing a bit?

#6

Unfortunately you can't do the same.

That's because HAM has only 16 base colours and all other are derived by changing a component at the time.

Unless you want to use just those 16 colours.

 Status: Offline
Profile     Report this post  
number6 
Re: No, the limits of HAM have not vanished!
Posted on 14-Apr-2024 23:12:27
#76 ]
Elite Member
Joined: 25-Mar-2005
Posts: 11602
From: In the village

@cdimauro

Understood. Hence also why I thought dropping saturation and shrinking dynamic range on the source might help. Transition to the human eye might be smoother.

Based on:

Quote:
We know that human eye is not sensitive to color patterns in high frequencies; therefore we use luminance patterns because the eye is more sensitive to luminance patterns in high frequencies and is able to distinguish the edges.


In other words since there are only "16" stick to the range most sensitive to the human eye.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: No, the limits of HAM have not vanished!
Posted on 14-Apr-2024 23:28:24
#77 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12894
From: Norway

@number6

If is a RGBRGBRGBRGBRGBRGB pattern. the distortion is only 2 pixels wide, with higher resolution, the distortion is decreased even more. but to make this work everything has to use this pixel pattern. Or else you get this ugly long distortion lines. The problem is that DPaint does not produce pictures like that.

if you picture generated for image quality, you have different pattern.
RRRRGGGBBRRRGBBRRRR, etc, if the changes in the only based on delta value of R,G,B channels, you change channel with highest error delta first. Then of course you sprinkle the picture with solid colors, that has closes match, perhaps find parts of the picture that has the worst match find the colors, find color count, sort it, and sprinkle solid colors there, if the solid color has lower error.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
cdimauro 
Re: No, the limits of HAM have not vanished!
Posted on 15-Apr-2024 5:46:23
#78 ]
Elite Member
Joined: 29-Oct-2012
Posts: 4040
From: Germany

@number6

Quote:

number6 wrote:
@cdimauro

Understood. Hence also why I thought dropping saturation and shrinking dynamic range on the source might help. Transition to the human eye might be smoother.

Which happens by using another colour space like HSL, YUB, LAB, etc., where luminance has a proper channel, but this cannot remove the fringing which is part of HAM's intrinsic nature.
Quote:
Based on:

Quote:
We know that human eye is not sensitive to color patterns in high frequencies; therefore we use luminance patterns because the eye is more sensitive to luminance patterns in high frequencies and is able to distinguish the edges.


In other words since there are only "16" stick to the range most sensitive to the human eye.

#6

Yes, got it. However the problem here is that you've to carefully chose those 16 colours to "cover" as much as possible all pixels of the image by reducing all components transistions.

Basically you're not free to chose whatever you want for those colours.

I mean: you can, as per your proposal, because you (the image creator) are the one that can select them one by one, but the end result wouldn't be optimal and you'll see several other artifacts.

 Status: Offline
Profile     Report this post  
BigD 
Re: No, the limits of HAM have not vanished!
Posted on 15-Apr-2024 8:28:58
#79 ]
Elite Member
Joined: 11-Aug-2005
Posts: 7383
From: UK

@Hans

Quote:
A few days ago, I stumbled on someone claiming that AGA Amigas weren't real Amiga computers either. To him, only OCS and ECS were the real deal.


Yeah and I guess you have to use cracked software loading from a floppy to get the 'true' Amiga experience?! Some people!! I would hazard a guess they jumped ship to a PeeCee as soon as they could afford one yet they begrudge the Amiga developing beyond the A500!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: No, the limits of HAM have not vanished!
Posted on 18-Jun-2024 10:12:24
#80 ]
Regular Member
Joined: 5-Dec-2008
Posts: 166
From: Australia

Hi @Karlos

I did find it intriguing when you suggested that I should try it myself. I would like to do that one day just as an interesting little exercise. The reason: just because it would be an interesting little exercise...

I'm snowed under working on other things but hopefully this is something I will come back to one day (not yet).

I did look up the conversion between RGB to HSV to get some idea of the process. What I found were the following algorithms:

R' = R÷255, G' = G÷255, B' = B÷255
Cmax = max(R',G',B'), Cmin = min(R',G',B'), Δ = Cmax-Cmin
if Δ = 0
...Hue = 0
elseif Cmax = R'
...Hue = 60° × ( ( (G' - B') ÷ Δ ) mod 6 )
elseif Cmax = G'
...Hue = 60° × ( ( (B' - R') ÷ Δ ) + 2 )
elseif Cmax = B'
...Hue = 60° × ( ( (G' - B') ÷ Δ ) + 4 )
if Cmax = 0
...Saturation = 0
else
...Saturation = Δ/Cmax
Value = Cmax

and in reverse:

When 0 ≤ H lessthan 360, 0 ≤ S ≤ 1 and 0 ≤ V ≤ 1
C = V × S, m = V - C
X = C × (1 - abs( (H ÷ 60°) mod 2 - 1 ) )
if 300° ≤ H
...R' = C, G' = 0, B' = X
elseif 240° ≤ H
...R' = X, G' = 0, B' = C
elseif 180° ≤ H
...R' = 0, G' = X, B' = C
elseif 120° ≤ H
...R' = 0, G' = C, B' = X
elseif 60° ≤ H
...R' = X, G' = C, B' = 0
elseif 0° ≤ H
...R' = C, G' = X, B' = 0
R = (R' + m) × 255
G = (G' + m) × 255
B = (B' + m ) × 255

I'll double check that later as that is a semi-translation from the math I found...
Certainly not as straight forward as RGB shifting but should be implementable in circuitry I imagine? It might have run a little hot or slow in the day? But I don’t know these things?

Last edited by gonegahgah on 18-Jun-2024 at 08:33 PM.
Last edited by gonegahgah on 18-Jun-2024 at 10:34 AM.
Last edited by gonegahgah on 18-Jun-2024 at 10:29 AM.
Last edited by gonegahgah on 18-Jun-2024 at 10:14 AM.
Last edited by gonegahgah on 18-Jun-2024 at 10:14 AM.
Last edited by gonegahgah on 18-Jun-2024 at 10:13 AM.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle