| |
algorithm
Registered: May 2002
Posts: 705 |
Tri Fli or other graphic modes...
Has there been any other recent custom graphic modes apart from x-fli or shifli. There was someone experimenting in a graphic mode known as tri-fli which can theoretically display thousands of colors.
Crest seem to be the experts in this field. When will crossbow finish 'meet crest'?
|
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Hmm.. Ok, i'm not a member of Crest, so i might not be authorized to answer this. But let's just face some facts:
The c64 has 16 hardware programmed colors, and will never have more. There are a few ways to *simulate* or *fake* more colors, like interlace, dithering etc.. Well, just use your imagination and do the best out of it! But you'll never get thousands of new *real* colors, even if you call it tri-fli, that's for sure :). |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
And trifli will flicker like hell, damn ugly. Could look a bit better on refresh-accelerated c128's with some more than 50hz, with pal, that is. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
HCL wrote:
"The c64 has 16 hardware programmed colors, and will never have more. There are a few ways to *simulate* or *fake* more colors, like interlace, dithering etc.. [...]"
that's not true. the PAL decoder works in a way that the color carrier of the current line is mixed 50% with the color carrier of the previous line. just take two colors with the same luminance (brightness) and put them in alternating rasterlines, those two colors will mix perfectly. on PAL, you can really say that the c64 has a lot more colors than those 16 hardwired ones. |
| |
Oxidy
Account closed
Registered: Mar 2003
Posts: 80 |
Quote: HCL wrote:
"The c64 has 16 hardware programmed colors, and will never have more. There are a few ways to *simulate* or *fake* more colors, like interlace, dithering etc.. [...]"
that's not true. the PAL decoder works in a way that the color carrier of the current line is mixed 50% with the color carrier of the previous line. just take two colors with the same luminance (brightness) and put them in alternating rasterlines, those two colors will mix perfectly. on PAL, you can really say that the c64 has a lot more colors than those 16 hardwired ones.
Do you know where I can find more information about how the PAL decoder work?
Colours with the same luminance will mix, most graphicians and all coders that were active during the "rasterbar era" know this, but a single "lonely" pixel can only have one out of 16 colours. Interlacing can work, but then again, it must have the same luminance or it will flicker like crazy. We can cheat and trick our eyes, but still, 16 it is.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Graham: Yes, so there you got another way of mixing colors, which perhaps is a bit more *real* than the others. You mix to colors and you get 16^2/2 colors (with half resolution) where most of them are unusable.
Is there anyone who knows *anything* about what tri-fli is? or is it *top-secret* Crest stuff ;) |
| |
Dane
Registered: May 2002
Posts: 423 |
One, two, THREE Fli-screens flickering madly...no, not even the colourblind forces of Crest are mad enough to actually do this anytime soon. Something for a demo like..."Visual Breakdown"? |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
It's here:
http://mars.wiwi.uni-halle.de/ec64/technical/discovery/issue1.h..
Unfortunately in German, but maybe babelfish can translate it roughly. |
| |
aeeben
Registered: May 2002
Posts: 44 |
"wow" - But I want 8 fields at 6.25 Hz... 320x100 pixels (4 vic banks and then use the yscroll trick to show either first or second half of the bitmaps and illegal mode to mask out the lower 100 pixels every second frame) How many colors do we have then? :) |
| |
Dane
Registered: May 2002
Posts: 423 |
*grossed out*
I'll stick to IXL-FLI, thank you very much. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
..so, if i understand that article right, tri-fli is basicly just some *design rules* to make your FLI-pictures or whatever less flickering!
Every c64 graphichian should read it! ;) |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
Duh! I just read it again and noticed that the article is in English! :-o
Never mind... |
| |
algorithm
Registered: May 2002
Posts: 705 |
It should not be too much of a problem in reducing the 'flickering' effect in interlaced modes.
I remember in my Amiga Coding days experimenting in custom graphic modes that by having alternating odd/even lines in one image and the opposite in another, the flickering would be partially reduced. I think one of the parts in crest's 'avantgarde' (The Wham interlace pic) uses this method.
eg
pic1 line1. Info from picture1
pic1 line2. Info from picture2
pic1 line3. Info from picture1
pic1 line4. Info from picture2
pic2 line1. Info from picture2
pic2 line2. Info from picture1
pic2 line3. Info from picture2
pic2 line4. Info from picture1
rather than
pic1 Entire picture1
pic2 Entire picture2
by having similar intensities combined with this method, it will result in an interlaced image with barely any noticable flickering especially when viewed on a tv set.
therefore it might be possible to have another interlaced image and flick 4 screens. (although FLI fullscreen would possibly have to be ruled out)
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
HCL wrote:
"Graham: Yes, so there you got another way of mixing colors, which perhaps is a bit more *real* than the others. You mix to colors and you get 16^2/2 colors (with half resolution) where most of them are unusable."
all of the colors are usable since you cannot avoid the color mixing. a graphician who draws pictures on C64 or vice with pal emulation will automatically use it.
Oxidy wrote:
"Colours with the same luminance will mix, most graphicians and all coders that were active during the "rasterbar era" know this, but a single "lonely" pixel can only have one out of 16 colours."
nopes, every pixel is a result of chrominance mixing. you only get the real 16 c64 colors when you use wide areas with the same color, because then the 50% mixing will mix with the same color...
it's ofcourse most obvious for colors of the same luminance, but also every other colors mix. just put blue and yellow on alternating rasterlines. you will see that both colors are far less saturated because mixing blue with yellow will result in something quite grey.
|
| |
Oxidy
Account closed
Registered: Mar 2003
Posts: 80 |
How can one lonely pixel have more that 16 colours on the c64?
My definition of a lonely pixel is a pixel surrounded by another colour (=background). And there can't be anything besides the background that affects the pixel colour. (or is there?) Alternating the background will give variations, but that wasn't the assumption.
A thought - if every pixel is the result of chrominance mixing (which it is) then it shouldn't be possible to get any of the real c64 colours, as the number of pixels aren't infinite. The outer pixels will mix 50%, and the one within with the outer mixed pixel, and so on... never reaching 100%.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Graham: Yes, you can use all of those colors, of course, and as you say: in real PAL-world you always *have to*. But i don't think this was the discussion. This is not tri-fli we're talking about, it's simply PAL. PAL will always give us strange mixes of those hardwired 16 colors, but what new have we gained with that!?
These are still important facts though, which i think not too many people take into account, so thanx for telling us!
algorithm: Yes, that's a much nicer way to use interlace. It isn't better in theory, but in practice it looks better! Have a look at the logo-stretcher in 'Interruptus Retriggerus' / Booze Design, it uses this technique. Rather smooth :).
Oxidy: If you put many pixels of the same color above each other, then PAL will mix them to the *right* color. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Oxidy wrote:
"How can one lonely pixel have more that 16 colours on the c64?"
a lonely pixel only will have one of the 16 c64 colors if you choose a color with the same chrominance. for example, a light red pixel on red background will be a true c64 color. or a grey pixel on black background. but if you choose a yellow pixel on blue background it will be very close to grey.
Oxidy wrote:
"Alternating the background will give variations, but that wasn't the assumption."
exactly. with different background colors the lonely pixel will have different colors. for example, if you choose black as background, the pixel itself will only have 50% saturation because the chrominance is mixed with a not existing color carrier.
Oxidy wrote:
"A thought - if every pixel is the result of chrominance mixing (which it is) then it shouldn't be possible to get any of the real c64 colours, as the number of pixels aren't infinite. The outer pixels will mix 50%, and the one within with the outer mixed pixel, and so on... never reaching 100."
no, to decode the color the color carrier of the current and the previous line is needed which results in 50% mixing of both lines. the color carrier itself is not mixed with anything. |
| |
Oxidy
Account closed
Registered: Mar 2003
Posts: 80 |
Graham:
You're definitely the king of PAL.. ;)
Thanks for the info...
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Graham wrote "the PAL decoder works in a way that the color carrier of the current line is mixed 50% with the color carrier of the previous line." Does that mean this effect will only work on PAL machines or does it also work on NTSC machines? also Krill wrote "Could look a bit better on refresh-accelerated c128's with some more than 50hz, with pal, that is." do 128's have a quicker refresh then 64's? and do the 128's have this quicker refresh in 64 mode? |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Coming from NTSC-land, and being very pixel-aware, I've never noticed this phenomenon on NTSC devices. Only the horizontal blurring/colorsmear exists over here. IIRC, the PAL 50% vertical smear actually comes from additional circuitry intentionally put the display for that result? |
| |
Stryyker
Registered: Dec 2001
Posts: |
Stingray:Some messing on a C128 register allows some lines to be removed which makes the display frequency increase (more frames per second). Only works on C128. Go64! (paper mag) had this. It may also be discussed here somewhere. It's main use so far would be for interlaced pictures to reduce flicker. I know one of the Commodore newsgroups has talked about it too. It may be $d030 issue. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Found this quote by Brian Dougherty who was President of Berkley Software "The width of each pixel is almost half of the NTSC colour clock, so when you alternate the pixels of two different colours, instead of getting the two colours that you think your getting you get a whole new phase interpretation". This is from an artical about the commodore 64 at www.commodore.ca The artical says that the vic II chip can produce 128 colors this way. Any way is this the same thing as what Graham has been talking about with the PAL decoder but on an NTSC 64 or is this diffrent? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
@stingray:
it works but it has some major problems: the first and most important problem is that it only works with composite video, once you connect your c64 to the monitor via seperate chroma/luma cables, you won't have this effect at all.
the second problem is the "almost half ntsc color clock" not "half ntsc color clock". on atari xl/xe computers, it's half the ntsc color clock so you indeed get relatively clean new colors, but on ntsc c64 the pixel clock is slightly faster than the color clock, and on pal c64 the pixel clock is slightly slower, so you get interference patterns instead of new colors. |
| |
_V_
Account closed
Registered: Jan 2002
Posts: 124 |
Concerning the 'flicker' topic, which seems to be important for the research into Tri Fli... flickering isn't necessarily bad. It can be used as a design element in your picture, to make a part of it sCREAm for attention.
In a sense, it's abusing the visual effect of a crude 'animation', and when done properly, isn't a bad thing. It helps propagating a dirty, vibrant, 'gritty' look which can be quite nice to watch in, for example, industrial-styled demos. If you desire more smoothness, good results can be achieved by alternating pixels of decreasing luminance. But it's not mandatory.
While I can understand the quest for more 'smoothness', it doesn't mean that it should be the ultimate goal for all the artists in the world. In Photoshop, smoothing is one of the many filters you can choose. So is 'flickering' if you go for a crude animation in the animation editor.
Smoothness and flickering don't define the quality of a picture, they're simply tools in the artist's box of wonders and should be seen as no more than that, meaning they're equal in value. Putting one above the other is pointless.
Of course, moderation is key here. There is a difference between scREAMing elements and a flickerfest SCREAMING the living daylights out of every observer to the point where they're visually impaired for the next 15 minutes. But even then, it can have a beauty and a purpose. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I think that what we really need is not more pseudo-colors, but higher resolution and putting more effort into making interlaced gfx look less flickery. Unless it's done intentional for making it "scream" for attention, ofcuz. :-)
HCL's stretcher in Interruptus Retriggerus is a good example of how interlace should look like, if you want to avoid flicker. |
| |
Dane
Registered: May 2002
Posts: 423 |
Bah, what we need is more gfx in interlaced X-fli of course. :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I agree with dane. We have shitloads of unused software modes. Who needs then a new one ? How many pictures there were in shifli since krestology for example ? and how much in dane's xfli ? Prolly its too hard to make something nice in them, also they are memorykillers... but still :) |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Thanks Graham. Just wondering if this statement "it only works with composite video, once you connect your c64 to the monitor via seperate chroma/luma cables, you won't have this effect at all." holds true for PAL 64's? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quote: Thanks Graham. Just wondering if this statement "it only works with composite video, once you connect your c64 to the monitor via seperate chroma/luma cables, you won't have this effect at all." holds true for PAL 64's?
yes. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
It's all starting to make sense now. I've always used separate chroma/luma cables but I would like to use a composite cable and see these other colors. I understand that this is a by-product of mixing the chroma and luma signals together and this effect will be present in every picture (composite video) weather intended or not. But what I would like to know is if any one knows of any good examples of this effect being deliberately used to display >16 colors? |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
no, that effect is not present in every picture. it can only produced with hires pixels, because only with a pixel frequency that high you can get close enough to the frequency of the color carrier.
on NTSC you have a color carrier frequency of 3.58 mhz, and hires mode on ntsc c64s has a pixel clock of 8.18 mhz, so if you use alternating light and dark pixels, you get a frequency of 4.09 mhz. the filter which seperates chroma and luma will use all frequencies which are above about 3 mhz (depends on manufacturer) for color decoding, so that 4.09 mhz pattern will be used as chrominance, not luminance.
with PAL it's similar: color carrier frequency of 4.43 mhz vs pixel clock of 7.88 mhz... alternating pixels will now result in a 3.94 mhz signal, which is a bit below the 4.43 mhz, but because filters are not perfect parts of that wave will still be filtered into the chroma signal. |
