Почему на приставках(Sega и NES) в PAL и NTSC разная скорость?

Сабж. Гуглинг привел только к списку консолей, и на каких регион влияет на скорость игр. Но почему скорость менялась, а самое главное - почему процессор работал в разных регионах на разной частоте, я так и не понял.

25 vs 30 кадров?

ПАЛ - 50Гц./черестрочнаяНТСЦ - 60ГЦ/чрзстр

Разница в 5 кадров, а уже скорость - того.

Были такие мультиформатные ТВ в 90 и видмафоны, мне даже как-то попадалась кассета чиста американская, а может мне это и приснилось. не знаю.

нтсц смотрелось намного лучше.

Хм. Интересно, почему нельзя было лочить на те же 50 фпс, чтобы везде шло одинаково?

На самом деле - причина достаточно простая: всё дело в играх.

Приставки первых поколений (где-то до 4-го поколения) в основном имели в своей коллекции 2D игры, которые оперировали спрайтами. Практически вся анимация была спрайтовой, а не процедурной 3D\2D как сейчас. Мало того, приставки нередко имели разные аппаратные фичи для управления спрайтами, типа масштабирования, поворота, переноса, тонирования. В те времена просто не существовало сегодняшней концепции 3D графики.

Так что всё было завязано на анимации спрайтов. Все игровые тайминги в игровой логике были построены на кадрах так или иначе. Программно «растягивать» анимации состоящие из «кадров» на разный FPS было просто нереально при тех возможностях которые давали приставки того времени.

Поэтому, всё было привязано в выходной частоте кадров, в том числе и частоты процессора\памяти приставки - чтобы игра работала просто на тупо 20% быстрее. На то время это было самым оптимальным решением, чтобы получить одинаковый геймплей без тиринга и необходимости заморачиваться с синхронизацией кадров на разных регионах и vsync'ом.

Аппаратный «VSYNC» - это дополнительное усложнение консоли, которые по тем временам были и так не самыми дешевыми устройствами. Такие вещи как тройная буферизация, тогда были совсем фантастическими - аппаратная реализация такой фичи в 8\16-битной консоли подняла-бы её цену процентов на 5-10-15-20. К тому-же даже тройная буферизация не избавляет от снижения плавности анимации при реальной частоте кадров 50 фпс на мониторе с 60 герцами. Можете сами в любом эмуляторе NES попробовать поиграть в игру с регионом PAL, сами заметите дрожание при скроллинге.

А без VSYNC'а - мы сразу получаем нехилый такой тиринг. При 20% разнице в FPS и частоте монитора - он получается очень заметным.

Так что большинство разработчиков игр особо не парилось на ту тему, что игра на NTSC консолях игралась в оригинальной скорости (в основном все игры того времени разрабатывали именно на NTSC), а на PAL консолях на 20% медленнее. Всё-равно рынок PAL консолей занимал куда меньшую долю.

Справедливости ради, находились ответственные разработчики, которые в своих играх правильно синхронизировали скорости для разных регионов. Обычно изменялась скорость музыки, и реже - скорость скроллинга фонов, так чтобы они смотрелись одинаково на разных частотах кадров. Анимация спрайтов всё-равно оставалась привязана к одинаковой частоте. Но игра хотя-бы по ощущениям игралась одинаково.

На dvd-фильмах тоже лучше смотрится. Не знаю почему, может быть, просто они качественнее делаются для США

Само-же понятие игрового FPS и его синхронизации с выходной частотой кадров начало появляться при массовом появлении 3D графики. Где-то в начале-середине 90-х, наверное. И разумеется, уже на новых консолях.

Процедурная 3D графика там всё-равно рендерилась на скоростях ниже выходной частоты кадров, и мало того, в зависимости от сложности сцены - эта скорость сильно менялась. Тогда уже и начали задумываться - как это всё отобразить без дрожания и тиринга (обычно с тирингом никто на ранних консолях с 3D графикой не боролся, даже на консолях последних поколений в некоторых играх отключен vsync).

Там уже и принципы рендера 2D спрайтов в 3D сцене были другими, тайминги для кадров спрайта расчитывались программно, и привязывались к некому реальному таймеру а не к частоте чипа и выходному ФПС. Ресурсы тех консолей это уже позволяли. Вот именно тогда и появились первые игры, которые имели одинаковую скорость на всех регионах.

На dvd-фильмах тоже лучше смотрится

А это зависит от того, с какой частотой кадров записан исходный материал на DVD. Если 29.97 + интерлейсинг, то оно будет лучше смотреться на NTSC. Если 23 или 25 кадров - то PAL.

DVD плееры тоже разные бывают. Некоторые имеют достаточно сложные алгоритмы по «размазыванию» исходной картинки на нужную выходную частоту.

Потому что тактирование проца и схемы формирования изображения от одного кварца

Тут самое интересное - что у нас творилось на территории ex-USSR с приставкой Dendy. У нас ведь лицензионный NES\Famicom не продавался. Вместо него был китайский клон под названием Dendy, со своими пиратскими китайскими картриджами (которые не безызвестная компания Steepler продавала как «лицензионные»). С частотами и таймингами там творился полный звездец - это был не NTSC но и не европейский PAL, хотя сама приставка выдавала картинку PAL. В самой последней версии эмулятора FCEUX пару месяцев назад даже появился отдельный регион «dendy» - для эмуляции частот и скорости «нашей» пиратской консоли, специально для ностальгирующих по тем ощущениям. (попробуйте на ней запустить chip and dale японского\американского региона (J\U), и попереключаться между опциами NTSC, PAL и DENDY, поймёте о чём я говорю)

Да, именно так, иначе инженерам нужно было заморачиваться и увеличить сложность аппаратной части и стоимость производства консоли. Да и разрабам игр это было не нужно особо, я выше уже описал.

скоро отпишу в тех. деталях, а то тут наукаретили и ленины опять пришли

лишь потому что ты местный дурачок то получишь нормальный, технически разжеванный и понятный даже для твоего уровня ответ про famicom (то, что в останках твоего мозга именуется как nes)

только потом обящательно дай понять, что понял ответ.

то, что в останках твоего мозга именуется как nes

Синхронизация игрового мира сделана по Vsync, а он для NTSC и PAL отличается почти на 5 кадров в секунду.

Назовите эти полторы с половиной игры, которые используют процедурную генерацию спрайтов и/или мешей.

Как раз пытаюсь вспомнить. Толи на Sega Genesis, толи на snes я видел на ютубе видос про такую игру, которая при «оверклокинге» эмулятора в разумных пределах начинала меньше тормозить и рендерить эффекты плавнее. А так выше уже все всё написали - в большинстве игр абсолютно все процессы привязываются к частоте кадров на выходе.

А вообще, игр с процедурным векторным 3d было достаточно много на 16 битных консолях. Почти все авиасимуляторы. Некоторые подстраивали скорость игрового процесса с учетом тормозов. И общий фпс игры менялся. Mig 29 fulcrum на сеге, например

Сейчас прочитал ваш коммент еще раз. Вы хотите примеров современных игр с поцедурной генерацией мешей ? Это почти любые игры допускающие процедурные деформации объектов. Есть и процедурные генерации текстур - это тоже в каждый второй игре сейчас встречается. Конечно там не полная генерация, все равно там используется образец или несколько образцов и хитрые, а дальше шейдеры с хитрыми алгоритмами уже работают. Как пример - эффекты стекающей воды по поверхностям при дожде.

Это не процедурная генерация. Как и эффект стекающей воды.

Объясните тогда, что конкретно вы подразумеваете под процедурной генерацией ?

Вообще, в оригинальном комментарии, под фразой «Практически вся анимация была спрайтовой, а не процедурной 3D\2D как сейчас», я имел ввиду процедурную АНИМАЦИЮ - а именно, использование 3D моделей (и плоских 2D мешей в «типа 2D играх»), и получение из них анимаций не по заранее заготовленным «картинкам-спрайтам» привязанным к какому-то системному таймеру (который в тех приставках привязан в итоге к одному конкретному кварцу), а через современный процедурный блендинг анимаций 3D моделей, не знаю как тут правильнее эту штуку назвать - в разных игровых движках оно немного по разному называется.

И вообще-то вполне себе процедурная. Посмотрите хотя-бы примеры таких шейдеров в официальных и неофициальных доках по Unity3d.

фамикон

настоятельно советую забори привычку употреблять nes. это всё равно топить за весомые заслуги американцев в победе в вов.

архитектура фамикона очень простая. источников «событий» (прерываний) для CPU не так уж и много. чуть меньше чем пальцев на руке у гомера симпсона. никаких программируемых таймеров и источников отсчета времени тоже нету [c оговоркой, как правило нету].

такты CPU никто не считал для игорей (чай не маководы с аппл1-2), тестировали тоже абы как.

прерываний всего аж целых 3: RESET, BRK, NMI

физически это аж целых 3 лапки процессора. если кто-то снаружи «логически» дрыгнет этими лапками, то процессор отложит все свои основные дела, и запустит обработчик случившегося прерывания.

reset - это посути самая главная точка входа. случается после запуска CPU, это самое первое что цпу выполняет.

NMI привязан к выводу PPU (picture processing unit), который дает сигнал о том, что кадр выведен на экран (vertical blanking). После этого, есть небольшой период времени, пока можно дрыгать графоном, без тиринга на экране и прочих нехороших эффектов.

на некоторый бордах (PCB) игрулей маппер [Multi-memory controllers or memory management controllers (MMC)], та штука через которую можно переключать банки памяти и маппить разные регионы рома на доступное цпу окно адрессного простраства, была доп логика, которая посути «считала» такты цпу и можно было зарядить по этому поводу таймер-счетчик, чтобы он стриггерил BRK. это пользовалось для доп-графона и анимации в более продвинутых и поздних мапперах.

с точки логической и программной точки зрения фамикон генерил цветную картинку в 256x240 квадратных пукселей, внутри PPU.

кроме того, внутри PPU был встроен енкодер в нужную систему цветности. дело в том, что NTSC и PAL имеют разное кол-во точек и строк на экране, поэтому квадратные пиксели растягивались до круглых :-) у NTSC меньше пиксели округлялись, чуть больше чем в 1.1 раза, но у PAL грубо говоря аж в 1.3 раза.

собственно, из-за этого PPU разных систем цветности имели разную частоту NMI (как минимум полу-кадров). Большинство игр использовали именно этот источник в качестве измерения игрового времени и только его. Но некоторые игрули попутно использовали допы из продвинутых мапперов.

для упрощения схематики и экономии деталей всё тактировалось внутри фамикона от одного кварца, то тактовая частота у CPU получалась делением частоты тактирования PPU. тобишь подсчитываешь такты CPU, но они напрямую и жестко через константу связаны с частотой PPU.

а тактовая частота работы PPU определялась исключетельно требованием к частоте работы цветового энкодера для заданной системы цветности.

т.е. налицо прямая зависимость всех возможных источников отсчетов «времени» от системы цветности.

если совсем на пальцах пояснять, то от частоты процессора игровой процесс в целом не зависел (если конечно о разумных пределах частоты процессора говорить, т.е. о случае когда он достаточно шустр чтобы процессить всё для адекватного геймплея). поэтому то, что процессор шпарил чутка быстрее для NTSC и чуть медленнее для PAL систем, в целом почти ни на что не влияло.

ибо игр завязанных на тактовую частота процессора единицы. (может с десяток максимум наберется).

фактически это значит, что если ты отцепишь CPU от тактовой частоты полученной делением тактовой частоты PPU, и запихаешь туда свой тактовый сигнал скажем в 2 раза шустрее для CPU, то 99% игр не будут работать быстрее, т.к. источник сигнала времени для них по прежнему PPU. однако, появится процессить передвижения спрайтов быстрее, поэтому на «сложных сценах», где все начинает мограть и тормозить, (т.е. случается framedrop), когда цпу неуспевает подвигать и запроцессить всё в рамках одного (полу)кадра. грубо говоря - это ситуации где много врагов и прочие. можешь на ютубе глянуть видосы, кто--то уже пробовал поднимать частоту на cpu.

но несколько игр из-за этого сломаются в прямом смысле. но чуть менее половины стерпит и ничего не заметит.

однако есть ещё один подвох, в CPU был встроен звукогенератор. меняешь частоту - тональность звуков моменяется тоже. больше частота - выше звук. поэтому PAL звучит ниже.

темп останется тот же, т.к. темп отсчитывался от NMI (PPU)

есть ещё один парадокс, т.к. размеры кадра разные у NTSC и PAL, то периоды vblank (vertical blanking) у них тоже разные. У PAL период vblank длиннее, поэтому NTSC игрули на PAL системах почти без framedrop-a работали. Это даже несмотря на то, что тактовая частота CPU у PAL систем была поменьше, чем у NTSC. Единственно, всё двигалось и звучало медленнее, т.к. источник времени как ты помнишь PPU. Однако slowdown-ов на сложных сценах не было.

если когда нибудь поиграешь в знакомые игры на оригинальной NTSC системе - то будешь разочарован, что slowdown (framedrop) случается достаточно регулярно часто. но при этом темп игры гораздо шустрее.

в те времена игры никто не оптимизировал и не вылизывал. (рынок игр был очень молодой и дикий. хавали всё подряд, без разбору)

поэтому даже самая известная игруля - super mario bros. местами тормозит на сложных сценах, где много врагов и обьектов движется. (на эмуляторе оно не тормозит, т.к. цпу там не эмулируется с точностью до такта.)

основной рынок игр для фамикона (и nes в т.ч.) в странах где NTSC система цветности. игры, рассчитаные для PAL фактически не выпускались (кроме нескольких оффициальных портов и нескольких экключивов). поэтому игруля для PAL региона - обычно означала NTSC ром. максимум тональность музыки правили, если не лень.

хотя есть игры, очень навороченные, которые очень жестко завязаны на тактовую частоту именно цпу, например емнип battletoads (либо оба, либо один из них). и пал-версия рома на ntsc системе не будет работать, и наоборот. но таких игр единицы и они скорее исключения.