APAC/Trucolour - a whole new approach

[Rybags]

I was going to add this to the "New true colour mode" thread, but this is an entire new approach.

We're all familiar with the HIP/TIP/RIP method of mixing Mode 10 with it's shifted pixels but in most cases it is used only as an extra luma channel.

 

I decided to create a picture which uses Mode 10 on every second frame to describe the colour channel.

 

 

So, we have 2 frames shown repeatedly:

 

Hue (Gr. 11)

Luma (Gr.10 describing luma as done ad infinitum before)

... repeat for 192 lines ...

 

Hue (Gr. 10 describing colour, with re-assignments as below)

Luma (Gr.9)

... repeat for 192 lines ...

 

One problem is that of course, Gr. 10 only allows us 9 distinct colours, but I've just performed substitution for certain colours. The table I used in generating the hues for Gr. 10 assigns the colours as follows:

Pixel Colour   Also reassign

0		 0
1		 1		14,15
2		 2
3		 3
4		 4
5		 5
6		 7	   6,8,9
7		11	  10,12
8		13

 

The assignments could probably do with some tweaking, in fact it might be optimal to decide on colour reassignments on a per-picture basis.

 

Here's the program that displays the picture - just binary load SIMPA1.XEX. Note - looks kinda crap on the emulator, but looks great on a real machine. Hold Start while the pic is displayed to prevent the frame switching.

 

SIMPA1.zip

 

Note2: seems the palette I used in photoshop has some of the blues mapped to Colour 10 - which explains why the water goes between green/blue. Have to fix that for later.

[Rybags]

I just looked at the program I used to generate the picture.

 

Seems it also has a problem - the colour reassignment is way out.

 

Correcting now, with luck once I've fixed it, it should look somewhat better, and hopefully less flickery.

[Heaven/TQA]

this looks much better even on emus than in the other thread...

[Rybags]

SIMPA2.zip

 

Here's one with a more correct substitution algorithm.

 

Still displaying green/blue - probably because I don't have a decent Atari palette for Photoshop.

 

Looks like I'll have to go hunting through some threads here and find a proper palette.

 

 

Using ver 4.1 of A800Win+ you don't get proper representation of the PAL colour blending. Hence, it will look different (ie worse) than real machine + TV

Edited May 3, 2008 by Rybags

[Heaven/TQA]

just playing around with some ideas... so actually i need to write 4 bytes to get 2 pixel on screen?

 

it looks like iFLI on c64 somehow...

[Rybags]

This one uses 2 screens, so just under 16K - and yes, 4 bytes for 2 perceived pixels.

 

You could also go all out and have a 4-screen version, with the colour done on the even scanlines, then odd.

 

e.g.

S1=11H, 10L ...

S2=9L, 11H ...

S3=10H,11L ...

S4=10L,11H ...

[Rybags]

 

JESS1.zip

 

 

Here's another one. Shows some nice definition of the hair.

 

Adapted from a pic which can be found at http://www.funponsel.com/images/jessica-si..._simpson_11.jpg

 

(I changed the colour of her top to blue)

[Rybags]

Here's another pic.

 

Note - NSFW, or wives/kids. In other words, topless.

 

I applied dithering with this one - for some reason Photoshop wanted to turn all the skin tones grey if I just went with the straight conversion to 256 colour palette.

 

WIFEY1.zip

 

(see if we can crack the hundred downloads on this one)

[Rybags]

 

UT3.zip

 

Taken from a pic of UT3.

[Heaven/TQA]

Rybags... is it not 4 am in AUS???

[Rybags]

Nah. Only 3:57

[Heaven/TQA]

http://www.atariage.com/forums/index.php?showtopic=89398

[twh/f2]

Nah. Only 3:57

 

excellent time to produce nice pictures like that!! :-)

 

grtx,

\twh

[Rybags]

Heaven - This method is a bit different from the last one I did - it just had the colour lines always as Gr. 11.

 

Here's a Level Start screen for your game...

 

 

A bit of a rush job.

 

Got the pic here http://mob.rice.edu/history/scripts/2007/tulsa-slide-0b.jpg

 

XEX file: HELL1.zip

[miker]

Well - seems interesting. I wonder how it looks on NTSC machines.

I ran the pics on my PAL 800XE and i realized that this mode produces a lot of flicker. It seems that this "truecolor" mode doesn't look good when the adjacent pixels have very different brightness.

The UT3 pic looks the best of all above. And the first pic or The Simpsons has better colors (the second one looks - "they are totally sun-baked).

 

 

Errm.. Why Wifey? Maybe a bit of Erica Campbell?

[Heaven/TQA]

Rybags... it seems you are on fire and in the "flow"-mode...

[Allas]

Rybags, great job! really you go where no man has gone before

It's impressive the amount of colors on my NTSC TV. This is potential photographic quality. Even the resolution seems to be high.

 

The bad new is, this picture flicks a lot. Like old TIP pictures, especially on white zones. Maybe should be an extra process on the pictures to reduce drastically this inconvenient. However the obtained results are great.

[+CharlieChaplin]

hmm,

since I am not a programmer, let me share some thoughts - but please don`t be angry if they are wrong or can`t be realized...

 

1) standard A8 gfx modes a) Gr.9 has 16 luminances, b) Gr. 10 has 9 colors, right ?!? Well, but Gr. 10 colors aren`t fixed, they could be any (nine colors) from the available A8 color palette, even 9 greys if you want, right ?!?

 

2) HIP/RIP mode: Gr. 10 allows the 160x200 (or 160x238) resolution in HIP + RIP,

a) HIP uses greys only, thus Gr. 9 uses greys and Gr. 10 uses greys also; but the luminance steps are somehow fixed, like

00, 02, 04, 06, 08, 0A, 0C, 0F to reduce flicker - correct ?!?

b) RIP uses color, but its Gr. 10 that uses colors (9 colors!) and Gr. 9 that performs the luminances, thats 9 colors each with

16 lum. that makes quite some strange colors, but in 160x200 (or even 160x238) resolution and low flicker...

 

----------------------------------

 

Now, according to Rybags (at least I hope so) how about that idea:

 

3) mix Gr. 10 + Gr. 11, here Gr. 11 gives us 16 colors, whereas Gr. 10 should give the luminances and the higher resolution (due to the Gr. 10 bug). Gives a lot of flicker right ?!? Ok, so let`s reduce Gr. 10 to eight luminances (where the 1st and last luminance are the same => black) and use fixed luminance steps like in HIP mode;

 

In the end we should / could have 16 colors each with 8 luminances = total of up to 128 colors, with a resolution of 160x200

(or 160x238) and hopefully some low(er) flicker... Now is that idea possible or just nonsense ?!?

 

-Andreas Koch.

 

P.S.: Would not be too surprised if some (all?) of my thoughts are wrong...

[+CharlieChaplin]

Errm.. Why Wifey? Maybe a bit of Erica Campbell?

 

 

Hmm, remove the "y" and you get "Wife" - Rybags wife perhaps

Ok, just a stupid joke - but one that comes to mind if you read "wifey"...

-Andreas Koch.

[Rybags]

No. That's Wifey - pretty famous in the web porn circles.

 

This mode does have it's compromises, but it's advantage is that you get a better illusion of the 160 horizontal resolution.

 

This work was fairly rushed, so these pics don't exactly have their colours produced optimally, and even the luminences could be better matched.

As said before, I've also been having problems with the colours - for some reason the palettes I have all seem to have blues represented in "Colour 10" which in fact on a real machine is a "bluish green". Of course, Photoshop seems to be a bit slack in it's hunt for a "best match" and for some reason is picking them.

 

Re luma - e.g. where GR.10 does the luma, I use value 2 to substitute 1. The problem you get especially with low luma values is that the steps are very marked. Once you get above about value 9 or so, even a difference of 2 isn't all that noticable.

 

The whole thing really just needs some tweakage. The best option would probably be to do it on a per-picture basis.

 

Finally, as with most interlacing schemes or GR.10/9 mixing schemes, you inherit the problem of flicker for lines that are only a pixel wide. A possible fix there might be to use some of the defocussing filters in Photoshop.

[dwhyte]

Would any of these modes be suitable for a game, or are they just good for a static display?

Edited May 4, 2008 by dwhyte

[Rybags]

The downside is that they require a graphics Kernal - you have to change the PRIOR register and COLBK every scanline of the pic.

 

Still, having a smaller vertical area would free up cycles, so a game is definately a possibliity in such modes.

 

I actually have an idea for a game, although it would be using a kernal as such to just give Gr.15 more colours.

 

 

Mountain__bridge.zip

 

Here's 2 more - a Mountain and a certain Aussie bridge.

 

The bridge one flickers rather much - probably due to single-pixel vertical lines. I like the clouds in the mountain one, but once again I've got problems with the sky flickering between green/blue and blue.

[+CharlieChaplin]

hmm,

can Interlace be mixed with DLI`s and PM ?!? Well, just another stupid thought, afaik G2F uses PM`s for additional colours and its also possible to use DLI`s there - think the mode is Gr. 12...

 

One can mix Gr. 15 with Gr. 11 for up to 64 colors, one can use DLI`s in Gr. 15 for additional colours, not sure if one can also use PM`s for additional colours there, but it would be cool to have all these things mixed: Gr. 15 + Gr. 11 + DLI`s + PMs to get as many colors as possible (or maybe use Gr. 12 + Gr. 11 + DLI`s + PM`s)... just a thought...

 

And err, interlace produces flicker, PM`s and DLI`s don`t, thus adding PM`s and DLI`s to a Gr. 15 + Gr. 11 picture would not generate more flicker, but as always, I am not sure if something like that is possible... -Andreas Koch.

[dwhyte]

The downside is that they require a graphics Kernal - you have to change the PRIOR register and COLBK every scanline of the pic.

 

Still, having a smaller vertical area would free up cycles, so a game is definately a possibliity in such modes.

 

I actually have an idea for a game, although it would be using a kernal as such to just give Gr.15 more colours.

 

Hmmm... text adventure with a drop-down screen like "The Pawn" or "Guild of Thieves" using this mode has now been jotted down in my to-do-list...

[analmux]

hmmm, it isn't needed to throw away ALL the cycles in the kernel.

 

a sequence of

sta wsync
lda #mode
sta gprior

 

costs 10 cycles if I'm correct. Then there can be done some other things.

 

Imagine some unrolled code that does 4 or 5 moves, and every time such a group of instructions is executed, glue it together with the above routine.

 

I think there are scenarios where this can work well. F.e. when you need some piece of unrolled code working with a double buffer.

 

lda source1
sta destination1
lda source2
sta destination2
lda source3
sta destination3
lda source4
sta destination4
lda source5
sta destination5

sta wsync
lda #mode
sta gprior

lda source6
sta destination6
lda source7
sta destination7
lda source8
sta destination8
lda source9
sta destination9
lda source10
sta destination10

sta wsync
lda #mode
sta gprior

lda source11
sta destination11
lda source12
sta destination12
....
etc.