Строение цветного экрана в играх ZX Spectrum
Vložit
- čas přidán 25. 07. 2024
- В одном из предыдущих видео я рассказывал о проблемах с цветом в Спектрумовских играх. Некоторые написали мне что мол "было интересно, но мы ничего не поняли". Так вот, в этом видео я попытаюсь рассказать о цветном устройстве экрана Спектрума буквально на пальцах, так гораздо доходчивее. Сразу скажу, ничего сложного в этом нет, и надеюсь, видео будет интересно тем у кого Спектрума не было, либо просто человек не вникал в его особенности.
0:00 ВСТУПЛЕНИЕ
00:23 СТРОЕНИЕ ЦВЕТНОГО ЭКРАНА СПЕКТРУМА
01:41 К ЧЕМУ ЭТО ПРИВОДИЛО?
02:24 ЦВЕТНОСТЬ В ИГРАХ
03:58 НАГЛЯДНЫЙ ПРИМЕР
04:36 ЧТО БЫЛО САМЫМ СЛОЖНЫМ ПРИ СОЗДАНИИ ИГР?
07:22 МЕЛКИЕ ДЕТАЛИ, ДИАГОНАЛИ
09:01 ГЛАВНАЯ СУТЬ КОНФЛИКТА
10:57 ОТКУДА 16 ЦВЕТОВ?
12:26 СПАСЕНИЕ В МОНОХРОМНОЙ ГРАФИКЕ?
13:17 А КАКИЕ ЕЩЁ ЭФФЕКТЫ МОГ ВЫВОДИТЬ СПЕКТРУМ ИЗНАЧАЛЬНО?
13:57 ОТКУДА ВСЯ ЭТА ИНФОРМАЦИЯ ОБ УСТРОЙСТВЕ ЭКРАНА?
14:35 ПОСЛЕДНИЕ ВОПРОСЫ И ЗАКЛЮЧЕНИЕ
15:28 ПЕРВАЯ РЕАКЦИЯ ЛЮБОГО ПРОГРАММИСТА НА СПЕКТРУМЕ НА ОГРАНИЧЕНИЯ ПО ЦВЕТУ
Для желающих поддержать канал: Карта Тинькофф 2200 7010 8566 7076 (Борис П.) - Hry
Были времена - бейсик потом ассемблер, отладка в STS, музыка.у меня даже несколько программ моих сохранилось )))
Стоит добавить что изображение записывалось чёрнобелым в специальную область памяти, а информация о цвете записывалась в соседнюю область памяти и как бы накладывалась поверх ЧБ картинки, типа прозрачной цветной плёнки. Область памяти начиналась с адреса 16384(сразу после ПЗУ), область пикселов занимала 6122 байта, область цвета 768 байт... если память не изменяет, я этим занимался в 1995 году, мог подзабыть)))
Жалобы на цвета Спектрума абсолютно глупые, потому то Спектрум изначально вообще не разрабатывался для игр, а во вторых многие игры показывали хорошую скорость как раз благодаря такому удачному решению организации "видеоадаптера" - процессору надо было записывать всего 7 килобайт данных, а для 3D игр часто использовалась всего треть экрана, это всего 2.5 килобайта.
Если бы инженеры думали об играх, то наверно добавили бы простую поддержку спрайтов, чтобы можно было накладывать поверх изображения спрайт главного героя, тогда бы небыло самого заметного конфликта атрибутов, но возможно это бы сильно увеличило стоимость Спектрума, в те времена разработка и изготовление дополнительной логики сильно увеличивало стоимость конечного продукта.
Все правильно, только растр занимал 6144 байта, а весь экран 6912 байт. Кстати, автор не упомянул про бордер.
@@MrSpeccy а бордюр вообще мог быть только одного цвета, поэтому разноцветные полоски на нём вообще магия какая-то
@@ymoxel Я полагаю, магия полосок на бордере давно освоена кодерами высшей категории. Они умеют даже крупный бегущий текст там рисовать. Наверно это возможно благодаря очень быстрой смене цвета этого бордера туда-обратно (в пределах микросекунд) в строго определённый момент положения луча ЭЛТ.
Игровым, он как раз стал по причине довольно неплохого на то время разрешения экрана, достаточно "резвого" для обработки процессором и одновременно компактного в плане "отъедания" памяти.
Учитывая, что спектрум в своей "базовой" инкарнации (16К/48К), позиционировался как домашняя персональная учебная машинка, целью был оптимум, минимальной стоимость при максимуме функциональности.
@@ArigatoTravels Начало рисования растра связано с прерыванием по сигналу INT, а скорость прохождения одной строки фиксирована и равняется 224 тактам процессора. Можно подсчитывать такты и в определённый момент менять цвет бордера.
Мелким не понять) Молодые специалисты не экономят, ни память, ни размер, ни... да, ничего они не экономят и пишут всё на оте... в общем, вы поняли)
Да уж, в распоряжении современных "машин" и разрешение 1680x1050 и более, и возможность задания цвета из более 16 миллионов цветов(а возможно и более, отстал от жизни 😆) для каждого пикселя. Да плюс еще всевозможные ускорители 2d-3d графики, и т.п.
Да уж, как говорится, сытый голодного не поймет.😀
Зато это всё компенсировалось интересным сюжетом, вдумчивым подходом и вниманием к деталям.
Ну не знаю. Два цвета из 16-цветной палитры это уже перебор. Как ни старайся, но Robocop 3 как на Денди создать не получится, никакой сюжет не исправит низкий уровень графики.
Наконец понял про конфликт атрибутов... хорошее доступное объяснение... спасибо за труд...
Эх, вспоминаю, как тогда в далёком 90м при начальном знакомстве со Спектрумом, не понимал, почему у меня в бейсике не получалось прорисовать линию одним цветом рядом с линией другого цвета!!! И думал тогда - в чём же подвох? Ведь в играх и на заставках это было без проблем, а у меня в бейсике никак не получалось!!! :-)))))))
Спасибо. На пару минут вернулся в детство! Да всё было именно так. Стоит отдать должное программистам и энтузиастам тех лет. Создавать игры в ассемблере, да с учётом всех тех ограничений - настоящее искусство!
Это смотришь и очередной раз поражаешься и мастерству и гениальности разработчиков этих игр. Со всеми этими ограничениями делать вполне играбельные игры. Современным малопонятно, что в то время не было принято подхода "а купи новую приблуду, тогда моя поделка на ней пойдёт": работали с тем, что есть.
И, кстати да: по поводу полноценных графических систем: CGA (на секунду: COLOR график адаптер или эррэй) выводил 4 что ли цвета всего (одновременно), помню из кружка предложили мне сходить в школу, я хз "с уклоном" она что ли была 🤷🏻♂️ я так и не понял. Ну пришёл, увидел эти IBM, и убило нулевое число цветов просто. Ещё у знакомого родаки были кооператоры, так купили ему xt наверное, и тоже стремали игрухи полуцвЕтные (принц и метал мутантс вроде были (боже, ну принц классный конеш, но мутанты - идиотизм же дикий 🤦♂️), разрешение конечно выше, но цветность казалась после спектрума никакая. Лично мой фаворит Star Raiders II вот где цветастая картина, ну опять же кому-то идиотизм - это, а мутанты = "вау!" 🤷🏻♂️
У процессора Зайлог, на котором построен Спектрум, вообще ОДНО прерывание (!). И крутись, как хочешь :))). Игровые программы Спекки все представляли собой бесконечный цикл (отрисовка кадра), а на единственное прерывание вешались перемещения управляемого игроком объекта.
В начале 90-х никогда не обращал внимание на эти нюансы. Плюс, как правильно сказано, кинескопные ТВ не "made in Japan" сглаживали все это. Спасибо, напомнили о тех годах:)
Спасибо большое за материал, спектрум был моим первым компьютером и все эти ограничения мной просто не замечались и считались естественными, так как не было особого опыта на других видах компов. Был еще БК у одноклассников, но мне мой спектрум больше нравился. До сих пор хранится в шкафу.
Спасибо за видео, тогда чтоб нарисовать что-то красивое на компьютере спектрум надо было действительно постараться и иметь талант
Хорошо рассказано, спасибо.
Вижу что-то про Спектруму - сразу лайк, подписка, комментарий.
Финал - бомба. :)
Спасибо огромное за видео, супер!!!
Какой доходчивый видос =))
Хорошее видео, интересно было, спасибо !
11:44 Черный цвет не имел повышенной яркости, не потому что "это было не так явно" на экране ч\б-телевизора, а потому что специальная схема внутри Спектрума аппаратно отключала сигнал BRIGHT, если RGB=000. Т.е. и на экране ч\б и на экране цветного телевизора при любой настройке яркости\контрастности можно было увидеть только 15 разных физических цветов (а логических цветов было 16 - от 0000 до 1111, но цвета 0000 и 1000 выглядели абсолютно одинаково).
Некоторые клоны Спектрума (например, Байт или приставка Эльф) такой схемы не имели, поэтому там было 16 физических цветов, что в некоторых играл приводило к искажениям изображения - вокруг спрайтов появлялся темносерый ореол.
Так что ZX Spectrum имел 16 логических цветов, которые отображались в 15 физических цветов.
Моя юность
Весьма доходчиво
Конец шикарный ) поржал ))
Мне кажется, что тогда в то время когда мы играли в эти игры то нам было по барабану про все эти конфликты цветов между собой), даже и не замечали их, было и так весело и интересно, ведь ничего другого у нас не было). А у меня, например, и вовсе был ч/б монитор Электроника и никакого дискомфорта не ощущал), даже как-то Спектрумовские игры в ч/б режиме даже более гармоничнее выглядели)..
особенно приятны были плавно мигающие объекты, либо тексты, на ч/б просто плавно меняли свою яркость, а не это раздражающее разноцветное мерцание.
вам да, а нам нет, мы постоянно рисовали в The Art Studio и это было настоящим испытанием тех лет. Хотя, если кто просто играл вы правы, но кто компьютер использовал не только для игрушек, но и для творчества, это была вечная проблема.
Ну да, я недавно поржал с видоса, как чувак на rtx4070 в 2К разрешинии добился "приемлемых" 120Гц )))
если очень быстро и синхронно с разверткой менять атрибуты, то можно было добиться 2 цвета не на 8х8 пикселей, а на 1x8 пикселей. Но делалось это только в демках.
У меня племяха увлеклась пиксель-aртом. Ну всяких анимешек рисует. Прикольно было когда я ей Art-studio врубил. Зато никто в мире так чётко не учитывает условий. Реально интересный канал. Продолжай если не влом. Всегда лайк.
За что ты ее так ненавидишь ?
Позже сделали полноценный мультиколор. Сперва в демках, а потом даже графический редактор запилили, в котором были индивидуальные цвета пикселей (8col editor).
Был журнал zx-ревю, выписывали 6а толпу, читали по очереди и ксерили у кого родители работали в продвинутых конторах
спасибо за воспоминания
У меня ещё хранится сборник в виде книжки за год. 92 и 93 год.
Знакоместо, по сути эквивалент Vesa в досе.
Потому что изначально для текста разрабатывалось.
В линуксе сейчас шрифты настраиваются - 8х8, 8х14, 8х16.
Вывод спрайтов по XOR был довольно стремным методом. Гораздо круче выглядели спрайты с маской, но они требовали больше памяти. помню выковыривал из образов magic эти самые спрайты, какой-то программой. Она выводила куски памяти на экран и подбором можно было определить ширину и точное место начала где начиналась графика. Далее все это перекидывал в CPM ATM-turbo2, там были 640x200 и 320x200, где картинки и спрайты выглядели уже интересней. А в 320x200 можно было даже полноценно раскрасить (ага, на ч/б мониторе). Но какой именной программой - теперь уже не могу вспомнить. Кто помнит?
Карамельненько 😏
Ну т.е. как конфетку облизал.
Нужно больше хардкора, больше мяса. Что бы передать всю боль графики Спектрума.
Ну да ладно, бывалые сами знают, а молодежи по большому счёту вроде как и не нужно, так в целях общего развития.
13:55 ни там ни там атрибут FLASH не используется, здесь просто переключение цветов. FLASH выглядит по-другому.
на денди тоже были ограничения
например три цвета на один спрайт + прозрачный фон
11:40 неправда, черный на аппаратном уровне сделан так, чтобы яркость на него не влияла. Если ты где-то и мог разглядеть ярко-черный, то разве что в некоторых недоработанных клонах.
@@Istor81 Это была фишка некоторых отечественных клонов. В оригинале оба чёрных цвета (бгг) были одинаковы, подо что игры и затачивались. Т.е. всего с разной яркостью было 15 цветов, а не 16.
а с другой стороны - это великое изобретение- экранное пространство спека.
Про мигание части реактора в Den Dare (13:45) категорически не согласен. Центральная часть меняет цвет фона циклически (фон то синий, то красный, то черный (в последнем случае создается эффект что объект вообще пропадает)), а боковые части (слева и справа от центральной) может быть и меняют тон с красного на черный и обратно, но все равно это не flash, это именно перекрашивание фона. Во flash атрибуты фона и тона тупо меняются местами, а потом возвращаются обратно, причем всегда с одной и той же частотой, поэтому на боковых частях, например, мы бы видели сначала.красные огни с черной полосой, а в следующий момент времени - черный квадрат с красной полосой (а не просто черный квадрат, как мы видим).
В Денди тоже экран разделяется на квадраты. Но там в каждом квадрате могло быть 4 цвета включая прозрачный цвет
Родной клэшинг.
Расскажи про полоски загрузки. Почему они ползли и вообще выглядели по разному при обычной и компрессионной загрузке. И как вообще это работало при том что задавалось одним цветом. Или это только в Бейсике был один цвет у рамки а на асме больше?
наверно зависело от частоты смены цвета
все просто: цвет бордюра менялся при получении каждого бита. А кодирование битов было частотной модуляцией. Поэтому цвет бордюра менялся десятки раз за время развертки экрана, от того и полоски, от того и изменение их ширины.
dielo v tom sto bordiur eto nie ekran dlea zx ... kogda kompiuter prinimal bit iz magnitofona to dielal komandu out ... mozno bylo napisat programu na mashinom kode stob tak siebie mieneal bordiur poloskami .... no tam jescio prieryvanijie nado bylo otkliucit stob rovnyjie polucilis .... itd
Да, рисовал в артстудио, тот ещё квест был!
Слушайте, а нельзя это ограничение обойти в эмуляторах? Чтобы при запуске обычной игры эмулятор сам поправлял цвета?
Есть такой способ - запускают 8 эмуляторов параллельно, в каждом из них пр-своему раскрашенная копия игры, и от каждого эмулятора берется только одна линия в знакоместе. Получается два цвета на линию. Под эту технологию переделаны несколько игр - их специально нужно перекрашивать
Не, я понимаю - фактически символьная графика ради экономии памяти(просто символы и цвета вы задаете произвольно сами). Но млин структура то какая ацкая! Видно как видеопамять устроена при загрузки картинки.
И тогда(в 91-93 годах) это было как само собой разумеещееся. То, что есть черно-белый образ и наложенный цвет поверх них.
Это позже, при знакомстве с IBM PC совместимой техникой, пришло понимание, что под пиксель могло быть и 2 и 4 бита. Что давало 4(тоже так себе режим, учитывая жестко заданные "кислотные" палитры) или 16 цветов, но уже для каждой точки.
А уж режим 256 цветов из 256K-палитры и вовсе смотрелся как чудо!)
Зато высчитывать адреса соседних байтов было легко.
Вроде бы цветной, но в тоже время монохромный
А чтобы совсем уже сорвать крышу у современных программистов, расскажу, что у Спекки *вообще не было* такого понятия, как "видео-память". Вся доступная программам память была "плоской" и адресовалась одинаково. Просто видеоконтроллер компьютера считал часть этой памяти "видео" и отображал её на экране. В результате можно было поместить программный код... прямо в картинку и исполнять его, как обычно. Например, на игровом поле есть зоны однотонной заливки - в них можно поместить программный код(!) и исполнять его оттуда в процессе игры.
Что там непонятного им было? Вот например, что в памяти есть область атрибутов, а есть область самих пикселов им наверное вообще мозг сломает.
можешь по-быстрому накидать на ассемблере процедурку вычерчивания линии из левого верхнего в правый нижний угол экрана (желательно с пояснениями) в соответствии с указанным алгоритмом?
czcams.com/users/results?search_query=dda+line+drawing
спасибо!
Сколько я над этой всей фигнёй просидел в детстве. Писал разные игрухи - и без того кривые - так ещё и с цветами бороться приходилось. И главное, интернетов действительно никаких не было, только опыт - сын ошибок трудных.
Его величество клешинг. 😉
товарищи, привет. Что за игра начинается на 2:25. Так забавно, что буквально с утра поиграл в новенькую High On Life и во второй миссии уровень с джунглями и он абсолютно срисован ИМЕННО с этой игры. Я, пррям офигел, когда заметил.
Рассказ не полный. Действительно, спектрум создавался не для графики, а для работы с текстом. Поэтому цвет окрашивал 1 знакоместо 8х8. Это очень сильно экономило память. Чтобы понять, какие возможности закладывались создателями в спектрум надо сделать рассказ о встроенных в ПЗУ процедурах, написанных на ассемблере. А там в основном именно работа с текстом, вывод текста, чтение портов ввода-вывода, и рисование графических примитивов. Жаль вместе с нашими спектрумами не поставлялось подробное фирменное описание этих процедур и правил по их вызову (в какие регистры какие параметры записывать, по каким адресам какие процедуры расположены) А ведь еще в 16384 байта так же поместился безглючный интерпретатор бэйсика (привет создателям Бэйсика Вильнюс из СССР для БК).
самым шиком считалось использовать именно процедуры из ПЗУ, а съэкономленную память пускать под хранение спрайтов. Если не ошибаюсь, так делали в игре Савэйдж. Так же это давало определенный прирост производительности, т.к. оперативная память доступна не всегда. Через определенное количество микросекунд она аппаратно блокируется. Устанавливается вектор немаскируемого прерывания и начинается аппаратный процесс регенерации памяти. Короче память на основе конденсаторов и их постоянно нужно подзаряжать. Пока происходит обработка прерывания, озу не доступно, однако пзу не нужно обновлять и оно продолжает быть доступно в любой момент. Соответственно секрет офигенной производительности всяких крутых мегадемок заключался в том, чтобы максимально использовать процедуры из пзу. Например, процедуры для расчета адресов знакомест, копирования знакомест и т.д. Поэтому есть тормозные игры, а есть очень резвые. Вроде не сильно соврал. Давно дело было)
Безглючный? В пзу гора ошибок, вплоть до ошибки в обработчике прерывания в тупой считалке кадров, из-за которой нельзя полноценно задействовать целую регистровую пару в программах совместно со стоковым обработчиком прерываний. Багов там полно, как и везде, только еще и уровня "плевок в вечность".
@@Zahadoomозу всегда и везде доступно, в т.ч. в прерываниях. Регенерация памяти происходит при выполнении процессором каждой инструкции.
Спасибо... Дизи топ...
Ну в Саваже конечно самая лучшая графика в спекртумовских играх.
У спектрума монохромная графика, просто они сделали монохромным не весь экран, а отдельные квадраты этого экрана. Ну то есть вы выводите на экран монохромную одноцветную графику а потом настраиваете монохромность каждого знакоместп по одному. Поэтому и речи быть не может о трех цветах в одном квадрате - тогда бы квадраты уже не были монохромными и это другая архитектура. И сделано это исключительно стобы сэкономить видеопамять.
Ты бы еще про мультиколор рассказал, вроде нет на ютубе инфы о том что это и как он работает.
Жаль, что собсна про строение экрана спектрума в этом видео как раз ничего нет. А там тоже та еще херня😂 Экран разбит на три трети, каждая из которых начинается со своих адресов. 8 горизонтальных пикселей знакоместа находятся рядом в одном байте, следующий байт - это уже первая строка знакоместа правее, а следующие по вертикали байты пикселей первого знакоместа располагаются в адресах, у которых изменяется старший байт, например, если первый в 4000h, то остальные в 4100h,... 4700h.Удобно символ 8×8 выводить в этой сетке, но на этом все удобства заканчиваются. 4800h - это уже пиксели первой строки второй трети экрана. 4020h - это первая строка знакоместа под первым знакоместом. А атрибуты цвета находятся вообще в другой области памяти. В общем, хрень полная. Флэш этот на хрен не нужен был, только избавил нас всех от большего множества цветов. И это не то, что показано в видео. Черный и черный повышенной яркости - это один цвет. 15 цветов всего благодаря этим чудесным решениям. А более всего не хватало в этой системе аппаратного скроллинга. Не так уж много пришлось бы допилить, но качественно другой уровень игровой графики получился бы на выходе. Нет повести печальнее на свете...
Ну как-так можно! Уж если знал про FLASH не надо в видеоряде показывать атрибутные мерцания по INK!
FLASH меняет циклически цвета фона и чернил, а не только что-то одно!
Конечно, позден мой коммент, но я не искал специально ролики, просто наткнулся, возмутился - чему тут учат!
Сорри...
На Коммодор 64 заметно лучше графика была
Там отвратная блеклая палитра.
@@OlegShwim ну... щито поделать...
@@Istor81 Клэшинга у Комодора нет, но по всем остальным параметрам графика Комодора полный отстой даже для тех лет. Такое ощущение, что за цвета там бабушка преклонных годов отвечала, которой уже весь белый свет не в радость)
А я думал покажут бабу которая на заставке блин
тут в основном про клешинг, а о строении экрана рассказано слишком поверхностно. За старания - лайк, за содержание - дизлайк, в остатке комментарий в поддержу канала. Всем добра!
@@Istor81 не поленился, перешёл по ссылке и посмотрел. Оба видео об одном и том же. В обоих автор старательно обходит тему строения экрана (разделение на область данных и область атрибутов, структура байта атрибутов, нелинейная адресация, методы пересчёта координат и т.д).
Остался при своём мнении.
Да, это интересная тема, в ассемблере приходилось писать подпрограмму пересчёта из координат в адреса памяти