English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 23 February 2019, 13:12   #21
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,404
Quote:
Originally Posted by TEG View Post
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?
Direct algorithms are too slow for doing that. You need to use a lookup table.
For computing the color difference, i got good results with R*2+G*3+B*1.
meynaf is offline  
Old 23 February 2019, 13:26   #22
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,521
Quote:
Originally Posted by TEG View Post
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?
I'm not sure I understood what you wrote..

My idea is to use a regular HAM image where base color 15 is unused and free to be used by 'anti-fringe' code.
Then a second partial chunky RGB 12bit image for the same picture (pre-calculated using RGB colors same as HAM image).
ross is offline  
Old 26 February 2019, 01:04   #23
TEG
Registered User

 
Join Date: Apr 2017
Location: France
Posts: 31
Thanks Ross for the clarification.

I have done my POC using Amos and it work well. I use a simple trick. I maintain an array containing the last indexed pixel encountered for each lines and I put it back if the current colour is an "hold an modify" one (not an indexed one).

Pro: small memory imprinted, short time for dev.
Con: slow? not the best result?

Perhaps it would be possible to store, for each column, in a very packed fashion, only bits that need to be changed to suppress the read column step. Not my goal at the moment. I'm curious to see the result of the same technique applied to Bobs.

Code:
Screen Hide 0
Flash Off
Curs Off
FILE$= FSEL( "", "", "Load Iff file to display")
Load Iff FILE$, 0

Locate 10, 5
S_HEIGHT= Display Height
Rem  Print S_HEIGHT

Reserve As Work 5, S_HEIGHT

Locate 3, 0
For X= 0 To 150
    
    Rem --Read colours of first column of pixels--
    For Y= 0 To S_HEIGHT- 1
       PIXELCOLOUR= Point( X, Y)
       If PIXELCOLOUR< 16
          Poke Start( 5)+ Y, PIXELCOLOUR
       End If
    Next Y
    
    Rem --Scroll 1 pixel--
    Screen Offset 0, X, 0
    
    Rem --Put colour back if not an indexed colour--
    For Y= 0 To S_HEIGHT- 1
       PIXELCOLOUR= Point( X, Y)
       If PIXELCOLOUR> 15
          Plot X, Y, Peek( Start( 5)+ Y)
       End If
    Next Y
    
    Wait 3
Next X

Wait 100
End
Attached Files
File Type: zip HAM scrolling without fringering.zip (157.0 KB, 3 views)
TEG is offline  
Old 26 February 2019, 10:22   #24
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,521
Quote:
Originally Posted by TEG View Post
I have done my POC using Amos and it work well. I use a simple trick. I maintain an array containing the last indexed pixel encountered for each lines and I put it back if the current colour is an "hold an modify" one (not an indexed one).
Interesting.
I have not tried your code so I do not know how effective it is.
But with this technique you could not have wrong colors instead of the fringe for the first pixes after the indexed? Because when you insert the indexed pixel you do it 'in the middle' of a possible series of modified pixels.
To move from one color to another you need 3 'steps' minimum, so a little bit of color errors should be visible..
ross is offline  
Old 26 February 2019, 10:35   #25
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 199
Perhaps the more efficient would be have a "correction map"
I mean a bitmap filled with the "nearer" palette color vs the current ham pixel on the ham picture
ie: for each pixel in ham picture found out what is current 12bits RGB ham color then found nearer palette value

You can enhance the trick as if ham pixel at (say) xy 10,20 is R4G8B6 and next pixel at xy 11,20 modify to R8 then only take into account the G an B value to find out the best palette value as the R value will be "auto corrected"

BTW & OT:
Perhaps doing a game in ham with only the characters("sprites") in ham and the background in palette pixels would be simpler : the characters ("sprites") will be surrounded with a black(palette) outline so HAM values would be assured to start/end on black for the "sprites"
thellier is offline  
Old 26 February 2019, 12:59   #26
chb
Registered User

 
Join Date: Dec 2014
Location: germany
Posts: 116
Quote:
Originally Posted by thellier View Post
BTW & OT:
Perhaps doing a game in ham with only the characters("sprites") in ham and the background in palette pixels would be simpler : the characters ("sprites") will be surrounded with a black(palette) outline so HAM values would be assured to start/end on black for the "sprites"
Yep, that's precisely what Pioneer Plague does. Only problem: Overlapping BOBs - to be more precise: a BOB on the left overlapping another one right of it. PP has overlapping and sometimes show fringing artifacts when two objects overlap, but it is not noticeable in game due to the fast motion. Anyway, PP is normally not considered as an example of an especially good-looking game - even though it has a strange fascinating vibe for me because it's so different.
chb is offline  
Old 27 February 2019, 22:41   #27
TEG
Registered User

 
Join Date: Apr 2017
Location: France
Posts: 31
Quote:
Originally Posted by ross View Post
Interesting.
I have not tried your code so I do not know how effective it is.
But with this technique you could not have wrong colors instead of the fringe for the first pixes after the indexed? Because when you insert the indexed pixel you do it 'in the middle' of a possible series of modified pixels.
To move from one color to another you need 3 'steps' minimum, so a little bit of color errors should be visible..
Yes but the idea was just to remove what the eye perceive as unacceptable: red or green fringes suddenly appearing.

@thellier
I agree with the "correction map", thanks for the idea. I guess a lot of optimization can be done.
I don't want to use sprites. Too limited in colours, it's ugly on an HAM screen.
TEG is offline  
Old 28 February 2019, 12:16   #28
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 783
Quote:
Originally Posted by TEG View Post
Yes but the idea was just to remove what the eye perceive as unacceptable: red or green fringes suddenly appearing.

@thellier
I agree with the "correction map", thanks for the idea. I guess a lot of optimization can be done.
I don't want to use sprites. Too limited in colours, it's ugly on an HAM screen.
As I read Thellier's post, he meant the opposite, while he called Blitter Objects "Sprites": the BOBs in full HAM and the background in palette.
Gorf is online now  
 


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:49.


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