A Programming CHALLENGE

[+Andrew Davie]

 

Thomas's last conversion, animating with the original.

Useful way to look at what is happening, where.

[Thomas Jentzsch]

I hope this will look a bit better soon. (maybe I should evaluate errors in the middle stronger than at the borders... )

 

Regarding the two frames: This was ruled out, so I will not flicker the image.

Edited October 23, 2013 by Thomas Jentzsch

[Thomas Jentzsch]

Here is the code. I tried to add some simple error compensation, but the results are not very convincing.

 

I suppose the next step has to be to switch the color mode to CIELAB.

bmpconv2.zip

Edited October 23, 2013 by Thomas Jentzsch

[Thomas Jentzsch]

Forgot the palette file.

 

bmpconv2.zip

[Thomas Jentzsch]

No new code, just making sure the source pictures and palettes used are optimal.

 

Attached you see three updated pictures.

1. colors reduced to Stella's default NTSC palette, using Floyd-Steinberg with reduced color bleeding

2. reduced to 18 pixel using cubic interpolation (this is the theoretical optimum we can reach with this resolution and colors)

3. the result of my converter based on picture 2 (use the attached bmp instead)

 

As you can see, the differences between 2 and 3 are not very large, even with the still pretty simple code.

Parrot_NTSC_18pixel_fsr.bmp

Edited October 24, 2013 by Thomas Jentzsch

[+Nathan Strum]

I like #2 better. Some of the horizontal lines (particularly the bird's face) in #3 span too many pixels.

[Thomas Jentzsch]

Of course 2 is better. This is the "theoretical optimum", using up to 18 colors/line.

[enthusi]

Ah, great job.

I wonder if one could use a missle or such for at least the eye?

yeah, I know this is all about that nice algo now.

Btw, your source compiled fine but I wasnt quite sure yet what to make of it.

Input would be something like picture 2?

Cheers

[Thomas Jentzsch]

Input has to be an uncompressed, 24 bit BMP file, with the target resolution (here 18x200).

 

BTW: I just realized that I could have based my conversion on a picture with the original colors...

[Thomas Jentzsch]

The current result when I base the conversion on a resized, full color picture.

Parrot_24bits_18pixel.bmp

Edited October 24, 2013 by Thomas Jentzsch

[enthusi]

Here is another fine example of Thomas' code

[Omegamatrix]

@enthusi the missiles are already being used for the pixels to make 18 blocks. On my phone so hard to quote.

 

@Thomas are you building bins? I got functionality to produce data now in code.

[Thomas Jentzsch]

No bins yet, for now I am concentrating on the algorithm only. Why wasting time with creating 2nd best pictures?

 

(But of course you can adapt your code to my code.)

 

When I got the LAB colors working and found a way how to effectively compensate errors in the next pixel, I will add a way to add exchange 2 (maybe 3, I haven't calculated the limit yet) colors at some pixel positions. This should improve the picture even more.

Edited October 24, 2013 by Thomas Jentzsch

[+Nathan Strum]

I'm curious to see how large of a binary this will make in the end... and how we might be able to use it in some homebrew title someday.

[Thomas Jentzsch]

Before i leave for a long weekend, a small experiment. To get an idea of the potential of using 2 or 3 more colors, the picture here shows 4 instead of 3 colors per line.

[GroovyBee]

How about applying a Gaussian blur filter to the image before colour conversion? That might produce less "sharp" colour transitions in the parrot's body.

[Thomas Jentzsch]

I think the sharp transitions are the result of using simple RGB instead of better color systems for calculation. Plus there are only 128 colors available for interpolation.

[Joe Musashi]

Omegamatrix mentioned that some interesting effects could be done by shifting the sprites. Maybe that could be exploited for some kind of anti-aliasing.

 

[Omegamatrix]

I was looking into using 4 colors per line, and I found a lot of lines you spend precious writes repairing colors that you had to trash earlier. It is certainly possible to do 4 colors, and maybe more... depending on the line, but sometimes it get complex.

 

 

In looking at when the writes can occur I realized that we can have 3 unique colors for each side of the screen for each line guaranteed. This is enormously simpler, and could potentially do up to six colors per line. I was thinking at first that it might leave an ugly divide between the left and right sides, but maybe the color picking code could overcome this by comparing the block adjacent to its side to blend or link the colors.

 

 

- left side blocks can use GRP0 and M0, right side can use GRP1 and M1 (or vice-versa). What is important is COLUP0 and COLUP1 can both be set before the blocks get drawn leaving only 2 color updates to be done for COLUBK & COLUPF on the right side.

- place M0 where block 9 is, and M1 where block 10 is. Leave the missiles always enabled (says cycles too!). What ever the color is of block 9 will be the color chosen for P0, and likewise the color for block 10 will be the color for P1.

.

.

;                            |
; 01 02 03 04 05 06 07 08 09 | 10 11 12 13 14 15 16 17 18
;                         |     |  |
;                        M0     M1 |
;                                  |
;                                GRP1, PF, or BK (background color from left side)
;
;
;    stx    VBLANK                ;3  @37
;    nop                          ;2  @39
;    nop                          ;2  @41
;    nop                          ;2  @43
;    sta    COLUPF                ;3  @46  doesn't trash blocks 9 or 10, since they are not PF
;    sty    COLUBK                ;3  @49  doesn't trash block 11

.

.

Anyhow what I like about this is you are guaranteed 3 unique colors per side with little effort. This would be an unrolled kernel, but it is simple. If this works it should be possible to expand to more colors...

[Thomas Jentzsch]

I like the idea of reusing the colors from the previous line. But this will make the code and the palette optimizing even more complicated.

 

My calculation says that we can update three colors each scanline (using abs,y loads). Using DPC+ we could update the colors 4 or 5 times. But for now a non enhanced, stock Atari 2600 is my target .

[+SpiceWare]

With Bus Stuffing we can now create displays with 18 unique background colors per scanline.

 

NTSC

 

 

 

PAL60:

 

 

Sadly the parrot image never uses 18 unique colors per scanline, so here's a color bar test pattern:

 

NOTE: At this time you can only run these on real hardware using a Harmony cartridge. The specs for BUS are not finalized, once we've done that I'll be submitting BUS support for Stella to stephena. It's probably the spec will change enough that these won't work when Stella officially supports BUS, but since the driver is part of the ROM they'll always work on the Harmony.

 

WARNING: While we don't expect any problems, I've been testing this on my own system after all, this code is potentially dangerous to the Atari. As such, run it at your own risk.

 

parrot_bus_NTSC.bin

parrot_bus_PAL.bin

test_bus_NTSC.bin

[+SpiceWare]

This is the kernel I'm using to generate the above:

ShowPicture
    ldx #200+1
    sta WSYNC
PictureLoop:
    dex             ; 2  2
    beq PLexit      ; 2  4 (3 5)
    sty COLUBK      ; 3  7
    SLEEP 15        ;15 22   
    sty COLUBK      ; 3 25
    sty COLUBK      ; 3 28
    sty COLUBK      ; 3 31
    sty COLUBK      ; 3 34
    sty COLUBK      ; 3 37
    sty COLUBK      ; 3 40
    sty COLUBK      ; 3 43
    sty COLUBK      ; 3 46
    sty COLUBK      ; 3 49
    sty COLUBK      ; 3 52
    sty COLUBK      ; 3 55
    sty COLUBK      ; 3 58
    sty COLUBK      ; 3 61
    sty COLUBK      ; 3 64
    sty COLUBK      ; 3 67
    sty COLUBK      ; 3 70
    sty COLUBK      ; 3 73
    jmp PictureLoop ; 3 76
PLexit:
    rts

---

The SLEEP15 means we have time for 5 more TIA updates, which would allow us to display all 5 moveable objects over the background image. With those we could add 3 more distinct colors.

[Omegamatrix]

If you flipped your monitor on the side (like Merlin's Walls) you could make the pixels seem not as squished while getting all of the colors. Is that cheating?

[Tjoppen]

I think this thread has come far enough that we have a few varianst we could put side-by-side with the present image in the Wikipedia article, with a note saying what's possible with further trickery. I see a note on the talk page about the nesdev people having a similar discussion, so we should perhaps at least link the talk page to this thread also

[+Andrew Davie]

Here's the MovieCart's effort...