English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 22 February 2019, 14:47   #1
TEG
Registered User

 
Join Date: Apr 2017
Location: France
Posts: 31
HAM scrolling

I was wondering, do we have a game or a demo showing HAM scrolling ?


Thanks in advance.
TEG is offline  
Old 22 February 2019, 15:00   #2
fryguy
Registered User
 
Join Date: Aug 2005
Location: Hjo, Sweden
Age: 39
Posts: 802
Maybe Pioneer Plague http://hol.abime.net/1068 but the background doesn't seem to have many colors.
fryguy is offline  
Old 22 February 2019, 15:39   #3
TEG
Registered User

 
Join Date: Apr 2017
Location: France
Posts: 31
To clarify what I'm searching for, it is full screen HAM scrolling.

I found some HAM text scrolling but no full screen. And yes, Pioneer is not convincing.
TEG is offline  
Old 22 February 2019, 16:40   #4
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 787
Quote:
Originally Posted by TEG View Post
I was wondering, do we have a game or a demo showing HAM scrolling ?
How about Kang Fu?

[ Show youtube player ]
Gorf is offline  
Old 22 February 2019, 17:00   #5
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 436
Olo Fight

[ Show youtube player ]
Solo Kazuki is offline  
Old 22 February 2019, 17:32   #6
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 787
Quote:
Originally Posted by Solo Kazuki View Post
Olo Fight
looks more like a static (non scrolling) HAM background
Gorf is offline  
Old 22 February 2019, 17:39   #7
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 436
All game is in HAM, And far background is also scrolling (but a little).

Some more

[ Show youtube player ]
Solo Kazuki is offline  
Old 22 February 2019, 17:46   #8
dodke
Registered User

 
Join Date: Feb 2018
Location: London / UK
Posts: 47
Olo Fight does not look like it's HAM at all, how did you come up with that? It's AGA so possibly 256 colours which is plenty.
dodke is offline  
Old 22 February 2019, 18:00   #9
TEG
Registered User

 
Join Date: Apr 2017
Location: France
Posts: 31
At least Kang Fu show it's technically possible. I forgot about this game. Thanks.

But we can see that the result of objects with few colours on a background with a lot of colours is not very graceful :-/

We can see too, that picture with gradient is used to minimized HAM artefacts.

And using blobs would create a lot artefacts. Do you think using sprites as a mask to hide blob artefacts would be doable ?
TEG is offline  
Old 22 February 2019, 18:13   #10
Solo Kazuki
Registered User
Solo Kazuki's Avatar
 
Join Date: Sep 2004
Location: Poland
Posts: 436
What? It looks very HAMish because HAM artifacts are visible and game has over 3000 colours on screen NOT 256.

http://aminet.net/package.php?packag...o/OloFight.lha

Quote:
The game uses a lot of colours, more than is usually available on an AGA screen (early previews made claims of using the HAM-8 mode with 262 144 colours, which would be a world first)
https://www.mobygames.com/game/olofight
Solo Kazuki is offline  
Old 22 February 2019, 18:35   #11
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,209
Bplcon0 is set to $0211 in Olo Fight so no HAM used at all.
StingRay is offline  
Old 22 February 2019, 18:51   #12
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 522
Quote:
Originally Posted by StingRay View Post
Bplcon0 is set to $0211 in Olo Fight so no HAM used at all.
...but, but it has over 3000 colors on screen!
britelite is offline  
Old 22 February 2019, 19:47   #13
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 116
AFAIK in Pioneer Plague the background solely consists of the 16 palette colors HAM6 mode offers, and modified colors are only used in the BOBs. Bill Williams used this scheme to avoid fringing both from scrolling and object plotting - you do not need any special handling compared to normal modes, just let your BOBs always start with a palette color on the left edge and you are fine.

Horizontal HAM scrolling is tricky because of fringing on the left screen edge. You might start a line with a modified color that changes a color that wasn't shown before, resulting in a modified background color instead until a palette color is displayed. One way to avoid this is preparing your image so that there's never more than e.g. 16 pix horizontally between two pixels with palette color (it doesn't have to be regularly every 16th pixel), and covering 16 pixels on the left edge with a sprite in background color. However, I do not know of any HAM converter which has an option for such an format.
chb is offline  
Old 22 February 2019, 21:55   #14
TEG
Registered User

 
Join Date: Apr 2017
Location: France
Posts: 31
Quote:
Originally Posted by chb View Post
Horizontal HAM scrolling is tricky because of fringing on the left screen edge. You might start a line with a modified color that changes a color that wasn't shown before, resulting in a modified background color instead until a palette color is displayed.

I made a quick test with Amos and I can confirm that the result is worst than expected. I mean, the number of horizontal pixels impacted, for the start of one single line, is more important than expected. I get very ungraceful green artefacts. I will try to see if I can change faulty pixels to palette ones on the fly.
Attached Thumbnails
Click image for larger version

Name:	ham_scroll_test1.jpg
Views:	111
Size:	52.9 KB
ID:	62150  
TEG is offline  
Old 23 February 2019, 02:00   #15
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,525
First idea that came to my mind.
Use only 15 base colors for the image (ADPro allows it, from 0 to 14).
Set the color 15 on each line with the copper so that is the first pixel and the one that allows the next to be right (logically it must be calculated for each line).
Eventually cover this first pixel with a sprite.
No more fringes
ross is offline  
Old 23 February 2019, 10:21   #16
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 116
@ross: That's a very nice idea, however determining the first visible pixel's RGB value could be quite costly - depending on the picture and the scroll value you will need to parse a lot of pixels to its left, in an not-so-convenient planar HAM format. That might not be doable for a 50 Hz scroll. One way to get around this is storing the picture* in 12 bit chunky in a separate buffer so you can directly look up its RGB value. Needs quite a bit of memory, but it does not need to be in chip RAM.

EDIT: I think you do not need to cover the first pixel with a sprite - if you set it to the RGB value it would have in the unscrolled image, it and all the following pixels will have correct color. But I think you'd need the blitter to make the first pixel color 15 on every line? Or changing background color (color 0) and covering the artifact with a sprite?

*actually only the pixels that can be scrolled to xpos = 0 (first pixel)

Last edited by chb; 23 February 2019 at 10:29.
chb is offline  
Old 23 February 2019, 10:29   #17
TEG
Registered User

 
Join Date: Apr 2017
Location: France
Posts: 31
Yes, this my idea too: to recalculate the first pixel and see the feasibility. Precalculated method you proposed Chb, is interesting too.

In fact, when I started the thread, I forgot that in HAM mode, a whole line can depend of the first pixel of this line. I was in the idea it was only true for 8 pixels or so (HAM is far away in my memory). And so the sprite trick is useless.
So I will maintain a precalculated set of data representing the x+1 column of pixels which approximated the real ones by using the palette ones and apply it to the image, after the image was scrolled by one pixel to the left.

Do someone know what algorithm I can use to take the most appropriated pixel from a 16 colours palette when coming from a potential 4096 colours pixel?

Last edited by TEG; 23 February 2019 at 10:35.
TEG is offline  
Old 23 February 2019, 11:15   #18
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 116
Quote:
Originally Posted by TEG View Post
So I will maintain a precalculated set of data representing the x+1 column of pixels which approximated the real ones by using the palette ones and apply it to the image, after the image was scrolled by one pixel to the left.

Do someone know what algorithm I can use to take the most appropriated pixel from a 16 colours palette when coming from a potential 4096 colours pixel?
For color difference: You could simply calculate the square of the Euclidean difference (R1-R2)**2 + (G1-G2)**2 + (B1-B2)**2, maybe with a higher weight for green to incorporate the sensitivity of the human eye. Or if you need better results, the standard CIE _Delta E (which probably is overkill for your purpose). Be aware, however, that the HAM palette colors may be a very bad match for a lot of your image colors - the ham palette does not need to represent the image colors, it needs to be a good base for modification. This depends on your picture (and converter). I think the approach Ross proposed is more powerful and not much more complicated, the only downside being the loss of one color.
chb is offline  
Old 23 February 2019, 12:44   #19
TEG
Registered User

 
Join Date: Apr 2017
Location: France
Posts: 31
Thanks Chb, help appreciated.

If I understand well what Ross proposed, is to convert the image to a 15 colours picture as a simple method to precalculate the colour of the pixels that will need to be modified. Is it that?
TEG is offline  
Old 23 February 2019, 13:09   #20
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,525
Ok, my idea in full.
You can avoid heavy calculation making a 'partial' pre-calculated 12bit RGB chunky for the pixel color 15, to store in copper every line (if you store this in chip ram you can use the blitter to fill the copper, else CPU).
Partial because only the left scrolled part need to be stored.

Bitplanes for the HAM image in consecutive planar memory region, and not interleaved.
This to fill the first pixel with only two blitter pass:
- first pass for the 00 on mode selection bits/planes (op. D=A&B, B=$7FFF)*
- second pass for the 1111 on CLUT planes (color 15) (op. D=A|B, B=$8000)*

And yes, with the proper RGB you do not need sprite cover

EDIT: *mask is dynamic logically, this is only an example for the MSB bit

Last edited by ross; 23 February 2019 at 13:28.
ross 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
sham instead of ham ? turrican3 Retrogaming General Discussion 1 13 December 2017 14:45
Why is HAM so underrated? Foebane Retrogaming General Discussion 15 02 December 2017 13:25
Ham videos Zooup1972 support.Apps 17 19 April 2015 01:35
Amiga HAM Si-Pie Amiga scene 12 14 November 2008 00:50
HAM Demo Frazor request.Demos 2 06 August 2003 15:36

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 01:46.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09027 seconds with 16 queries