+Andrew Davie Posted October 23, 2013 Author Share Posted October 23, 2013 Thomas's last conversion, animating with the original. Useful way to look at what is happening, where. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 23, 2013 Share Posted October 23, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 23, 2013 Share Posted October 23, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 23, 2013 Share Posted October 23, 2013 Forgot the palette file. bmpconv2.zip Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 24, 2013 Share Posted October 24, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Nathan Strum Posted October 24, 2013 Share Posted October 24, 2013 I like #2 better. Some of the horizontal lines (particularly the bird's face) in #3 span too many pixels. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 24, 2013 Share Posted October 24, 2013 Of course 2 is better. This is the "theoretical optimum", using up to 18 colors/line. Quote Link to comment Share on other sites More sharing options...
enthusi Posted October 24, 2013 Share Posted October 24, 2013 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 24, 2013 Share Posted October 24, 2013 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... Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 24, 2013 Share Posted October 24, 2013 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
enthusi Posted October 24, 2013 Share Posted October 24, 2013 Here is another fine example of Thomas' code 2 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted October 24, 2013 Share Posted October 24, 2013 @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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 24, 2013 Share Posted October 24, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Nathan Strum Posted October 24, 2013 Share Posted October 24, 2013 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 24, 2013 Share Posted October 24, 2013 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. 2 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 24, 2013 Share Posted October 24, 2013 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 24, 2013 Share Posted October 24, 2013 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. Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted October 24, 2013 Share Posted October 24, 2013 Omegamatrix mentioned that some interesting effects could be done by shifting the sprites. Maybe that could be exploited for some kind of anti-aliasing. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted October 29, 2013 Share Posted October 29, 2013 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... Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted October 29, 2013 Share Posted October 29, 2013 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 . Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 28, 2016 Share Posted August 28, 2016 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 3 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 28, 2016 Share Posted August 28, 2016 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. 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted August 28, 2016 Share Posted August 28, 2016 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? Quote Link to comment Share on other sites More sharing options...
Tjoppen Posted November 26, 2016 Share Posted November 26, 2016 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 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 25, 2021 Author Share Posted September 25, 2021 Here's the MovieCart's effort... 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.