Atari 8-Bit Graphics Capabilities

[Gunstar]

22 minutes ago, flashjazzcat said:

You mean the descender text mode? That's ANTIC mode 3.

 

Ok, so there is a graphics mode 3 on that chart that is designated as Antic mode 8, and no Antic mode 3 shows up there for Antic, so is this a case like the GTIA "not really modes" for this Antic mode because it's for descender's? Never documented by Atari as a "mode?" Could someone argue this just like the argument that GTIA modes just...what, I forget...they seem to look and act like bitmap graphic modes to me from the perspective of an artist...

Edited July 21, 2019 by Gunstar

[flashjazzcat]

6 minutes ago, Gunstar said:

Ok, so there is a graphics mode 3 on that chart that is designated as Antic mode 8, and no Antic mode 3 shows up there for Antic, so is this a case like the GTIA "not really modes" for this Antic mode because it's for descender's? Never documented by Atari as a "mode?" Could someone argue this just like the argument that GTIA modes just...what, I forget...they seem to look and act like bitmap graphic modes to me from the perspective of an artist...

No: it's probably not listed because no graphics mode number corresponds to ANTIC mode 3. But it's a real mode as opposed to some other mode type augmented by the most significant bits of PRIOR. Only difference is that it requires a custom display list. The resident font and screen handler aren't geared up to support the descender mode and - say - a twenty line screen editor, so I guess it was pointless attaching a CIO graphics mode to that ANTIC mode.

 

The 'GTIA' modes are only called GTIA modes because they weren't present on the CTIA chip. Those modes differ from mode F (on which they are based) solely in terms of the way GTIA interprets the bits in the pixels as colour information (and the horizontal resolution as far as the "S:" device is concerned).

[Gunstar]

Thanks @flashjazzcat . So what exactly is the "mode" I've heard referred to as mode 7+ which for decades, even paint programs that claim mode 7+. IIRC it is twice the vertical resolution of mode 7, or 160x192, with 4 colors, which seems to me to be redundant anyway with mode 15? would there be a memory advantage for some reason? And how is it achieved compared to mode 15?  There must be some reason people used it instead of mode 15...

Edited July 21, 2019 by Gunstar

[flashjazzcat]

I always understood "Graphics 7+" or "7+1/2" to be Graphics 7 with twice the vertical resolution and thus twice the memory requirement - i.e. Graphics 15. The only thing special about modes 12 thru 15 is that they weren't natively supported by the 400/800 OS, AFAIK. You could always build a custom DL to get at them, but the XL/XE OS brought with it proper CIO graphics modes which allowed these four modes to be invoked like any other.

 

[Gunstar]

Ok, so 7+ was something that could be done without a custom display list before the OS supported the other modes then? How was it invoked, if you know, or anyone? Or is 7+ just what they called mode 15 back when they did have to use a custom DL and it wasn't designated as mode 15 by the OS yet?

Edited July 21, 2019 by Gunstar

[flashjazzcat]

9 minutes ago, Gunstar said:

Ok, so 7+ was something that could be done without a custom display list before the OS supported the other modes then? How was it invoked, if you know, or anyone? Or is 7+ just what they called mode 15 back when they did have to use a custom DL and it wasn't designated as mode 15 by the OS yet?

The latter.

[Gunstar]

Here is a compilation I found somewhere that describes the Atari's "software" graphic modes, which I guess covers mixed modes, as well as interlacing page flipping and other tricks. At least what was invented at the time, @R0ger 's new modes could be added as well as a couple others I've seen threads for in recent months and years. It also doesn't include the way Rasta converter (and I think Images done with G2F) accomplishes what it does. Some of these software modes have viewers/converters for them, and some even have paint programs that utilize them, and in the case of Pryzm and Interpainter, I think the modes were introduced with the paint program of the same name.

 

Any Point, Any Colour

The APAC System, or Any Point, Any Colour was a software-driven display mode capable of displaying an image using all 256 of the Atari's possible colors. By taking 80×192 mode lines that displayed 16 hues, and those that displayed 16 shades, and either interlacing rows of them, quickly alternating between rows of them, or both, a screen displaying 80×96 or 80×192 pixels in 256 colours could be perceived.

APAC was created in early 1987 and later introduced in the magazine ANALOG Computing, Issue #60, May 1988 in an article by Tom Tanida. The source code was written in 6502 assembly language.

APAC used a Display List Interrupt, or DLI, after each line of the screen was drawn to alternate between GTIA Graphics Mode 11 (15 hues) and 9 (15 shades of grey) of the GTIA chip. The hues and luminances would blend together on the screen (usually a television) to create the effect of a palette of 256 visible colours, with the artifact of a thinner, horizontal blank line in between each visible line.

APACView

In 1992, Jeff D. Potter created a GIF decoder and image viewer for the Atari called APACView.

ColrView mode (as I mentioned in regards to the Computer Eyes hardware, using red, green and blue lenses to take 3 pictures to allow 4096 colours with Computer Eyes)

Later, Potter created another GIF decoder, and later a JPEG decoder was created, which broke an image into the three red, green and blue channels. 16 shades of each, at 80×192 pixels, would be displayed in an interlaced and flickering fashion. The human eye's persistence of vision would allow the viewer to see 4096 colours (12 bpp) at 80×192, with slight 'rolling' artifacts in solid red, green or blue fields in the image. This was called ColrView mode.

Pryzm

Independently, in 1990 Darryl Yong created a similar software-driven display mode called Pryzm capable of producing an image that could be perceived to use all 256 of the Atari's possible colours with full 80×192 resolution. This was achieved using vertical blank interrupts to rapidly change between GTIA Graphics Modes 9 and 11. Programming interfaces for Atari BASIC, Action!, Turbo-Basic XL were included.

Interpainter

In 1993, Michael Franczak of the Polish demo group TIGHT wrote a graphics paint program called InterPainter. It creates 160x192 pictures which use 9 colours, by switching two 160x192 bitmaps every Vertical Blank Interrupt.

FlickerTerm 80

In 1994, Clay Halliwell created FlickerTerm 80, an ANSI/VT100 terminal emulator program, which uses 40×24 text mode, combined with two character sets with an identical 4×8 font—one with the pixels on the left half of the 8×8 grid, the other on the right. By alternating where in memory ANTIC looks for graphics, and which font to display, an 80×24 character screen can be displayed. It uses less memory (about 2 KB) and can be more quickly manipulated, compared to rendering 80×24 characters using a 320×192 bitmap mode (which would require about 8 KB). The disadvantage of this mode is the 60Hz flicker on all displayed charactes (50Hz on PAL systems). As such, it was most legible on monitors with high-persistence phosphors.

HARD Interlacing Picture

In 1996, Atari demo coders HARD Software from Hungary created HARD Interlacing Picture (HIP), which can display 160×192 pixels in 30 shades of grey. It interlaces two modes — 80×192 with 16 shades of grey, 80×192 with 9 paletted colors — and utilizes a bug in the GTIA chip that causes one of the modes to be shifted ½ pixel, allowing for a perceived 160 pixels across.

Later, other demo coders created RIP graphics mode, which is similar to HIP, but can display 160×192 pixels in colour.

Another variant is the TIP mode, which alternates between Graphics 9, 10, and 11 and can display 256 colours at about 160x100 resolution.

Champions Interlace

In 1996, the Polish demo group Atari Programming Champions released Champions Interlace (CIN), a viewer which shows pictures in 160x192 bitmap mode with 64 colours. The technique involves switching between Graphics 15 and Graphics 11 every scanline, giving off 16 colours at 4 luminances.

SuperIRG

In 1998, Bill Kendrick created a puzzle video game for the Atari (Gem Drop) which utilized a similar effect, but by using two alternating character sets (fonts) in coloured text. (Each character is 4×8 pixels, each pixel being one of 4 colors.) No colour palette changes occurred, and ANTIC's display list wasn't altered — only a vertical blank interrupt was used to change the character set. This allowed for approximately 13 colours on the screen. Solid colour fields that were based on two actual colours (e.g., dark red created by flickering between red and black) had less artifacting because they could be drawn in a checkerboard fashion. This mode was called SuperIRG. (Normal 4×8 multi-colored text on the Atari is called IRG.) 

Text modes related to Super IRG

In 2010, Bobby Clark documented an additional 18 display modes which are related to Super IRG, in that these modes are also based on a Vertical Blank Interrupt that changes the character set. In addition other flags, such as the GTIA setting and colour registers, are modified as well. Here is a listing of these display modes:

Super IRG 2: A modification of Super IRG, in which colour register data is shifted every VBI in addition to the character set, allowing for 23 colours on screen, but with no character dithering.

Super 0: This mode is based out of GRAPHICS 0 (ANTIC 2) and shifts the character set, background color and text luminance every VBI. As a result, each character is 8x8 pixels and can display 4 colours. When Graphics 0 artifacting (NTSC only) is taken into account, 16 colours can be perceived on screen.

DIN (Display Interlace): This mode shifts the Display List every VBI, between ANTIC 4 and ANTIC 2. The result is an 8x8 character grid with two colours, overlaid by a 4x8 4-colour character grid which adds additional color data, allowing an effective character resolution of 8x8 with 10 colours available. With Graphics 0 artifacting (NTSC only), there are 20 colours perceivable.

Super 9: This mode is based out of Graphics 0, but with the GTIA flag set so that it displays GRAPHICS 9, the 16 monochrome shade mode. The character set and background register are modified every VBI, resulting in a 2x8 character grid which can display 256 duo-tone shades.

Super 10: Similar to Super 9, this mode instead has the GTIA flag set to GRAPHICS 10, the 9 colour palette mode. As in Super IRG, only the character set is shifted every VBI, allowing for a perceivable 45 colours at 2x8 character grid resolution. A dithering pattern can be used in this mode, in a similar fashion as Super IRG.

Super 11: Similar to Super 9, except that in this case the GTIA flag is set to GRAPHICS 11, the 15 hue mode. The background register is shifted every VBI, which affects the brightness of these graphics, allowing for a 2x8 character grid which can display 256 colors at 3 luminance levels.

APAC 0: This is the text equivalent of the APAC mode. The GTIA flag is cycled between GRAPHICS 9 and 11 every VBI, in addition to the character set flip. This allows for any of the Atari's 256 colour palette (16 hue x 16 luminance) to be displayed in a 2x8 character grid.

HIP 0: This is a text mode variation of the HIP mode. The GTIA flag is cycled between GRAPHICS 9 and 10 every VBI, in addition to the character set flip. A 2x8 character grid with 16 monochrome shades displayable, is overlaid with a 2x8 9 color palette character grid, which has been shifted one color clock to the right. This gives an apparent pixel resolution of 160x192 for the display mode, with 144 colours displayable per character cell.

CHIP 0: This display mode is a modification of HIP 0, except that the GTIA flag is cycled between GRAPHICS 10 and GRAPHICS 11. Anywhere between 128 and 144 colors can be displayed per character cell, at an apparent pixel resolution of 160x192 for the display mode.

CIN 12/13: Inspired by the Champions Interlace bitmap mode, this mode is based out of an ANTIC 4 display list, but with the GTIA flag being cycled between normal mode, and GRAPHICS 11, and the 4 playfield colour registers in ANTIC 4 set to monochrome values. A 4x8 character grid which can display 4 monochrome shades, is overlaid onto a 2x8 character grid which can display 14 different hues. The result is a character resolution of 4x8 with 60 colours displayable.

Super CIN: A modification of CIN 12/13, but with a display list shift (as in the DIN mode) between ANTIC 2 and ANTIC 4 added. The GTIA flag shifts between normal mode and GRAPHICS 11, with the display list shift increasing the colour resolution to 80 colors (16 hue by 5 monochromme) at 4x8 character resolution.

MIN 12/13 and Super MIN (Monochrome Interlace): Similar to the CIN text modes, except that the GTIA flag is shifted between normal mode and GRAPHICS 9 monochrome under an ANTIC 4 display list, allowing between 60 and 80 colours (5 hue by 16 monochrome) to be displayed, at 4x8 character resolution.

PCIN 12/13 and Super PCIN (Programmable CIN): This variation on the CIN text modes shifts the GTIA flag between normal mode and GRAPHICS 10 under an ANTIC 4 display list, allowing for the display of 34 to 35 colours at a character resolution of 4x8. Because GRAPHICS 10 and ANTIC 4 share 4 colour registers, a dithering pattern can be used to reduce flicker, as in Super IRG, when using these colors.

CIN 0, MIN 0, and PCIN 0: These variations of CIN, MIN, and PCIN involve an ANTIC 2 (Graphics 0) display list, and a GTIA shift between normal mode, and one of the three GTIA modes. A 2x8 GTIA character grid is overlaid onto an 8x8 2-colour character grid, enabling display of 32 colours with CIN 0 and MIN 0, or 18 colors with PCIN 0. Making use of Graphics 0 artifacts will double these colors.
 

Edited July 21, 2019 by Gunstar

[Gunstar]

13 hours ago, Gunstar said:

Ok, I managed some much better pictures this evening with the lights off.

Here are RGBY 8x11f images, PAL S-video to VGA PAL-60 output at 1024x768 XGA on an LCD screen, brightness set at 45 and contrast at 90. NO upscaling or other effects, with my 1200XL's SV 2.1 video upgrade. Except the one image "Face" which has two pics and one is with my converter's upscaling/deinterlacing/comb filtering ON-but it does re-introduce some flickering that you can't see in the picture. As you can see, with my upgraded 1200XL video, on LCD VGA, the color saturation is much richer and works well for these images. The camera alters the colors seen in real-life a bit, but overall a good representation of what I see on my monitors, minus a little sharpness.

Sorry for quoting myself, but the reason I didn't include some of the other RGBY 8x7f images @R0ger posted was because of my phone's camera. In the other images (most with large dark areas) the camera will try to enhance the very dark reds or greens that are there instead of true black, and while doing so over saturates the other reds and greens (Robocop) and the photos look terrible, and trying to edit them back wouldn't be representing the real-life monitor image as close. It did this too a lesser extent on other images, but not nearly as noticeable.

[Gunstar]

Referring to my post above listing the software graphic modes...just when you think that everything hardware wise, and with clever programming, and exploitation of bugs for tricks has been found or tried, someone comes along with another way, generally another improvement with the on-going fight between graphic resolution and color depth, not just a different way. Like the graphics of Rastaconverter images or @R0ger 's new ones. I can't wait to see further improvements on RGBY and other new software modes emerge! And don't bother saying it's run it's course, that's been said before. (I'm not referring to R0ger's modes, but what can  be done in general manipulating the Atari's graphics in different ways)

Edited July 21, 2019 by Gunstar

[Gunstar]

4 hours ago, flashjazzcat said:

I always understood "Graphics 7+" or "7+1/2" to be Graphics 7 with twice the vertical resolution and thus twice the memory requirement - i.e. Graphics 15. The only thing special about modes 12 thru 15 is that they weren't natively supported by the 400/800 OS, AFAIK. You could always build a custom DL to get at them, but the XL/XE OS brought with it proper CIO graphics modes which allowed these four modes to be invoked like any other.

 

All right, well from now on, when I try and explain the Atari's graphic capabilities this will be my response:

 

The Atari has 8.3 graphic modes and 6 text modes with a palette upto  128/256 (4096 virtual/perceived) colors, depending on the graphics mode, or mixed modes, resolutions ranging  from 20x12 to 320x192/336x240 (overscan) and colors on screen ranging from 2 up to 256 (4096 perceived virtual colors) and 4.4 to 5 player/missile sprites of 4, 2x240 missiles(all the same color as corresponding players) to 4-5, 8x240, (x1 color each) which can be used to enhance on-screen colors and animation within graphic modes. With different limits on resolution and color palette and depth within those ranges, depending on the hardware or programmed mixed-mode. The graphic modes can be manipulated on the Atari hardware through assembly/machine language like a sand-box mode, with undefined, as of yet, overall limits to what else can be done within those ranges and pushing hardware graphic limits beyond the documented ones through this programming manipulation. These programming abilities have been greatly enhanced with the release of the Altirra emulator for more precise manipulation then possible on the real hardware.

 

Is that fair and cover the technical truth enough?

 

Of course that's not even including Escalpaint, which also wasn't listed in the software graphic modes, that, IIRC, can have 4096 perceived colors from a virtual/perceived palette of over 32 thousand? Though I think it works pretty much the same as colrview/Computer Eyes R,G,B mode with flipping screens, but I don't know how they get the large palette. But the rest sounds good enough to not mention it.

 

I suppose, also, that there could be a mention of known limitations of P/M re-use and multi-plexing are of hardware and software sprites and scrolling abilities of the graphics for a more over-all graphic ability description, beyond static screens.

 

 

Edited July 21, 2019 by Gunstar

[+Adam+]

One of the "software-driven modes" that is not on the list from post #182:

 

Graphics modes can be mixed by switching between 2 modes every second line. As I checked, GR.9 can be mixed successfully with high resolution GR.8 - the result is: hi-res details, 16 shades and no flickering Additional PMG allows to use extra colours as an underlayer: in GR.8 lines missiles and players can modify the hue of playfield pixels, in GR.9 lines missiles can modify hue and luminance of pixels.

 

I've created that kind of graphics for "Assembloids XE" in 2013 (unfortunately this game is PAL only), coded by Xeen, music & sound effects by stRing.

 

 

This is how two of the in-game faces look after separation of the modes:

 

 

 

P.S. Yikes, it's my post number 500 here on AtariAge

[+CharlieChaplin]

Errmm,

 

"Later, Potter created another GIF decoder, and later a JPEG decoder was created, which broke an image into the three red, green and blue channels. 16 shades of each, at 80×192 pixels, would be displayed in an interlaced and flickering fashion. The human eye's persistence of vision would allow the viewer to see 4096 colours (12 bpp) at 80×192, with slight 'rolling' artifacts in solid red, green or blue fields in the image. This was called ColrView mode."

 

there is a small error in that description ("and later a JPEG decoder was created..."). JView was the name of the tool that Jeff Potter created, J stood for the authors name (Jeff) and NOT for JPEG, since that tool only converts GIF-87a pictures into the Colrview modes (Gr.8/9/15 as three separate + uncompressed R,G,B or one compressed *.RGB pic/s). Nowadays almost everyone assumes that JView means JPEG view, but thats not the case, you can only view+convert GIF-87a with it. And errmm, viewing such Gr.9 Colrview pics on a PAL A8, you see nowhere near 4096 colours, not even 256 colours, just 3-4 colours with 16 shades each (very disappointing, luckily the Gr.15 Colrview mode works good on PAL; made several hundred conversions myself back then). Think the only JPEG viewers/decoders we have on the A8 are by Raphael Espino, named A8JDPEG and CPEGview or something like that...
 

Edited July 21, 2019 by CharlieChaplin

[emkay]

OK.

Actually , I hate those scanlines. The Atari needs only one type of scanlines , if mixing of resolutions is wanted.

 

 

Remember:

 

 

Yes, it's my old friend  You see 3 different modes in one scanline, you see "high resolution" colored text , and standard Modes in one game screen. On a real monitor you won't see any "scanline"... no flicker....

 

As I had chosen to use the PMg for a Pause Mode in that game, and for a simple switch inbetween, no PMg is used in the graphics. So there is a lot potential to add colors and details with ease. 

Not to tell that the display information of the game is 3 times in density...

Edited July 21, 2019 by emkay

[+CharlieChaplin]

12 hours ago, +Adam+ said:

You mean something like Gury's page about standard graphics modes?: http://gury.atari8.info/ref/graphics_modes.php

 

I agree, outstanding work by R0ger. But I'm wondering, why still there is no separate thread?

Yep, these are nice examples of standard A8 gfx modes. Okay, would be even nicer to have some more examples from famous A8 demos and games, but thats at least a good start. Think these screenshots and a few more (from demos and games), as well as screenshots for newer/modern A8 gfx modes would belong in this thread...

 

Regarding Roger's pictures, I also wish there would be a separate thread...

 

[Gunstar]

41 minutes ago, CharlieChaplin said:

Errmm,

 

"Later, Potter created another GIF decoder, and later a JPEG decoder was created, which broke an image into the three red, green and blue channels. 16 shades of each, at 80×192 pixels, would be displayed in an interlaced and flickering fashion. The human eye's persistence of vision would allow the viewer to see 4096 colours (12 bpp) at 80×192, with slight 'rolling' artifacts in solid red, green or blue fields in the image. This was called ColrView mode."

 

there is a small error in that description ("and later a JPEG decoder was created..."). JView was the name of the tool that Jeff Potter created, J stood for the authors name (Jeff) and NOT for JPEG, since that tool only converts GIF-87a pictures into the Colrview modes (Gr.8/9/15 as three separate + uncompressed R,G,B or one compressed *.RGB pic/s). Nowadays almost everyone assumes that JView means JPEG view, but thats not the case, you can only view+convert GIF-87a with it. And errmm, viewing such Gr.9 Colrview pics on a PAL A8, you see nowhere near 4096 colours, not even 256 colours, just 3-4 colours with 16 shades each (very disappointing, luckily the Gr.15 Colrview mode works good on PAL; made several hundred conversions myself back then). Think the only JPEG viewers/decoders we have on the A8 are by Raphael Espino, named A8JDPEG and CPEGview or something like that...
 

Ok, so an error in what something is to be corrected and also stipulations need to be added in depending on NTSC or PAL machines. Because I've used Colrview and looked at images with it on my NTSC Atari and it does do what and how it says on NTSC. I remember being amazed with an image of Kirk and Spock.

Edited July 21, 2019 by Gunstar

[+CharlieChaplin]

1 hour ago, CharlieChaplin said:

"Later, Potter created another GIF decoder, and later a JPEG decoder was created, which broke an image into the three red, green and blue channels. 16 shades of each, at 80×192 pixels,

 

The correction is very easy:

"Later, Potter created another GIF decoder, named JView, which broke an image into the three red, green and blue channels. 16 shades of each, at 80×192 pixels..."

Just replace "and later a JPEG decoder was created" with "named JView" - that's all.

 

[+Stephen]

9 hours ago, Gunstar said:

Isn't there a chroma-pot or something on the UAV board? Is it only the RGB versions that improve chroma saturation or do they not do it either?

No - the pot on the UAV is to make the artifacting colours match 400 or later XL styles.  I do not know of anything that boosts chroma saturation.

[+CharlieChaplin]

Here are some RGB pictures from my collection (most Anime/Manga pics have been converted by me, while I only collected the others). Boot the images with Basic enabled, since the viewer on most of them is written in Basic, first press 1 for Dir. of drive 1 and then A to view all RLE-compressed RGB pictures.

 

Did also some .PCX emulator screenshots of four RGB9 pics. (with PAL settings and OlivierP palette) and when XnView counted the colours of these PCX images it said, they have between 30 and 49 colours (converted them into JPG then for those that cannot view PCX images, but the colour count for these JPEG's is incorrect and way too high compared to the original pictures)...

 

RGB9_screenshots.zip RGB_pics.zip

[Gunstar]

18 hours ago, CharlieChaplin said:

 

The correction is very easy:

"Later, Potter created another GIF decoder, named JView, which broke an image into the three red, green and blue channels. 16 shades of each, at 80×192 pixels..."

Just replace "and later a JPEG decoder was created" with "named JView" - that's all.

 

@CharlieChaplin First, let me say I'm sorry, I quoted the wrong post.

 

I looked at some of those images you posted, and you are right, they are nothing near 4096 colors and frankly, look bad. But I came across one image that was actually the palette that this particular RGB mode can display a couple dozen colors (I think it says in the list I posted), but most are incredibly washed-out and nearly B/W "shades" as you said. But these RGB images are made up of several graphics 15 screens of 160x192 of red, green and blue, so all the colors and shades are made up of only 4-5 shades per image x3,  so if that is 4 shades then 4x4x4=64 colors. If it's 5 shades on each then 5x5x5=125 colors. but the colors just don't come out as colorful, no matter what you adjust, in the way this RGB mode flips or combines the three images, like the conversion process did not account for washed out colors or source image was not prepared properly with too high a gamma or something.

 

The Colrview images (which I'm still trying to locate the viewer and pics in my archives) uses GTIA mode 11(?) with 16 shades of red, green and blue in each of the three flipping images, 16x16x16 and creates 4096 virtual colors on-screen with 80x192 resolution (NTSC), but also, with Colrview images, you are directed to turn the screen brightness down until the yellow border on the menu screen becomes a dark orange, IIRC, before loading an image, then of course you could adjust the brightness to your liking from there, but it allowed for colors that were more saturated looking, even if the images were dark (best viewed in a dark room) and it works really well. At least on NTSC systems with the fast page-fipping too.

 

I have yet to try it on my PAL computer, or on an LCD screen. The last time I viewed a Colrview RGB image was when my 1084S CRT monitor was working and my 1200XL was still an NTSC machine. However, I do have an NTSC 800 that I can view them on also, but still it would be on an LCD screen, not CRT that I think the mode works best on, with the brightness way down. 

 

I did find it to be true with these images you posted of G15 RGB, that if you turn the brightness way down more colors are visible, but even at the higher resolution, the colors are mostly still too washed out except for the darkest ones. It's just not as good an RGB mode, even if it is twice the resolution. But the mode was clearly not designed to have the brightness turned down, as it really didn't bring out much more color at all, even if I also tried turning up the color saturation. like ColrView images do. Unless, I come to discover that they look great on a CRT, and they just don't work right on LCD for color since it's a digital display instead of analog, 

 

The other problem with all RGB modes is that the perception of all that color is contingent to the flipping of images or scan lines which creates either a rolling or flickering effect in constant motion, for the eye to pick up the perception of virtual colors, and photos and screen shots just don't work as still images. I'm not even sure how it work out trying to demonstrate them on video.

Edited July 22, 2019 by Gunstar
quoted wrong post

[Synthpopalooza]

If anyone is interested ... I did a series of experiments rendering pictures in a variety of Super IRG modes.  Some were ok and some were nice.  

Probably the highlight of this is the GTIA mode picture where I used a DLI change to allow a unique 256 color palette per scanline.

Edited July 22, 2019 by Synthpopalooza

[Gunstar]

5 minutes ago, Synthpopalooza said:

If anyone is interested ... I did a series of experiments rendering pictures in a variety of Super IRG modes.  Some were ok and some were nice.  

Probably the highlight of this is the GTIA mode picture where I used a DLI change to allow a unique 256 color palette per scanline.

Yes, this is some very cool stuff it looks like, I can't wait to take a look. 

[Synthpopalooza]

This one here ... Graphics 9 in text mode, double buffered.  BAK is changed every character line and character sets and BAK are additionally flickered each character line.  The result is a unique 256 color palette per scan line.  About 4,000 colors can be put onscreen at once.  The effect looks better on NTSC or a modern LCD.

[Synthpopalooza]

The drawback to a lot of these type pictures is they can get flickery though there are some techniques to deal with it.  There were also a series of font editors I wrote which seemed to get some notice in the ABBUC 2011 software contest ... I was surprised. 

[Synthpopalooza]

And this ... in a mode I termed PCIN ... Graphics 12+10 ... it's about a 35 color mode, in areas where the PF colors mix you can checkerboard and reduce flicker.  This is from the Space Ace laserdisc game.  The possibility of using this mode to do the game on the Atari was discussed but never got very far.

[Gunstar]

I know the scene well, from the arcade and from my Jaguar CD game.   

 

I do think it would be a good mode for a game.

Edited July 22, 2019 by Gunstar