Что интересно - на S-Video муар хоть и поменьше, но всё равно он есть. И ещё впридачу появляются какие-то непонятные вертикальные полосы Шириной чуть меньше пикселя...
Что интересно - на S-Video муар хоть и поменьше, но всё равно он есть. И ещё впридачу появляются какие-то непонятные вертикальные полосы Шириной чуть меньше пикселя...
С уважением, Александр.
Scorpion ZS-256 Turbo+ GMX-2048
SID-Blaster/ZX
Музей ретрокомпьютеров в Минске!
Здесь ничего нет => http://byteman.by
И здесь тоже --->>> http://bytespace.by
Этот эффект есть и на аналоге. Только более сглаженный, что ли.
Думаю, что для его минимизации, во-первых, должна быть качественная цветовая несущая, синусоидальная, а не упрощенный меандр, как, например, в NES. А во-вторых, должно быть качественное разделение яркостной компоненты и цветовой поднесущей в самом телеке.
Согласно тому, что я читаю, проблема не в качестве цветовой поднесущей, а в том, что для яркостной составляющей сигнала отведена слишком узкая полоса.
Больше игр нет
Как может быть отведена для яркостной компоненты узкая полоса, если разрешение в яркостном канале от 0 до 3.5МГц по стандарту NTSC. На 3.5МГц начинается яркостной мусор, т.к. это уже цветовая поднесущая, и ее просто надо эффективно отфильтровать, чтобы информация из нее не перешла в яркостной канал в виде муара. Где тут чего-то может быть отведено неправильно? Могут стоять кривые фильтры, которые плохо вычистят поднесущую, таким образом мы ее увидим в виде яркостного муара. Или же сам сигнал может получить яркостную помеху от поднесущей при смешивании, например.
Не то что бы отведено неправильно, скорее злоупотреблено тем, что отведено. Если бы яркостная составляющая честно фильтровалась перед тем как стать частью композитного сигнала, проблемы бы не было, наверное. Но, как бы это могло получиться?
В строке у компьютера, например, 256 пикселей. Время строки 1/15625c, значит если хотим иметь 384 пикселя (256 видимых и бордюр), один пиксель == 1/15625/384 c. Выходит, что верхушка частоты, даже если пиксели выдавливаются не в виде резких прямоугольников, а гладким фильтрованным синусом, 15625*384 = 6.0МГц.
У PAL-а цветовая поднесущая 4.43 МГц. Никак не получается в нее не вляпаться если хочется иметь "высокое разрешение" 256 пикселей в строке. Хотя, чисто теоретически, во время одной строки системы PAL, включая невидимую часть, упихивается 4.43e6/15625=283.5 цветных пикселя. В видимую, я считаю примерно 80% — 230.
У NTSC дела обстоят еще (х)уже. Так и что мы увидим, если все зафильтруем "как положено"?
Больше игр нет
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Да. Это за время вообще всей строки, 64мкс — включая синхру и портики. Собственно видео в этом — 51.95мкс, то есть 230 "настоящих" точек на всю ширину экрана. А C64 в HIRES режиме показывает что-то вроде 320 точек в строке, еще и стиснутых бордюром.
Больше игр нет
Насколько я помню, цветовой сигнал вырезается режекторным фильтром. А это значит, что из сигнала убирается только частота .4,4 МГц (плюс, минус). Итого мы имеем полосу аж до звукового сигнала.
И среди всех систем у NTSC самые больше помехи от цветного сигнала.
ого понаписали то
и во первых,и во вторых,и в третьих! совершенно верно дружище.Этот эффект есть и на аналоге. Только более сглаженный, что ли.
Думаю, что для его минимизации, во-первых, должна быть качественная цветовая несущая, синусоидальная, а не упрощенный меандр
аналогичного характера полоски,на своей SMD,я заборол именно заменой генератора поднесущей .
придумайте как это сделать для С64-и будет вам счастье.
про режекторный фильтр тоже близко,но увы и ах не для современных цифровых тв.
Скрытый текст
Apollo 1260 75mhz | 64mb | Mediator | VooDoo3 | RTL8139 | hdd | dvd-rw | OS3.1
Pentagon 1024 sl2.2 | ZXMC2 | neoGS | TSFM | nemoIDE | hdd | cd-rom
ATM 7.10 | hdd | cd-rom
Commodore 64 | fdd
БК 0010-01
and some retro consoles/pc stuff...
[свернуть]
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)