| |
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....
|
| |
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: 702 |
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: 716 |
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. |
| Previous - 1 | 2 | 3 - Next |
