HAM scrolling

[meynaf]

Originally Posted by TEG

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.

[ross]

Originally Posted by TEG

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).

[TEG]

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.

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

[ross]

Originally Posted by TEG

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

[thellier]

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"

[chb]

Originally Posted by thellier

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.

[TEG]

Originally Posted by ross

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.

[Gorf]

Originally Posted by TEG

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.