A Programming CHALLENGE

[GroovyBee]

The A8 guys have a tool called RastaConverter that analyses images and converts them to target hardware format making the "best" use use of colour changes per line and PMG placement. Maybe the same techniques could be adapted to the limitations of the 2600 in some fashion?

 

You can see some of the graphics people have tried out in this thread :-

 

http://atariage.com/forums/topic/200118-images-generated-by-rastaconverter/

 

The PC app started life here :-

 

http://atariage.com/forums/topic/156160-quantizator/

[Thomas Jentzsch]

IIRC the Amiga's HAM modus only works with interlacing. So you would rule that one out too?

[enthusi]

Hm, does the Amiga even have that one palette it is limited to?

With regard to the wikipedia article, it directly shows the (or 'a palette', since RGB values dont actually match a 2600 palette) palette for PAL and NTSC and then that awful picture.

Interlace with different colors will result in colors not represented in that hardware palette at all.

_I_ would indeed rule that out - I hate to disagree but I love some fruitful discussion

My argument here:

best possible Parrot: interlace maybe

best Parrot as palette show-off for this wiki-article: 1 frame, no interlace

[tokumaru]

I agree with everything enthusi said. Flickering/interlacing effects do not represent what the console can render in one frame. A screenshot of Stella's phosphor mode is a manipulated image, and not what the TIA outputs. As I see it, that Wikipedia article is supposed to show the kinds of images the different video chips are capable of generating, and not the kinds of tricks your eye can play on you over time, which can't even be properly represented in a static image. No simulations of any other video chip in that article are making use of any tricks, such as composite video artifacts that can greatly increase the apparent number of colors in an image.

[Joe Musashi]

Actually, even the "Ugly Parrot" image is already borderline because the other consoles could do mid-screen color register changes as well. Since all of the 2600's graphics elements only have a single bitplane, the image should IMHO only have two colors. This would be even uglier, but the goal of the article is to highlight differences in the basic capabilities of the display hardware.

 

Then again, unlike the other consoles, the 2600 does not have a graphics processor that does the data fetching, so this has to be in software and you have no choice other than changing registers every line.

 

It would probably be best to have a second image that shows the parrot with tricks and make this clear in the description. But I still agree with enthusi that it should only be used what can be done in a single frame.

 

[SeaGtGruff]

Actually, even the "Ugly Parrot" image is already borderline because the other consoles could do mid-screen color register changes as well. Since all of the 2600's graphics elements only have a single bitplane, the image should IMHO only have two colors. This would be even uglier, but the goal of the article is to highlight differences in the basic capabilities of the display hardware.

 

I disagree with that last phrase. The goal of the article-- as indicated by its title-- is to illustrate the differences in the color palettes of the different video game consoles, not to highlight the differences (and limitations) in the basic capabilities of their display hardware.

 

The article says the images don't use dithering, but is that because dithering was considered to be "cheating," or for another reason? The article doesn't say why dithering wasn't used. It's true that dithering can give the appearance of additional colors, so the differences in the palettes are more easily seen if the pictures don't use dithering. But some of the pictures come close to using dithering simply because of the size of the pixels and the fact that different colors are used within a small area. And if we look at the companion article that shows different computer palettes, several of the images do use dithering-- they even say which dithering algorithm was used. So there's no real consistency regarding whether it's okay to use dithering or not. Why is it okay to use dithering with monochrome images or 8-color images, but not with other palettes?

 

As far as changing colors from line to line-- or even mid-line-- the NES picture would seem to indicate that color changes are acceptable (and the 2600 pictures also indicate that). The article implies that the NES picture was created by simply converting the original image to the NES palette, without attempting to make it a "realistic" example by conforming to the NES's display limitations-- "Because of the constraints mentioned above, there are no current simulated screen images available for the NES." It says that only 13 colors are available at one time for the background, yet the image contains 41 unique colors, therefore it can't possibly be "realistic"-- unless it's allowing for the possibility of changing the background palettes and/or using sprites to display additional colors (or, more likely, because no attempt was made to create a "realistic" NES example). As to why some of the other pictures don't use color changes, it may have simply been because the author(s) didn't take the extra time to create images that used color changes.

 

I do agree that if the intent is to illustrate what the original image looks like using the color palette of a given video game console (or computer), then "tricks" like mixing colors via flickering or by using the PAL color-blending behavior are out. But changing colors mid-picture, or using sprites to get more than 2 colors on a line, are probably okay. But it would be good to create multiple examples, as was done with the side-by-side dither-free and dithered images.

[Bit Expander]

I made another attempt to maximize the ability of the 2600 to display a picture.

 

My current "achievement" is a picture 19x192 in resolution (single frame) with each line having 13 different colors.

 

The hard part is to take an image and encode it optimally for the display, I'd appreciate any help...

 

What I basically do is use the sta, stx, sty, sax... type of speed-code mentioned earlier, but I added 3 loads that allow changing base colors and color "mixes" (SAX).

 

The 3 loads are "masked" by bars of P0, P1 and PF color (P0, P1 and BL) that contribute 3 independant colors as well.

 

I attached a randomized data screenshot +source.

 

16bitmap.zip

[Joe Musashi]

I disagree with that last phrase. The goal of the article-- as indicated by its title-- is to illustrate the differences in the color palettes of the different video game consoles, not to highlight the differences (and limitations) in the basic capabilities of their display hardware.

The title of the arcticle may be misleading. If it were only about the palette range, it would be enough to only show the respective sub-spaces of the RGB color space. The parrot images would not be needed. Yet it makes sense to have them, because on machines where not every pixel can be of any available color, it's necessary to make clear what the display restictions are.

 

The article says the images don't use dithering, but is that because dithering was considered to be "cheating," or for another reason? The article doesn't say why dithering wasn't used. It's true that dithering can give the appearance of additional colors, so the differences in the palettes are more easily seen if the pictures don't use dithering. But some of the pictures come close to using dithering simply because of the size of the pixels and the fact that different colors are used within a small area. And if we look at the companion article that shows different computer palettes, several of the images do use dithering-- they even say which dithering algorithm was used. So there's no real consistency regarding whether it's okay to use dithering or not. Why is it okay to use dithering with monochrome images or 8-color images, but not with other palettes?

Yes, what is most important is that dithering is (not)used consistently. Either it should be applied everywhere or not at all. As you say, it's better not to use it, because the more colors can be displayed, the more difficult it gets to see any differences.

 

I quickly looked over the 8- and 16-bit computer articels and I cannot find any dithered images except for the Apple II, where it is clearly mentioned. If this is mixed up somewhere it may be a mistake. Here's the image for 2-color CGA:

 

 

As far as changing colors from line to line-- or even mid-line-- the NES picture would seem to indicate that color changes are acceptable (and the 2600 pictures also indicate that). The article implies that the NES picture was created by simply converting the original image to the NES palette, without attempting to make it a "realistic" example by conforming to the NES's display limitations-- "Because of the constraints mentioned above, there are no current simulated screen images available for the NES." It says that only 13 colors are available at one time for the background, yet the image contains 41 unique colors, therefore it can't possibly be "realistic"-- unless it's allowing for the possibility of changing the background palettes and/or using sprites to display additional colors (or, more likely, because no attempt was made to create a "realistic" NES example). As to why some of the other pictures don't use color changes, it may have simply been because the author(s) didn't take the extra time to create images that used color changes.

I'm a bit too lazy to look up the NES specs now . If you are right and the image really can only be done with mid-frame color changes, this picture should be exchanged. For the SMS below, a 32 color image is shown and noticed that with raster interrupts the whole 64 color palette could be displayed.

 

I do agree that if the intent is to illustrate what the original image looks like using the color palette of a given video game console (or computer), then "tricks" like mixing colors via flickering or by using the PAL color-blending behavior are out. But changing colors mid-picture, or using sprites to get more than 2 colors on a line, are probably okay. But it would be good to create multiple examples, as was done with the side-by-side dither-free and dithered images.

In the end, there would have to be clear rules for a meaningful comparison. It would vote against using mid-frame changes not only it requires CPU assistance, also it may be very difficult to do on some machines. It does not seem it has been used for any of these images (except the VCS). Including sprites would make more sense, but that technique is not used in the companion articles for the home computers as well as in this article.

[+Nathan Strum]

I made another attempt to maximize the ability of the 2600 to display a picture.

 

My current "achievement" is a picture 19x192 in resolution (single frame) with each line having 13 different colors.

 

The hard part is to take an image and encode it optimally for the display, I'd appreciate any help...

 

What I basically do is use the sta, stx, sty, sax... type of speed-code mentioned earlier, but I added 3 loads that allow changing base colors and color "mixes" (SAX).

 

The 3 loads are "masked" by bars of P0, P1 and PF color (P0, P1 and BL) that contribute 3 independant colors as well.

 

I attached a randomized data screenshot +source.

 

 

Hmmm...

 

So maybe something like this?

 

[Bit Expander]

 

Hmmm...

 

So maybe something like this?

 

parrot.gif

 

VERY impressive, and fast! How did you decide on the optimal base colors, order of replacement and usage of SAX? I found it hard to define an algorithm, as I kept finding optimizations when trying to encode by hand...

[Thomas Jentzsch]

I suppose that just a resized image using an Atari 2600 NTSC palette.

 

I just tried that myself using GIMP.

1. scale image to 19x200 (cubic)
2. mode/indexed: use Atari 2600 palette (Floyd-Steinberg)
3. scale image to 304x200 (none)

@Nathan: In those cases, I always wonder which step order is the best. Is there a rule for it?

Edited October 17, 2013 by Thomas Jentzsch

[+Nathan Strum]

Thomas is correct - it's a mockup. If I could actually code anything, I'd post the real thing. But I'm pretty good at converting graphics, given specs to work from.

[+Nathan Strum]

I suppose that just a resized image using an Atari 2600 NTSC palette.

 

I just tried that myself using GIMP.

1. scale image to 19x200 (cubic)
2. mode/indexed: use Atari 2600 palette (Floyd-Steinberg)
3. scale image to 304x200 (none)

@Nathan: In those cases, I always wonder which step order is the best. Is there a rule for it?

 

That's the order I generally use. I use Photoshop, but the principles are the same. Sometimes I'll try different orders or scaling methods (nearest neighbor, bicubic smoother, bicubic sharper), just to see if I can push the end results one way or the other. Sometimes reducing the number of colors prior to scaling works better.

 

For example, you could convert the full-sized image to Stella's palette first, then back to RGB prior to scaling. This gets the colors more in Stella's ballpark prior to throwing away detail, but retains a higher bit depth for scaling. Then I'd covert it back to Stella's palette at the end.

 

This one scales down as RGB, then gets converted to Stella:

 

 

This one was converted to Stella, then back to RGB (the colors don't change, but the bit depth does), then scaled down, then converted to Stella again:

 

 

Sometimes I'll scale down in stages, too. Maybe going to 38 pixels wide first, then 19. Just in case it's throwing away some detail I don't want it to when making the bigger jump. In this case, it doesn't make a lot of difference, but there is some:

 

 

Scaling stuff down for bitmaps gets a bit trickier. In those cases I'll use Threshold or Posterize adjustments to dial in how I want the palette reduced.

 

These could be done using the same sort of 96 pixel bitmap as the Chetiry title screen. The difference here is this is just using three colors (RGB-ish), where Chetiry could do line-by-line color changes. If I took some time tweaking it, I could probably get better results.

 

 

 

This doesn't really show the 2600's palette though... it's just showing three colors.

Edited October 17, 2013 by Nathan Strum

[Thomas Jentzsch]

For a real 2600 optimizing the pixel colors will become pretty tough.

 

While we vertically have the full resolution, horizontally for each scanline we only have 3 colors available (plus a 4th color resulting from ANDing the color code of 2 colors), one of those 3 colors can be changed at 3 for the whole picture fixed pixel positions (e.g. pixel 5, 8 and 14).

Edited October 18, 2013 by Thomas Jentzsch

[enthusi]

There were some attempts to do generic gfx with just those 4 colors for the C64.

I wrote a converter for the "sonderbar"-demo and Veto pixeled some nice swan:

The demo utilized the heavy use of SAX for and-ed colors as well

 

Edit: that image spanned several screen vertically, but just used 12 horizontal 'pixels'.

Edited October 18, 2013 by enthusi

[GroovyBee]

While we vertically have the full resolution, horizontally for each scanline we only have 3 colors available (plus a 4th color resulting from ANDing the color code of 2 colors), one of those 3 colors can be changed at 3 for the whole picture fixed pixel positions (e.g. pixel 5, 8 and 14).

Sounds like the A8's G2F tool could help with the image given those limitations.

 

http://g2f.atari8.info

[Thomas Jentzsch]

Maybe, but I have no idea about all those modes and acronyms.

[Omegamatrix]

How about filling the playfield and using stores to COLUPF instead. You could set the playfield to score mode if one of the colors had the right bit. Turning score on/off could give 2 more colors. You could also have the background set for a third color bringing the total to seven.

[+Nathan Strum]

How about filling the playfield and using stores to COLUPF instead. You could set the playfield to score mode if one of the colors had the right bit. Turning score on/off could give 2 more colors. You could also have the background set for a third color bringing the total to seven.

 

Would the horizontal resolution still be 19?

[Thomas Jentzsch]

Yup.

[Thomas Jentzsch]

Maybe we should start with something simple? Like 19 pixel and just 3 colors/line? Since we can change all three colors each line, we should be able to mix the colors using the high vertical resolution.

 

Maybe such a picture can be calculated with some existing graphics software?

[Omegamatrix]

I'm still thinking about filling the playfield. It does have it's limitations:

 

- In score mode, the left side of the playfield takes the color of COLUP0, and the right side takes the color of COLUP1.

- The middle of the playfield might not line up with a color change like you would get from storing to the background color. Therefore the middle color changes are best done out of score mode. Also there might be a pixel that is not the correct color right at the change from left side playfield to right side playfield (this is a hardware consequence).

- You return to the playfield color you had before scoremode, when you diasble score mode. A work around is to leave score mode on and change COLUP0 or COLUP1 instead. Again you run into trouble in the middle of the screen, and you lose the original color for COLUP0 or COLUP1 for the rest of the scanline.

- Finally, you also still need the colors with the right bits (on or off). It might be easier to start with Score on and disable further down the line then to try and turn it on.

 

 

Leaving gaps in the playfield increases complexity as you also have to determine if the values written to the playfield will affect the symmetry of the playfield. Also score mode enabled with priority mode does not work, but without looking in Stella I don't recall which mode wins in this case (if any). So bits 0 and maybe 2 are a concern in CTRLPF writes. That being said flipping symmetry of the playfield could be advantageous depending on the line.

 

 

Still though an algorithm could be written for each case, and maybe their could some cases with partial playfields and the background color active as well (for 7 colors per line). There would be a lot of scenarios to check for though...

[+5-11under]

It's annoying that the only "fat" parrot is the one for the Atari 2600. Did the initial author(s) not think to use a landscape format picture. They also forgot the Microvision.

(could do better... )

[Omegamatrix]

I have a new idea for 18 block bitmap. Each block is 4 pixels wide.

 

- playfield in asynchronous mode to update any block outside of drawing area

- Vblank used to hide background color before and after 18 blocks

- GRP0 and GRP1 in quadsize, so each bit = 4 pixels

- Missiles used in 4 pixel mode.

 

 

BoringLines.zip

 

 

This way you have 4 colors to play with, and smaller blocks to stop the squashed look. The missiles are placed in the center so either COLUP0 or COLUP1 can be used there. In the rom I drew the top part of the screen with M1 and the bottom with M0. With this method everything can be set before the blocks are drawed. This leaves time to update with some more colors while they are being drawed, possibly bringing in a few more colors.

 

 

The big disadvantage right now is that GRP0 and GRP1 are stuck to different sides of the screen. However, CTRLPF can also be used to carry some of the colors to the other sides. I don't expect CTRLPF to be used though since at that point it would probably be easier to swap one of the colors to the background or playfield.

 

 

Finally as I write this I realized I should have slid P0 to the right by 1 block (4 pixels) so that all 8 bits could be used instead of 7, but It's late now...

 

 

Edit: I also realized I didn't show the 4th color (the background) because it's completely covered up by the blocks. It's there though behind the yellow, green, and (blue?) blocks.

[LS_Dracon]

 

 

I have a new idea for 18 block bitmap. Each block is 4 pixels wide.

 

 

 

- playfield in asynchronous mode to update any block outside of drawing area

 

- Vblank used to hide background color before and after 18 blocks

 

- GRP0 and GRP1 in quadsize, so each bit = 4 pixels

That I was planning to do, but the others tests result in a better image.

Obviously it can be made using 1 scanline resolution, but would be painful to convert by hand.

This is the left upper corner of the image only, and this is a macaw, not a parrot :

Edited October 19, 2013 by LS_Dracon