Jump to content
Andrew Davie

A Programming CHALLENGE

Recommended Posts

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

 

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

Edited by Thomas Jentzsch

Share this post


Link to post
Share on other sites

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 by Thomas Jentzsch

Share this post


Link to post
Share on other sites

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.

post-45-0-62591000-1382635327.png

post-45-0-85011100-1382635347.png

Parrot_NTSC_18pixel_fsr.bmp

post-45-0-39229000-1382635605.png

Edited by Thomas Jentzsch

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by Thomas Jentzsch

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

post-45-0-87650300-1382652782.png

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 .

Share this post


Link to post
Share on other sites

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

 

NTSC

post-3056-0-08369800-1472404622_thumb.jpg

 

post-3056-0-30355300-1472404479_thumb.png

 

 

PAL60:

post-3056-0-97735800-1472404486_thumb.png

 

 

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

post-3056-0-97093500-1472406148_thumb.jpg

post-3056-0-14294000-1472406000_thumb.png

 

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

  • Like 3

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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? :D

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...