Комментарии 86
«PAL — это прежде всего про страны Европы и СНГ» странно, почему я всегда считал что на просторах необъятной вещание шло в формате SECAM?
Тоже удивило, потом понял, что речь про времена консолей. Секама на них уже не было в принципе
Почему же не было, было, но редко, в основном на самых ранних приставках в версии для Франции. Их делали по самому остаточному принципу, это как PAL, но с совершенно кривой палитрой. И была даже версия Dendy Classic SECAM, самые первые поставки. Потом пошли PAL.
Так и было до недавнего времени. У SECAM лучше приём в условиях помех, насколько я помню, поэтому для нашей необъятной она довольно удобна. Но у каждой системы есть свои специфические искажения и недостатки.
Все правильно был SECAM, но у ретро-консолей был только PAL для данного региона. И подавляющее число жителей СНГ тех времен ставили в телеки декодеры «SECAM в PAL», на чем, в свое время, очень сильно наварились теле-мастера.
НЛО прилетело и опубликовало эту надпись здесь
Именно поэтому подавляющее большинство игр для PAL региона, примерно на 17% медленнее чем было задумано изначально:
Вот этот момент нифига не очевиден. Развёртка там черезстрочная, но, обычно, консоли/микрокомпьютеры не страдали выдачей разных полукадров и дублировали один и тот же полукадр два раза. Привязываться к началу обновления экрана консолям было не нужно, но можно. В таком случае, действительно, частота обновления задаёт скорость работы программы. Но можно ведь и не привязываться — это дело видеоконтроллера не допускать сбоев картинки при изменении видеопамяти.
НЛО прилетело и опубликовало эту надпись здесь
Я тут подумал, и решил, что всё гораздо проще было. Был один кварц на всё, а частота экрана получалась его делением. И вот это кварц просто был разный для PAL и NTSC. Вот и всё.
НЛО прилетело и опубликовало эту надпись здесь
Однако, если бы железо позволяло, то программистам не нужно было привязываться к тактам.
Они привязывались не к тактам, они привязывались к прерыванию. А вот это уже прерывание привязывалось к основному кварцу.
Привязываются к тактам всюду и ещё как. Без точнейшей привязки к тактам нельзя написать ни одной игры на 2600, и едва ли получится сделать что-то на NES.
Интересно, как вы это делаете, если инструкции процессора имеют разное время выполнение и там масса переходов? Что же, программа во всех подпрограммах выровнена nop до одинакового числа тактов при любых ветвлениях? ;) Кто вам рассказал про это? Никогда никто по тактам программы не выравнивал, всегда используют что-то типа halt и ждут прерывания.
Знаете — это даже не смешно. Напоминает изумление моей малолетней племянницы эпизодом из трёх мушкетёров, где они отбирают разрешение для отплытия из Франции у Миледи: «но как так может быть — на документе разве фотки не было?».
Да и в Apple IIGS у 65C816 есть режим, когда переход через границу страницы генерирует лишний такт — думаете его ввели, потому что у них транзисторный бюджет слишком большой был?
Да, считают такты по всем веткам, вставляют задержки если нужно. Никакой программы без набора команд 6502 с растактовкой вы для 2600 не сделаете — ну никак. Такое железо. Почему, как вы думаете, Pitfall! считается таким прорывом? Да потому что никто и представить себе не мог, что на платформе без видеопамяти и прерываний можно сделать такое!
Никогда никто по тактам программы не выравнивал, всегда используют что-то типа halt и ждут прерывания.И как вы это предлагаете сделать на 6507, где для удешевления #IRQ и #NMI из корпуса не выведены?
Да и в Apple IIGS у 65C816 есть режим, когда переход через границу страницы генерирует лишний такт — думаете его ввели, потому что у них транзисторный бюджет слишком большой был?
Да, считают такты по всем веткам, вставляют задержки если нужно. Никакой программы без набора команд 6502 с растактовкой вы для 2600 не сделаете — ну никак. Такое железо. Почему, как вы думаете, Pitfall! считается таким прорывом? Да потому что никто и представить себе не мог, что на платформе без видеопамяти и прерываний можно сделать такое!
Это я просто не обратил внимание на 2600. Число и число. Ну так и написали бы atari 2600. Да, в столь ранних приставках выравнивали, это действительно так, поскольку видеопамяти фактически нет. Но в консолях 80-х такого уже не было.
Но в консолях 80-х такого уже не было.Было-было, ещё как было. Не во всей программе, как под 2600, но в отдельных процедурах. На Хабре даже есть перевод серии статей, где объяснялось как именно эти игры издевались над железом.
Многие эффекты там невозможны без подгонки всех операций по тактам — просто скорости железа не хватает всё на прерываниям делать.
но в отдельных процедурах.
Тут, вообще говоря, речь-то не об отдельных процедурах. В отдельных процедурах и milticolor делали на ZX. Но это не стандартный режим работы аппаратуры (потому и не работает на любом клоне zx).
НЛО прилетело и опубликовало эту надпись здесь
Обратите внимание, о чём, собственно, разговор.
Дано: Частота работы игры определяется стандартом PAL или NTSC.
Появилось утверждение, что цикл игры просто выровнен по тактам под видеосигнал. На это утверждение я ответил, что никто так не делает и есть прерывание задающее начало игрового цикла и, скорее всего, получающееся делением основного генератора (которые разные в PAL и NTSC версиях). И вот по этому прерыванию уже выровнена игра. Замечу, что этот ответ никоим образом нет отменяет выравнивание по тактам внутри игрового цикла отдельных процедур, в том числе, задающих операции с графическим процессором. Но сама игра работает с привязкой к частоте кадров не потому, что за один игровой цикл выполняет одинаковое количество тактов.
Дано: Частота работы игры определяется стандартом PAL или NTSC.
Появилось утверждение, что цикл игры просто выровнен по тактам под видеосигнал. На это утверждение я ответил, что никто так не делает и есть прерывание задающее начало игрового цикла и, скорее всего, получающееся делением основного генератора (которые разные в PAL и NTSC версиях). И вот по этому прерыванию уже выровнена игра. Замечу, что этот ответ никоим образом нет отменяет выравнивание по тактам внутри игрового цикла отдельных процедур, в том числе, задающих операции с графическим процессором. Но сама игра работает с привязкой к частоте кадров не потому, что за один игровой цикл выполняет одинаковое количество тактов.
кстати о миледи… а пол в документе отражен не был?
Там даже не было написано сколько человек с ней ехало. Дикие времена, дикие нравы…
В те времена границ, похожих на сегодняшние, в общем-то не было. Так что запрет касался кораблей. И разрешение его обойти тоже было на корабль. А если вы на корабле в эпоху парусников, путь даже и всего лишь через Ла-Манш, в одиночку поплывёте… можете ведь и не доплыть…
В те времена границ, похожих на сегодняшние, в общем-то не было. Так что запрет касался кораблей. И разрешение его обойти тоже было на корабль. А если вы на корабле в эпоху парусников, путь даже и всего лишь через Ла-Манш, в одиночку поплывёте… можете ведь и не доплыть…
Ну 2600 это отдельная статья: как вы без привязки к тактам вообще хоть что-то изобразите на железке без прерываний (на 6507 для удешевления отсутствуют входы #IRQ и #NMI) и без видеобуффера (там памяти только под одну экранную строку)?
Гораздо веселее привязка к тактам на PlayStation 2: там скорость такая, что это всё не так-то просто воспроизвести даже на современном железе, процессоров много (не SMP, они все разные), а синхронизации в большинстве игр нету, всё выверено по тактам…
Гораздо веселее привязка к тактам на PlayStation 2: там скорость такая, что это всё не так-то просто воспроизвести даже на современном железе, процессоров много (не SMP, они все разные), а синхронизации в большинстве игр нету, всё выверено по тактам…
а синхронизации в большинстве игр нету, всё выверено по тактам…
На PS2? Где такое написано? Вы это сами видели или просто кто-то где-то сказал?
Можете с разработчиками PCSX2 поговорить. Там у них куча настроек на эту тему. Вплоть до того, что у них есть отдельный «специально для Final Fantasy X» без которого в ней текстуры «рассыпаются».
Так это опять про отдельные процедуры, или «а синхронизации в большинстве игр нету, всё выверено по тактам…»?
Тут я боюсь мы будем долго спорить на тему что такое «всё».
Все процедуры, которые что-то делают на нескольких процессорах — просчитаны по тактам, никакой синхронизации внутри них нету в большинстве игр. Но, конечно вся игра в целом — нет. Там обычно довольно много кода, работающего только на основном процессоре. Его уже незачем в тактах считать… всё-таки почти 300MHz…
Все процедуры, которые что-то делают на нескольких процессорах — просчитаны по тактам, никакой синхронизации внутри них нету в большинстве игр. Но, конечно вся игра в целом — нет. Там обычно довольно много кода, работающего только на основном процессоре. Его уже незачем в тактах считать… всё-таки почти 300MHz…
Все процедуры, которые что-то делают на нескольких процессорах — просчитаны по тактам,
Разве её процессор Emotion Engine не использует параллельное выполнение инструкций? Он же суперскалярный. Сдаётся мне, что такого не может быть в конце XX века, а это значит, что есть возможность создания барьера, пусть даже на уровне процессора.
Он же суперскалярный.Суперскаляр — да, но спекуляций там нет.
есть возможность создания барьера, пусть даже на уровне процессора.Инструкции там есть, но ими не пользуются. Так как если вы не просчитаете всё в тактах, то синхронизация приведёт к тормозам, а если просчитаете — то нафиг она нужна?
Суперскаляр — да, но спекуляций там нет.
Так речь и не про спекулятивное выполнение. Просто если процессор выполняет несколько инструкций одновременно, то в чём тогда выравнивание по тактам (тоже синхронизация) процессоров, если на них запущен разный код? А если запущен одинаковый код, тогда это простое распараллеливание однотипных действий и совсем не интересно с точки зрения растактовки игры, так как синхронизацией по тактам процессоров не является.
А если запущен одинаковый кодКак вы собрались запускать там одинаковый код если это процессоры разную архитектуру имеют?
У вас просто в голове, похоже, немножко смешалось. Русская Wiki, как обычно, всё «опускает для ясности», но в Английской — всё чётко: The Emotion Engine consists of eight separate «units», each performing a specific task, integrated onto the same die. These units are: a CPU core, two Vector Processing Units (VPU), a 10-channel DMA unit, a memory controller, and an Image Processing Unit (IPU).
Как я сказал — это ни разу не SMP. CPU, VPU0 и VPU1 — это три разных процессора. Ну примерно как 8086 и 8087. И чтобы они не «разъезжались» есть способы их синхронизовать (что-то типа
fwait в 8086).Только вот игры этим почти не пользовались — просто рассчитывалось всё так, чтобы VPU выдавали результат ровно тогда, когда он нужен в CPU.
И писать это и эмулировать это всё — жуткий гемор…
Только вот игры этим почти не пользовались — просто рассчитывалось всё так, чтобы VPU выдавали результат ровно тогда, когда он нужен в CPU.
Так вот в этом варианте как раз хрень и получается. Если процессоры умеют выполнять несколько инструкций одновременно, как синхронизировать по тактам? Вы же не знаете, сколько тактов займёт выполнение программы — суммированием тактов на команду это число не получится. Нет, это можно выяснить для конкретной ревизии чипа, но, боюсь, очень трудоёмко. Вот что более реально, так это создать барьер и на этом закончить извращения.
Вот что более реально, так это создать барьер и на этом закончить извращения.И, тем не менее, во многих играх барьера нет…
Нет, это можно выяснить для конкретной ревизии чипа, но, боюсь, очень трудоёмко.Не так сложно, как кажется. Для процессоров класса Pentium или R5900 всё вполне считается: там может исполняться либо одна комнда за такт, либо две, причём ограничения это всё фиксированны.
А если чуток промахнулись — можно всегда пару Nop'ов добавить. Железка то — вот она…
Барьеры же — гораздо медленее, они и сейчас дорогие, а на «старых» процессорах они чуть не весь pipeline с нуля перезапускали…
В PAL/NTSC версиях приставок часто помимо кварца отличается много чего ещё. В той же NES делители другие, и в итоге на такт пиксельклока в NTSC приходится нецелое количество тактов процессора (ужасно усложняет жизнь, озвереть можно как), а в PAL целое. В PAL также сделали период обратного хода луча аж втрое дольше, что конечно очень хорошо, но если это применить, адаптация такой игры PAL>NTSC сильно усложняется.
ужасно усложняет жизнь, озвереть можно как
Чем? У вас PPU в NES живёт своей жизнью и сам выдаёт спрайты и всю остальную муру.
Усложняет сплит скролл, например. Он даже в первом SMB есть. Железо NES проектировалось ориентировочно в 1981 году и не предполагало никаких сложных игр. То, для чего оно делалось — простые одноэкранные аркады типа Donkey Kong. Все более сложные игры, пошедшие с 1985 года, результат выжимания всех соков и использования множество трюков, и всё это завязано на точное знание устройства CPU/PPU и их точной потактовой синхронизации.
Все более сложные игры, пошедшие с 1985 года, результат выжимания всех соков и использования множество трюков, и всё это завязано на точное знание устройства CPU/PPU и их точной потактовой синхронизации.
Пример такой точной потактовой синхронизации у вас есть?
К вопросу об усложнении жизни, написано на днях. У вас было столько приставок и компьютеров, я думаю, вы разберётесь, что это такое, зачем оно нужно, и как работает без подсказок.
Заголовок спойлера
;------------------------------------------------------------------------------
irq_line_sy_init:
lda #<_split_list
sta <IRQ_SPLIT_LIST+0
lda #>_split_list
sta <IRQ_SPLIT_LIST+1
rts
irq_line_sy_m:
;6 for jsr
lda #39 ;2
jsr timing_delay ;25+39
ldx #0 ;2
lda (IRQ_SPLIT_LIST),y ;5+
iny ;2
stx PPU_ADDR ;4
sta PPU_SCROLL ;4
stx PPU_SCROLL ;4
and #$f8 ;2
asl a ;2
asl a ;2
sta PPU_ADDR ;4 this write should be done on the hblank
rts ;6=109 including jsr
irq_line_sy:
sta MMC3_IRQ_DISABLE
pha
txa
pha
tya
pha
lda #69 ;2
jsr timing_delay ;25+69
ldy #0
_irq_loff_0:
;NTSC 113.6 CPU clocks per line
;to make up the .6 to an integer, lines needs to have slightly shifted timings in groups of ten
;five lines is 568 cycles exactly, but there is still a slight shift
jsr irq_line_sy_m ;109 0
nop ;2
lda <0 ;3
jsr irq_line_sy_m ;109 114
nop ;2
nop ;2
jsr irq_line_sy_m ;109 227
nop ;2
lda <0 ;3
jsr irq_line_sy_m ;109 341
nop ;2
nop ;3
jsr irq_line_sy_m ;109 454
nop ;2
lda <0 ;3
jsr irq_line_sy_m ;109 0
nop ;2
lda <0 ;3
jsr irq_line_sy_m ;109 114
nop ;2
nop ;2
jsr irq_line_sy_m ;109 227
nop ;2
lda <0 ;3
jsr irq_line_sy_m ;109 341
nop ;2
nop ;3
jsr irq_line_sy_m ;109 454
cpy #220 ;2 height of the raster
bcc _irq_loff_0 ;2/3
lda #0
sta PPU_MASK
pla
tay
pla
tax
pla
rti
Может мне тоже кинуть кусок какого-нибудь дампа хрен знает чего и посоветовать «как-то так. разбирайтесь»? Идея-то в чём?
> nop ;2
> nop ;3
Хм, не опечатка? Я после школы 6502 не мучал, но трёхтактного nopʼа не помню :/
> nop ;3
Хм, не опечатка? Я после школы 6502 не мучал, но трёхтактного nopʼа не помню :/
Спасибо за внимание! Да, конечно, опечатка, довольно частая у меня в подобных местах. Как раз подгонялись тайминги 'на живую', заменялись lda zp на nop и обратно, что поиграть ± такт, а комментарии после этого не поправил. К слову, в итоге этот код был переделан до неузнаваемости, теперь там табличка тактовой задержки для каждой отдельной строки.
Точная потактовая могла быть. Но вот вышеозвученный сплит-скролл делался довольно просто и без потактовой синхронизации — в NES есть регистр-счетчик, декрементирующийся каждую строку растра, и генерирующий прерывание при обнулении.
Увы, в базовой конфигурации такого нет. В ней есть три основных метода отлова нужной строки: точная задержка кодом, либо флаг пересечения пикселей нулевого спрайта с пикселями фона, либо флаг превышения кол-ва спрайтов на строку. Последние два позволяют не тратить время процессора совсем впустую, потратить кое-как часть на полезные действия.
Также есть особо чудной и самый козырный способ — прерывание по концу проигрывания DPCM сэмпла, можно сделать пустой сэмпл известной длины, запустить его в начале кадра, и получить прерывание близко к нужному месту, позволяя в это время работать основному потоку (соответственно звук лишается цифрового канала).
В любом случае после срабатывания флага или прерывания надо очень точным таймингом загнать нужную запись обновления регистров скролла в hblank, иначе будут артефакты. Регистры скролла только кажутся простыми (адрес и X/Y смещение), на самом деле там очень хитроумная логика, требующая планирования порядка записей — какая запись перезапишет какой внутренний счётчик, какие биты проигнорируются. И она была известна разработчикам ещё в 1985, используется в SMB, если эту логику не эмулировать, скролл не будет работать.
Прерывание по строке есть только в некоторых жирных мапперах, в частности MMC3. Но оно реализовано через аппаратный хак, с кучей ограничений. Нужно, чтобы был включён рендер. Нужно, чтобы тайлы спрайтов и фона были в разных банках PPU (включая режим 8x16). Нужно, что в конфигурации не было CHR RAM. Разные версии маппера имеют свои особенности, типа диапазона возможных строк. Прерывание приходит ближе к началу строки, когда записи уже делать поздно, и нужно программной задержкой ждать следующую строку — таким образом нельзя сделать обновление по прерыванию каждую строку, только через одну. Ну и другие приятные мелочи.
И не стоит забывать про джиттер. Во-первых, всегда есть джиттер на 4 такта, а процессор не отличается быстротой — легко промахнуться мимо hblank. Но есть хитрые способы отсинхронизироваться и удерживать стабильное смещение тактов от начала кадра. Также DPCM — если он используется в игре, каждый раз, когда происходит выборка байта, процессор тормозится, и вся синхронизация кадра уплывает. Типичное проявление — графические артефакты в такт ударным.
Также есть особо чудной и самый козырный способ — прерывание по концу проигрывания DPCM сэмпла, можно сделать пустой сэмпл известной длины, запустить его в начале кадра, и получить прерывание близко к нужному месту, позволяя в это время работать основному потоку (соответственно звук лишается цифрового канала).
В любом случае после срабатывания флага или прерывания надо очень точным таймингом загнать нужную запись обновления регистров скролла в hblank, иначе будут артефакты. Регистры скролла только кажутся простыми (адрес и X/Y смещение), на самом деле там очень хитроумная логика, требующая планирования порядка записей — какая запись перезапишет какой внутренний счётчик, какие биты проигнорируются. И она была известна разработчикам ещё в 1985, используется в SMB, если эту логику не эмулировать, скролл не будет работать.
Прерывание по строке есть только в некоторых жирных мапперах, в частности MMC3. Но оно реализовано через аппаратный хак, с кучей ограничений. Нужно, чтобы был включён рендер. Нужно, чтобы тайлы спрайтов и фона были в разных банках PPU (включая режим 8x16). Нужно, что в конфигурации не было CHR RAM. Разные версии маппера имеют свои особенности, типа диапазона возможных строк. Прерывание приходит ближе к началу строки, когда записи уже делать поздно, и нужно программной задержкой ждать следующую строку — таким образом нельзя сделать обновление по прерыванию каждую строку, только через одну. Ну и другие приятные мелочи.
И не стоит забывать про джиттер. Во-первых, всегда есть джиттер на 4 такта, а процессор не отличается быстротой — легко промахнуться мимо hblank. Но есть хитрые способы отсинхронизироваться и удерживать стабильное смещение тактов от начала кадра. Также DPCM — если он используется в игре, каждый раз, когда происходит выборка байта, процессор тормозится, и вся синхронизация кадра уплывает. Типичное проявление — графические артефакты в такт ударным.
Не все так просто, если вспомнить эпоху VHS, то там на 4% скорость отличались. И было очень заметно на слух, что тональность голоса немного другая. Ну и вообще в телевидении это было впринципе, когда пытались сигнал показать через иную систему вещания.
Развёртка там черезстрочная, но, обычно, консоли/микрокомпьютеры не страдали выдачей разных полукадров и дублировали один и тот же полукадр два раза.Попробуйте включить в любом эмуляторе frameskip=1 и «насладиться» игрой на 30 к/с.
Думаете, зря на ютубе при выкладывании геймплея cо старых консолей особо указывают — «60 fps»?
А зачем мне это пробовать?
Чтобы наглядно увидеть, что вы заблуждаетесь.
В чём я заблуждаюсь? В черезстрочной развёртке? Ну извините, так телевизор устроен. Что там в SNES не знаю, но NES, Spectrum, Amiga фигачат два одинаковых полукадра.
На этих приставках в основных режимах черезстрочная развёртка не используется, каждый полукадр идёт как самостоятельный кадр половинного разрешения. Содержание каждого полукадра отличается, оно не одинаковое. Т.е. приставки показывают 50/60 разных картинок в секунду.
То, что не используется сдвиг полукадра (т.е. честная черезстрочность, полукадр не на том же месте геометрически) — отчасти правда. Т.е. если пытаться взять и вывести картинку полного разрешения, выводя её в соседних полукадрах, она на многих подобных системах будет смотреться неправильно, как простое мерцание — если, конечно, не используется режим высокого разрешения (при наличии).
То, что не используется сдвиг полукадра (т.е. честная черезстрочность, полукадр не на том же месте геометрически) — отчасти правда. Т.е. если пытаться взять и вывести картинку полного разрешения, выводя её в соседних полукадрах, она на многих подобных системах будет смотреться неправильно, как простое мерцание — если, конечно, не используется режим высокого разрешения (при наличии).
На консолях и ПК, подключаемых к телевизору, не используется сдвиг полукадров. Фактически, полукадрами это называть вообще некорректно — телевизор просто работает, как монитор с разрешением 256×224(240).
каждый полукадр идёт как самостоятельный кадр половинного разрешения.
Нет. Там обычное дублирование. Полукадры совершенно одинаковы.
Т.е. приставки показывают 50/60 разных картинок в секунду.
25/30 и не более.
Это такой IT троллинг, я понял. Спасибо, прекращаю тратить время.
Странно, но я так же решил про вас. Уж больно не совпадает с тем, что я вижу на реальном железе (у меня есть и денди, и спектрум, и амига и я в своё время возился с их видеокадрами).
Может быть, вы только с эмуляторами знакомы? Там может быть как угодно, не спорю. Но реальные системы просто дублируют поля и всё.
Может быть, вы только с эмуляторами знакомы? Там может быть как угодно, не спорю. Но реальные системы просто дублируют поля и всё.
>>каждый полукадр идёт как самостоятельный кадр половинного разрешения.
Кстати, Amiga 500 даже не утруждает себя формированием указания на чётный полукадр. Я был очень удивлён, как телевизор Витязь воспринял такой сигнал — он его выводил строго как верхнюю половину экрана, так как решил что это режим без интерлейсинга и ожидал продолжения картинки, а Amiga забила хоть на какие-то различия полукадров. Впрочем, там можно настроить в workbench нужный видеорежим.
Выглядит вот так:
Кстати, Amiga 500 даже не утруждает себя формированием указания на чётный полукадр. Я был очень удивлён, как телевизор Витязь воспринял такой сигнал — он его выводил строго как верхнюю половину экрана, так как решил что это режим без интерлейсинга и ожидал продолжения картинки, а Amiga забила хоть на какие-то различия полукадров. Впрочем, там можно настроить в workbench нужный видеорежим.
Выглядит вот так:
Amiga по многим характеристикам куда ближе к тому железу, которое вы можете купить в магазинах сегодня, чем к 2600 или NES, вы уж извините.
А год-то разработки какой? ;)
На скринах в статье нифига не atari 2600 и даже не NES, кстати.
На скринах в статье нифига не atari 2600 и даже не NES, кстати.
А год-то разработки какой? ;)Какая разница какой там год разработки? Многие вещи, которые есть уже в самой первой версии Amiga в приставки и PC пришли ближе к XXI веку. Она очень сильно опережала своё время. Так что Amiga — это не очень показатель. Хотя подобрать для неё «правильный» Dell 2001FP было той ещё задачей…
Она, конечно, вся на ускорителях, но PC её догнали не к XXI веку точно. Скорее, к середине 90-х (за исключением режима переменной плотности пикселей в части экрана). Тем не менее, даже она со своими ускорителями выводит картинку изначально ровно как два одинаковых полукадра. Хотя, конечно, у неё широкие возможности программирования видеорежимов.
за исключением режима переменной плотности пикселей в части экранаЭто как раз одна из редких вещей, выдающих её возраст. Такие вещи как раз в 80е были распространены. Apple IIGS тоже так умеет (отсюда, кстати, шестицветное Apple лого: вот как раз его в меню Apple IIGS изобразить было можно… а если бы цвета не были именно горизонтальными полосками — то ничего бы не получилось).
Все консоли и почти все домашние компьютеры тех лет выдают только полукадры (отсюда разрешение 240/224 по высоте), и никакие кадры не дублируются. Все игры на консолях тех лет и большая часть игр на компьютерах типа ZX Spectrum привязываются к началу кадра. Почти на всех консолях до 32-битной эры доступ к видеопамяти возможен только во время обратного хода луча или принудительного гашения экрана (иначе либо сбои картинки при изменении видеопамяти, или — редко — задержка обращения до конца кадра), а попасть в обратный ход без привязки к началу экрана никак нельзя. Как правило в начале кадра всюду генерируется прерывание. А других таймеров в тех системах как правило нет, поэтому все действия привязаны именно к частоте кадров, и как правило с самых первых приставок до 32-битного поколения старались обеспечить полную полукадровую частоту обновления, 50/60 герц. Игры с медленной перерисовкой в основном встречались на компьютерах, где не было железа, чтобы обеспечить такую скорость, зато был более свободный доступ к видеопамяти (ZX-подобные).
Насколько я помню, в спектрумах доступ к видеопамяти возможен всегда. Скорость работы памяти вполне себе позволяла разносить такты запросов от видео-контроллера и процессора. Причем, запросы видео-контроллера еще и служили в качестве циклов необходимой регенерации DRAM (так как все равно проходили весь необходимый диапазон строк).
Про это я упомянул в конце сообщения. Да, у ZX доступ к видеопамяти возможен всегда, что позволяет делать более детализированную, хотя и существенно медленную графику. Т.е. можно выводить сколько угодно спрайтов, делать 3D рендер, и так далее.
Но там своя интересная специфика: ОЗУ делится на два поля, 16 и 32 килобайта, физически находящиеся в двух разных банках DRAM (т.е. там аж 16 микросхем памяти). Первое общее с видеобуфером, процессор при выборке байта видеоконтроллером тормозится (причём непосредственно через тактовый вход, не WAIT), поэтому в нижней памяти возникает очень сложный паттерн тактов. Также есть аппаратный баг, это торможение не срабатывает при некоторых условиях, в частности при размещении таблицы векторов прерывания в нижней памяти — тогда на экране возникает так называемый 'снег'. Второе поле памяти без торможения, весь критичный к таймингам код (биперная музыка, бордюрные эффекты, мультиколор) может работать только там. В ZX Spectrum 16K второго поля просто нет (не установлены микросхемы ОЗУ), соответственно все перечисленные эффекты там невозможны.
В поздних советских клонах схемотехника и элементная база сильно отличаются от оригинала, конфликт доступа к ОЗУ решён иначе, и в них уже одно общее поле памяти без тормозов.
Но там своя интересная специфика: ОЗУ делится на два поля, 16 и 32 килобайта, физически находящиеся в двух разных банках DRAM (т.е. там аж 16 микросхем памяти). Первое общее с видеобуфером, процессор при выборке байта видеоконтроллером тормозится (причём непосредственно через тактовый вход, не WAIT), поэтому в нижней памяти возникает очень сложный паттерн тактов. Также есть аппаратный баг, это торможение не срабатывает при некоторых условиях, в частности при размещении таблицы векторов прерывания в нижней памяти — тогда на экране возникает так называемый 'снег'. Второе поле памяти без торможения, весь критичный к таймингам код (биперная музыка, бордюрные эффекты, мультиколор) может работать только там. В ZX Spectrum 16K второго поля просто нет (не установлены микросхемы ОЗУ), соответственно все перечисленные эффекты там невозможны.
В поздних советских клонах схемотехника и элементная база сильно отличаются от оригинала, конфликт доступа к ОЗУ решён иначе, и в них уже одно общее поле памяти без тормозов.
Можно не привязываться. Но тогда у Марио ноги будут впереди головы бежать. Что бы кадры получались цельными, нужно все изменения проводить только между кдрами.
старые аналоговые pal, ntsc, secam (во Франции негативный)…
50 герц, 60 герц…
про особенности тактирования и вывода сигнала сказали…
Кстати, а почему в играх ntsc где сигнал на тв должен идти в формате (приблизительно, тк формат аналоговый) 480i, размер кадра по высоте больше, чем в pal с размером кадра 576i ?
А всё статью, ИМХО, можно свести к тому что: игры европейского региона калеченые от рождения, если играть, а не коллекционировать — берите американку.
50 герц, 60 герц…
про особенности тактирования и вывода сигнала сказали…
Кстати, а почему в играх ntsc где сигнал на тв должен идти в формате (приблизительно, тк формат аналоговый) 480i, размер кадра по высоте больше, чем в pal с размером кадра 576i ?
А всё статью, ИМХО, можно свести к тому что: игры европейского региона калеченые от рождения, если играть, а не коллекционировать — берите американку.
Кстати, а почему в играх ntsc где сигнал на тв должен идти в формате (приблизительно, тк формат аналоговый) 480i, размер кадра по высоте больше, чем в pal с размером кадра 576i ?Не понял вопроса. Если вы на телевизоре, где физически 576 строк отрисуете их только 480 — то как раз и получите чёрные поля сверху и снизу…
Самая большая проблема с поддержкой PAL/NTSC в том, что это в принципе не решаемо без значительных компромиссов. Допустим, мы задизайнили игру, где персонажи бегают с кратными частоте развёртке пиксельными скоростями — в простейшем случае каждое обновление герой или экран смещается на один пиксель (или раз в два кадра, или в три). Всё выглядит довольно плавно и красиво. Не важно, для какой из систем это было сделано изначально.
Теперь нам нужна поддержка другой системы, и нужно сохранить те же скорости движения, то есть откорректировать их на 17%. Мало того, что для одного варианта было достаточно целых чисел, а теперь нужна fixed point арифметика, что сильно медленнее (на старых приставках даже сдвиги дорогие), но мы никак не сможем сохранить плавность — появятся либо пропущенные перемещения за обновления, либо двойные, идущие определённым паттерном. И неважно, делать ли такую коррекцию на уровне отдельных объектов, или на уровне обновления всего экрана (т.е. дублировать каждый 6-ой кадр изначально-PAL игры на NTSC, или наоборот, делать два обновления каждый 5-ый кадр изначально-NTSC игры на PAL), плавность при прежних таймингах уже никак не получить.
По совокупности этих причин — сложно сделать, результат всегда плохой — в большей части случаев разработчики забивали на сохранение абсолютных таймингов, сохраняя относительные, т.е. не делали ничего, и игра просто шла на 17% медленнее/быстрее, но так же плавно и с точно таким же геймплеем.
Теперь нам нужна поддержка другой системы, и нужно сохранить те же скорости движения, то есть откорректировать их на 17%. Мало того, что для одного варианта было достаточно целых чисел, а теперь нужна fixed point арифметика, что сильно медленнее (на старых приставках даже сдвиги дорогие), но мы никак не сможем сохранить плавность — появятся либо пропущенные перемещения за обновления, либо двойные, идущие определённым паттерном. И неважно, делать ли такую коррекцию на уровне отдельных объектов, или на уровне обновления всего экрана (т.е. дублировать каждый 6-ой кадр изначально-PAL игры на NTSC, или наоборот, делать два обновления каждый 5-ый кадр изначально-NTSC игры на PAL), плавность при прежних таймингах уже никак не получить.
По совокупности этих причин — сложно сделать, результат всегда плохой — в большей части случаев разработчики забивали на сохранение абсолютных таймингов, сохраняя относительные, т.е. не делали ничего, и игра просто шла на 17% медленнее/быстрее, но так же плавно и с точно таким же геймплеем.
Думаю для многих бывших игроков Dendy ещё будет интересно узнать что Dendy не была по таймингам ни PAL приставкой ни NTSC.
ru.wikipedia.org/wiki/Dendy#Технические_характеристики
ru.wikipedia.org/wiki/Dendy#Технические_характеристики
PAL нужен — в нем разрешение больше (768*576 против 640*480). И если игра действительно PAL, а не NTSC втиснутый в PAL, то в ней нет никаких черных бордюрчиков.
Могу добавить, что проблемы с PAL/NTSC сохранялись вплоть до времен Playstation 2. Во-первых, в PAL большее количество строк, но откуда их брать? Далеко не все разработчики заморачивались «честным» повышением разрешения, и просто ставили бордюры — черные полосы сверху и снизу экрана. Есть и в той же Final Fantasy X, и ещё в просто куче игр.
Во-вторых, скорость игры. Не знаю как, но косячили разработчики и в этом. Есть хорошо известные игры, в PAL-версии которых играть просто невозможно из-за «тормознутости». Например, Devil May Cry.
В-третьих, цензура, да. Причём этот пункт сохраняется и для PS3 и для PS4 и думаю будет актуален всегда. Как правило, PAL-версии сильнее зацензурены, но есть очень-очень редкие исключения.
Playstaion 1 тоже имела все те же проблемы, к которым добавлялась ещё одна, важная для определенного «круга пользователей»: только PAL-версии игр имели хитрые защиты от пиратства, так называемые анти-модчипы. Иногда они просто не давали запускать игру, иногда включались после первого уровня, а иногда действовали совсем подло и создавали какой-то специфический баг, не позволяющий дойти игру до конца, нередко активировавшийся после десятка часов игры и заставлявший игрока бесцельно переигрывать по несколько раз (хорошо известный пример — одна из частей Spyro). Причём некоторые защиты были настолько лютыми, что баги, создаваемые ими, затрагивали и честных, лицензионных пользователей, так что в отдельных случаях игры потом переиздавали уже без защит (опять ту же Spyro). В NTSC версиях ничего подобного не существовало.
Из преимуществ PAL можно отметить, что так как европейские версии почти всегда выпускались позже американских, то PAL-релиз (если он был) зачастую содержал исправление некоторых багов и даже иногда получал дополнительный контент. Американские версии получали это позже только с перевыпуском или допечаткой игры. Но, в принципе, консольные игры тогда и так были хорошо отлаженными (ещё бы, диски-то не пропатчишь), так что особо критичные баги встречались не так часто.
И ещё забавный факт: PAL-версии фильмов на DVD были короче NTSC на 1/24.
Во-вторых, скорость игры. Не знаю как, но косячили разработчики и в этом. Есть хорошо известные игры, в PAL-версии которых играть просто невозможно из-за «тормознутости». Например, Devil May Cry.
В-третьих, цензура, да. Причём этот пункт сохраняется и для PS3 и для PS4 и думаю будет актуален всегда. Как правило, PAL-версии сильнее зацензурены, но есть очень-очень редкие исключения.
Playstaion 1 тоже имела все те же проблемы, к которым добавлялась ещё одна, важная для определенного «круга пользователей»: только PAL-версии игр имели хитрые защиты от пиратства, так называемые анти-модчипы. Иногда они просто не давали запускать игру, иногда включались после первого уровня, а иногда действовали совсем подло и создавали какой-то специфический баг, не позволяющий дойти игру до конца, нередко активировавшийся после десятка часов игры и заставлявший игрока бесцельно переигрывать по несколько раз (хорошо известный пример — одна из частей Spyro). Причём некоторые защиты были настолько лютыми, что баги, создаваемые ими, затрагивали и честных, лицензионных пользователей, так что в отдельных случаях игры потом переиздавали уже без защит (опять ту же Spyro). В NTSC версиях ничего подобного не существовало.
Из преимуществ PAL можно отметить, что так как европейские версии почти всегда выпускались позже американских, то PAL-релиз (если он был) зачастую содержал исправление некоторых багов и даже иногда получал дополнительный контент. Американские версии получали это позже только с перевыпуском или допечаткой игры. Но, в принципе, консольные игры тогда и так были хорошо отлаженными (ещё бы, диски-то не пропатчишь), так что особо критичные баги встречались не так часто.
И ещё забавный факт: PAL-версии фильмов на DVD были короче NTSC на 1/24.
В формате PAL видео могло работать только с частотою 25 и 50 кадров в секунду
Способ кодирования цветового сигнала не зависит от частоты кадров. Например в Бразилии частота сетевого напряжения 60Гц и соответственно число полей в секунду 60, но система цветного телевидения — PAL.
Я бы не стал доверить мнению по теме «РЕТРО ГЕЙМИНГ», чуваку с татухой рукава, серьгами во всяких местах и разговочиком в стиле «пацик со двора». Блин откуда эти эксперты берутся?
Все равно что искать огрехи между «свежим» и «грушевым», для всего свои цели.
Если человек изначально говорит, что ему не нужен PAL то о какой экспертности может идти речь? Это никак не относится к слову «Ретро», мы играли, как могли, на чем могли и всегда получали от этого удовольствие.
Это все равно что, доказывать, что в былые времена играть в баскетбол волейбольным мечем было плохо!
Все равно что искать огрехи между «свежим» и «грушевым», для всего свои цели.
Если человек изначально говорит, что ему не нужен PAL то о какой экспертности может идти речь? Это никак не относится к слову «Ретро», мы играли, как могли, на чем могли и всегда получали от этого удовольствие.
Это все равно что, доказывать, что в былые времена играть в баскетбол волейбольным мечем было плохо!
В моем мегадрайве был переключатель частоты рядом со слотом расширения. И он работал даже без перезагрузки. Правда большую часть времени я играл на 50гц — думал, что это нормальная частота, а 60 ускоренная.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ретрогейминг: PAL vs NTSC. Или почему PAL не нужен