Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Tri Fli or other graphic modes...
2003-05-20 07:37
algorithm

Registered: May 2002
Posts: 702
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'?
 
... 20 posts hidden. Click here to view all posts....
 
2004-02-23 15:28
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?
2004-02-23 17:05
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.
2004-02-23 17:26
_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.
2004-02-23 22:27
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.
2004-02-23 23:06
Dane
Account closed

Registered: May 2002
Posts: 421
Bah, what we need is more gfx in interlaced X-fli of course. :)
2004-02-24 10:16
Oswald

Registered: Apr 2002
Posts: 5007
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 :)
2004-02-26 13:20
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?
2004-02-26 13:52
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.
2004-02-26 14:33
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?
2004-02-26 17:00
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.
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
nucleus/TempesT
Hok/Remember
iAN CooG/HVSC
Guests online: 341
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.049 sec.