Comments 19
Конечно поражает как приходиться преодолевать трудность когда у тебя железо в игровом устройстве слабее чем в современных смарт браслетах. Сказать бы им характеристики топовой видеокарты 2022 года RTX 4090. И как мы этими ресурсами распоряжаемся что вынуждены использовать ии генерацию кадров потому что вычислительных ресурсов мало )).
Интересно во сколько десятков тысяч раз современный топ игровой пк мощнее первых консолей с 16 битными палитрами ?
Сейчас, во многом вследствии прогресса мироэлектроники, память ОЗУ стала намного дешевле.
Что и привело практически к повсеместному распространению TrueColor images/video.
Да, было время, когда базой был (у некоторых) монохромный монитор (тот-же Hercules, с диагональю CRT около 12", зелёный).
Мне довелось начать знакомиться с PC уже с монитором, державшим разрешение, как помню, 1024768. Модели самой первой своей видеокарты уже не помню. Хотя памяти там было — 256kB, не плохо для того времени. А конфигурация ПК (на 1992г) была такой: i80386SX (без математического сопроцессора, тогда он был в отдельном сокете) 25MHz, разогнанный до 33MHz. Винт был (общий размер) 210MB, и был разбит (в partition table, что в составе MBR) на 4 раздела. 50MB - не казалось мало, если речь о дисковом пространстве. И память (RAM) в 2MB тогда считалась достаточно большой. Нормально запускались "форточки" (Windows 3.1). А само название "форточки" было обусловлено хотя-бы тем, что запускались они из под MS-DOS v6.22. В основном режиме - процесор работал в RealTime mode. Из языков программирования - сначала был лишь MS Basic, интерпретатор. Что и стимулировало изучать Assembler, вместе с Borland TurboPascal 7.0. Да, была и звуковая карта, совместимая с SB Pro (и содержавшая в себе и Adlib). С технической документацией - было не ахти. Хотя что-то - удавалось достать и из FidoNet. Ту-же техническую документацию на оборудование, откуда появлялись знания о том, в какие порты и что надо писать, чтобы инициализовать какое-то устройство. Моим учебником ассемблера на первых порах был файл virList.web (txt-файл с описанием вирусов, что детектировались и обезвреживались антивирусом DrWeb {Игоря Данилова}). Конкурентом у DrWeb была программа AIDStest (как помню, Лозинского). Heuristic-анализатор — подтолкнул к изучению полиморфиков. Остановил это изучение, когда был создан образец, что даже не подозревался DrWeb-ом. HackerView - уже имел нормальный дизассемблер, и позволял легко "фокусничать" (например, вставляя команду RetN, 0C3h (выталкивает со стека помещённый туда 0 {слово, 16 бит}, и процессор выполнял инструкцию int 20h, что находилась по этому адресу в сегменте, где была запущена программа. Фактически - завершала работу программы. Но это - самые простые варианты фокусов. Более сложные, например: через некоторое время после завершения программы содержимое текстового экрана начинала "съедать" змейка вроде такой: -*< Дело происходило, чаще всего в текстовом режиме, #03, 8025.
Нормально завершившаяся программа, если оставляла свою резидентную часть, могла быть дезактивирована тем-же Volcov Commander-ом.
Именно этот факт - стимулировал более детальное изучение операционки.
Решение было найдено простое: куда-нибудь в самый верх адресного пространства - помещался блок, содержавший, обычно, менее 400 байт.
Фокусы с MCB (Memory Control Block) и каким-то словом в младших адресах системы
(что-то вроде 0х417)
позволяли обеспечить устойчивость этого внедрённого модуля.
И на него - перенаправлялось {через таблицу векторов} прерывание 1Ch. Что и обеспечивало "оживание" необходимой процедуры.
Как можно видеть, всё - просто и надёжно :).
монохромный монитор (тот-же Hercules, с диагональю CRT около 12", зелёный)
...а мой первый личный монитор был не зелёный, и даже не серо-голубоватый, а янтарный! Купил с рук в комплекте с системником, правда, 8086, что в 94-м было уже неприлично старо, но я в этом корпусе, слегка доработанном напильником, собрал 386DX40, а вот за неимением цветного монитора, довольно долго сидел на "геркулесе"... а потом отец с какой-то премии подогнал аж Pentium 200 MMX с 15" SONY - вот тогда-то я и вкусил всех прелестей hiew - иначе проги, скомпилированные TurboPascal'ем крашились с Runtime error 200 - приходилось искать цикл, "измеряющий скорость процессора" и менять часть инструкций на NOP (90h, если не путаю) - вот тогда и Rockwell на 56k поселился на домашней линии, и Fidonet с BBS, и простыни формата А1 прайс-листов из компьютерных магазинов, и потуги работы с графикой напрямую... но с приходом Windows95 я не смог войти в новую парадигму программирования (да, мне были ближе MCB, прерывания, порты ввода-вывода и вот это всё), да и учился не на ИТ-специальность...
*покряхтывая встаёт и шаркающей походкой направляется к офисному "кулеру")))
Если взять SNES, производительность её процессора около 1.5 MIPS. Производительность современной копеечной платки Arduino - 16 MIPS, чуть более дорогой, но всё ещё копеечной ESP32 - 200-600 MIPS. Какой-нибудь i7 8700K даёт цифры порядка 35000 MIPS. То есть он мощнее, чем SNES примерно в 23 тысяч по самым скромным прикидкам, сравнивая только синтетические целочисленные вычисления центрального процессора. Фактически эту разницу можно умножать ещё в разы за счёт эффективных вычислений (процессор SNES не умеет аппаратно умножать и делить даже целые числа). Ну а если учесть ещё и вычислительную мощность современных видеокарт, тут мои полномочия всё, я даже не представляю, как это сравнить.
При этом количество генерируемых пикселей выросло вовсе не так сильно.
Скажем, у NES разрешение экрана 256x240 пикселей, а у современного 4k монитора - 3840x2160. С учётом того, что в старых консолях цвет был 4-битный, а в современных - 4-байтный, то информации стало генерироваться больше в 15x9x8 = 1080 раз. То есть ни одна современная игра тормозить уже не должна, если она сделана такими же умелыми программистами, как те, что делали игры для консолей.
То же самое касается и размеров игр. Если игры для NES занимали в среднем 256Кб, то сейчас средняя игрушка должна весить согласно вышеприведённой пропорции порядка 276 Мб. На деле даже меньше, ибо алгоритмы сжатия всё это время тоже не стояли на месте.
Тут 2 момента
допустим, мы апскейлим графику в 1000 раз в количестве пикселей. Но если алгоритмы останутся старыми, это не впечатлит игроков. Сейчас нужно расчитывать освещение каждого пикселя, и реалистичные формулы, применяемые в некоторых (устаревших, до трассировки) моделях освещения - тригонометрия с углами между нормалью поверхности и направлением на источник света.
Раньше железо было фиксировано и можно было ассемблером напрямую достукироваться до всех регистров видеопроцессора. Сейчас мало того, что железа целый зоопарк, так ещё и производители не раскрывают низкоуровневые спецификации, прячась за проприетарными драйверами.
А что касается размеров, так возросли требования к количеству контента. Мы (игроки) хотим, чтобы персонаж иногда бросал реплики, да желательно разные, да ещё и записанные в не 8 bit, 8 KHz, а получше. Только это сразу даёт гигабайты контента.
А вот кстати странно: почему синтез звука так сильно отстал от синтеза изображения? Ведь хранить десятки часов записанных реплик во всех возможных вариантах - это, если подумать, так же глупо, как вместо рендеринга в реальном времени заранее отрендерить каждый объект и каждый кусок стены по всех возможных позициях и углах зрения с шагом 1 градус, а потом просто подгружать спрайтами нужные кадры из такого фильма.
Скажем, в древних демках была трекерная музыка, почему она не получила развития? И почему у нас есть видеокарты с чудовищной вычислительной мощностью, но нет и не предвидится сравнимых по мощности "звуковых процессоров", способных осуществлять синтез речи в реальном времени с учётом эмоций?
Локальный синтез речи до сих пор хромает, хоть и меньше, чем лет 15 назад. Вероятно, будет хромать до момента, когда у подавляющего большинства не будет железо, запускающее нейросеть (у них огрехов значительно меньше). Я как-то попытался углубиться в теорию синтеза речи (сильно до нейросетей) — понял, что образования не хватает, причём не в компьютерах, а в биологии (восприятие речи) и лингвистике (из чего речь вообще состоит).
При этом всякое 3d делалось практически каждым студентом — тригонометрия была даже в школе, не говоря уже об университетах, там особо думать не требовалось, вдобавок даже в 90-х было ДОХРЕНА информации и готовых алгоритмов для текстур и освещения. Ну и огрехи типа "монстр из нескольких треугольников" не слишком заметны под текстурами, в отличие от огрехов типа неверных ударений в синтезированной речи.
Что касается трекерной музыки — вполне себе была в играх. В том же Unreal, например. Но вообще, midi проиграть — это простой и нетребовательный стандартный модуль, что для Adlib, что для Wavetable-аддона к звуковой карте, в отличие от трекерной музыки, где надо выделить процессорное время на микширование сэмплов и написать соответствующий код. Трекерная музыка использовалась в довольно небольшой промежуток времени, когда процессорные мощности резко возрастали с "doom на 486" до "q3 на TNT", а потом стало проще выделить несколько процентов процессора на декодирование mp3, причём стандартным кодеком, интегрирующимся в ОС, т.е. стандартными средствами.
У midi очень паршиво с переносимостью. Если трекерная музыка всё своё несёт с собой, то тут нужна внешняя библиотека сэмплов, которая от системы к системе отличается, равно как и способы доступа к ней, и может быть вообще не установлена. В итоге если игрушка использует midi, то вероятность словить проблемы с их проигрыванием очень высока - данная технология обладает чудовищно низкой надёжностью, чтобы на неё закладываться.
А вот кстати странно: почему синтез звука так сильно отстал от синтеза изображения?
Потому что ресурсов хватает, чтобы записать в высочайшем качестве 70 часов звука (или сколько там идёт игра). А раз это не является узким местом, зачем напрягаться и решать неважную проблему, можно приложить силы к более важным.
Проблема не в количестве пикселей, а в том что на этих пикселях) С таким подходом вы получите графику NES растянутую в 4к, не более. Там примитивное 2д, сделанное простой геометрией. Тут у нас сейчас в большинстве игр сложное 3д, c весьма сложным рендером, всякими плоскостями отсечения, тонной шейдеров и т.д. А можно еще пост-эффектов и частиц добавить, от чего видеокарте просто плохо станет )
Спасибо за статью, начал волноваться что про Атари и их 4 цвета не напишете, но нет, всё как и надо, мой поклон.
В программе Fractint вращением палитры делались очень залипательные анимации фракталов...
Черт возьми, слова "CGA" и "уныние" были для меня синонимами большую часть жизни. В детстве у меня был "Поиск", первое время подключенный к ч/б ламповому ТВ, а чуть позже - к "корветовскому" монитору, также ч/б. В школе, где я учился, в кабинете информатики стояли такие странные пост-советские агрегахтунги "ЕС-7978", с полноценно воспроизведенной CGA-картой и с цветными дисплеями. Так вот дома, на черно-белом экране, картинка в играх выглядела пристойнее, чем на относительно приличных мониторах в школе ))) Так бы я и прожил жизнь в убеждении, что CGA - унылая какаха, ориентированная исключительно на "деловую" графику (в представлениях 80-х годов) если бы не ностальгия ))) Решил воспроизвести один из тех проектиков, где ESP-32 эмулирует IBM PC (XT) и программно выводит картинку на VGA-монитор. А чтобы было интереснее, заменил RGB-видеовывод на NTSC (тоже заимствованный, пришлось только подогнать положение "субпикселей" в строке, чтобы цвета плюс-минус соответствовали изначально заложенным разработчиками CGA). Я уже не помню, в какой из игрушек впервые своими глазами увидел "композитные" цвета, но реакция моя была: "А чо, ТАК МОЖНО БЫЛО?" Не, потом уже понял, что нельзя, конечно. С советскими телевизорами (SECAM) уж точно нельзя. А жаль ) Представление об играх моего детства не то чтобы перевернулось, но как-то жалко стало, что эта их сторона мимо меня прошла )
У CGA в любой палитре можно изменить цвет BG, а в HIRES - оба.
Графика древности: палитры, часть 2/2