|
16
Bit per Pixel
Interlaced
Truecolour
on
the Atari TT
Recently I dealt with the idea of improving my interlaced C2P
which provides an interlaced 12bit (444) mode on the TT in order
to reduce the flicker a bit. Well, after playing around with
some ideas it occurred to me that it should be possible to
actually display 65536 colours on a TT even if its video's DAC
only provides a 444 resolution and thus a maximum amount of 4096
colours.
So how can you achieve 16bit colour you might ask. Well, there
have always been simple tricks yielding to great effects in the
demo coding scene, right? Just look at Paradox' recent
achievement to make up an interlaced 14bit resolution providing
640x400 pixels which of course is far beyond the shifter's
original specifications.
Now the trick that I came up with on the TT is quite easy, not
requiring any synced code or anything similar, just plain
interlacing between two half-images based on the Jaguar's CrY
colourspacewhere colours get divided into a cyan-red part (Cr,
4-4bit) and into a luminance (Y, 8 bit) which was basically
chosen despite its non-standardness to implement fast and easy
gouraud-shading in the machine's Blitter AFAIR.
The CR table (which resides in the jaguar's video chip) can be
thought of as a colour-cube whose outline has been distorted to
fit a square so that a certain (CrY) colour's chroma value can
be addressed in a 2 dimensional array from two 4bit coordinates.
Illustration coming up:
It seemed obvious that I could use the TT's 8bpp greyscale mode
in order to fake the luminance layer in my interlacing scheme
and use the 2nd half-image to render the CR part with in a
palette taken from the Jaguar's ROM table.
Converting from RGB to CrY can be done by computing the RGB
colours luminance, use that one to normalize the RGB vector and
then find the closest match to the 256 ROM table entries. hint:
It's completely safe to use Y = max(R,G,B) as the luma and
normalization value instead of any perceptual formula or similar
as it gives better results in connection with CrY images...
However, there are convenient tools, such as TGA2CRY.TTP to
convert from RGB to CrY.
To demonstrate the capabilities of the emulated CrY mode I've
made up a little tool called CRYVIEW.TTP which is supposed to
run only on the Atari TT and which you should find in this
issue's "Filez" folder.
As you may notice there are some drawbacks: for one thing
there's obviously a lot of flicker involved, but I am already
working on a method that switches between colour and grey-mode
each scanline and flips grey and coloured lines over each VBL so
the flicker doesn't become that much laminar.
Secondly, using an interlaced grey half-image causes the Y layer
to be mixed in additively instead of multiplicative which means
that a luminance of 0 can't be achieved so that colours can't be
darkened completely. The third disadvantage is that the TT's
shifter uses palette register 0 to determine the screens border
colour which would be a bright blue in the CR table and black in
the Y ramp which produced pretty much unacceptable contrast and
flicker results. Hence I dropped colour 0 in the CR palette so
that colours with a CR value of 0x00 are rendered to the next
closer match (0x01) so that the amount of displayable colours is
reduced by 256 to 65280 which doesn't make a noticeable
difference anyway.
Ah and btw, a nice thing working in CrY mode is that you can
abuse the 68030 pack/unpk instructions which are actually meant
for converting BCD numbers to ASCII strings to quickly extract
the Cr channels bitfields into high and low byte order and
reorder them just as easily. The unpacked version provides you
with a pixelformat that lets you mix, average or filter your
image data for free. Just take a look into
"filez/cryview/cry.s" -> "antialiasImage" to get an idea of
what i'm talking about here. there are similar instrucions in
the jaguar's GPU suited to process CrY image data, but with the
68030 it works as follows:
; packed Cr pixels d0.w = **** **** C1C1 R1R1
; d1.w = **** **** C2C2 R2R2
unpk d0,d0,#0 ; #0 specifies an additional offset
unpk d1,d1,#0
; now unpacked d0.w = **** C1C1 **** R1R1
; d1.w = **** C2C2 **** R2R2
add.w d1,d0 ; Average the two pixels
lsr.w #1,d0
pack d0,d0,#0 ; Reorder into CCCC RRRR format
As you see the unpacked format reserves a field of four blank
pixels above each channel so that you can mix up to 16 pixels.
The Y channel can be filtered pretty much straighforward once
it's been extracted because it is nothing more than a plain 8bpp
channel so you don't need any packing/unpacking in its case.
Note: You can replace unpk by 'lsl.w #4,dx; lsr.b #4,dx' and
pack by 'lsl.b #4,dx; lsr.w #4,dx' in this special case on CPUs
lacking those instructions but this document is aimed at the
TT030, anyway.
If you have any questions regarding that CrY mode or if you are
interested in a double-pixeled (speed issues) c2p that converts
from a 16bpp CrY to an interlaced screen on the TT drop me a
line via ray(at)tscc(dot)de or via IRC (#atariscne) if you
manage to catch me up there.
Keep it real, stay Atari.
Ray / tSCc for Alive, 2005-12-20
|
