Просмотр полной версии : Новый принцип устранения клешинга
Smalovsky
20.07.2016, 02:52
Я придумал новый принцип устранения клешинга.
Особенности:
- Требует мало оперативной памяти;
- Может использоваться в модели 48k(*);
- При использовании палитр увеличивает количество цветов на экране;
- Совместим со стандартным графическим режимом( позволяет запускать программы);
- Не требует отказа от использования приемов и методов программирования для стандартного графического режима;
- Пригоден для аппаратного ускорения.
В общем, я решил пока публично не открывать сам способ, а выбрать специалистов, что бы они рассмотрели новый способ устранения клешинга. Среди этих специалистов( предварительно):
Максагор;
Блэк_Кэт;
ЗСТ;
АлексРайдер( при условии неразглашения определенным лицам).
Только я сначала хочу этот способ запатентовать в двух странах. Это связано с тем, что я хотел бы ограничить игровые программы для нового режима этическими принципами, то есть используя новый режим разработчик аппаратного или программного обеспечения будет ОБЯЗАН соблюдать этические нормы.
null_device
20.07.2016, 08:48
Попахивает каким-то велосипедостроением, а-ля ULA+. Или - показалось?!
Патентовать, конечно же, надо обязательно. Очевидно, что открытие революционного способа незамедлительно вызовет разработку и появление десятков тысяч новых устройств, спектрум снова пойдёт в широкие массы. После чего программисты двух стран ринутся адаптировать старый и писать новый софт под эти устройства. Очевидно, что некоторые разработчики ПО сразу же захотят разработать какое-нибудь непотребство. А разработчиков аппаратного обеспечения, тем более, хлебом не корми, дай только этические нормы нарушить. Вот тут-то и пригодятся спасительные патенты - т.к. написание софта под новый спектрум снова встанет на коммерческие рельсы, и никому в голову не придёт выкладывать анонимные непотребства в сеть. А автора коммерческого продукта легко будет привлечь к суду за нарушение патентов.
Smalovsky,
1. Клешинг устраниться у...:
1.1 ...новых игр и переписанных старых?
1.2 ...старых игр...:
1.2.1 ...пропатченных хакерскими методами?
1.2.2 ...пропущенными через автоматическую патчилку?
1.2.3 ...просто сам собой, или в крайнем случае выбором режима работы из нескольких вариантов?
2. Реально воплотить...:
2.1 В эмуляторе?
2.2 В новых машинах, разработкой конфигурации?
2.3 В новых машинах, разработкой карты?
2.4 Даже в фирменных машинах и рассыпных клонах, разработкой карты?
3. Что за этика, и какие проблеммы с этикой?
Smalovsky
22.07.2016, 02:53
Reobne,
1.1 да
1.2.1 да
1.2.2 нет
1.2.3 нет
2.1 - 2.3 да
2.4 Простейший вариант Swap можно использовать в клонах. В фирменных машинах, думаю, тоже можно использовать. Вопрос в том, что в фирменнлй машине нельзя будет использовать палитру.
3 Компьютерные игры не должны пропагандировать и побуждать к насилию. Однако, возможны игры такого плана как про полицейских, спец. отряд по борьбе с терроризмом и т.д. В таких играх есть элементы насилия, однако они не должны изображать садизм и наслаждение злом. Также не допустимо изображение крови.
Недопустима игра за отрицательного персонажа. Такое понятие как "жизни" должно быть заменено понятием "попытки". Игра не должна вызывать привыкание и зависимость. Прохождение игры не должно занимать много времени. Игра не должна подавлять усталость игрока, давая ему возможность и желание при длительной игре( свыше часа) оставить игру и заняться своей повседневной жизнью. Компьютерные игры не должны подавлять психику человека и вызывать эффект замещения настоящей действительности на виртуальное пространство. Игры не должны способствовать ассоциациям игрока с игровым персонажем.
Запрет магии как чего-то положительного. Запрет магических ритуалов и заклинаний. Недопустимо использование в игре главного персонажа как мага, волшебника и т.д.
Запрет ненормативной лексики.
Приблизительно так.
Smalovsky
22.07.2016, 21:25
Прогресс:
Решил писать материалы по новому видеорежиму. Планирую сделать два документа - один более рекламного характера, а второй будет описывать техническую сторону.
Теперь насчет шутничков. Рекомендую им прекратить шуточки, иначе они будут отстранены от любой разработки для нового видеорежима.
Интересно чем ,это, все закончится.
А, имхо, ничем. Даже если эта вундервафля воплотится в железе, гипотетически под нож пойдут 90 процентов игр. Хорошо, что топикстартер новую технологию печати книг не придумал. :)
Я, правда, не эксперд, но смутно себе представляю этический контроль в патентном праве. Кто в теме, поясните, оно так можно? :)
Barmaley_m
24.07.2016, 12:44
Я, правда, не эксперд, но смутно себе представляю этический контроль в патентном праве. Кто в теме, поясните, оно так можно? :)
Очень просто:
1. По умолчанию никто, кроме владельца патента, не имеет права использовать запатентованную технологию. Вообще никак.
2. Владелец патента может заключать лицензионные договоры, по которым за деньги, на время, и при соблюдении заданных им условий, предоставлять право использования технологии третьим лицам.
Чтобы получить право на использования технологии, вы должны заключить с владельцем патента лицензионный договор. В нем и будут прописаны моральные и прочие ограничения. Также обычно имеется пункт, что лицензия (право на использование технологии) аннулируется при нарушении лицензиатом обязанностей по договору, в частности - моральных принципов.
Условия лицензионного договора не могут противоречить воле владельца патента. То есть, если он вообще ни за какие деньги не согласен убрать из договора ограничения на моральные принципы - то вы не сможете заключить договор и не сможете (легально) пользоваться технологией.
С современными технологиями DRM можно принудительно реализовать множество ограничений. Как здесь уже заметили - можно блокировать запуск на устройстве несертифицированных программ, как это делается для всяких XBox и Playstation. Можно связываться через интернет с сервером владельца патента и передавать на него информацию, а также скачивать оттуда списки отзыва сертификации. То есть вот эта угроза автора:
Теперь насчет шутничков. Рекомендую им прекратить шуточки, иначе они будут отстранены от любой разработки для нового видеорежима.
Вполне осуществима. Если вы заключили с ним лицензионный договор, получили сертификат на написанную вами игру, а потом позволили себе шутить - то он сможет в любой момент отозвать сертификат, и игра перестанет запускаться у всех пользователей. Дополнительно он сможет взыскать с вас моральный ущерб по суду. В такой ситуации шутки плохи.
Alex Rider
24.07.2016, 15:57
ИМХО, все разговоры про лицензии и патенты имеют смысл после хотя бы демонстрации прототипа. Ибо, насколько я знаю, у нас после 90-х серийно реализованы только 2 графических расширения, решающих проблемы атрибутов. Зато разговоров о разработке очередного творения - выше крыши. Хотя, сам подход ТС к созданию устройства правильный: вместо публичного предложения концепции, которую обязательно раскритикуют, найти разработчика аппаратной части и программера, способного адаптировать или написать под режим пилотные софты, сделать втихорца и потом уже предлагать общественности.
ZX_NOVOSIB
26.07.2016, 09:00
Без малого неделя прошла. А мнения специалистов из первого поста всё нет. Где мнение специалистов? :(
Smalovsky
27.07.2016, 07:40
Сначала замечания на посты друзей антиклешинга.
криэйтор писал комментарий о сроке действия патента:
Ну что, пусть патентует.
Иногда срок может быть продлен...))
Tрол73 писал о спутниковом наблюдении:
дабы поклонники какого-нибудь гарри поттера не успели бы даже начать создание своих аморальных игрушек
Неуспели и сели...))
Рэйдак писал:
неужто этот новый принцип круче чем zx-poly
Может и не круче,а может и круче. Нужен работайющий прототип.
Прогресс:
Отправил письмо по эл.почте одному специалисту. Второму специалисту писал в личку, но что-то нето, надо по эл.почте.
Закончил описание принципа устранения клешинга. Осталось подготовить иллюстрации к описанию( свыше 10-ти).
Буду начинать рекламный материал.
Для иллюстраций мне нужны скриншоты из игр. Также нужны скриншоты из игр, где игровой объект меньше маски( вот выдержка из технического описания:
"Часто маска игровых объектов в старых играх больше по размеру самого изображения игрового объекта на величину в один пиксель. Такое решение позволяло не смешиваться изображению объекта и фона...").
Может и не круче,а может и круче. Нужен работайющий прототип.
до прототипа краткое описание принципа уже скажет работающее или неработающее и какие трудозатраты требуются для адаптации софта
Alex Rider
31.07.2016, 01:44
Тема - просто образчик оффтопа. Давайте уже про всяческие отношения полов и их религионзую оценку аккуратно говорить во Флейме. Что касаемо темы - пока нет описания идеи и работающего прототипа, разговоры тут путсые, разработки в принципе нет, обсуждать нечего. Если ТС не тролль, то он ведь нисколько не расстроится, если обсуждение его работы мы отложим до публикации видео работы прототипа или текста патента, правда?
Smalovsky
31.07.2016, 02:27
Я не расстроюсь. Только этическая составляющая использования видеорежима также равнаправна как и техническое описание. И мне надо будет где-то писать прогресс.
Есть нормы - есть видеорежим, нет норм - видеорежим будет только моей собственностью.
Alex Rider
31.07.2016, 02:48
Есть нормы - есть видеорежим, нет норм - видеорежим будет только моей собственностью.
Ну ок. Но как бы нет устройства в публичном пространстве - нет этических аспектов его использования другими, чего обсуждать-то сейчас?
Shnurkov
31.07.2016, 14:22
Тему почистил, просьба обсуждать в этой теме только видеорежим и патенты на него. если большое желание обсуждать этику в играх, религию и т.д.,то велкам в отдельную тему и желательно не в концепциях. Дальше буду раздавать карточки
inozemcew
14.08.2016, 14:57
Заинтересовала тема, решил подумать, как же можно малой кровью убрать клэшинг. Идея такая - экран состоит из нескольких экранных плоскостей (2,4,8 штук), которые находятся над друг над другом. Самая нижняя плоскость - обычный спектрумовский экран, на нем рисуется фон. Каждая следующая плоскость предназначена для рисования спрайтов. Это тоже обычный спековский экран, но с одним отличием. Если его точка имеет цвет INK, то она отображается цветом из атрибутов этой плоскости. Если же она имеет цвет PAPER, то она считается прозрачной, и сквозь нее "просвечивают" нижележащие слои. Вот, в принципе, и всё. Для управления всем этим хозяйством нужен один-едиственный порт, в котором задается номер плоскости, которая маппится в адресное пространство экрана ($4000-$5aff).
Как это все работает - очень просто. Рисуем фон на самой нижней плоскости, переключаемся на плоскости повыше, рисуем спрайты. Если модифицируем готовую игру, достаточно найти процедуру вывода спрайта, и вставить перед ней OUT (c),<номер плоскости>, а после нее вернуть плоскость 0.
Двух плоскостей уже достаточно, чтобы убрать клэшинг атрибутов фона и спрайтов. Четырех хватит, чтобы сделать независимыми фон, врагов, снаряды и героя. Восемь плоскостей позволят решить вообще все проблемы клэшинга.
Итак, достоинства - просто, доступно, легко модифицировать готовый софт. Теперь недостатки. Главный недостаток - сам по себе клэшинг, не такая уж большая беда. Да неприятно, но если его убрать мало что изменяется. Монохромные спрайты остаются монохромными, и без существенной переработки это никак не исправить. Вот, парочка мок-апов для того, чтобы было видно, что получим в конце-концов.
5785857859
null_device
14.08.2016, 15:30
экран состоит из нескольких экранных плоскостей (2,4,8 штук)
Чем-то мне это неуловимо напоминает дендиевские "слои"...
inozemcew, Хорошая попытка, но вижу трудности. (Давно тут сидим)
Вот возьмём твою картинку с Рэмбо, и рассмотрим белые бочки на жёлтом полу.
Пол, как я понимаю, нарисован на нулевом слое(самом дальнем (самом нижнем)), а бочки, допустим на втором.
Но чтобы бочки были правильные, нам не только надо добавить белый цвет, но и чёрный (окантовка и рёбра).
Это значит, что нам нужно, либо править нулевой слой, либо вводить первый слой (между 0 и 2), с чёрным ИНК-ом.
А это уже не слабо раздует модифицируемую программу и по тактам и по байтам.
По тактам, конечно, важно не для бочек, а для спрайта героя и других подвижных объектов.
основных проблем вобщем две при решении клешинга
1. где взять вычислительную мощность
2. как адаптировать старый софт (на написание нового расчета ничтожно мало)
null_device
14.08.2016, 15:38
Теперь недостатки.
Главный "недостаток": для каждого слоя нужна взять ~6К под "страницу" видео-памяти. И как-то реализовать программно-аппаратный интерфейс (ведь теперь, 50 раз в секунду, на экране должно отображаться содержимое всех слоев).
inozemcew
14.08.2016, 16:02
Чем-то мне это неуловимо напоминает дендиевские "слои"...
Не-не.. Скорее Векторовские битпланы.
Но чтобы бочки были правильные, нам не только надо добавить белый цвет, но и чёрный (окантовка и грани).
Конечно, маска спрайта. Совершенно правильно, имеется два варианта. Либо выводим в нижележащий слой как обычную маску, либо в промежуточный слой, как черный спрайт. Ничего тут стремного нет. В каждой игрушке, использующей маскИрованные спрайты такая процедурка есть. Единственное, это когда вывод спрайта и маски делается сразу для каждого отдельного байта. Тут надо или немного изменить процедуру вывода и разнести вывод маски и спрайта (по процессорному времени это будет практически одинаково), либо да, таки переключать плоскости. Тут можно придумать, для ускорения процесса, триггер четный/нечетный, который будет менять плоскости n и n-1 через каждый записанный байт.
где взять вычислительную мощность
Мощьность для чего? Чтобы сделать OUT (порт),<плоскость для спрайта>? Так ее не очень и много-то надо
как адаптировать старый софт
Расставить OUT (порт),<плоскость для спрайта> перед процедурой вывода спрайта. Достаточно STSа, даже дизасемблер не нужен.
- - - Добавлено - - -
Главный "недостаток": для каждого слоя нужна взять ~6К под "страницу" видео-памяти. И как-то реализовать программно-аппаратный интерфейс (ведь теперь, 50 раз в секунду, на экране должно отображаться содержимое всех слоев).
Да, 8 битная память тут никак. Для 4 слоев надо уже 32 бита.
И как-то реализовать программно-аппаратный интерфейс
Позиционный шифратор и мультиплексор, чтобы из 2,4 или 8 INKов выбрать один.
Мощьность для чего? Чтобы сделать OUT (порт),<плоскость для спрайта>? Так ее не очень и много-то надо
и для этого тоже и для того что цпу надо будет пересылать гораздо больше байт памяти чем он привык и для чего расчитан, так как цвета из ничего не бывают
null_device
14.08.2016, 16:12
Мощьность для чего? Чтобы сделать OUT (порт),<плоскость для спрайта>? Так ее не очень и много-то надо
Кто будет извлекать данные из памяти для построения картинки на экране? В обычном спектруме, чтением данных и атрибутов из памяти - этим занимается процессор z80. ;)
Основное, что мне в этом методе "не нравится" - он не обеспечивает "честного" режима цвет-на точку в пределах знакоместа. Т.к., для него - слоев надо, минимум 8! И, вот тут мы подошли к вопросу, относительно атрибута знакоместа - яркость... как быть с ним?
Любое изменение программы - условно равносильно написанию новой программы.
Поясню мысль: чтобы вставить что-то куда-то - надо найти свободное место.
значит в то место где нужно вставить OUT надо будет вставить CALL на свободное место где будет исходный кусок программы (как минимум 3 байта) + OUT + RET.
Есть другой вариант: дизасм всё и вся, и сборка обратно.
Кто эти будет заниматься ?
Чисто аппаратными средствами (без изменения программы) не добиться результата...
Посему "новый вариант устранения клешинга" - это фикция.
Реально борьба с клешингом - это создание физически другого компьютера и написание нового софта. Другого способа нет и не будет.
Кому "нужен" такой "новый вариант устранения клешинга" ?
null_device
14.08.2016, 16:36
AlexG, насколько я понял, целью и было:
создание физически другого компьютера и написание нового софта.
А также: возможностью запуска старых программ без получения "недокументированных эффектов" на экране. Написании "новых" с учетом, изобретенной "мульки" и правка "старых" программ, насколько это возможно и оправданно - без обратной соместимости.
запуск "старых" оригинальных программ на другом железе для устранения клешинга не возможна без модификации "старых" программ.
вот и получаем "новые" программы на другом железе...
На ПК уже давно нет клешинга
В чём профит этого "нового способа" ??? если всё "новое" должно быть ? с таким успехом можно взять любую другую платформу и писать на неё программы сразу без клешинга.
Я могу в теории написать (портировать) любую игру на ПК и "вуаля - клешинг отсутствует"!!!
были ж программы портированые на атари коммнодоре спектруме.
В чём новизна(идея) сего "патента"? в том что "новыми словами" описываются уже существующие реалии ?
Дык это попахивает плагиатом...Какая здесь борьба за нравственную чистоту ?
Почему-то это напоминает мне "палату №6", ну или комплекс наполеона...
Сорри за оффтоп. По мне тема высосана из пальца и к "физической реализации не пригодна"
AlexG,
Любое изменение программы - условно равносильно написанию новой программы
Весьма условно. :)
inozemcew
14.08.2016, 17:12
и для этого тоже и для того что цпу надо будет пересылать гораздо больше байт памяти чем он привык и для чего расчитан, так как цвета из ничего не бывают
Не-не-не.. все намного проще.. Никто никуда ничего дополнительно не пересылает.
Как это работает в обычном спеке? Сначала рисуется фоновый лес и заливается атрибутом с зеленым INKом, правильно? Потом, на фоне этого леса рисуется персонаж и атрибуты поверх него устанавливаются в белый, с соответствующим клэшингом. Что предлагается, прежде чем рисовать героя надо переключить экранную плоскость, дальше все тоже самое - рисование спрайта, установка атрибутов, где тут дополнительные байты для пересылки?
Весь фокус в том, что обычном спеке прорисовка экрана под персонажем происходит дважды. Сначала рисуется фон и его атрибуты, а потом он же затирается спрайтом героя и его атрибутами. Идея ж в том, что при том же объеме данных, они не затирают друг друга, а идут в разные плоскости, что и позволяет разрулить клэшинг.
Основное, что мне в этом методе "не нравится" - он не обеспечивает "честного" режима цвет-на точку в пределах знакоместа.
А разве это требовалось? Суть задачи - убрать клэшинг с максимально возможной совместимостью с существующим софтом.
Любое изменение программы - условно равносильно написанию новой программы.
Вы ошибаетесь. Изменения, которые потребуется внести, ничуть не сложнее, скажем, переделки записи сохранения на ленту под ТР-ДОС.
- - - Добавлено - - -
И, вот тут мы подошли к вопросу, относительно атрибута знакоместа - яркость... как быть с ним?
А что за проблема с ним?
null_device
14.08.2016, 17:32
А что за проблема с ним?
На каждом слое мы имеем в области цветовых атрибутов бит яркости и мерцания. Для стандартного экрана спектрума они задаются для всего знакоместа. Как они будут интерпритироваться в вашей реализации?
Никто никуда ничего дополнительно не пересылает.
Как минимум, нужно вместо записи в одну область памяти, "щелкать" портом - переключая слои и пересылать туда данные. При этом, надо выводить ОДНОВРЕМЕННО (либо, квазипараллельно - не суть) состояние всех слоев в виде точки растра на экране (существенную часть времени, процессор спектрума, занят именно этим). Техническая реализация, подразумевает, что отрисовка всех слоева будет укладываться по тактам в процедуру вывода стандартного экрана.
inozemcew
14.08.2016, 17:51
На каждом слое мы имеем в области цветовых атрибутов бит яркости и мерцания. Для стандартного экрана спектрума они задаются для всего знакоместа. Как они будут интерпритироваться в вашей реализации?
С точки зрения цветности все очень просто. Смотрите, вместо того, чтобы рисовать фон, героя, снаряды, врагов на одном экране, мы рисуем фон на одном экране, героя на втором, пули на третьем и монстров на четвертом. Заметьте, объем прорисовки точно такой же, как и для одного экрана. Теперь видеокарта накладывает эти экраны один на другой, причем цвет PAPER для верхних экранов считаем прозрачным. Если мы, например в верхней плоскости имееем INK точку ярко-красного цвета - ее и выводим. Если же эта точка установлена в 0 (PAPER) - идем в слой ниже и смотрим его. Если там темно-синий INK - выводим, нет - спускаемся дальше, и так до последнего слоя, который уже обычный спековский экран.Вот и весь алгоритм работы видеоконтроллера, никаких шейдеров, процессоров и тд и тп.
При этом, надо выводить ОДНОВРЕМЕННО (либо, квазипараллельно - не суть) состояние всех слоев в виде точки растра на экране (существенную часть времени, процессор спектрума, занят именно этим).
Нет. Ничего не выводится квазипаралельно. Слои нужны только, чтобы для каждого спрайта можно было задать приоритет и выбрать, в соответствии с этим приоритетом, атрибут для его пикселей установленых в 1. Больше ничего не меняется. Никаких "точка своим цветом" и т.п., только устранение клэшинга с минимальными усилиями.
null_device
14.08.2016, 18:00
Нет. Ничего не выводится квазипаралельно.
Попробуйте отрисовать подряд восемь стандартных экранов спектрума. А потом - представаить, как это будет реализовано в железе.
С точки зрения цветности все очень просто.
Тоесть, для отображения всей палитры надо уже 16 слоев. Как-то многовато...
Почитайте тему
http://zx-pk.ru/threads/21462-bystraya-videokarta-quot-meteor-2013-quot.html
и хватить "лохматить бабушку" (с)
рисуем фон на одном экране, героя на втором, пули на третьем и монстров на четвертом.
Так, а слои перед этим надо очистить?
Напрашивается квадробуферизация. Один буфер отображается в текущем кадре. Второй готов к отображению в следующем кадре. Третий заполняется процессором пулями и героями. Четвёртый очищается спецблиттером-обнулятором. :)
Почитайте тему
http://zx-pk.ru/threads/21462-bystra...2013-quot.html
и хватить "лохматить бабушку" (с)
у этой "видеокарты" спектрум затеряется в fpga в качестве ненужного довеска, а тут тема насчет клешинга у спектрума всеж
- - - Добавлено - - -
Напрашивается квадробуферизация.
какие бы слои не были они берут память, а память надо кому то пересылать, вот вопрос кто это будет делать, как правило все решают что "надо делать контроллер который будет это делать", после чего выясняется что с текущими решениями такой контроллер будет на порядки мощнее того кому будет помогать и вообще неясно зачем при таком надо спектрум
В той теме
"Видеокарта "Meteor Graphics" позволяет путем небольших изменений в коде игры устранить клешинг атрибутов главного героя (ГГ)
"
Это разве не новое железо с небольшими изменениями в коде ?
Перечитайте первое сообщение и с десяток последних темы ТС.
Как говорится "найди десять отличий" от Видеокарта "Meteor Graphics"
А выглядит это так: ТС хочет запантетовать то что "придумал" zst.
Ещё скажите что я не прав...
А выглядит это так: ТС хочет запантетовать то что "придумал" zst.
Ещё скажите что я не прав...
это врядли, так как там идей нет, изобретений тоже, патентовать нечего, сложно запатентовать архитектуру процессор+память, если они к тому же соединены по вполне стандартной схеме
А здесь что не обсуждаются слои со всеми вытекающими последствиями ?
Вот ZX-Poly - это да оригинальная в своём виде идея.
А здесь что не обсуждаются слои со всеми вытекающими последствиями ?
я вообще не понимаю почему всех клинит на слоях если учесть что спектрум это платформа в которой нет какого то графического процессора который диктовал бы слои и это можно было бы использовать, т.е. все игры разрабатывались совершенно разнообразно и рассчитывать "вот в игре слои" это как то странно, так как все игры от разных разработчиков написаны совершенно по разному, играться с атрибутами - но большинство игр черно-белые, а те что с атрибутами они уже как правило подогнаны под знакоместа что бы раскрашено выглядеть
Дык и я о том же. Если обсуждаем слои - то идём в ту тему.
Как было выше сказано "клешинг" это железо+софт. Убираем ""клешинг" - получаем "IBM PC"(всё что угодно только не спектрум48/128).
И остаётся "политика" "Я запрещаю нажимать клавишу ПРОБЕЛ на IBM PC".
ПС: можно поизвращаться в 128 посредством переключения экрана - для моделирования двух слоёв. Но это тоже уже было изобретено (или у меня старческий склероз?)
Основное, что мне в этом методе "не нравится" - он не обеспечивает "честного" режима цвет-на точку в пределах знакоместа.
А мне это наоборот, нравится. Цвет на точку рождает чудовищ. Да и не нужен он никому сейчас. Ладно в 1995 было круто иметь графон как на пэцэ. Но сейчас-то что за ним гнаться?
А описанная "ВЕКТОРизация" - это действительно простая идея, которая заметно улучшит вид картинки самой малой кровью.
inozemcew
14.08.2016, 19:17
Попробуйте отрисовать подряд восемь стандартных экранов спектрума. А потом - представаить, как это будет реализовано в железе.
Но зачем? Зачем рисовать восемь экранов?
Один экран рисуется, один! совсем один! Просто разные части этого экрана разносятся по разным плоскостям.
Тоесть, для отображения всей палитры надо уже 16 слоев.
А не надо отображать всю палитру. Цель совершенно в другом.
Так, а слои перед этим надо очистить?
Да, иногда таки надо.. Но. В диззиобразных играх там никто не перерисовывает фон каждый кадр. Только восстанавливают фон под спрайтом и рисуют спрайт в новом месте. В данном случае, вместо восстановления фона нужно просто стереть спрайт на старом месте.
Как вариант, можно сделать так, что запись в слой 0 автоматом обнуляет пиксели всех остальных слоем. Тогда старая процедура восстановления фона автоматически сотрет все вышеналоженые спрайты.
какие бы слои не были они берут память, а память надо кому то пересылать, вот вопрос кто это будет делать, как правило все решают что "надо делать контроллер который будет это делать",
Нет. Никаких контроллеров. Исключительно родной Z80. Да, памяти задействовано в разы больше, но большая часть ее просто простаивает, задействованный объем будет такой же, как в оригинале.
А выглядит это так: ТС хочет запантетовать то что "придумал" zst.
Извините, но я не имею никакого отношения ни к топикстартеру, ни к его заморочкам.
но большинство игр черно-белые,
Как раз такое раскрасить проще простого. Лишь бы был последовательный вывод спрайтов. Попадание в знакоместа совсем не причем.
Но зачем? Зачем рисовать восемь экранов?
Один экран рисуется, один! совсем один! Просто разные части этого экрана разносятся по разным плоскостям.
А не надо отображать всю палитру. Цель совершенно в другом.
Да, иногда таки надо.. Но. В диззиобразных играх там никто не перерисовывает фон каждый кадр. Только восстанавливают фон под спрайтом и рисуют спрайт в новом месте. В данном случае, вместо восстановления фона нужно просто стереть спрайт на старом месте.
Как вариант, можно сделать так, что запись в слой 0 автоматом обнуляет пиксели всех остальных слоем. Тогда старая процедура восстановления фона автоматически сотрет все вышеналоженые спрайты.
Нет. Никаких контроллеров. Исключительно родной Z80. Да, памяти задействовано в разы больше, но большая часть ее просто простаивает, задействованный объем будет такой же, как в оригинале.
Извините, но я не имею никакого отношения ни к топикстартеру, ни к его заморочкам.
Как раз такое раскрасить проще простого. Лишь бы был последовательный вывод спрайтов. Попадание в знакоместа совсем не причем.
Я конечно сильно извиняюсь но ВЫ лично когда либо разрабатывали схему электрическую принципиальную ? Написали хоть одну коммерчески успешную программу ?
У Вас что ни фраза - то черномырдин.
"Один экран рисуется, один! совсем один! Просто разные части этого экрана разносятся по разным плоскостям."
Определитесь что у вас значит экран а что плоскости в физических реалиях.
"Да, памяти задействовано в разы больше, но большая часть ее просто простаивает, задействованный объем будет такой же, как в оригинале. "
как может память задействована в разы больше и будет при этом простаивать и объём будет такой же как в оригинале ?!
inozemcew
14.08.2016, 19:37
ПС: можно поизвращаться в 128 посредством переключения экрана - для моделирования двух слоёв. Но это тоже уже было изобретено (или у меня старческий склероз?)
Вот, кстати, сейчас на этом примере и объясню принцип работы. Представьте, что мы сначала выводим фон и спрайты на стандартный экран. Все хорошо, но есть клэшинг. Затем мы в 128к, на 0м экране нарисовали фоновое изображение, а на 1м экране на черном фоне рисуем и двигаем спрайты. Объем данных очевидно такой же, как и в первом случае. Экраны переключаем через кадр и видим, как спрайты движутся по фону без всякого клэшинга, но, к сожалению есть противное мерцание. Как от него избавиться? Очень просто. 1й экран нужно включать только тогда, когда на нем отображается точка цветом INK, иначе нужно включить 0й экран для отображения фона. Программно это сделать затруднительно, вот и предлагается аппаратная доработка.
Вот примерно так все и работает. Только экранов-плоскостей может быть и больше двух.
спрайты движутся по фону без всякого клэшинга, но, к сожалению есть противное мерцание.
Хм, плоховат пример. Как это без всякого клешинга?
Ладно, не надо уже в четвёртый раз всё по новой объяснять. Кому надо, тот и в первый раз всё понял. Надо дальше двигаться. Придумать адреса портов. Придумать как оно будет со стороны программы управляться и переключаться. Переделать одну игру. Например "3 недели в раю". Обкатать её на эмуляторе. :)
inozemcew
14.08.2016, 20:07
Я конечно сильно извиняюсь но ВЫ лично когда либо разрабатывали схему электрическую принципиальную ?
Было дело :v2_blush:
Определитесь что у вас значит экран а что плоскости в физических реалиях.
Извините, возможно я где-то нечетко выразился. Во фразе "для построения экрана требуется такой же объем данных, как и на обычном спеке" под словом "экран" следует понимать "кадр изображения, формируемый в одном цикле игры".
как может память задействована в разы больше и будет при этом простаивать и объём будет такой же как в оригинале ?!
Очень просто. Если, например, мы из каждой страницы 128й памяти будем использовать по 256 байт, то общий объем использованной памяти будет равен 2кБ. Остальная память будет простаивать. Так и здесь. Суммарный объем заполненный изображением будет почти таким, как на стандартном экране, остальное будет заполнено нулями.
null_device
14.08.2016, 20:26
А не надо отображать всю палитру. Цель совершенно в другом.
Либо я не понимаю значения "клэшинг", либо - одно из двух!
Зачем рисовать восемь экранов?
памяти задействовано в разы больше, но большая часть ее просто простаивает, задействованный объем будет такой же, как в оригинале.
Это, каким же образом?!
В диззиобразных играх там никто не перерисовывает фон каждый кадр. Только восстанавливают фон под спрайтом и рисуют спрайт в новом месте. В данном случае, вместо восстановления фона нужно просто стереть спрайт на старом месте.
"Родите" мне пожалуйста, хотя бы не функциональную, а структурную схему - как все это должно работать. Но, перед этим почитайте о работе видеоконтроллера zx-spectrum. Так, для общего развития.
s_kosorev
14.08.2016, 21:16
Я конечно сильно извиняюсь но ВЫ лично когда либо разрабатывали схему электрическую принципиальную ?
http://speccy.info/DMA_USC
тут такой момент интересен "DMA Ultrasound Card (часто используется сокращение DMA USC) - звуковая карта для отечественных клонов ZX Spectrum. Разработана Алексеем Иноземцевым и группой Witchcraft Creative Group (Украина, города Дзержинск и Зугрэс Донецкой области) "
Spectramine
14.08.2016, 21:33
Итак, достоинства - просто, доступно, легко модифицировать готовый софт. Теперь недостатки. Главный недостаток - сам по себе клэшинг, не такая уж большая беда. Да неприятно, но если его убрать мало что изменяется. Монохромные спрайты остаются монохромными, и без существенной переработки это никак не исправить. Вот, парочка мок-апов для того, чтобы было видно, что получим в конце-концов.
Интересная идея. Я лично вижу в ней большой потенциал. Избавление от клэшинга это уже большой плюс, а для цветных спрайтов есть битовые планы всей памяти (ZX-Poly и Spec256).
- - - Добавлено - - -
Жаль, с ее помощью не раскрасишь игры, которые изначально монохромные. Ну то есть раскрасишь, но надо к спрайтам добавлять информацию о цвете, изменять процедуру вывода, в общем, возни намного больше. upd. ...хотя,тогда можно к Out на переключение слоя добавить Out на управление цветом спрайта)
а для цветных спрайтов есть битовые планы всей памяти (ZX-Poly и Spec256).
ZX-Poly в отличии от Spec256 еще позволяет увеличить всеж в два раза разрешение оставив клэшинг, что очень клево для системных и прикладных программ, которые не надо переписывать, что я показал на примере ZXWord, спектрум это всеж не только для игр, но и для серьезных дел платформа
http://speccy.info/DMA_USC
тут такой момент интересен "DMA Ultrasound Card (часто используется сокращение DMA USC) - звуковая карта для отечественных клонов ZX Spectrum. Разработана Алексеем Иноземцевым и группой Witchcraft Creative Group (Украина, города Дзержинск и Зугрэс Донецкой области) "
Если это так - то странно выглядят изречения сего товарища...
Либо я не понимаю значения "клэшинг", либо - одно из двух!
Белая бочка с чёрной окантовкой стоит на жёлтых досках с чёрной-же оконтовкой. 3 цвета и нет клешинга. Не надо любой цвет на точку.
null_device
15.08.2016, 07:41
Reobne, если внутри одного знакоместа, одновременно, нет возможности отобразить всю палитру - о каком устранении клэшинга можно говорить?
null_device, думаю, мы как-то по разному понимаем клешинг.
Смотрим клешинг в Lode Runer на приложенной картинке. Я вижу, что достаточно применить два слоя inozemcew-а, нулевой и первый, и клешинга не будет.
Вот то самое устранение клешинга, о котором мы говорим.
Жду ответной иллюстрации. :)
s_kosorev
15.08.2016, 08:35
сли это так - то странно выглядят изречения сего товарища...
Да нет, все просто, просто не хватает силы мысли осознать что пытается довести "товарищ".
null_device
15.08.2016, 09:09
Reobne, каждый слой, теоретически решит проблему вывода отображения в одном знакоместе еще одного элемента, цветом отличного от тех что там есть. Эту мысль, я уловил.
А теперь, представим, что нужен еще подвижный (или неподвижный - не суть) элемент, которые надо отобразить в то же знакоместо, что и фиолетового человечка, но он имеет цвет, отличный от представленных на экране (например - желтого)? Нужен еще один слой!
null_device, Не представляю. Приведи пример, дай картинку.
- - - Добавлено - - -
Даже если теоретически, предположить, что есть игра, в которой, до полного устранения клешинга не хватит 8-ми слоёв. Всё равно 8-мь слоёв inozemcew-а уберут огромную часть клешинга и в ней.
ZX_NOVOSIB
15.08.2016, 10:39
Всего 3 цвета на знакоместо решили бы проблему клэшинга в 99% zx-игр. Ну а 4 цвета - это было бы вообще роскошно ))
"Цвет на точку" - не особо то и нужен, не стоит за ним гнаться. В общем три цвета на знакоместо = хана клэшингу.
Три цвета - уже победа, диззи уже не придётся быть хамелеоном и принимать цвет травы, деревьев, перил и т.п.
Перед Уолли из "трёх дней в раю", уже не будет стоять выносящая мозг дилемма: кем быть по жизни - хамелеоном или маляром? Он наконец-то сможет быть просто самим собой!
inozemcew
15.08.2016, 11:29
Ну то есть раскрасишь, но надо к спрайтам добавлять информацию о цвете, изменять процедуру вывода, в общем, возни намного больше. upd. ...хотя,тогда можно к Out на переключение слоя добавить Out на управление цветом спрайта)
Цвет спрайта не управляется OUTом. В каждом слое есть своя область атрибутов. Только PAPER у верхних слоев прозрачен. А INK и определяет цвет спрайта. Для монохромных спрайтов все очень просто. Достаточно нужный слой заранее залить необходимым цветом INK, и тогда при выводе в этот слой спрайт сразу же будет окрашен в нужный цвет.
А теперь, представим, что нужен еще подвижный (или неподвижный - не суть) элемент, которые надо отобразить в то же знакоместо, что и фиолетового человечка, но он имеет цвет, отличный от представленных на экране (например - желтого)? Нужен еще один слой!
Ваша проблема в том, что вы отталкиваетесь от неких абстрактных понятий, а не от конкретных спектрумовских игр. Посмотрите на типичную игру - сколько спрайтовых слоев вы там найдете? Герой, предметы, враги - вот практически и все.
Ладно, не надо уже в четвёртый раз всё по новой объяснять. Кому надо, тот и в первый раз всё понял. Надо дальше двигаться. Придумать адреса портов.
Та не.. Объяснять таки надо. Народ начинает понимать идею, но до конструктивной критики (ради чего я сюда собственно и запостился) дело еще не дошло. А недостатки в предложеной схеме таки имеются. Не надуманные, типа "как z80 справится?" или "нет 16 цветов на точку", а таки реальные.
не функциональную, а структурную схему - как все это должно работать.
Вы уверены, что это вам поможет понять суть предложенной идеи? Чего-то я сомневаюсь, что структурная схема этому поможет. А то не очень хочется заниматься бесполезным рисованием.
Smalovsky
15.08.2016, 11:43
Пусть автор предложенного принципа пишет в своей теме, а не в мою.
Прошу модератора временно заблокировать тему, пока я мне напишу ему в личку о разблокировке. Пока я сейчас хочу хоть как-то юридически оформить техническую информацию на случай патентного спора( у меня принцип другой, но всё же...).
А автору нового принципа нужно подумать, как ему разнести слои в памяти( в одной памяти или отображаемыми страницами) и решить проблему выборки данных да так, что бы не затереть системные переменные( если будут отображаться страницы по 8 кб, то в месте с переключением страницы переключится и информация необходимая системе).
надуманные, типа "как z80 справится?"
поабавило, z80 это единственный активный компонент в системе и при этом его нагрузка рассматривается как "надуманная" :)
inozemcew, нужно решать нюансы.
Как назвать новый стандарт?
Какие порты управления, с что они делают.
При переключении страницы рисования какое окно переключается?
(Например конкретно с $4000 по $5AFF, или для упрощения аппаратуры с $4000 по $5FFF, или ещё как-то. Что делать со вторым экраном для Spectrum128К?)
Я конкретно спрашиваю. Если сам не хочешь об этом подумать, так и скажи, подумаем вместе.
Smalovsky
15.08.2016, 11:59
Ребята, в отдельную тему.
Какой смысл плодить 100500 одноимённых тем по устранению клешинга.
Как назвать новый стандарт?
InnoLayers, гы
Какой смысл плодить 100500 одноимённых тем по устранению клешинга.
Ну а прикинь счас на этой незапатентованной технологии игр про зло и магию наштампуют? Да ещё и прямо в этой теме? ТС расстроится...
- - - Добавлено - - -
для упрощения аппаратуры
Будто кто-то будет это на мелкой логике собирать :)
Smalovsky
15.08.2016, 13:31
Я, например, не лез в темы ZST со своим принципом антиклешинга, а создал свою тему.
- - - Добавлено - - -
Ну а прикинь счас на этой незапатентованной технологии игр про зло и магию наштампуют?
Пусть на этот вопрос ответит автор нового непатентованного принципа.))
Очень он глупо поступил, что сразу расскрыл свой видеорежим. Теперь ему возможно придётся увидеть как с помощью его видеорежима на экране будут показываться страшные вещи - особо жестокие убийства, гомосексуализм и половые извращения, педофилия... Ведь больных людей возможно очень много и среди спектрумистов, и они непременно выплеснут на экран все свои болезненные представления.
Мне жалко человека...
Очень он глупо поступил, что сразу расскрыл свой видеорежим. Теперь ему возможно придётся увидеть как с помощью его видеорежима на экране будут показываться страшные вещи - особо жестокие убийства, гомосексуализм и половые извращения, педофилия... Ведь больных людей возможно очень много и среди спектрумистов, и они непременно выплеснут на экран все свои болезненные представления.
http://cs630430.vk.me/v630430473/413fb/mL62pR1vCgQ.jpg
Сорян, не выдержал)))
Я, например, не лез в темы ZST со своим принципом антиклешинга, а создал свою тему.
И как только в теме внезапно стали обсуждать собственно клешинг, вместо вопросов нравственности и морали, попросили всех "вон из моей песочницы" :)
практически джентельменский набор
http://www.worldofspectrum.org/pub/sinclair/screens/load/b/gif/Bloody.gif
ZX_NOVOSIB
15.08.2016, 14:19
Ведь больных людей возможно очень много и среди спектрумистов, и они непременно выплеснут на экран все свои болезненные представления.
Ты прав, бро, среди спектрумистов полным-полно больных во всю голову людей. Буквально каждый третий - словно сбежал из психушки. Однако больные люди, к счастью, не склонны делать игры! Бро, игры делают в основном здоровые, больные же не делают игр, больные только выплескивают на форум свои болезненно-бредовые представления ;)
inozemcew
15.08.2016, 14:40
поабавило, z80 это единственный активный компонент в системе и при этом его нагрузка рассматривается как "надуманная"
Понятно, что имея экранной памяти в 2,4,8 раз больше, можно нагрузить z80 по самые помидоры. Но, для того чтобы устранить клэшинг в существующих играх это просто не нужно. Клэшинг устраняется из-за того, что разные спрайтовые слои выводятся в разные экранные плоскости. Объем же данных, которые надо перелопатить процессору, практически не изменяется.
Как назвать новый стандарт?
Не знаю. Мне собственно безразлично.
Какие порты управления, с что они делают.
Один порт - номер плоскости, которая смаппирована в адреса $4000-$5aff, нижняя плоскость, которая спековский экран, имеет номер 0, устанавливается по сбросу. Можно сделать бит 7 - отключение плоскостей 1 и выше, но если при записи в 0ю плоскость остальные будут очищаться, то это не нужно.
Что делать со вторым экраном для Spectrum128К?
Ничего специального. Он будет иметь такую же структуру и управление от того же порта.
Это все мелочи. Есть вопросы потруднее.. Сколько плоскостей потребуется. Чем их больше, тем сложнее конструкция. Можно ли сделать спрайтовые плоскости теневыми, т.е. недоступными для чтения? Нужны ли отдельные плоскости для спрайтовых масок? Какова должна быть структура спрайтовых слоев, может есть вариант лучше, чем спековский экран с прозрачным PAPER?
null_device
15.08.2016, 15:54
Клэшинг устраняется из-за того, что разные спрайтовые слои выводятся в разные экранные плоскости.
Вы описываете видеопроцессор а-ля, NES. В противном случае:
имея экранной памяти в 2,4,8 раз больше
упрёмся в быстродействие шины для передачи данных, или:
можно нагрузить z80 по самые помидоры
конвертируя и пересылая, или детектируя, что вот это спрайт должен лежать в другой "слое" с такими-то атрибутами и отображаться так-то и так-то.
inozemcew, пока не вижу сложности в софтверной части - основной "спотыкач" в реализации вашей примочки "в железе".
Нужны дополнительные банки памяти, в которых будут лежать аналоги "теневых экранов" (читай - слоев), структура данных в которых будет 1 в 1 повторять стандартный экран спектрума (изложенный вами принцип "эквилибристики" со спрайтами - мне не до конца понятен, что за штука и как оно работает).
Самое, главное: на аппаратном уровне решить вопрос с построением изображения на экране телевизора. При отрисовке строки экрана, нужно извлечь в буфер, данные из памяти "стандартного" экрана вместе с атрибутами, а затем, по-очереди, из всех дополнительных с их атрибутами - после чего, совместить полученную информацию из буферов в соотвествии с вашей логикой и выдать ее на телевизор в виде разноцветной линии. Если делать это по очереди, от моргания, вполне можно будет получить приступ эпилепсии (т.к. квазипараллельность товарищь (http://zx-pk.ru/threads/26792-novyj-printsip-ustraneniya-kleshinga.html?p=881916&viewfull=1#post881916) inozemcew, почему-то отверг).
Короче, ждем у барака. ;)
Понятно, что имея экранной памяти в 2,4,8 раз больше, можно нагрузить z80 по самые помидоры. Но, для того чтобы устранить клэшинг в существующих играх это просто не нужно. Клэшинг устраняется из-за того, что разные спрайтовые слои выводятся в разные экранные плоскости. Объем же данных, которые надо перелопатить процессору, практически не изменяется.
я наверное неочень понимаю идею, тут лучше действительно расписать в виде блоксхемы какой что бы понятно стало что имеется в виду
Spectramine
15.08.2016, 16:40
Цвет спрайта не управляется OUTом. В каждом слое есть своя область атрибутов. Только PAPER у верхних слоев прозрачен. А INK и определяет цвет спрайта. Для монохромных спрайтов все очень просто. Достаточно нужный слой заранее залить необходимым цветом INK, и тогда при выводе в этот слой спрайт сразу же будет окрашен в нужный цвет.
.
А как вы будете заливать нужный слой цветом? Я и предлагаю - для монохромных игр задавать цвет спрайта (или слоя) через OUT в другой порт. Если так, как предлагаете вы, это процессору надо, кроме OUT по переключению слоя, ещё как-то заливать нужный слой цветом INK (а программисту - ещё куда-то втиснуть эту заливку в код программы) . А так - выдал в порт INK выводимого спрайта перед сменой слоя, и видеокарта дальше сама знает, что спрайт выводится с этим INK, и заполняет им атрибуты спрайта автоматом, при выводе процессором пиксельной части спрайта (которая для монохромных игр им только и выводится, без атрибутной части). То есть, кроме порта переключения слоя, ещё вводится порт управления атрибутом спрайта, и вместо одного OUT на вывод спрайта - два. (А нулевое, например, значение в порту атрибута означает, что атрибут пишется в слой не видеокартой из порта атрибута, а программой при выводе цветного спрайта).
- - - Добавлено - - -
http://cs630430.vk.me/v630430473/413fb/mL62pR1vCgQ.jpg
Сорян, не выдержал)))
Во-первых, не всем насрать, вот топикстартеру не насрать. А остальным - тихо удивляться, как в одной голове сочетается идея избавления от спектрум-клэшинга и озабоченность "как с помощью его видеорежима на экране будут показываться страшные вещи - особо жестокие убийства, гомосексуализм и половые извращения, педофилия..." Лично я решил считать это особо тонким троллингом, моя психика отказывается принимать это всерьёз.
Да нет, все просто, просто не хватает силы мысли осознать что пытается довести "товарищ".
ОФФтоп. Значит я суперстар...:v2_dizzy_vodka3:
s_kosorev
15.08.2016, 17:14
Имхо реализация проста, можно и 16 бит обойтись, виртуальной работать с пакетами по 64бит, единственное частота должна быть в 8 раз выше частоты памяти спектрума, если использовать sdram 16 бит, в итоге получится что то около 50мгц
inozemcew
15.08.2016, 17:14
я наверное неочень понимаю идею, тут лучше действительно расписать в виде блоксхемы какой что бы понятно стало что имеется в виду
Окей, давайте посмотрим как устроен обычный спековский видеоконтроллер
57867
Регистр атрибута, сдвиговый регистр, и мультиплексор, который в зависимости от значения текущего бита выбирает какую часть атрибута, INK или PAPER выдавать на видеовыход.
Теперь, что нужно, чтобы получить 4 слоя. Очевидно еще 3 штуки RAMы паралельно стандартной. Плюс логика, которая в зависимости от значения в порту управления устройством обеспечивает доступ процессора к нужной линейке RAM. Далее 4 регистра атрибутов, в которых защелкиваются 4 атрибута и 4 сдвиговых регистра в которых происходит сдвиг пиксельных данных. Далее дешифратор, в зависимости от того, в каком из сдвиговых регистров выпала старшая единица выбирает соответствующий регистр атрибута, а мультиплексор через элемент "и" блокируется на выдачу цвета INK, пока из всех сдвиговых регистров не выпадут все нули. Вот, в принципе, и вся кибернетика.
57868
Или какая еще другая блок-схема нужна?
s_kosorev
15.08.2016, 17:24
В эмулятор нужно добавить для проверки мыслей, ну там диззи пофиксить
Есть одна бредовая мысль - а что если сделать видеокарту по следующему принципу:
1. Предварительно загружаем в некотором виде в девайс фрагменты спрайтов и цвета для них. Эта информация хранится внутри видеокарты
2. Перед отрисовкой кадра видеокарты анализирует изображение, ищет в нём обозначенные спрайты и раскрашивает их перед отображением.
3. Информация о спрайтах конкретной игры и их раскраске предварительно загружается отдельной программой, код игры не трогается вообще.
С одной стороны, наверное, это слишком наивный подход, с сомнительной жизнеспособностью, т.к. при реализации наверняка всплывёт куча подводных камней.
С другой стороны, не представляю, что могло бы помешать при таком подходе улучшить, например, изображение главного героя, как минимум. А, в идеале, гораздо больше.
Вообщем, тут всё будет упираться в производительность видеоконтроллера и алгоритмы распознавания образов.
inozemcew
15.08.2016, 20:09
А как вы будете заливать нужный слой цветом?
Элементарно
out <порт управления>,1
ld hl,$5800
ld de,$5801
ld bc,$2fff
ld (hl),6 ; INK = 6, BRIGHT=0, PAPER без разницы, он прозрачный, из под него просвечивают нижние слои.
ldir
out <порт управления>,0
Всё. Теперь все, что рисуется в плоскости 1 будет иметь желтый цвет. Если не залезет в область атрибутов. А в монохромных играх вывод спрайта как раз и не трогает область атрибутов.
при выводе цветного спрайта
А что такое "цветной спрайт?" Это тот же монохромный, но только после его вывода в соответствующую область атрибутов пишется соответствующие атрибуты. Но когда спрайт попадает в другую плоскость, его атрибуты пишутся тоже в эту плоскость и не затирают атрибуты фона. Заметьте "цветной спрайт" != "многоцветный спрайт". Многоцветные спрайты в спектрумовских играх - это совсем-совсем другая песня. Без перерисовки графики это совсем никак и даже близко не ставится целью данной разработки.
- - - Добавлено - - -
Есть одна бредовая мысль - а что если сделать видеокарту по следующему принципу:
Можете попробовать. Что получится можно примерно посмотреть здесь. (http://web-ext.u-aizu.ac.jp/~mozgovoy/zxrecolor/en/about.html)
ИМХО, повторить такое в железе будет не просто, да и перерисовать графику - тоже не два байта переслать.
blackmirror
15.08.2016, 20:12
inozemcew, если вместо дешифратора поставить микросхему памяти, в которую можно загрузить "палитру" управляющих сигналов OE и S, то можно будет без проблем выбрать paper или ink из любого слоя. Это позволит выбирать сколько слоёв используются для кодирования цвета или в каком слое маска загрузкой нужной "палитры". К примеру можно будет сделать два цвета(в пределах знакоместа) на фон, маску и два цвета на спрайт, для этого потребуется три слоя (в слое маски атрибуты не используются). Можно объединить два слоя и получить 4 цвета на фон, а объединив еще два получить три цвета для спрайта+прозрачный. Можно заранее заполнить для 4х слоёв paper и ink всеми 8 цветами, а "палитру" сделать таким образом, чтобы первые 3 слоя соответствовали красному, зелёному и синему, нарисовать там полноцветную картинку, а 4й слой использовать в режиме инверсии цвета или 1 цвет на знакоместо+прозрачность и прокручивать там какой-то текст не трогая никаких атрибутов.
Lethargeek
15.08.2016, 20:37
Это все мелочи. Есть вопросы потруднее.. Сколько плоскостей потребуется.
Вопрос лёгкий. Плоскостей не требуется нисколько. Аппаратные тайлы, спрайты, плоскости и слои - это всё дремучие архаизмы, к тому же "чуждые идеологии Спектрума". Нужен гибкий механизм трансляции восьми бит в восемь пикселей двух произвольных цветов (в том числе "прозрачного" цвета), быстро и удобно переключаемых. Что-то наподобие:
http://zx-pk.ru/threads/21462-bystraya-videokarta-quot-meteor-2013-quot.html?p=869225&viewfull=1#post869225
http://zx-pk.ru/threads/21462-bystraya-videokarta-quot-meteor-2013-quot.html?p=870718&viewfull=1#post870718
Есть одна бредовая мысль - а что если сделать видеокарту по следующему принципу:
1. Предварительно загружаем в некотором виде в девайс фрагменты спрайтов и цвета для них. Эта информация хранится внутри видеокарты
2. Перед отрисовкой кадра видеокарты анализирует изображение, ищет в нём обозначенные спрайты и раскрашивает их перед отображением.
3. Информация о спрайтах конкретной игры и их раскраске предварительно загружается отдельной программой, код игры не трогается вообще.
то тогда получится zxpoly в котором меняется только инфа о спрайтах, без изменения исполняемого кода вообще, только в качестве интеллектуального раскрашивателя юзается персона за компом что бы пометить какие цвета должны быть, но это одноразово
Что-то только счас дошло, у спрайтов paper-то нет совсем (потому что точки, где пиксель выключен - прозрачны). Поэтому одним OUT-ом перед началом вывода спрайта не обойтись никогда вообще. Сколько цветов на спрайте - столько и слоев нужно задействовать.
http://savepic.ru/11008263m.png (http://savepic.ru/11008263.htm)
Smalovsky
15.08.2016, 22:08
Что-то только счас дошло, у спрайтов paper-то нет совсем (потому что точки, где пиксель выключен - прозрачны). Поэтому одним OUT-ом перед началом вывода спрайта не обойтись никогда вообще. Сколько цветов на спрайте - столько и слоев нужно задействовать
Наконец-то дошло...))
Здаётся, мне это всё розыгрыш тэсэлыча - вкинуть заранее малопригодный видеорежим в мой топик( мотив мести за троллинг канала Z80).
Я посмеялся от души...)) Сколько спектрумистов клюнуло на вброс...
Но и огочился я прилично - за новый видеорежим безо всяких моральных обязательств некоторые готовы мать родную продать...
Ребята, даю вам два дня очистить топик............
даю вам два дня очистить топик............
проще тебя устранить
http://savepic.ru/10963219.jpg
Smalovsky
15.08.2016, 22:29
Гудбой, я в том смысле, что афёра расскрыта. Нет смысла больше вестись на малопригодный видеорежим. Понаписали столько постов зря, их лучше удалить.
Риобн, казалось бы опытный хардварщик, не смог раскусить, что изображения становятся дырявыми в одном слое...
Лучше согласитесь на моральные нормы и дождитесь настоящего видеорежима.
null_device
15.08.2016, 22:40
огочился я прилично - за новый видеорежим безо всяких моральных обязательств некоторые готовы мать родную продать
Странно было бы ожидать како-то иной реакции после такой "рекламы": "Шаг влево-шаг в право, расценивается, как попытка к бегству, прыжок на месте, как попытка улететью Наказание - расстрел!". При всем этом, никакой конкретики, но куча громких слов в стиле: "Невиданные возможности! Доработка, с помощью двух проводов и трех резисторов! Совместимость 164%!".
Впрочем, опять-таки: ждем у барака... :)
- - - Добавлено - - -
Сколько цветов на спрайте - столько и слоев нужно задействовать.
Которую страницу, пытаюсь донести эту мысль. Каждый дополнительный цвет на знакоместо, кроме "базовых" двух +1 слой.
Которую страницу, пытаюсь донести эту мысль. Каждый дополнительный цвет на знакоместо, кроме "базовых" двух +1 слой.
Но если не наворачивать цвет на точку, то двух слоев хватит каждому.
Другое дело, что это формат спрайта меняет очень существенно, особенно если движок не использует вывод масок.
null_device
15.08.2016, 23:22
Но если не наворачивать цвет на точку
Какой прок, от такого решения, если нельзя использовать все его возможности. "Плата" в виде потери программно-аппаратной совместимости, за возможность одновременного отображения трех-четырех цветов в одном знакоместе - это как-то несерьезно.
Тема, в целом скатывается в фаггорию достоинств внедрения нового "графона". На спектруме существует куча игр, где используется монохромная графика или наблюдается клэшинг. Если игра действительно интересна - техническая и визуальная реалиация, вторична.
Smalovsky, Извини, твоя тема называется "Новый принцип устранения клешинга". Мы обсуждаем поиски нового принципа устранения клешинга. Вроде всё сходится.
inozemcew
16.08.2016, 09:18
вместо дешифратора поставить микросхему памяти, в которую можно загрузить "палитру" управляющих сигналов
Можно. Можно даже просто взять 4-8 битовых планов и обычную палитру, и затем заполнив эту палитру специальным образом, получить псевдополупрозрачные слои. Именно так это делается на "Векторе". Плюс еще там 16-256 цветов на точку и т.д. и т.п. Однако, для устранения клэшинга это все лишнее. Пиксельная графика в Спеке принципиально монохромная, поэтому все эти "16 цветов на точку" без перерисовки графики просто не нужны. А перерисовывать графику, занятие таки не сильно простое. Поэтому я не хочу связываться со всякими палитрами и т.п., потому, что никто не будет
нарисовать там полноцветную картинку, а 4й слой использовать в режиме инверсии цвета или 1 цвет на знакоместо+прозрачность и прокручивать там какой-то текст не трогая никаких атрибутов.
как это показывает многолетний невеселый опыт.
гибкий механизм трансляции восьми бит в восемь пикселей двух произвольных цветов (в том числе "прозрачного" цвета), быстро и удобно переключаемых.
Смотрите, тема называется "устранение клэшинга" причем очевидно подразумевается, что клэшинг устраняется в "старых" играх. И желательно с минимальными усилиями. Давайте, для примера, возьмем какую-нибудь из старых игрушек от MikroGen. Там спрайт выводится на экран по XOR и таким же образом стирается. Что нам нужно изменить, при наличии спрайтовых слоев? Достаточно перед выводом спрайта сделать OUT <номер слоя>. Теперь штатная процедура вывода прочитает нолики из области пикселей, сделает XOR со спрайтом, и вернет это дело обратно в экран, а потом запишет область атрибутов новый INK. Мы увидим спрайт поверх фона своим цветом, без клэшинга с атрибутами фона, причем, как побочный эффект, инверсии на пересечении пикселей не будет. Следующий спрайт рисуется в своем слое точно также родной процедурой. Затем, стирание спрайта. Включаем нужный слой. Штатная процедура еще раз делает XOR, стирая спрайт. Записывает на место атрибутов спрайта атрибуты фона, что теперь уже не имеет значения.
Все изменения, которые нам потребуются для устранения клэшинга - это вывести в порт номер слоя перед процедурой рисования спрайта. Т.е. модифицировать придется всего несколько байт.
Теперь ваш способ с трансляцией. Как он будет работать, и что нужно будет изменить в играх от того же MikroGen?
Lethargeek
16.08.2016, 21:19
Смотрите, тема называется "устранение клэшинга" причем очевидно подразумевается, что клэшинг устраняется в "старых" играх. И желательно с минимальными усилиями. Давайте, для примера, возьмем какую-нибудь из старых игрушек от MikroGen. Там спрайт выводится на экран по XOR и таким же образом стирается.
"старых" это не обязательно настолько древних, где еще не научились спрайты маскировать))
Что нам нужно изменить, при наличии спрайтовых слоев? Достаточно перед выводом спрайта сделать OUT <номер слоя>. Теперь штатная процедура вывода прочитает нолики из области пикселей, сделает XOR со спрайтом, и вернет это дело обратно в экран, а потом запишет область атрибутов новый INK. Мы увидим спрайт поверх фона своим цветом, без клэшинга с атрибутами фона,
зато с клэшингом с атрибутами других спрайтов в том же слое
ну, или каждому выделять по слою, насколько хватит
тогда нужен лишний код для выбора слоя
Теперь ваш способ с трансляцией. Как он будет работать, и что нужно будет изменить в играх от того же MikroGen?
Вообще зависит от ситуации, а навскидку - добавить в процедуру лишнюю запись: прочитать экран, записать байт спрайта, поксорить, записать ксорку (при повторной записи в тот же адрес автоматически переключится набор из двух активных цветов, вторая "запись" - два прозрачных цвета, при стирании меняется очередность). В памяти Спектрума получится оригинальная ксорка, но увидим то, что получилось во внешней памяти.
Только спрайты ксоркой - дырявое убожество и без клэшинга. Смысла нет специально под такие игры оптимизировать, из них приличных, дай-то Клайв, если наберётся полсотни. А вот спрайты с маской для слоистой схемы уже удобны будут гораздо меньше - и по два слоя потребуется на спрайт, и количество цветов доступных уменьшится, и стирать штатно спрайты могли не только восстановлением, но и обновлением фона. Сами игры более продвинутые, отнимают больше ресурса - в целом пространства для манёвра гораздо меньше.
inozemcew, Вот тема (http://zx-pk.ru/threads/25711-vybor-i-rezervirovanie-adresov-dlya-novykh-ustrojstv.html?p=835227#post835227) по выбору портов.
Колебаться по выбору количества слоёв не конструктивно. Предлагаю взять восемь. Если будет мало - потом ещё добавить. Если много - убавить.
По поводу чтения процессором данных слоя (а не только записи в окно). Предлагаю, чтобы он читал-таки. А то как он несколько спрайтов на одном слое правильно отобразит?
Далее предлагаю сделать хоть того-же LodeRuner-а на эмуляторе, и увидеть наконец, как оно будет. :)
Hacker VBI
17.08.2016, 10:21
Reobne, это что, ещё и эмулятор переделывать??? :confused:
Hacker VBI, Да, это-же проще, чем сразу в железе. По моему. :)
- - - Добавлено - - -
Просто надо закончить первый вариант спецификации.
- - - Добавлено - - -
А пока это проект - призрак без ног.
Нужны номера портов, и точно что они делают.
Hacker VBI
17.08.2016, 10:44
Reobne, всё, гачи :)
inozemcew
17.08.2016, 16:27
Только спрайты ксоркой - дырявое убожество и без клэшинга. Смысла нет специально под такие игры оптимизировать, из них приличных, дай-то Клайв, если наберётся полсотни.
Ну, во-первых, про полсотни - это вы явно погорячились. Игр со спрайтами без маски знаачительно больше, чем вы насчитали, включая даже "икону" Спектрума Dizzy :). Во-вторых, безмасочный цветной спрайт без клэшинга смотрится таки лучше, чем с маской и клэшингом или монохромом. Можно, например, сравнить того же Dizzy в версиях для С64, где спрайт без маски, и Спека, где есть маска и клэшинг.
Но я согласен с вами, с маской таки надо что-то делать. Самый простой вариант, тупо не обращать внимания на маску, и модифицировать игру аналогично вышеописанному случаю с ксоркой. При этом маска не будет ничему мешать, но и маскировать пиксели нижележащего слоя тоже не будет. Оставим это на крайний вариант, когда нет возможности/лень модифицировать процедуру вывода спрайта.
Как же сделать работу со спрайтовыми масками максимально простой? Вспомним, как обычно делается вывод маскированного спрайта. Берется байт из экранной памяти, на него с помощью AND накладывается маска, затем с помощью OR накладывается спрайт и байт отправляется обратно в экран. Это самый типичный вариант работы с маскированными спрайтами, на него и будем ориентироваться.
Для каждого бита каждого спрайтового слоя добавим еще один бит маски. Теперь слои будут не однобитные, а двухбитные. Один бит, как и раньше, хранит пиксель спрайта, а второй используется для хранения маски. Биты маски непосредственно не доступны, а заносятся из регистра маски, для которого придется выделить отдельный порт.
Как все это будет работать? К сожалению, изменений в программы придется вносить больше. Перед выводом спрайта включаем в экранной области нужный слой. Затем переходим к процедуре вывода спрайта, читаем байт из экрана, выводим байт маски в порт, и продолжаем дальше по родному алгоритму - на считанный байт с помощью AND накладывается маска, затем с помощью OR накладывается спрайт и байт отправляется обратно в экран. При этом маска из порта маски переписывается в маску слоя, а сам регистр маски заполняется единицами.
Вот примерно так это должно работать. Для наглядности накидал небольшую схемку.
57889
Итого, изменения в программу понадобится внести такие изменения: перед выводом спрайта нужно выставить в порт номер слоя, в который он выводится, и в процессе вывода спрайта, байт маски дополнительно выбрасывать в порт маски. ИМХО, не так, чтобы сильно сложно.
прочитать экран, записать байт спрайта, поксорить, записать ксорку (при повторной записи в тот же адрес автоматически переключится набор из двух активных цветов, вторая "запись" - два прозрачных цвета, при стирании меняется очередность).
Долго разбирался, но не совсем понял, где вы собираетесь хранить и как устанавливать цвет спрайта? Что делать с атрибутами, которые изменяет процедура вывода спрайта?
- - - Updated - - -
Колебаться по выбору количества слоёв не конструктивно. Предлагаю взять восемь. Если будет мало - потом ещё добавить. Если много - убавить.
Согласен, 8 - оптимальное количество.
По поводу чтения процессором данных слоя (а не только записи в окно). Предлагаю, чтобы он читал-таки.
Конечно данные слоя доступны для чтения. С точки зрения процессора, слой - он как страница памяти в 128м спеке, только переключаются слои в адресах $4000-$5aff. То что слои как-то по особому читаются параллельно видеоконтроллером и как-то накладываются в зависимости от битов и приоритетов, процессор это не колышет. Он видит слой, как обычный спековский экран. То, что вдруг при переключении слоя из экранной памяти вдруг исчезло изображение фона, процессор волновать не должно. Пусть рисует спрайты на чистом экране, теми же процедурами, которыми он рисовал их раньше поверх фона. При аппаратном наложении слоев все будет отображаться правильно.
Lethargeek
17.08.2016, 22:06
Игр со спрайтами без маски знаачительно больше, чем вы насчитали,
я считал не все подряд, а приличные (их % намного меньше для ранних игр)
Долго разбирался, но не совсем понял, где вы собираетесь хранить и как устанавливать цвет спрайта?
ну где-где, в регистрах видеокарты, а устанавливать быстрой записью номера в отображаемые на память порты
Что делать с атрибутами, которые изменяет процедура вывода спрайта?
свой атрибут на каждый пиксель (необязательный)
ИМХО самый простейший способ решить проблему клэшинга был бы (тогда, в 80е) сделать аппаратное наложение двух экранов, у одного из которых один из цветов прозрачный.
Фон рисуется в одном экране, объекты в другом. Красивые динамические игры можно было бы на даже бейсике клепать.
Ессно сам клэшинг никуда бы не делся (в каждом из экранов) но вот четыре цвета на знакоместо это прикольно.
По затратам памяти лишь чуть больше честного четырехцветного (13.5 кб против 12кб). а смотрелось бы в разы лучше того же коммодора.
Lethargeek
18.08.2016, 09:25
Бука, нереально было сделать такое дёшево, память требовалась вдвое быстрее, или уже в середине 80-х ставить банки параллельно, но тоже достаточно быстрые (старый софт рассчитывал на нетормозящую память), и тоже не задаром. А тогда 8-битные компы уже шли к закату, заниматься ими было неперспективно. Вот добавить дополнительный режим атрибута "4 цвета при прямоугольных точках" в духе комода с самого начала было возможно.
"4 цвета при прямоугольных точках" в духе комода с самого начала было возможно.
В комоде был режим 40*25 знакомест с 2я цветами на 8*8 или 20*25 знакомест с 3+1общий на 4*8 знакоместо, плюс спрайты.
В амерском проапгрейженном Спеке Timex 2068 были штатно два экрана, 512*192моно и мультиколор хардварный (легко кстати потом на нашей рассыпухе делали, см Балтик например).
Аппаратный гигаскрин тоже легко делали. Тут идея в том, что для второго экрана один из цветов прозрачный - и все, спрайтуйпосамоенимагу.
Но конечно это уже совсем другой Спек, и другая ULA...
inozemcew
18.08.2016, 12:20
Ессно сам клэшинг никуда бы не делся (в каждом из экранов) но вот четыре цвета на знакоместо это прикольно.
Поддерживаю. И клэшинг доставал бы намного меньше.
57897
При этом игры могли выглядеть бы покрасивше.
5790957898
А вот если к этому добавить палитру, хотя бы на 64 цвета, то было бы еще красивее.
5791057907579025790357908
Ну, а если чуть-чуть пожертвовать горизонтальным разрешением, то можно иметь уже 6 цветов на знакоместо, которые можно, в разумных пределах, перераспределять на 2 плана.
5791157912579135791457915
Smalovsky
18.08.2016, 12:39
Тогда соглашайтесь на моральные и этические принципы...
inozemcew
18.08.2016, 13:29
ну где-где, в регистрах видеокарты, а устанавливать быстрой записью номера в отображаемые на память порты
Не, вы немного не так поняли вопрос. В игре цвет спрайта хранится в виде кода атрибута, который после вывода спрайта записывается в область атрибутов. Про регистры видеокарты старые игры не имеют ни малейшего понятия. Как цвет из(или вместо) области атрибутов должен попадать в видеокарту?
Собственно, мне интересно "устранение клэшинга" только с точки зрения адаптации старого софта. Если под новое железо пишется исключительно новый софт, то это совсем отдельная тема, с совершенно другими целями.
- - - Updated - - -
нереально было сделать такое дёшево, память требовалась вдвое быстрее, или уже в середине 80-х ставить банки параллельно,
ИМХО реально, надо было 1кб RAM от ZX81 не выбрасывать, а задействовать, как теневую память атрибутов. Получилось бы 2 бита на пиксель в двух планах, атрибут на знакоместо, и при желании сэкономить память, возможность использовать режим 1bpp простой манипуляцией атрибутами.
Да, памяти задействовано в разы больше, но большая часть ее просто простаивает, задействованный объем будет такой же, как в оригинале.
Во первых, при стандартной организации памяти, понадобится в разы бОльшая скорость чтения из памяти, что ру5 и подобные просто не осилят. Нужно их читать параллельно, как на векторе. С другой стороны, смотрел видео про комп, который отображал цвет интересным образом.
Итак, эти несколько плоскостей видеопамяти имеют один адрес, а записываются данные из порта. Т.е., устанавливаете в порт цвет с кодом $02, и пишете в видеопамять однобитную картинку, а при чтении со всех плоскостей там оказывается код цвета $02, который идёт на видеовыход. Это позволяет задавать цвет для каждых 8 горизонтальных точек, но избавиться от вертикального клешинга атрибута, и при показе не нужно читать ещё и байт атрибута. Единственный минус этого способа, просто так не считать обратно цветную картинку, чтобы запомнить фон под спрайтом, придётся вводить дополнительное чтение из порта.
s_kosorev
19.08.2016, 10:19
Т.е., устанавливаете в порт цвет с кодом $02, и пишете в видеопамять однобитную картинку, а при чтении со всех плоскостей там оказывается код цвета $02, который идёт на видеовыход.
EGA называется :)
Hacker VBI
19.08.2016, 11:09
inozemcew, красивые картинки. сам рисуешь?
Та не.. Объяснять таки надо. Народ начинает понимать идею, но до конструктивной критики (ради чего я сюда собственно и запостился) дело еще не дошло.
Думаю, самый большой недостаток системы - частичное устранение (спрайты 8х8 всё ещё одноцветные) не самого большого недостатка применением огромного количества памяти и повышенным требованием к быстродействию.
Кстати о спрайтах, я не заметил в обсуждении, ведь, тот же спрайт с человеком или катящейся бочкой будет прозрачен там, где не надо. Как быть с этим?
- - - Добавлено - - -
Можно даже просто взять 4-8 битовых планов и обычную палитру, и затем заполнив эту палитру специальным образом, получить псевдополупрозрачные слои. Именно так это делается на "Векторе". Плюс еще там 16-256 цветов на точку и т.д. и т.п.
Так вы и предлагаете по сути нечто похожее на векторовскую реализацию. Там тоже при разбивке на слои получается по 1 цвету на однобитный слой. Но там немного проще оперировать со слоями. Разве что, самый нижний слой будет уступать по количеству цветов вашей реализации.
- - - Добавлено - - -
Все изменения, которые нам потребуются для устранения клэшинга - это вывести в порт номер слоя перед процедурой рисования спрайта. Т.е. модифицировать придется всего несколько байт.
Не совсем модифицировать. Точнее, вставить. Для этого нужно подвинуть некий код, в нём придётся поковыряться на предмет перемещаемости. Думаю, это не так и просто будет адаптировать игру к такому выводу на экран. Правда, если спрайт выводится xor'ом, то можно будет команды чтения заменить на команду вывода в порт, тогда да, будет не так сложно. Или сначала запоминается фон, то тоже его можно заменить на запись в порт.
В общем, я хочу сказать, что если уж при модифицировании игры придётся двигать код, то можно его модифицировать и под другие методы вывода.
inozemcew
19.08.2016, 20:54
красивые картинки. сам рисуешь?
Ага, балуюсь помаленьку. Есть еще немного вариаций на тему "что было бы, если бы битпланов было бы 2" , только не знаю куда стоит выкладывать.
Это позволяет задавать цвет для каждых 8 горизонтальных точек, но избавиться от вертикального клешинга атрибута,
Если бы такой способ задания атрибута знакоместа был бы в спектруме изначально - никаких проблем. Но увы, весь софт написан под экран с атрибутами в $5800-$5aff, так что метаться поздно.
спрайт с человеком или катящейся бочкой будет прозрачен там, где не надо. Как быть с этим?
Уже говорилось - регистр маски. Причем только для игр в которых спрайты с масками. Остальные остаются, как есть. Впрочем, на с64 и MSX hi-res спрайты тоже без маски. Можно сравнить.
Для этого нужно подвинуть некий код,
Двигать ничего не нужно. Заменить вызов старой процедуры вызовом новой из которой потом сделать JP в старую - не требует перемещения никакого кода.
Двигать ничего не нужно. Заменить вызов старой процедуры вызовом новой из которой потом сделать JP в старую - не требует перемещения никакого кода.
Тогда можно цвет и через порт задавать, не делая несколько плоскостей, как выше написал. Разве что, можно сделать одну плоскость на фон и одну на все спрайты с прозрачным цветом. Будет задаваться цвет и прежней процедурой выводиться однобитная картинка, получая нужный цвет.
NEO SPECTRUMAN
19.08.2016, 22:49
Можно даже просто взять 4-8 битовых планов и обычную палитру, и затем заполнив эту палитру специальным образом, получить псевдополупрозрачные слои. Именно так это делается на "Векторе". Плюс еще там 16-256 цветов на точку и т.д. и т.п.
Так вы и предлагаете по сути нечто похожее на векторовскую реализацию. Там тоже при разбивке на слои получается по 1 цвету на однобитный слой. Но там немного проще оперировать со слоями. Разве что, самый нижний слой будет уступать по количеству цветов вашей реализации.
проблема векторной реализации в том что что спрайты нарисованные в одном плане однобитные без маски
чтоб нарисовать разноцветный спрайт с маской придется отрисовывать спрайт несколько раз в разных планах(переключать банки\пересчитывать\изменя ть адреса)
более интересный вариант был бы
4 плана по 2 бита на точку в каждом
но а дальше все как у вектора
в итоге было бы 4 плана со всеми преимуществами вектора
всякими масками\полупрозрачностям� �
и возможность быстро отрисовывать многоцветные спрайты
правда проблема что в конечном итоге
на один слой всего по 3 цвета палитры
и 4 цвета для фона
что как то маловато...
вторая проблема чтобы оставить совместимость с адресацией спековского экрана
придется уменьшить количество пикселей по горизонтали (широкие комодорские пиксели).
и нужно будет переписывать все процедуры отрисовки спрайтов тк теперь один байт экрана на 4 широких пикселя
inozemcew
20.08.2016, 13:09
Тогда можно цвет и через порт задавать, не делая несколько плоскостей, как выше написал.
Можно конечно, но..
Во первых, потребуется как минимум 4 бита дополнительно на каждый пиксель. Так что сильно сэкономить на памяти не получится.
А во-вторых, самое неудобное, после вывода изображения этим способом, понять какая точка имеет какой цвет невозможно. Допустим два спрайта накладываются по XOR. Теперь один спрайт надо стереть. Делаем еще раз вывод по XOR, но как понять, какого цвета должны быть восстановленные пиксели - цвета фона или цвета заданного по OUT? Тоже самое для процедуры вывода спрайта, которая запоминает пиксели под спрайтом в буфере - например рисование указателя мыши. Когда курсор рисуется в отдельном слое - никаких проблем, даже восстанавливать ничего не надо. Но как вы восстановите пиксели, цвет которых не знаете?
более интересный вариант был бы 4 плана по 2 бита на точку в каждом но а дальше все как у вектора
4 плана по 2 бита на точку в каждом но а дальше все как у спектрума - атрибут на знакоместо, но для каждого плана свой. У вектора цвет точки определяется комбинацией битов в 4 планах. Такое не нужно. Нужно определить, точка какого плана является видимой, вот из этого плана и взять атрибут - это и будет цвет точки.
возможность быстро отрисовывать многоцветные спрайты
На спектруме нет многоцветных спрайтов. Ждать, что их кто-то раскрасит, как показывает практика, можно до 2го пришествия.
придется уменьшить количество пикселей по горизонтали
Это тоже ненужно. Как раз запись маски можно сделать через порт, это сработает, в отличие от вывода цвета через порт.
Lethargeek
21.08.2016, 00:19
В амерском проапгрейженном Спеке Timex 2068 были штатно два экрана, 512*192моно и мультиколор хардварный (легко кстати потом на нашей рассыпухе делали, см Балтик например).
Аппаратный гигаскрин тоже легко делали.
так (относительно) легко-то потому что тайминги те же самые
Тут идея в том, что для второго экрана один из цветов прозрачный - и все, спрайтуйпосамоенимагу.
а тут надо вдвое больше тянуть из памяти, то есть либо дорогую быструю память, либо параллельные банки, что снижает надёжность (а Спек и так сперва не отличался большой надёжностью) и удорожает настройку (что в конечном итоге выливается в повышение цены и противопоказано массовому производству), да и самой памяти нужно больше (а Спек начинался с 16кб)
- - - Добавлено - - -
Не, вы немного не так поняли вопрос. В игре цвет спрайта хранится в виде кода атрибута, который после вывода спрайта записывается в область атрибутов. Про регистры видеокарты старые игры не имеют ни малейшего понятия. Как цвет из(или вместо) области атрибутов должен попадать в видеокарту?
всё я понял, написал же сразу:
записью номера в отображаемые на память порты
для игр, пишущих атрибуты перед пикселями, достаточно таким (одним) портом считать всю область атрибутов памяти Спека
для пишущих атрибуты после - либо изменить порядок вызова процедур, либо сначала явно цвет устанавливать, либо сочетать
плоскости для этого не нужны, и активные два цвета можно выбирать любой разрядности, как девайс по максимуму сумеет
NEO SPECTRUMAN
21.08.2016, 00:20
Вот примерно так это должно работать. Для наглядности накидал небольшую схемку.
Нажмите на изображение для увеличения. Название: sloi2.jpg Просмотров: 33 Размер: 21.4 Кб ID: 57889
Почитал повнимательней(бегло пробежался глазами).
Способ конечно интересный.
Хотя как задается цвет для спрайтов я не увидел (не дочитал)
но предположу что или для каждого слоя своя палитра из 2-х цветов
или что палитра задается как то перед отрисовкой спрайта
тогда для простоты адаптации нужно
дополнительный порт для конфигурации
- выбор типа маски 00111100 и инверсная 11000011.
- выбор обнулять регистр маски после записи или нет (не всегда же нужно и быстрее)
- как\чем "обнулять" регистр маски 00000000 или 11111111 или это должно определятся на основе выбора инверсная\не инверсная маска
дешифрация порта маски должна быть по младшим 8 битам
для быстрого засылания туда значений при помощи out ($**),a
так как занимать BC для дополнительного out-а сильно жирно
и все вроде бы хорошо
а теперь вопрос как теперь стирать и перемещать то что нарисовано где то там в слое который отображается поверх?
или нули маски будут и стирать содержимое слоя при повторной записи?
а еще нужно чтоб спрайты не мигали поверх фона
и тут вся эта конструкция начинает внезапно увеличиваться в размерах
уже нужен как минимум 2-й экранный буфер
и больший разбор и изменение кода
и в конечном итоге под этот новый видеорежим
придется переписывать весь вывод графики
хотя вот какая нибудь automainia переделается на ура
но оно того стоит??
и есче
что делать с играми которые сначала рисуют в бекбуфер?
а потом быстро перекидывают экран
сам буфер может быть и вверх ногами))
есть игры которые рисуют в бекбуфер
несколько слоев графики
а потом сверху игрока
а потом переносят на экран только несколько знакомест с изображением игрока
и все в буфере вверх ногами при этом)))
это сколько нужно будет найти и переписать...
и кто это будет делать?
это только на первый взгляд кажется что там подменить процедуру вывода и все
на практике вылезет столько подводных камней...
с таким же успехом все это проще переписать под тсконфу
но под неё что то особо никто ничего и не адаптирует
и сколько будет этих девайсов 10? 15?
3Ы: а тем временем spec256 конфа пилиться, вроде как, для ReVerSE-U16
а разукрашивать игры под неё...
inozemcew
21.08.2016, 17:23
Хотя как задается цвет для спрайтов я не увидел (не дочитал)
но предположу что или для каждого слоя своя палитра из 2-х цветов
или что палитра задается как то перед отрисовкой спрайта
Все проще. У каждого слоя своя область атрибутов. Цвет спрайта берется оттуда. Перед отрисовкой спрайта цвет задавать не обязательно, можно сделать это и после.
дополнительный порт для конфигурации
- выбор типа маски 00111100 и инверсная 11000011.
- выбор обнулять регистр маски после записи или нет (не всегда же нужно и быстрее)
- как\чем "обнулять" регистр маски 00000000 или 11111111 или это должно определятся на основе выбора инверсная\не инверсная маска
- всегда инверсная, которая накладывается по AND.
- обнулять обязательно, в смысле заносить 11111111. При чтении байта из пикселей слоя заносить маску в регистр маски. При записи в порт маски, складывать старое и новое значение по AND. Это позволит выводить несколько спрайтов в один слой.
- дополнительный порт для конфигурации не нужен.
а теперь вопрос как теперь стирать и перемещать то что нарисовано где то там в слое который отображается поверх?
Очевидно, запись байта в более нижний слой должна обнулять байты вышележащих слоев. Но, думаю, достаточно только очистки спрайтовых слоев при записи в слой фона.
что делать с играми которые сначала рисуют в бекбуфер?
Ничего. в бекбуфере нет информации о том какому объекту какой пиксель принадлежит. Как это обойти, я, к сожалению, не знаю.
это только на первый взгляд кажется что там подменить процедуру вывода и все
на практике вылезет столько подводных камней...
Безусловно. Без предварительной обкатки на эмуляторах не и речи о воплощении всего этого в железе.
для пишущих атрибуты после - либо изменить порядок вызова процедур, либо сначала явно цвет устанавливать, либо сочетать
Дополнительные изменения в код, понятно.
Lethargeek
21.08.2016, 21:24
Дополнительные изменения в код, понятно.
так без них в общем случае никак не получится, потому важно, чтоб эффект от изменений был наибольшим
и в зависимости от оригинального кода вплоть до 100% изменений можно вынести в отдельный загрузчик
NEO SPECTRUMAN
21.08.2016, 22:55
дополнительный порт для конфигурации
- выбор типа маски 00111100 и инверсная 11000011.
- выбор обнулять регистр маски после записи или нет (не всегда же нужно и быстрее)
- как\чем "обнулять" регистр маски 00000000 или 11111111 или это должно определятся на основе выбора инверсная\не инверсная маска
- всегда инверсная, которая накладывается по AND.
- обнулять обязательно, в смысле заносить 11111111. При чтении байта из пикселей слоя заносить маску в регистр маски. При записи в порт маски, складывать старое и новое значение по AND. Это позволит выводить несколько спрайтов в один слой.
- дополнительный порт для конфигурации не нужен.
нужен нужен
процедура рисования спрайта может
как брать байт из экрана 10101010
делать and 11000011 маска
и or 00011000 спрайт
так и с точностью на оборот
делать or 00111100 маска
и and 11100111 спрайт
понадобиться находить и менять сами спрайты и их маски
а это может вызвать дополнительные проблемы и артефакты (я как то ужо инверсировал графику в игре...)
а если вся графика запакованная?
для облегчения работы не помешал бы порт конфигурации
не обязательное обнуление позволит немного оптимизировать\ускорить отрисовку
зачем каждый раз засылать маску если процедура печати её, к примеру, по просту не меняет
например она вот такая
11110000
11110000
11110000
11110000
11110000
11110000
11110000
11110000
- - - Добавлено - - -
Очевидно, запись байта в более нижний слой должна обнулять байты вышележащих слоев. Но, думаю, достаточно только очистки спрайтовых слоев при записи в слой фона.
а почему при этом спрайты не будут мигать поверх фона?
а они будут мигать
Все проще. У каждого слоя своя область атрибутов. Цвет спрайта берется оттуда. Перед отрисовкой спрайта цвет задавать не обязательно, можно сделать это и после.
то есть на уровне каждого слоя будет свой клешинг?? :v2_dizzy_biggrin2:
не в принципе терпимо
inozemcew
22.08.2016, 16:53
потому важно, чтоб эффект от изменений был наибольшим
Позвольте не согласиться. ИМХО важнее всего минимум изменений в коде - максимально возможная адаптация под имеющийся софт.
так и с точностью на оборот
Честно говоря, такого не встречал. Но, в принципе, учесть такой вариант можно. Только никаких портов конфигурации. Достаточно, скажем, установить старший бит в номере слоя.
зачем каждый раз засылать маску если процедура печати её, к примеру, по просту не меняет
Вообще-то, никто не проверяет "а не изменилась ли маска?", лично я такого не видел. Проще взять и вывести, чем проверять.
а почему при этом спрайты не будут мигать поверх фона?
а они будут мигать
Не будут. В оригинале же не мигают. Значит авторы игрухи уже позаботились, чтобы отрисовка шла в нужный момент.
то есть на уровне каждого слоя будет свой клешинг??
В каждый слой выводить спрайты одного цвета. Отсюда больше 16 слоев нужно разве что чисто теоретически.
Lethargeek
22.08.2016, 20:39
Позвольте не согласиться. ИМХО важнее всего минимум изменений в коде - максимально возможная адаптация под имеющийся софт.
Ой, а с клэшингом зачем бороться тогда, раз единственный критерий - абсолютно минимальные изменения? С ним-то изменений вообще не нужно))) Или всё-таки эффект имеет значение, но тогда он должен быть наибольшим для любого уровня переделки. Кстати, чем это выбор слоя перед печатью спрайта "минимальнее" выбора активного цвета? Ведь фактически выбор слоя - тоже способ выбора цвета, только неинтуитивный и расточительный.
NEO SPECTRUMAN
22.08.2016, 20:57
Не будут. В оригинале же не мигают. Значит авторы игрухи уже позаботились, чтобы отрисовка шла в нужный момент.
в оригинале на экран выводиться уже совмещенные значения
тут же будут выводится сначала фон в слой фона
а это по вашему уже должно будет стирать более верхние слои спрайтов
а потом только будут рисоваться сами спрайты
а если луч пройдет по еще не отрисованому спрайту
а отрисовка фона уже идет(стирающая все в верхних слоях)
вот тебе и мигание
посмотри 99% игр для Львов ПК01
и как выглядеть это уныние
хотя если выводить строку фона туда строку спрайта туда
вероятность встретится с лучом будет низкой
но это сильное замедление
мало того что куча out-ов в порт маски
так еще и куча смен слоя туда сюда
Ой, а с клэшингом зачем бороться тогда, раз единственный критерий - абсолютно минимальные изменения? С ним-то изменений вообще не нужно)))
затем что новый софт для платформы появляется с частотой 0.01 в год и к нему интерес 0.01% от аудитории
NEO SPECTRUMAN
22.08.2016, 21:07
зачем бороться тогда
затем что
да какая разница
главное с чем то бороться :v2_dizzy_rastoman:
inozemcew
23.08.2016, 09:33
в оригинале на экран выводиться уже совмещенные значения
Совмещенные значения ЧЕГО с ЧЕМ?
а это по вашему уже должно будет стирать более верхние слои спрайтов
а потом только будут рисоваться сами спрайты
Хорошо. Давайте рассмотрим процесс поподробнее. Что нам нужно? - Нам нужно убрать спрайт на старом месте и нарисовать на новом.
Как обычно убирается спрайт в обычных спековских играх? Есть несколько распространенных методов.
Если спрайт выведен по XOR, то нужно еще раз сделать XOR - делаем это в слое спрайта, фон тут не затрагивается вообще.
Второй вариант - фон под спрайтом запоминается где-то в буфере, при стирании возвращается на место. Значит перед выводом спрайта переключаем слой. Старая процедура честно сохраняет нули из слоя спрайта в буфер, считая это фоном. А потом при стирании также возвращает эти нули на место. Сам фон опять не затрагивается.
Третий вариант - спрайт стирается перерисовкой куска фона из буфера фона и затем рисуется на новом месте. Тоже принципиально ничего не меняем. Старая процедура честно пытается восстановить кусочек фона, при этом стирая спрайты над ним, и потом рисует спрайты заново в новом месте.
То, что при наложении маски читается фон, на него накладывается маска и т.д. - теряет свое первоначальное значение. То, что старая процедура вывода принимает за фон, на самом деле нули из слоя спрайтов, вот в чем вся хитрость. Если маскированные спрайты не накладываются друг на друга в одном слое - маску достаточно выбросить в порт маски, не нужно ни читать старое значение, ни делать AND и т.п, так как старое значение === нули из слоя спрайтов. Это кстати освобождает место и такты для вывода маски в порт.
Как видите ничего принципиально не меняется. Если оно мерцало до, будет мерцать и после. А если не мигало, то зачем ему мигать?
Старая процедура честно пытается восстановить кусочек фона, при этом стирая спрайты над ним
Не совсем понятно. Перерисовываем фон, включен нулевой слой. И при этом стираются байты в слоях с 1 по 7 ???
Возможно придётся код перерисовки фона переписать в код обнуления в слое стираемых спрайтов.
inozemcew
23.08.2016, 10:37
Кстати, чем это выбор слоя перед печатью спрайта "минимальнее" выбора активного цвета? Ведь фактически выбор слоя - тоже способ выбора цвета, только неинтуитивный и расточительный.
Суть проблемы не просто в цвете, а в том, что надо неким образом различать объекты на экране, в данном случае спрайты. Это нужно хотя бы потому, что вывод пикселей и установка цвета для них с помощью атрибутов - отдельные и независимые операции. Плюс к этому, в спековских играх метод "вывел и забыл" работает далеко не всегда. Т.е. надо как-то помнить какие пиксели от чего. Разделение на слои и помогает с этим справиться.
- - - Updated - - -
Не совсем понятно. Перерисовываем фон, включен нулевой слой. И при этом стираются байты в слоях с 1 по 7 ???
Конечно. Именно так оно и работает в обычном спеке. Перерисовывается фон, при этом стираются спрайты. Его для этого и перерисовывают, чтобы стереть спрайты. Именно так и делают "старые" игры.
Теперь, когда спрайты находятся в своих слоях, фон перерисовывать не надо, но по логике работы программы, она хочет стереть все спрайты. Она так сделана, и собственно, сделать по другому в стандартном экране не получится. Мы стараемся максимально использовать логику "старой" игры. Поэтому, когда рисуется фон, надо стирать все спрайты над фоном в этом месте. Дальше, походу, должен быть вывод всех этих спрайтов, просто потому, что в оригинале перерисовка фона их тоже затирала.
Как опцию можно сделать для фона еще один номер слоя, например 128, где перерисовка будет без очистки спрайтовых слоев. Для переделки существующего софта это особого значения не имеет.
Перерисовывается фон, при этом стираются спрайты.
Так, ладно. А если мы красим 1-й слой, то стираются-ли слои 2-7?
- - - Добавлено - - -
Я удивлён, так как себе это не так представлял. Казалось, что каждый слой независим, и распределён хакером_адаптации в свою функциональную область, исходя из анализа конкретной игры.
Взять хоть того-же Рембо, бочки на полу. Чтобы их расклешить это уже 2 слоя на фон нужно.
Или Диззи, Деревья коричневые, листья на них зелёные, оба элемента являются фоном.
blackmirror
23.08.2016, 12:42
Чтобы полностью устранить проблему нужно выводить атрибуты перед спрайтом, спрайт выводить по маске, а на каждую точку добавить по одному байту для хранения её атрибутов. Такой вариант будет эквивалентен 256 слоям пронумерованным по комбинации атрибутов. Работать это будет следующим образом: записываем атрибут, записываем маску, записываем 8 точек, при этом аппаратно должен читаться атрибут и записываться к тем из 8 точек, запись в которые разрешения маской. Основной минус данного режима в том, что теряется совместимость с мультиколором, поэтому где-то нужно добавить бит для включения данного режима.
inozemcew
23.08.2016, 14:41
Так, ладно. А если мы красим 1-й слой, то стираются-ли слои 2-7?
Трудный вопрос. Групповая очистка нужна однозначно. Просто потому, что отрисовка фона подразумевает очистку спрайтов, и делать это отдельно для каждого слоя не имеет смысла - это в несколько раз больше работы для Z80.
Взять хоть того-же Рембо, бочки на полу. Чтобы их расклешить это уже 2 слоя на фон нужно
Там такая ситуация - фон под спрайтами копируются в буфер и потом спрайты стираются копированием из буфера обратно. Т.е. фон достаточно нарисовать один раз и больше не трогать, а потом только работать со спрайтовыми слоями. А вот с бочками я таки погорячился. Там они хранятся без маски, нарисованные стоящими на досках. Т.е. нет простого способа вывести их без клэшинга. Надо допиливать напильником графику.
В общем сложно сказать исходя чисто из теории, но наверное стоит делать очистку вышележащих слоев опциональной. Например с помощью старшего бита номера. Бит == 0, вышележащие слои очищаются при записи в текущий, если равен 1 - то не очищаются. Соответственно теоретическое максимальное количество слоев не больше 128. На данный момент, а там посмотрим. Ну и равноправие слоев тоже восстановлено. :)
- - - Updated - - -
Работать это будет следующим образом: записываем атрибут, записываем маску, записываем 8 точек,
Уточните, пожалуйста, куда что записывается? Атрибут куда - в порт, в область атрибутов, еще куда-то?
Как потом стереть такой спрайт?
Lethargeek
23.08.2016, 21:06
Суть проблемы не просто в цвете, а в том, что надо неким образом различать объекты на экране, в данном случае спрайты. Это нужно хотя бы потому, что вывод пикселей и установка цвета для них с помощью атрибутов - отдельные и независимые операции.
свой атрибут на каждый пиксель - и нет проблем
Плюс к этому, в спековских играх метод "вывел и забыл" работает далеко не всегда. Т.е. надо как-то помнить какие пиксели от чего. Разделение на слои и помогает с этим справиться.
Ну и как же разделение на слои нам поможет справиться, например, с положением, когда старый код захотел атрибутно перекрасить один из наложенных в одном слое (потому что были одного цвета) спрайтов? Вообще привязка спрайтов или цветов к слоям потому плохая идея (как и в принципе иерархичная организация по слоям), что в оригинальной "однослойной" графике с клэшингом порядок наложения объектов свободный, и со слоями мы рискуем получить другую картинку не только в смысле устранения клэшинга (да и то неполного устранения), но и в смысле (не)видимости объектов, что даже на играбельность и проходимость может влиять. Схема же с нормальным выбором рабочего цвета позволяет и накладывать объекты в любом порядке, и от клэшинга избавиться совершенно, и сложных схем очистки не городить.
NEO SPECTRUMAN
23.08.2016, 23:08
Поэтому, когда рисуется фон, надо стирать все спрайты над фоном в этом месте. Дальше, походу, должен быть вывод всех этих спрайтов, просто потому, что в оригинале перерисовка фона их тоже затирала.
реквестирую пример игры которая сначала рисует фон
а потом сверху рисует спрайты
в принципе это может быть или что то мерцающее
или что то фреймовое
или с привязкой к частоте кадров
примеры там где все движущийся спрайты рисуются поверх черного фона
и не когда не соприкасаются с местностью не предлагать
реквестирую пример игры которая сначала рисует фон
а потом сверху рисует спрайты
оно ?
http://www.worldofspectrum.org/pub/sinclair/screens/in-game/d/DestinyMission.gif
http://www.worldofspectrum.org/infoseekid.cgi?id=0001363
blackmirror
24.08.2016, 11:36
Уточните, пожалуйста, куда что записывается? Атрибут куда - в порт, в область атрибутов, еще куда-то?
Как потом стереть такой спрайт?
В процессе размышления над стиранием идея несколько мутировала:
Поскольку спрайтам нужно всего несколько цветов, но разным спрайтам разные, значит напрашивается вариант с палитрами. Делаем общую палитру на 256 цветов, а каждому спрайту задаём базовый цвет (порт color_base), к которому добавляеется смещение в 1,2,3 бита в зависимости от разрядности спрайта чтобы получить окончательный цвет из палитры. Нулевой цвет всегда считаем прозрачным. В видеопамяти изображение будет храниться в формате 8 слоёв дающих 8 бит на точку и скорее всего нам понадиботся 64 разрядная шина и регистр pixel_buf для обработки. Видеопамяти должно быть много, к примеру 16 страниц в каждую из которых влезает экран.
Кроме рисования со стороны процессора полезным будет режим наложения спрайта из одной страницы в другую. Для подержки этого режима добавляется порт с двумя переменными page_for_read и page_for_write, первая задаёт номер страницы из которой читается спрайт, вторая номер страницы в которой рисуется видимый или промежуточный экран. Когда процессор читает байт из экранной области, то соответствующие 8 точек из страницы спрайта попадают в pixel_buf. Когда процессор записывает байт в экранную область, то читаются 8 точек из страницы экрана, на них накладываются ненулевые точки из буферного регистра и это записывается обратно. Кроме этого в каждую точку pixel_buf записывается цвет color_base. (Еще возможен режим наложения целого блока 8x8 при чтении и записи атрибутов знакоместа, но для его поддержки скорее всего уже понадобится очередь команд.)
Если page_for_read и page_for_write совпадают, значит в буферный регистр запись будет идти со стороны процессора. Какие слои будут записаны определяется содержимым порта layer_mask. После записи layer_mask для фактического изменения точек понадобится столько операций записи в экранную область, сколько слоёв разрешено, а до этого данные записываются в слои pixel_buf. При записи последнего разрешённого слоя данные накладываются на страницу экрана, при этом layer_mask по and накладывается на цвет каждой точки и если получается 0, значит точка считается прозрачной. Кроме этоговсе точки pixel_buf снова заполняются значением color_base.
Иными словами перед рисованием спрайта нужно указать layer_mask чтобы знать какие слои записывать и color_base чтобы определить цвет для остальных слоёв. Кроме этого задав различающиеся page_for_read и page_for_write можно накладывать спрайты из одной страницы в другую сразу по 8 точек (или по 64 если есть очередь команд).
NEO SPECTRUMAN
24.08.2016, 22:56
оно ?
вотэта жесть
особенно при времянках пентагона...
Hacker VBI
25.08.2016, 11:19
А вообще - это всё поразительно.
Есть цвет на точку в АТМ
http://zxn.ru/screen9/theboard23.png
есть цвет на точку в Спринтере (http://www.youtube.com/watch?v=mcB8lHRxiWo)
есть цвет на точку в TS conf
http://www.youtube.com/watch?v=fQdL0VF52Og
Есть графическое расширение для Pentagon SL 2.2
http://zame-dev.org/pub/zx/16-col-sp.png
Чо не пользуетесь?
Почему не пишете под это всё?
Поболтать охота?
Hacker VBI, когда появится "новый принцип устранения клешинга", начнут изобретать ещё более новый, т.к. этот ВНЕЗАПНО станет неудобным, не каноничным, не по вере и т.д.
я так полагаю, что всё сводится к тому, что все хотят использовать привычный 256на192 с его атрибутами, но чтобы при этом "цвет на точку" было)))гг
когда появится "новый принцип устранения клешинга", начнут изобретать ещё более новый
секрет устранения клешинга в том что "все со смехом спрашивают когда же это кончится?!" (С) Салтыков-Щедрин
если заметил, то авторов не интересует решение проблемы, интересует продвижение себя и один вон даж до "патентования! договорился :)
ZX_NOVOSIB
25.08.2016, 12:46
А вообще - это всё поразительно.
Есть цвет на точку в АТМ
есть цвет на точку в Спринтере
есть цвет на точку в TS conf
Есть графическое расширение для Pentagon SL 2.2
Чо не пользуетесь?
Почему не пишете под это всё?
Поболтать охота?
Всё просто. АТМ, Спринтер и т.п. - это не классический спектрум, а какие-то монстры. Поэтому для них и не пишут.
Все хотят некую видеокарту, которую можно было бы вставить в классический международнопризнанный спектрум (фирмА, пентагон). Захотел - вставил в любой из фирменных спеков, захотел - переткнул какой-нибудь джампер на карте и вставил её в пентагон (или вообще в скорпион, в дельту и т.д.). Если бы такая видеокарта существовала, то под неё, возможно, писали бы куда больше софта чем под монстры. Стандарт, классика - это фирменный спек и пентагон, всё остальное - левак ))) Стоит ли удивляться, что под левак пишут гораздо меньше софта, чем под стандарт? Под стандарт - большая аудитория. Под левак - значительно меньше.
Hacker VBI
25.08.2016, 12:50
и карта станет леваком сразу же, и будут говорить что это не спектрум а какой то монстр, и писать под это западло (это ж не спектрум, помните?)
ибо аудитория значительно меньше, ну всё это
ZX_NOVOSIB, были такие девайсы, как ГС, нГС, ТурбоСаунд (включая ФМную версию). много софта под это всё сегодня делается на пентагонах и фирмах? нет. это монстры. не стандарты. зачем ТС или нГС (с какой-то адской мп3 хреновиной), если есть обычный АУ. вот на этом и заканчивается всё. есть девайс, но чё то ни кто не гоняет его. дадут вам карту, но не попрёт...
атм и спринтер даже рядом не монстры. там такие же z80 стоят, разогнаные.
ZX_NOVOSIB
25.08.2016, 13:21
Hacker VBI, карта не может стать леваком по определению :) Любая карта расширения, которую можно воткнуть в фирменный спек (или в пентагон) - православна по определению, и не может быть леваком, и находит своих поклонников. Всё что можно воткнуть в уже готовый фирменный спектрум - не левак. Леваком может быть лишь компьютер целиком, но не карта расширения. Все вышеперечисленные видеорежимы не получили поддержки и не пользовались спросом потому, что они были осуществлены на базе монстро-клонов, а не в виде отдельной универсальной карты. Монстро-клоны интересны немногим - маленькая аудитория. Широкой аудитории интересен классический спек, а уже вместе с классическим спеком ей автоматически интересны и любые штуковины, которые можно в спек воткнуть, воткнуть и побаловаться ;)
ZX_NOVOSIB, пример про звуковины я привёл. если говорить про графику, то режим 16ц достаточно провославен, т.к. втыкаться мог в любой клон. гдето-то в разделе про графику в железе болтается схема и даже была, помнится, карта под зхбас, воткнул и получил режим 16ц. в крайнем случае с очень несложными доработками в машине. если посмотреть на наших братьев по разуму в буржуазии, то они там ка ктолько свои +2/+3+мб02 не крамсают. там такие у них ёлки - палки торчат, пятногоны просто курят в коредоре. и ничё. потому ваша отговорка явно тут не работает.
ZX_NOVOSIB
25.08.2016, 13:35
были такие девайсы, как ГС, нГС, ТурбоСаунд (включая ФМную версию). много софта под это всё сегодня делается на пентагонах и фирмах? Эти девайсы не продавались в виде готового изделия, изделия, которое можно было бы просто купить, и просто воткнуть в задницу своего фирменного спектрума. Поэтому и не стало популярным, поэтому не считается :) Да и звук - это одно, а картинка - совсем другое. Для человека гораздо важнее зрительное восприятие, чем слуховое.
http://www.sellmyretro.com/category/retro-computers/sinclair/sinclair-zx-spectrum/hardware?page=1&listSort=nextEnding - вот здесь куча всяких штуковин для спека. Если бы среди этих штуковин была видеокарта, то люди бы её и покупали и софт под неё писали (желательно конечно несколько игр под карту адаптировать перед началом продаж, чтобы интерес был). А если к этой карте прикрутить и всякие там кемпстоны-div IDE и проч., то карта вообще бы хитом стала ))
Кстати там по ссылке кажется можно купить платы от MV1971? Или я ошибаюсь? Раньше я там даже его BDI в продаже видел, щас чо-то нету.
ZX_NOVOSIB, ГСы всегда продавались в собранном виде ещё в 90е годы (конец 90х), а позднее их можно было и самому собрать. А ещё позднее ЧРВ выпустил НГС, которые тоже можно было у него приобретать в готовом виде и в виде конструкторов. ровно как и ТС.
CodeMaster
25.08.2016, 13:47
Эти девайсы не продавались в виде готового изделия, изделия, которое можно было бы просто купить, и просто воткнуть в задницу своего фирменного спектрума
Не продавали в том числе и потому, что фирменных спектрумов в России было меньше чем этих девайсов.
я так полагаю, что всё сводится к тому, что все хотят использовать привычный 256на192 с его атрибутами, но чтобы при этом "цвет на точку" было)))гг
Очень похоже, что всё сведётся к поиску философского камня.
Очень похоже, что всё сведётся к поиску философского камня.
да давно его паренёк в очках захапал))) что его искать-то)))
inozemcew
25.08.2016, 16:51
свой атрибут на каждый пиксель - и нет проблем
Я правильно понимаю, вместо атрибута на 8х8 пикселей, вы предлагаете атрибут на, грубо говоря, 1х1 пиксель? А устанавливать текущий атрибут через порт атрибута, правильно? Тогда такой вопрос - как получить и где сохранять изображение под спрайтом?
в оригинальной "однослойной" графике с клэшингом порядок наложения объектов свободный,
Ну, не такой уж он свободный. В том же RamboIII - 12 спрайтов, которые накладываются строго по порядку, запоминая фон по собой, и потом в обратном порядке стираются, что обеспечивает правильное восстановление фона. А вот в Pssst спрайты рисуют и стирают, как попало. Если искусственно замедлить игру, то видно как беспорядочное наложение и стирание спрайтов образует кратковременные артефакты. Разнесение по слоям автоматически убрало бы эти артефакты.
Порядок вывода обычно задается один раз, и по ходу игры не меняется. Если же он намеренно таки меняется, то ничего не мешает поменять и порядок слоев. А если вывод спрайтов хаотичен, то наведение порядка пойдет только на пользу.
gurfunkel
25.08.2016, 18:34
Очень похоже, что всё сведётся к поиску философского камня.
http://savepic.su/7405930m.jpg (http://savepic.su/7405930.htm)
если рассмотреть режим аттрибутный когда смешиваются аттрибуты с сохранением два цвета в 8 на 8, но смешиваются аттрибуты из разных планов, то шахматный режим смешивания в zx-poly показал весьма любопытный результат в этом деле, сохранив цвета удалось удвоить разрешение
https://github.com/raydac/zxpoly/blob/master/docs/screenshots/zxw_zxpoly512x384.png?raw=true
NEO SPECTRUMAN
25.08.2016, 22:44
zx-poly
кстати Raydac просвети. лень искать\а ужо и не помню и не находил вроде
есть ли хоть один такой в железе?
один проц может работать в адресном пространстве другого?
или как то обмениваться информацией с другими процами?
есть ли хоть один такой в железе?
один проц может работать в адресном пространстве другого?
или как то обмениваться информацией с другими процами?
в железе нету, в конце 90-х думали делать, но смысл пропал, а у петерсов спринтер мог заэмулить что угодно, но не несколько z80
там есть регистры для смещения памяти для каждого проца в общей куче и после ресета они все каждый в своих 128 кб, но меняя базовое смещение можно или перекрыть частично адресные пространства или все вообще в одни 128 кб засунуть
там еще можно мапить адресное пространство другого проца как порты ввода вывода для главного проца (при этом флагами выставлялось что можно генерить маскируемое и немаскируемое прерывание), думал что можно будет так другие процы как эмули железа если что юзать
я думаю что в железе такое можно было заимпелемнтить но конечно блочек был бы приличный и только Зонову или Немо наверное в те времена под силу, но первый тогда сказал что время ушло, второй предал анафеме сказав что не спектрум! (прикидываю что он сказал бы про видеокарты все эти сегодня, предлагаемые)
NEO SPECTRUMAN
25.08.2016, 23:37
там еще можно мапить адресное пространство другого проца как порты ввода вывода для главного проца (при этом флагами выставлялось что можно генерить маскируемое и немаскируемое прерывание), думал что можно будет так другие процы как эмули железа если что юзать
а оно эмулируется?
а оно эмулируется?
конечно, иначе откуда я бы скриншоты брал, у меня в подписи ссылка на исходники эмуля
или если вопрос на тему "эмулируется ли железо", то я не писал эмулей несуществующего железа для zxpoly, только предполагаю, что это возможно, в основном юзал маппинг портов для рассовывания данных по памяти других процов
NEO SPECTRUMAN
26.08.2016, 00:07
иначе откуда
не в смысле я знаю только о его видео режимах
эмуль у меня тоже когда то где то был
а теперь с долбаного github-а и не скачаешь без бутылки ежедневного обновления браузера... :v2_dizzy_facepalm:
3Ы: надо бы
http://speccy.info/ZX-Poly
немного подзаполнить
а то там ничего нету толком
NEO SPECTRUMAN
26.08.2016, 00:15
у меня в подписи ссылка на исходники эмуля
была б полезней ссылка на бинаркник или хотя бы jar-ник эмуля
ато мя видимо забанели вгугле
ужо наверное год на мои запросы выдают одну еру***.
была б полезней ссылка на бинаркник или хотя бы jar-ник эмуля
там есть ссылки на пресобранное на гуглдрайве, но так как гуглдрайв сказал мне что "нам кажется что ты юзаешь гуглдрайв для какогото сайта, мы закроем эту возможность", то надо будет на гитхаб перетащить, в выходные посмотрю
на википедии была какая то инфа, но так как скриншоты из немоих прог, то копирасты вохбудились и затерли
Lethargeek
30.08.2016, 01:11
Я правильно понимаю, вместо атрибута на 8х8 пикселей, вы предлагаете атрибут на, грубо говоря, 1х1 пиксель? А устанавливать текущий атрибут через порт атрибута, правильно?
Не через "порт атрибута", а через область памяти, как на Спеке. И что значит "устанавливать"? Можно выбрать цвет для рисования спрайта, который (конкретизируем для 16-битных пикселей) может быть атрибутным индексом (старший бит 1, при отображении дополнительно читается цвет по индексу) или напрямую 15-битным кодом цвета (старший бит 0). После можно поменять цвета атрибутов, соответственно все уже нарисованные этим атрибутным цветом пиксели перекрасятся. Обобщение спектрумовского принципа, только без обязательной атрибутной сетки (не для всех индексов).
Тогда такой вопрос - как получить и где сохранять изображение под спрайтом?
А зачем его "получать", куда? Просто в памяти видеокарты переносить. Адреса на спектрумовской шине отслеживать, попадают ли в отображаемые пространства. И притом не только примитивно копировать, а еще, возможно, объединять из двух источников, считая байт на шине данных Спектрума маской - тогда при модернизации старых игр можно полноцветные объекты рисовать как бы старым восьмибитным процессором, еще меньше трогая старый код. Хотя лучше блиттером это делать.
Ну, не такой уж он свободный. В том же RamboIII - 12 спрайтов, которые накладываются строго по порядку, запоминая фон по собой, и потом в обратном порядке стираются, что обеспечивает правильное восстановление фона. А вот в Pssst спрайты рисуют и стирают, как попало. Если искусственно замедлить игру, то видно как беспорядочное наложение и стирание спрайтов образует кратковременные артефакты. Разнесение по слоям автоматически убрало бы эти артефакты.
Где-то строго, где-нибудь не строго. Лично я против таких непредсказуемых "улучшений"
Порядок вывода обычно задается один раз, и по ходу игры не меняется. Если же он намеренно таки меняется, то ничего не мешает поменять и порядок слоев.
Лишний код. А как же принцип "минимальности изменений"? А как узнать, сколько спрайтов в буфер нам накидает за несколько физических кадров? Раскапывать логику игры?
Даже Остап Бендер, которому нужно было всё сразу, был готов взять и по частям.
Пусть даже останется этот клешинг (см. рис. позиция 1), но уберётся этот (см. рис. позиция 2), это уже хорошо!
Не нужен нам принцип минимальности изменений, за чистоту которого мы будем лбы разбивать, главное это нетрудность изменений.
Неопределённости всякого рода ложатся на хакера_адаптпции. Вот когда он выберет конкретную игру, и будет сам решать, где XOR эффект, а где хаосксор; где пауза, а где подвисание; где клешинг, а где работа с цветами; где эффект мерцания, а где не успевание за лучём. Вот он сам решит, что он сможет устранить, а что нет. Сам решит, нужна ему информация о количестве спрайтов или нет, если нужна, то сам найдёт инструмент, как посчитать. По крайней мере это будет человек не сильно глупее нас с вами. :) Нет смысла заранее страдать.
Hacker VBI
30.08.2016, 11:55
"В том же RamboIII - 12 спрайтов, которые накладываются строго по порядку, запоминая фон по собой, и потом в обратном порядке стираются, что обеспечивает правильное восстановление фона. В том же RamboIII - 12 спрайтов, которые накладываются строго по порядку, запоминая фон по собой, и потом в обратном порядке стираются, что обеспечивает правильное восстановление фона. "
какой смысл стирать в правильном порядке, если фон под ними один и тот-же. накладывать спрайты - да, имеет смысл
по уму - сначала восстановление фона для всех спрайтов (причём возможно даже с учётом повторов), потом наложение всех спрайтов по маске.
а потом уже отображение
я извиняюсь, что у вас значит "хаос-ксор" ? :v2_dizzy_facepalm:
inozemcew
30.08.2016, 14:28
Не через "порт атрибута", а через область памяти, как на Спеке.
Для атрибутов 1х1 нужна область в 48кб. Куда это впихуется, чтобы было "как на Спеке.", те отображенным в адресное пространство Z80? Или каким образом будет задаваться цвет конкретных пикселей со стороны Z80?
И что значит "устанавливать"?
Текущий цвет устанавливается предварительно неким образом (например через порт), после чего все выводимые пиксели получают этот цвет.
Можно выбрать цвет для рисования спрайта,
Каким образом? Через спектрумовские атрибуты или еще как?
После можно поменять цвета атрибутов, соответственно все уже нарисованные этим атрибутным цветом пиксели перекрасятся.
Т.е. надо понимать, что речь у вас идет не об атрибутах в спектрумовском смысле (т.е. два цвета, которые выбираются в зависимости от значения бита пикселя), а об индексированном цвете и палитре? Иначе эта ваша фраза просто не имеет смысла.
А зачем его "получать", куда?
Как вы собираетесь восстанавливать изображение под спрайтом?
Лишний код. А как же принцип "минимальности изменений"?
Нет, код который меняет приоритет спрайтов, уже есть в игре. Приделать автоинкремент номера слоя при выводе спрайтов, ничуть не сложнее фиксированного вывода номера.
А как узнать, сколько спрайтов в буфер нам накидает за несколько физических кадров?
Зачем нам может понабиться такое, и в чем тут трудность?
- - - Updated - - -
какой смысл стирать в правильном порядке, если фон под ними один и тот-же. накладывать спрайты
Ну, об этом надо, наверное, спрашивать авторов оригинальных игры.
Мне видятся 2 причины. 1) Экономия памяти, не нужно хранить в буфере весь фон (лишних 4-6 кб таки не мало), достаточно буферов под размер спрайтов.
2) Спрайты с более медленной анимацией (предметы, анимированные детали фона) можно выводить на заднем плане реже, чем спрайты с быстрой анимацией (герой, пули и т.п)
я извиняюсь, что у вас значит "хаос-ксор" ?
Спрайты, которые выводятся на экран используя логическую операцию XOR. Можно выводить и стирать их в произвольном порядке, при этом фон полностью восстанавливается после убирания последнего спрайта.
я извиняюсь, что у вас значит "хаос-ксор" ?
Спрайты, которые выводятся на экран используя логическую операцию XOR. Можно выводить и стирать их в произвольном порядке, при этом фон полностью восстанавливается после убирания последнего спрайта.
Но чаще всего выглядит это хаотично, и такую дребедень также можно устранить. Но только если это дребедень, а не так и было задумано.
В идеале мог-бы быть инструмент, который позволил бы хакеру_адаптации, даже не знать ассемблера. Он должен включать в себя эмулятор. Запускаем в этом эмуляторе игру. Потом, когда на экране какой-то клешинг, ставим на паузу. Тыкаем на экране в пиксель, который должен-бы быть не таким, по нашему мнению. Программа_адаптптель предлагает несколько вариантов устранения. Выбираем подходящий, или вздыхаем что не получилось. Тестируем. Сохраняем. И готово - новая версия игры! :)
NEO SPECTRUMAN
30.08.2016, 18:57
но уберётся этот (см. рис. позиция 2)
а за рисование атрибутов фона поверх спрайта ГГ у меня всегда было желание расстреливать
(особенно доставляет когда это inc 0 paper 0)
мне намного больше нравится квадратный ореол вокруг
Lethargeek
01.09.2016, 21:30
Для атрибутов 1х1 нужна область в 48кб. Куда это впихуется, чтобы было "как на Спеке.", те отображенным в адресное пространство Z80?
"КАК на Спеке" - это не "в адресном пространстве Z80", а в адресном пространстве видеокарты
для совместимости со старым софтом только часть атрибутов для z80 нужно отображать
Текущий цвет устанавливается предварительно неким образом (например через порт), после чего все выводимые пиксели получают этот цвет.
ну и атрибутный точно так же, какая разница? одним битом от неатрибутного отличается
Т.е. надо понимать, что речь у вас идет не об атрибутах в спектрумовском смысле (т.е. два цвета, которые выбираются в зависимости от значения бита пикселя), а об индексированном цвете и палитре? Иначе эта ваша фраза просто не имеет смысла.
"атрибуты в спектрумовском смысле" - частный случай индексированного цвета
Нет, код который меняет приоритет спрайтов, уже есть в игре. Приделать автоинкремент номера слоя при выводе спрайтов, ничуть не сложнее фиксированного вывода номера.
это как? мы откуда знаем, сколько спрайтов может в кадре появиться в каждой игре? а что делать, если спрайтов вдруг оказывается больше, чем аппаратных слоёв? а что делать, если в кадре обновляются не все спрайты, или вовсе разные в разных кадрах?
Зачем нам может понабиться такое, и в чем тут трудность?
так вообще-то игры часто работают - рисуют в буфер долго, медленно и печально, а потом всё (относительно) быстро перебрасывают в экран
а в чём трудность - см. вопросы выше
Здесь тоже создают "чудовище" со слоями? устраняют клешинг в старых играх?
поясните, используется ли в играх, просто отключение ROM? И использование RAM0? 16К коту под хвост.
Игра игре рознь! Платформер на одном экране и аля "черный ворон" или "вера", где присутствует перерисовка всего игрового кадра со скролом "мира", грубо говоря нужно "залить фон" одним тайлом, или вырезать кусок, лучше и проще чем блиттер тут нет для 8 бит.
пока вы фантазировали я уже устранил клешинг
http://savepic.ru/11231593.png
NEO SPECTRUMAN
03.09.2016, 23:21
пока вы фантазировали я уже устранил клешинг
с клешингом было лучше :v2_dizzy_biggrin2:
inozemcew
04.09.2016, 01:19
для совместимости со старым софтом только часть атрибутов для z80 нужно отображать
Можете схематично изобразить, как будет 48к атрибутов 1х1 транслироваться частями в адресное пространство z80.
ну и атрибутный точно так же, какая разница?
Разница имеется. При установке цвета через порт, цвет устанавливается всегда ДО вывода пикселей. Если же мы имеем область атрибутов, как в спектруме, то мы можем задать цвет пикселей, как до, так и ПОСЛЕ их вывода на экран. И это "после" сильно усложняет ситуацию, т.к. очень трудно понять к каким именно пикселям должен относиться новый цвет, а какие нужно не трогать, чтобы избежать клэшинга.
"атрибуты в спектрумовском смысле" - частный случай индексированного цвета
Спековские атрибуты - очень специфичный случай. Хотя бы тем, что индекс принимает только 2 значения - INK и PAPER. У вас тоже самое, два значения?
это как? мы откуда знаем, сколько спрайтов может в кадре появиться в каждой игре?
Смотрим на экран, считаем, загибая пальцы :) Если честно, долго пытался вспомнить игру, где меняется порядок вывода спрайтов, помню, что была, но названия так и не вспомнил.
что делать, если спрайтов вдруг оказывается больше, чем аппаратных слоёв?
Раскладывать на сколько есть, по возможности группируя одноцветные спрайты.
а что делать, если в кадре обновляются не все спрайты, или вовсе разные в разных кадрах?
Ничего не делать, такое как раз идеально подходит для слоев.
игры часто работают - рисуют в буфер долго, медленно и печально, а потом всё (относительно) быстро перебрасывают в экран
А вот тут засада однозначная, причем для любого метода. Из-за однобитности буфера информация о принадлежности пикселей объектам теряется и фиг определишь, где правильно покрашено, а где клэшинг. Переделывать под прямой вывод в экран, возможно с использованием двойной буферизации.
Здесь тоже создают "чудовище" со слоями? устраняют клешинг в старых играх?
поясните, используется ли в играх, просто отключение ROM? И использование RAM0? 16К коту под хвост.
Игра игре рознь! Платформер на одном экране и аля "черный ворон" или "вера", где присутствует перерисовка всего игрового кадра со скролом "мира", грубо говоря нужно "залить фон" одним тайлом, или вырезать кусок, лучше и проще чем блиттер тут нет для 8 бит.
Из темы в тему переползает "таже самая концепция" которая сводится к "сделать из спектрума sprinter/tsconf". Но эта идея давно реализованна и имеет минимальный интерес наряду с другими "прибамбасами" типа GS, 16c и т.д. Так вот минусы таких доработок:
1. несовместимость с zx стандартами (только <1% софта их поддерживает);
2. абсурдная "гипертрофированность" железа (требуются частоты и\или интеграция в несколько раз больше чем у zx, что уже сравнимо с amiga, segamd, snes; для сравнения у zx-a 99% софта не требует частот более 14Mhz от того железа на котором оно работает);
А теперь про идею "чудовище" которую "создают":
1. требует минимального хака софта, сравнимого с хаками типа "изменение кнопок управления", "озвучка ay музыкой", "руссификация", "добавление cheat-ов", "взлом защиты от копирования" (т.е. того же самого что 99% софта уже успешно прошло);
2. использует то же поколение электронных компонентов что и zx (т.е. НЕ выглядит как "инородное тело");
2. абсурдная "гипертрофированность" железа (требуются частоты и\или интеграция в несколько раз больше чем у zx, что уже сравнимо с amiga, segamd, snes; для сравнения у zx-a 99% софта не требует частот более 14Mhz от того железа на котором оно работает);
Такая гипертрофированность вполне оправдана при одном условии, имхо, если в код игры не надо будет вмешиваться (или практически не надо), и где перерисовки, т.е. раскраски, потребует лишь графика. Словом, направление примерно как у ZX-Poly.
Lethargeek
04.09.2016, 19:13
Можете схематично изобразить, как будет 48к атрибутов 1х1 транслироваться частями в адресное пространство z80.
Ну так и будет - выбрать стартовый адрес памяти z80, выбрать размер окна, выбрать стартовый адрес внешней видеопамяти (все три параметра можно изменять неодновременно и независимо) - после этого видеокарта будет все обращения по адресам окна считать обращениями к себе. Что тут непонятного-то?
Разница имеется. При установке цвета через порт, цвет устанавливается всегда ДО вывода пикселей. Если же мы имеем область атрибутов, как в спектруме, то мы можем задать цвет пикселей, как до, так и ПОСЛЕ их вывода на экран. И это "после" сильно усложняет ситуацию, т.к. очень трудно понять к каким именно пикселям должен относиться новый цвет, а какие нужно не трогать, чтобы избежать клэшинга.
Нету разницы. До вывода выбираем "атрибут индекс такой-то" и рисуем сколько нам надо пикселей. После перезаписью одной ячейки внешней видеопамяти заменяем цвет у этого атрибута. Все пиксели с этим атрибутным индексом перекрасятся.
Спековские атрибуты - очень специфичный случай. Хотя бы тем, что индекс принимает только 2 значения - INK и PAPER. У вас тоже самое, два значения?
НЕТ. Мы сейчас о цвете ПИКСЕЛЕЙ говорим. ОДИН ПИКСЕЛЬ Спека принимает только ОДНО значение. Специфична у Спека лишь привязка атрибутов к координатам (что для совместимости, для части атрибутов, может обеспечить видеокарта).
Смотрим на экран, считаем, загибая пальцы Если честно, долго пытался вспомнить игру, где меняется порядок вывода спрайтов, помню, что была, но названия так и не вспомнил.
Изометрических таких должно быть немало. А вообще иногда не то что порядок спрайтов меняется, а количество и состав объектов генерируется случайно.
Раскладывать на сколько есть, по возможности группируя одноцветные спрайты.
Для чего потребуется копаться в логике игры, что гораздо неприятнее и сложнее, чем заниматься исключительно графическим кодом.
Ничего не делать, такое как раз идеально подходит для слоев.
см. выше
А вот тут засада однозначная, причем для любого метода. Из-за однобитности буфера информация о принадлежности пикселей объектам теряется и фиг определишь, где правильно покрашено, а где клэшинг. Переделывать под прямой вывод в экран, возможно с использованием двойной буферизации.
Не для любого. Буферу тоже можно выделить окно в памяти видеокарты, где храниться будут цветные пиксели, а при переброске буфера в экран Спектрума видеокарта перебросит свой цветной буфер в свой цветной экран. Группами по 8 пикселей синхронно с z80 по условию попадания адреса последнего чтения в окно буфера и адреса последней записи в окно экрана. Схему можно развивать дальше (говорил уже об объединении по байту-маске полноцветных пикселей из двух адресов-источников)
Для простоты адаптации и совместимости с 48К нужно что-то простое. Нет смысла придумывать новые видеорежимы итд.. итд.. никто под них писать не будет.
Самый простой способ сделать спрайт без клешинга - создать дополнительную теневую видео-область в которую легко читать/писать. А потом обычный экран рисовать вместе с теневым вот и результат :) Простота переделки игр - должна быть в смене адреса вывода спрайта ГГ и врагов. Например обычный экран с адреса #4000, а теневой с #0000. Грабли конечно будут при адаптации, но это самый простой способ.
inozemcew
05.09.2016, 18:26
Для простоты адаптации и совместимости с 48К нужно что-то простое. Нет смысла придумывать новые видеорежимы итд.. итд.. никто под них писать не будет.
Однозначно поддерживаю. Нафиг не нужны все эти монстры со встроенным искусственным интеллектом. 4 слоя без всяких масок и прочего выпендрежа - для начала с головой. А дальше уже видно будет.
Например обычный экран с адреса #4000, а теневой с #0000.
Теневой тоже с #4000. И не один, а пара-тройка. Переключать значением в порт. Для "теневых" экранов PAPER прозрачный. Это собственно и предлагалось.
Что тут непонятного-то?
Непонятно, насколько это будет похоже на спектрум.
ОДИН ПИКСЕЛЬ Спека принимает только ОДНО значение.
Нет. Он таки принимает ДВА значения - 1 и 0, INK и PAPER. По этому индексу и выбирается из байта атрибута (который является такой себе мини-палитрой на два цвета) конкретное значение цвета.
До вывода выбираем "атрибут индекс такой-то" и рисуем сколько нам надо пикселей.
Т.е. как бы вместо отдельных слоев, для каждого пикселя храним номер слоя, в который он попал бы, если бы были слои. Правильно я вашу мысль понимаю?
Изометрических таких должно быть немало.
Вот с изометрическими движками, как-то знакомство не сложилось. Очень приветствуются ссылки на внутреннее устройство таких движков.
Lethargeek
05.09.2016, 20:23
Простота переделки игр - должна быть в смене адреса вывода спрайта ГГ и врагов. Например обычный экран с адреса #4000, а теневой с #0000. Грабли конечно будут при адаптации, но это самый простой способ.
ну ё-моё... :v2_dizzy_facepalm: самое простое - это перезадавать только цвет! а ты зачем-то хочешь еще и адрес...
Нафиг не нужны все эти монстры со встроенным искусственным интеллектом. 4 слоя без всяких масок и прочего выпендрежа - для начала с головой.
если головой подумать, то это монстр (притом "монстр" не в смысле мощи и устрашения, а в смысле генетической неполноценности и уродства))
Нет. Он таки принимает ДВА значения - 1 и 0, INK и PAPER. По этому индексу и выбирается из байта атрибута (который является такой себе мини-палитрой на два цвета) конкретное значение цвета.
Ладно, может принимать ОДНО из двух возможных значений (ink и paper это просто условность). А два значения - это частный случай 2^n значений для n=1.
Т.е. как бы вместо отдельных слоев, для каждого пикселя храним номер слоя, в который он попал бы, если бы были слои. Правильно я вашу мысль понимаю?
Нет, неправильно. Наложение объектов (точно так же, как и на Спектруме) определяться будет порядком их отрисовки, а не тем номером.
Вот с изометрическими движками, как-то знакомство не сложилось. Очень приветствуются ссылки на внутреннее устройство таких движков.
А зачем? И так ведь понятно, что там накладывать объекты нужно по удалённости. А удалённость изменяется при движении.
inozemcew
08.09.2016, 18:53
то это монстр
Ну, со стороны реализации в железе - не два проводка перерезать, конечно, но и другие варианты ничуть не проще. А со стороны программирования все просто и логично. Нет каких-то предварительных шаманств с режимами и регистрами, которые нужно сначала запрограммировать, нет сложного внутреннего состояния которое нужно учитывать. Все вполне в идеологии спектрума, ИМХО.
может принимать ОДНО из двух возможных значений
если головой подумать то любой индекс всегда принимает ОДНО из нескольких возможных значений.
Наложение объектов (точно так же, как и на Спектруме) определяться будет порядком их отрисовки, а не тем номером.
Да, точно. В этом различие.
Тогда позвольте уточнить, а как вы собираетесь сопоставлять индекс с оконечательным цветом пикселя? Я так понял, для каждого индекса будет один глобальный цвет (т.е. для всего экрана сразу). Или же для каждого индекса будет отдельная область атрибутов, которая будет переключаться по установке индекса в порту?
И так ведь понятно, что там накладывать объекты нужно по удалённости.
Если перерисовывать всё - никаких проблем нет. Рисуем самые дальние объекты в самый нижний слой, если попадается объект другого цвета, например спрайт игрока, просто переключаемся в слой выше и рисуем дальше тем же алгоритмом.
Хуже, если в игре была частичная перерисовка. Тут надо уже смотреть конкретный игровой движок.
Lethargeek
11.09.2016, 02:57
Ну, со стороны реализации в железе - не два проводка перерезать, конечно, но и другие варианты ничуть не проще.
Я к тому, что монструозность - это также соотношение сложности железа к его возможностям.
Например, N цветов вместо 2^N при том же размере памяти уже как-то не особенно вдохновляет.
А со стороны программирования все просто и логично. Нет каких-то предварительных шаманств с режимами и регистрами, которые нужно сначала запрограммировать, нет сложного внутреннего состояния которое нужно учитывать.
Просто и логично выбирать в простейшем случае только цвет, а не шаманить с распределением цветов и спрайтов в слои.
Все вполне в идеологии спектрума, ИМХО.
Многослойность не в идеологии Спектрума.
если головой подумать то любой индекс всегда принимает ОДНО из нескольких возможных значений.
Если головой подумать, то зависит от того, что считать "значениями" (взять хотя бы спековский атрибут...)
Тогда позвольте уточнить, а как вы собираетесь сопоставлять индекс с оконечательным цветом пикселя? Я так понял, для каждого индекса будет один глобальный цвет (т.е. для всего экрана сразу). Или же для каждого индекса будет отдельная область атрибутов, которая будет переключаться по установке индекса в порту?
Индекс это просто число. Как прошивку карты запрограммируем, так она и будет сопоставлять. Глобальный цвет - самое простое решение, притом совместимое со старым zx-экраном при определённом режиме записи (то есть, два каких-то атрибутных кода писать как индексы, вычисляемые исходя из адреса пикселя; и даже если эти все особые индексы не использовать нигде, кроме их "законных" знакомест, всё равно еще незанятых ~30 тысяч)
Если перерисовывать всё - никаких проблем нет. Рисуем самые дальние объекты в самый нижний слой, если попадается объект другого цвета, например спрайт игрока, просто переключаемся в слой выше и рисуем дальше тем же алгоритмом.
И как узнать, не копаясь в логике работы движка, когда начинается отрисовка этих "самых дальних" объектов? А если каждый раз другого цвета новый объект? Причем их кол-во заранее неизвестно. Что-то может подобрать персонаж, потом выкинуть; после взрыва что-то разлетается на куски, которые потом мигают пару секунд...
Хуже, если в игре была частичная перерисовка. Тут надо уже смотреть конкретный игровой движок.
Со слоями часто надо "смотреть", а ведь хотелось только "устранить клэшинг" или монохром немного подкрасить :rolleyes:
inozemcew
13.09.2016, 15:20
Например, N цветов вместо 2^N при том же размере памяти уже как-то не особенно вдохновляет.
Если задача стоит отобразить N цветов, то 2^N, при том же размере, конечно лучше. Но задача у нас другая - устранить клэшинг не трогая графику и с минимальным вмешательством в код. Тут количество цветов - параметр второстепенный. Более того, задействованная память не пропадает понапрасну, как вам кажется, а используется для хранения изображения под спрайтами. Вы, кстати, тоже собираетесь хранить изображение под спрайтами в памяти видеокарты? Это разве не будет напрасным расходованием видеопамяти?
Многослойность не в идеологии Спектрума.
Как раз 3/4 игр для спека и построены на идеологии многослойности. Просто аппаратные ограничения не позволяют раскрасить слои изображения без клэшинга.
Как прошивку карты запрограммируем, так она и будет сопоставлять.
Программировать будем когда - на этапе изготовления, или уже по ходу игры?
И как узнать, не копаясь в логике работы движка, когда начинается отрисовка этих "самых дальних" объектов?
Очевидно, в начале цикла отрисовки. По другому на стандартном экране сделать невозможно.
Со слоями часто надо "смотреть", а ведь хотелось только "устранить клэшинг" или монохром немного подкрасить
Нет, как раз "смотреть" надо редко, стандартных игр типа "фон-спрайты" на порядок больше, чем хитровывернутых.
Очевидно, в начале цикла отрисовки. По другому на стандартном экране сделать невозможно.
Немного прицеплюсь к слову "невозможно".
Теоретически возможно, формируя инфу типа Z-буфера.
И как узнать, не копаясь в логике работы движка, когда начинается отрисовка этих "самых дальних" объектов?
Просто отлаживать надо. Запускаешь игру и пошагово смотришь что за чем рисуется. Выявляешь процедуры вывода спрайтов. Это совершенно рутинная деятельность, когда уже умеешь отлаживать. Гораздо проще чем разбираться в логике, и тем более делать ремейк. Хакинг он на то и хакинг.
Lethargeek
13.09.2016, 20:32
Если задача стоит отобразить N цветов, то 2^N, при том же размере, конечно лучше. Но задача у нас другая - устранить клэшинг не трогая графику и с минимальным вмешательством в код. Тут количество цветов - параметр второстепенный.
Не такой уж и второстепенный при достаточно большом числе перекрывающихся объектов. И дело ведь не только в цветах, плоскостная память "бит на пиксель" невыгодна по многим причинам. Например, неудобна для реализации схемы рисования объектов старым кодом с выбором сдвига (что легко позволяло бы ускорить часть старых игр).
Более того, задействованная память не пропадает понапрасну, как вам кажется, а используется для хранения изображения под спрайтами. Вы, кстати, тоже собираетесь хранить изображение под спрайтами в памяти видеокарты? Это разве не будет напрасным расходованием видеопамяти?
Тут как раз напрасного расходования нет, потому как "изображение под спрайтами" (даже в играх с наксоренными спрайтами) изначально на экран всё равно попало откуда-то из памяти Спектрума (или будет попадать из памяти видеокарты - для новых игр), там оно и продолжает себе храниться (и для новых или сильно переделанных игр получается намного лучшего качества). Исключения на Спеке - элементы интерфейса как в Antiriad, но им хватит только одного слоя.
Как раз 3/4 игр для спека и построены на идеологии многослойности. Просто аппаратные ограничения не позволяют раскрасить слои изображения без клэшинга.
100% игр для Спека рисуют графику в однослойный буфер или в экран. И даже на логическом уровне у большинства двухмерных фон обычно (полу)пустой, и на переднем плане мало объектов, а изометрические игры - не для слоёв.
Программировать будем когда - на этапе изготовления, или уже по ходу игры?
Как обычно - на этапе обновления или сброса, а по ходу только выбирать готовые варианты (полагаю, хватит и одного)
Очевидно, в начале цикла отрисовки. По другому на стандартном экране сделать невозможно.
А как узнать, когда начало этого цикла))) Может, всё же лучше не заморачиваться и выбрать схему, не заставляющую лишнего "узнавать"? Вот в однослойной схеме надо только выбрать/вычислить новый цвет рисуемого объекта, очевидно в самых типичных случаях это можно сделать просто по его адресу. И дальше процедур непосредственно обновления экрана - не нужно лезть.
Нет, как раз "смотреть" надо редко, стандартных игр типа "фон-спрайты" на порядок больше, чем хитровывернутых.
Это неоправданный оптимизм. Просто может выглядеть только внешне.
И "смотреть" вообще никогда не надо, если можно этого избежать.
- - - Добавлено - - -
Просто отлаживать надо.
Просто не надо лишних ненужных "надо" :p
Запускаешь игру и пошагово смотришь что за чем рисуется. Выявляешь процедуры вывода спрайтов. Это совершенно рутинная деятельность, когда уже умеешь отлаживать. Гораздо проще чем разбираться в логике, и тем более делать ремейк. Хакинг он на то и хакинг.
С графикой, конечно, проще всего. Но дело в том, что многослойность как раз потребует совершенно лишних разборов логики.
inozemcew
14.09.2016, 14:50
Не такой уж и второстепенный при достаточно большом числе перекрывающихся объектов.
Двадцать лет назад, может быть. Сейчас - точно второстепенный.
Например, неудобна для реализации схемы рисования объектов старым кодом с выбором сдвига (что легко позволяло бы ускорить часть старых игр).
Увы, видео в спеке имеет схему "бит-на-пиксель". Без перерисовки графики это не изменить.
изначально на экран всё равно попало откуда-то из памяти Спектрума (или будет попадать из памяти видеокарты - для новых игр), там оно и продолжает себе храниться
Тут есть один момент - сколько времени нужно на построение всего этого статического фона? В большинстве игр, игровой экран строится один раз, и никто его не перерисовывает каждый кадр. Ибо хранится это все тайл-мапами, и разворачивается не так чтобы шустро. Сколько времени занимает в Диззи переход из одного экрана в другой? - Таки прилично.
Поэтому вашу схему "рисовать каждый кадр с нуля" на самом деле всегда стараются использовать как можно меньше. В играх со статическим фоном - практически никогда. А таких игр - добрая половина.
100% игр для Спека рисуют графику в однослойный буфер или в экран.
Но делают они это послойно. Рисуется фон, поверх него спрайты, один за другим - слой за слоем. От того, что стандартный экран позволяет только слеплять слои до кучи, сам принцип послойного вывода от этого никуда не девается.
Вот в однослойной схеме надо только выбрать/вычислить новый цвет рисуемого объекта, очевидно в самых типичных случаях это можно сделать просто по его адресу. И дальше процедур непосредственно обновления экрана - не нужно лезть.
Кстати, можете сказать, как вы собираетесь в этой схеме реализовать такую элементарную вещь, как курсор мыши?
а изометрические игры - не для слоёв.
Вам почему-то кажется, что экранные объекты должны быть жестко привязаны каждый к своему слою. На самом деле, динамическое перераспределение слоев в процессе построения кадра - это совершенно несложно.
Вот в однослойной схеме надо только выбрать/вычислить новый цвет рисуемого объекта, очевидно в самых типичных случаях это можно сделать просто по его адресу. И дальше процедур непосредственно обновления экрана - не нужно лезть.
Еще раз спрашиваю - как стереть потом такой объект? Причем под словом "стереть" подразумевается не очистить до черного цвета, а восстановить то, что было нарисовано на месте объекта до его вывода. А там, под ним могли быть другие объекты, которые могли накладываться друг на дружку самым произвольным образом. Те старые процедуры, что есть в играх теперь не годятся совершенно. Они ничего не знают о цвете объектов. Как вы собираетесь это восстанавливать, ну, кроме полной перерисовки с нуля, что не подходит по соображениям производительности.
- - - Updated - - -
Теоретически возможно, формируя инфу типа Z-буфера.
На практике нечто похожее делается в Exolon. Там, проверяется атрибут знакоместа, и если он имеет определенное значение, то спрайты в это знакоместо не выводятся, считается что там изображение переднего фона. На клэшинг не влияет ибо привязано к знакоместам. Делать подобное на уровне отдельных пикселей, имхо, нереально.
Lethargeek
14.09.2016, 21:29
Двадцать лет назад, может быть. Сейчас - точно второстепенный.
Ну, лично мне было бы совсем не второстепенно, если не хватило цветов на спрайты, потому что кто-то очень умный решил до этого, что четыре одноцветных дырявых слоя мне "с головой" :rolleyes:
Увы, видео в спеке имеет схему "бит-на-пиксель". Без перерисовки графики это не изменить.
Зато можно изменить скорость вывода горизонтально сдвинутых объектов для части игр.
Тут есть один момент - сколько времени нужно на построение всего этого статического фона? В большинстве игр, игровой экран строится один раз, и никто его не перерисовывает каждый кадр. Ибо хранится это все тайл-мапами, и разворачивается не так чтобы шустро. Сколько времени занимает в Диззи переход из одного экрана в другой? - Таки прилично.
Поэтому вашу схему "рисовать каждый кадр с нуля" на самом деле всегда стараются использовать как можно меньше. В играх со статическим фоном - практически никогда. А таких игр - добрая половина.
Вот не надо мне приписывать ерунды. Где в словах "изображение под спрайтами изначально на экран всё равно попало откуда-то из памяти Спектрума" зашифрована "схема рисовать каждый кадр с нуля"?? (кстати, не такая уж редкая!) Фон под спрайтами можно восстанавливать (пусть даже полной) отрисовкой только тех объектов (или тайлов), на которые он попал. Можно - переброской снятого заранее куска фона. Во всех случаях (вот сюрприз-то!) эти пиксели всё равно находятся где-то в памяти.
Но делают они это послойно. Рисуется фон, поверх него спрайты, один за другим - слой за слоем. От того, что стандартный экран позволяет только слеплять слои до кучи, сам принцип послойного вывода от этого никуда не девается.
Еще раз. Это не послойный вывод, а ПООБЪЕКТНЫЙ (в общем случае - с неизвестным заранее числом и цветом этих объектов)
Кстати, можете сказать, как вы собираетесь в этой схеме реализовать такую элементарную вещь, как курсор мыши?
Да как угодно. Я ж могу переносить и перекрашивать попиксельно любые восьмипиксельные полоски (так же, как на Спеке, и даже проще).
Вам почему-то кажется, что экранные объекты должны быть жестко привязаны каждый к своему слою.
Мне почему-то кажется, что не надо делать лишней дурной работы :rolleyes:
На самом деле, динамическое перераспределение слоев в процессе построения кадра - это совершенно несложно.
Это обещать несложно, а сделать сложно (уж сложнее мелкой правки графпроцедур). Не говоря уже о том, что не нужно.
Еще раз спрашиваю - как стереть потом такой объект? Причем под словом "стереть" подразумевается не очистить до черного цвета, а восстановить то, что было нарисовано на месте объекта до его вывода. А там, под ним могли быть другие объекты, которые могли накладываться друг на дружку самым произвольным образом. Те старые процедуры, что есть в играх теперь не годятся совершенно. Они ничего не знают о цвете объектов.
А зачем им что-то знать о "цвете объектов" (и самих объектах)? Они тупо затирают кусок экрана сохранённым в буфере куском фона. Даже если фон многоцветный, а не двухцветный, в памяти видеокарты можно хоть на каждый бит из памяти Спектрума выделить по полноцветному пикселю (если для совсем уж ленивых).
inozemcew
15.09.2016, 14:01
о четыре одноцветных дырявых слоя мне "с головой"
Давайте возьмем 250 слоев с масками, это меньше чем 3 мегабайта памяти.. Я не вижу тут никакой принципиально-неразрешимой трагедии.
эти пиксели всё равно находятся где-то в памяти.
Как раз весь фокус, что нигде в памяти спектрума нет этих пикселей, в том виде, как они отображаются на экране. Они существуют только в памяти видеокарты. И получаются там последовательным наложением графических объектов. Поэтому
переброской снятого заранее куска фона
восстановить ничего так просто не получится, потому что родные процедуры восстановления понятия не имеют, что фон уже не просто монохромные однобитные пиксели, а сложная многоцветная картинка с "атрибутом на пиксель". Вам нужно как-то прочесть эти самые "атрибуты" и где-то их сохранить, прежде чем рисовать новый спрайт поверх них.
Они тупо затирают кусок экрана сохранённым в буфере куском фона
И получаем монохромное изображение под затертым спрайтом. Или вы собираетесь угадывать, откуда процедура взяла байт для сохранения в буфере, а потом для чего прочитала байт из буфера и соответствующим образом перетаскивать параллельно пиксельные атрибуты в памяти видеокарты(а-ля Спек256)?
Я ж могу переносить и перекрашивать попиксельно любые восьмипиксельные полоски (так же, как на Спеке, и даже проще).
Это замечательно. Но нам надо перекрасить их "так как там было" до того, как там нарисовали курсор мыши. На Спеке для этого делают буфер на 16 байт (для курсора 8х16) и сохраняют "как было" в нём. Теперь по-вашему методу, 16 байт как в Спеке уже не хватит - каждый пиксель кроме состояния 0/1 несет еще и информацию о цвете. Как ее получать из видеокарты, где хранить и как потом записать обратно?
Это обещать несложно, а сделать сложно (уж сложнее мелкой правки графпроцедур)
Да что там сложного-то? Можно даже аппаратно сделать, чтобы последний записанный слой автоматически становился самым верхним. Это будет полностью имитировать последовательное наложение объектов. Хотя, на самом деле такое и не нужно. Достаточно одного байта для хранения номера текущего слоя. В начале цикла обнуляем его, а в процессе отрисовки объектов инкрементируем. Всё. Объекты будут укладываться в слои точно в порядке отрисовки, как вы и хотели.
Lethargeek
16.09.2016, 09:27
Давайте возьмем 250 слоев с масками, это меньше чем 3 мегабайта памяти..
:v2_dizzy_facepalm: а давайте вспомним, что пиксельклок PAL кадра ~ 7мгц
спросим, на какую частоту памяти в современных самоделках стоит рассчитывать
и прикинем, сколько за 1/50 секунды можно прочитать слоёв для отображения
(а еще ведь, кроме отображения, требуются такты в них рисовать)
Я не вижу тут никакой принципиально-неразрешимой трагедии.
а я не вижу смысла в жирном девайсе для решения одной лишь частной задачи
на пределе способном выдать только *****картинку без потенциала для улучшения
Как раз весь фокус, что нигде в памяти спектрума нет этих пикселей, в том виде, как они отображаются на экране. Они существуют только в памяти видеокарты. И получаются там последовательным наложением графических объектов. Поэтому
восстановить ничего так просто не получится, потому что родные процедуры восстановления понятия не имеют, что фон уже не просто монохромные однобитные пиксели, а сложная многоцветная картинка с "атрибутом на пиксель". Вам нужно как-то прочесть эти самые "атрибуты" и где-то их сохранить, прежде чем рисовать новый спрайт поверх них.
Это замечательно. Но нам надо перекрасить их "так как там было" до того, как там нарисовали курсор мыши. На Спеке для этого делают буфер на 16 байт (для курсора 8х16) и сохраняют "как было" в нём. Теперь по-вашему методу, 16 байт как в Спеке уже не хватит - каждый пиксель кроме состояния 0/1 несет еще и информацию о цвете. Как ее получать из видеокарты, где хранить и как потом записать обратно?
а до конца дочитывать не судьба?
Даже если фон многоцветный, а не двухцветный, в памяти видеокарты можно хоть на каждый бит из памяти Спектрума выделить по полноцветному пикселю (если для совсем уж ленивых).
Впрочем, сохранять текущую подложку перед выводом каждого объекта просто невыгодно, и неудобно восстанавливать всегда в обратном порядке. Вряд ли в играх часто применяется такой метод. Статичный фон лучше сохранить заранее целиком или таблицей ссылок на тайлы, и оттуда брать нужные куски для восстановления; а динамичным фоном - в буфере полностью стирать старый кадр.
И получаем монохромное изображение под затертым спрайтом. Или вы собираетесь угадывать, откуда процедура взяла байт для сохранения в буфере, а потом для чего прочитала байт из буфера и соответствующим образом перетаскивать параллельно пиксельные атрибуты в памяти видеокарты(а-ля Спек256)?
ЧТО угадывать? Адреса всех операций видны на шине. Если Спектрум переносит байт из буфера на экран, карта может сделать то же самое у себя для соответствующей группы из восьми пикселей.
Да что там сложного-то? Можно даже аппаратно сделать, чтобы последний записанный слой автоматически становился самым верхним. Это будет полностью имитировать последовательное наложение объектов. Хотя, на самом деле такое и не нужно. Достаточно одного байта для хранения номера текущего слоя. В начале цикла обнуляем его, а в процессе отрисовки объектов инкрементируем.
И тут - опа! - вдруг закончились чистые слои (а нечистые нельзя наверх перетаскивать). Кстати, как узнать, что объект со слоя был убран полностью? а не остался, скажем, трупом или обломками (есть игра, в которой нужно буквально карабкаться по кучам тел убитых врагов)
ZX_NOVOSIB
16.09.2016, 10:26
есть игра, в которой нужно буквально карабкаться по кучам тел убитых врагов
что за игра?
Lethargeek
16.09.2016, 21:02
ZX_NOVOSIB, угадай ;) (подсказка: ******* *** *******) тащемта игра довольно известная
подсказка: ******* *** *******
N.. the W...
NEO SPECTRUMAN
16.09.2016, 23:25
Давайте возьмем 250 слоев с масками
:v2_dizzy_facepalm:
может уже проще взять spec256
или запилить что нибудь с похожим принципом работы
и не обязательно городить 15 спектрумов для этого
нужно только в N раз больше памяти по быстрее
и новый самопальный проц
ZX_NOVOSIB
17.09.2016, 08:22
угадай (подсказка: ******* *** *******) тащемта игра довольно известная
N.. the W...
Игра может и известная, однако дичайше однообразная и скучная, графики нет вообще, художник не парился. Скачал rzx - прохождение 45 мин., тому, кто 45 минут вытерпел это однообразие нужно медаль дать :)
И хотя игру бы это не спасло, но лучше бы ГГ не перенимал цвет фоновых обектов - выглядит убого. В диззи это канает, в этой игре абсолютно нет.
inozemcew
17.09.2016, 10:48
а давайте вспомним, что пиксельклок PAL кадра ~ 7мгц
спросим, на какую частоту памяти в современных самоделках стоит рассчитывать
Понятное дело, что 250 это не 4 и не 8, мультиплексировать на ходу такое не нужно. Тут нужен внутренний Z-буфер и пересчет видимого пикселя только во время записи. Опять же ничего нереального. Единственное что нереально, это то, что нам действительно понадобятся аж 250 слоев.
И тут - опа! - вдруг закончились чистые слои
А мы продолжаем рисовать, как ни в чем не бывало. Пусть все падает в верхний слой и там клэшится. Тут же вся изюминка, что эта штука отлично масштабируется. Процедурки вывода не меняются же, есть новый слой - рисуется без клэшинга, нету - значит рисуется, как в обычном Спеке. А если когда-то потом аппаратных слоев добавить все расклэшится само собой.
а я не вижу смысла в жирном девайсе для решения одной лишь частной задачи
Вообще-то мы обсуждаем принципы устранения клэшинга. Как отдельный девайс возможно оно и не нужно, а вот как режим какой-нибудь вундервидеокарты - вполне.
сохранять текущую подложку перед выводом каждого объекта просто невыгодно,
Это как раз неважно. Масса существующих игр делает именно так.
Адреса всех операций видны на шине. Если Спектрум переносит байт из буфера на экран, карта может сделать то же самое у себя для соответствующей группы из восьми пикселей.
Очень сомнительно, что такое вообще возможно. Во-первых буфер один, а спрайт может выводиться в любое место экрана. Надо как-то устанавливать соответствие внутрях видеокарты между буфером и положением спрайта. Я не представляю, как это можно сделать из-за того, что во-вторых, нет одной единственной операции "перенести байт из экрана в буфер". Есть 100500 способов перемещения байтов, как в одиночку, так и попарно. И все они не атомарны. Между чтением из экрана и записью в буфер может произойти куча всего, включая прерывания. Как вы будете отлавливать это на шине? Чего-то мне кажется, что если бы все было так просто, авторы Спек256 не заморачивались бы с альтернативным процессором.
Адреса всех операций видны на шине. Если Спектрум переносит байт из буфера на экран, карта может сделать то же самое у себя для соответствующей группы из восьми пикселей.
Чтобы уследить за регистрами Z80, через которые всё в основном переносится(за исключением переноса по LDI)... Так вот, чтобы уследить за регистрами Z80... , хм, надо почти полностью эмулировать Z80!
- - - Добавлено - - -
Причём и прерывания вместе с ним ловить и обрабатывать, а не только команды расшифровывать и выполнять для раскрашенных регистров.
Без прерываний Амауроте не пойдёт точно.
Да ещё и по хорошему, раз у нас две гимнастки выполняют синхронные упражнения, то нужен и судья, оценивающий синхронность. В простом случае, при рассинхрозе показывать "синий экран" и все стопорить до сброса. Чуть сложнее, научить карту игнорировать, и пытаться восстановить синхронизацию.
В общем марока. :)
Lethargeek
17.09.2016, 21:01
Понятное дело, что 250 это не 4 и не 8, мультиплексировать на ходу такое не нужно. Тут нужен внутренний Z-буфер и пересчет видимого пикселя только во время записи. Опять же ничего нереального. Единственное что нереально, это то, что нам действительно понадобятся аж 250 слоев.
да-да, снова нужно то, нужно сё, нужно что-нибудь еще...
интерес не в теоретической возможности, а в оправданности
и по сравнению с однослойной схемой получилось, что многослойная:
1) требует больших аппаратных ресурсов
2) требует больших трудозатрат при модернизации старых игр
3) принципиально выдаёт картинку худшего качества (хоть с 250 слоями)
4) неудобна для приделывания к ней полезных расширений типа блиттера
и к тому же:
А мы продолжаем рисовать, как ни в чем не бывало. Пусть все падает в верхний слой и там клэшится.
5) ...на самом деле толком не устраняет клэшинг! :v2_dizzy_facepalm:
А мы продолжаем рисовать, как ни в чем не бывало. Пусть все падает в верхний слой и там клэшится. Тут же вся изюминка, что эта штука отлично масштабируется. Процедурки вывода не меняются же, есть новый слой - рисуется без клэшинга, нету - значит рисуется, как в обычном Спеке. А если когда-то потом аппаратных слоев добавить все расклэшится само собой.
"новый принцип устранения клэшинга когда-то потом" :v2_clapp:
(нужно сделать новым заголовком тредика, ящетаю))
Вообще-то мы обсуждаем принципы устранения клэшинга. Как отдельный девайс возможно оно и не нужно, а вот как режим какой-нибудь вундервидеокарты - вполне.
Осталось понять, зачем "какой-нибудь вундервидеокарте" столь убогий прожорливый режим, когда задачу устранения клэшинга выгодней и лучше решить иначе. :v2_confu:
Это как раз неважно. Масса существующих игр делает именно так.
"Масса" - эта скока? Парочку примеров хотя бы? Именно чтоб процедура вывода спрайта каждый раз сохраняла кусок фона под этим спрайтом со всем там нарисованным до того, а потом перед новым кадром медленно и печально восстанавливала фон в обратном порядке? Вот ни разу не встречалось такого, в то время как наткнуться на "формирование кадра в буфере с нуля" можно часто. Наши хакеры, бывало, даже делали ускоренные версии таких игр для 128k (например, такой Thanatos я ковырял) - разворачивая цикл переброски буфера на страницу.
Очень сомнительно, что такое вообще возможно. Во-первых буфер один, а спрайт может выводиться в любое место экрана.
Буфера! Если буфер есть, то спрайты туда рисуют. А уж буфер после переносится на экран.
Надо как-то устанавливать соответствие внутрях видеокарты между буфером и положением спрайта.
Ну при чем тут "положение спрайта"?? Нужно только знать адреса, где может храниться графика. Даже безразлично, в какой раскладке.
Я не представляю, как это можно сделать из-за того, что во-вторых, нет одной единственной операции "перенести байт из экрана в буфер". Есть 100500 способов перемещения байтов, как в одиночку, так и попарно. И все они не атомарны. Между чтением из экрана и записью в буфер может произойти куча всего, включая прерывания. Как вы будете отлавливать это на шине?
Да никак не буду. Способы перемещения не волнуют, если сами байты не изменяются (а если байты изменяются в процессе, то это не переброска, а отрисовка, вопрос отдельный). Нужно только помнить последний адрес, по которому читалось что-то из буфера.
Чего-то мне кажется, что если бы все было так просто, авторы Спек256 не заморачивались бы с альтернативным процессором.
Так у них была задача раскрасить игры вовсе без вмешательства в старый код и без претензий на физическую реализацию.
- - - Добавлено - - -
Чтобы уследить за регистрами Z80, через которые всё в основном переносится(за исключением переноса по LDI)... Так вот, чтобы уследить за регистрами Z80... , хм, надо почти полностью эмулировать Z80!
Именно для переброски блока как раз не надо, интересуют исключительно адреса.
Причём и прерывания вместе с ним ловить и обрабатывать, а не только команды расшифровывать и выполнять для раскрашенных регистров.
"б-же мой, да насрать" мне на прерывания! Ну, разве (чисто теоретически) кроме случаев, когда после чтения буфера прерванным кодом прерывание зачем-то тоже читает буфер. Можешь выдумать вменяемый сценарий, зачем так делать? Переброска (в over 95% игр-то уж точно) либо полностью в обычном коде, либо полностью же - в обработчике прерывания. Хотя можно и за прерываниями следить, вход-возврат на шине прекрасно видно, и выполнять какой-нибудь аналог команды EXX для нескольких регистров видеокарты (или даже в обработчике добавить код её вызова).
Люди, вы хоть итожте в каком-то посте текущие наработки) А то сложно понять весь смысл предлагаемой конструкции, размытый по десятку страниц)
NEO SPECTRUMAN
17.09.2016, 21:53
Наши хакеры, бывало, даже делали ускоренные версии таких игр для 128k (например, такой Thanatos я ковырял)
:v2_ohmy:
нада отдельная тема со списком ускоренных игр :v2_blink:
Lethargeek, Мне кажется ты сильно упрощаешь "слежение за шиной". Рассмотрим типичную ситуацию отзеркаливания байта через 256-байтный буфер. Я не представляю, как "следильщик за шиной", не имея искусственного интеллекта, правильно отзеркалит цвета.
Вот в ZX-Poly всё понятно. Каждый из 4 процессоров свой байт отзеркалит через таблицу, и всё правильно получиться.
Lethargeek
18.09.2016, 14:11
Lethargeek, Мне кажется ты сильно упрощаешь "слежение за шиной". Рассмотрим типичную ситуацию отзеркаливания байта через 256-байтный буфер. Я не представляю, как "следильщик за шиной", не имея искусственного интеллекта, правильно отзеркалит цвета.
А мне кажется, что ты снова путаешь отрисовку и переброску буфера (каковую в принципе вовсе лучше поручать блиттеру). Зеркалирование относится к отрисовке, а там всё зависит от особенностей реализации (может, маска зеркалится отдельно и всё двухцветное) и можно явно устанавливать режим вывода (в данном случае - с разворотом полосок пикселей).
Вот в ZX-Poly всё понятно. Каждый из 4 процессоров свой байт отзеркалит через таблицу, и всё правильно получиться.
Зато непонятно, как поступать с атрибутными эффектами или ксоркой (и даже с возможностью рассинхрона, если вдруг пиксель проверяется через флаг). У каждой схемы есть какие-то недостатки.
Зато непонятно, как поступать с атрибутными эффектами или ксоркой (и даже с возможностью рассинхрона, если вдруг пиксель проверяется через флаг). У каждой схемы есть какие-то недостатки.
Предлагаю составить список задач и типов вывода графики, которые надо учитывать при разработке метода устранения клешинга и раскраски. Например:
1. Вывод и стирание по XOR.
2. Зеркалирование спрайта по таблице
3. Атрибутные эффекты
и т.д.
Предлагаю составить список задач и типов вывода графики, которые надо учитывать при разработке метода устранения клешинга и раскраски. Например:
1. Вывод и стирание по XOR.
2. Зеркалирование спрайта по таблице
3. Атрибутные эффекты
и т.д.
Это походу тупиковый путь развития дискусии, так как сильно много вариантов алгоритмов вывода и под каждый делать железное ускорение вероятнее всего невозможная задача.
Давайте спустимся до "базового zx-железа" без учета СОФТового уровня и строить концепции там, тогда будет понятнее возможен ли вариант upgrade-a железа, если не возможен то вся эта концепция бесполезный треп (так как требует существенного изменения софта спектума, поcле которого он станет не спектрумом а другим компом с z80 процессором).
1. суть zx-видео: оно состоит из квадратов 8х8 пикселей у которых есть PAPER/INC+BRIGHT+FLASH, т.е. для задания изображения в 1 квадрате надо занести 8 байт в каждом их которых 8 PAPER/INC-битов-селекторов + 1 байт атрибутов в котором 3 бита PAPER-a, 3 бита INK-a, 1 бит FLASH, и 1 бит BRIGHT; в целом каждый квадрат занимает 9 байт и при количестве 32x24 квадратов это 6912 байт.
2. предлагается поверх каждого квадрата навесить еще несколько слоев похожих квадратов в которых нету PAPER (а значит и FLASH).
Возникает вопрос, если ранее программа заносила 9 байт то теперь будет заносить еще по 9 на каждый новый слой? Откуда взять дополнительную скорость\память для этого?
null_device
19.09.2016, 01:04
предлагается поверх каждого квадрата навесить еще несколько слоев похожих квадратов в которых нету PAPER (а значит и FLASH).
Возникает вопрос, если ранее программа заносила 9 байт то теперь будет заносить еще по 9 на каждый новый слой? Откуда взять дополнительную скорость\память для этого?
Эти вопросы, я задавал еще в самом начале топика.
В таком виде, для отображения не слишком многоцветной картинки в пределах одного знакоместа - можно использовать несколько "дополнительных" экранов. Но, ТС периодически заводит речь о спрайтовых экранах, наложении, масках и громоздкости цвета на точку. Напомню, при реализации через стандартные экраны с атрибутами знакоместа - для отображения всех базовых цветов нужно 16 экранов - на каждый цвет и режим яркости (это при самом "худшем" варианте).
Это походу тупиковый путь развития дискусии, так как сильно много вариантов алгоритмов вывода и под каждый делать железное ускорение вероятнее всего невозможная задача.
Не согласен.
Вариантов вывода весьма ограниченное число, под которое попадет 99.9% игр.
Их надо понимать, и лучше иметь список.
inozemcew
20.09.2016, 01:16
1) требует больших аппаратных ресурсов
Не требует. Вряд ли единицы мегабайт RAM можно считать большим аппаратным ресурсом.
требует больших трудозатрат при модернизации старых игр
Как раз наоборот, трудозатраты минимальны, графика и процедуры остаются родными.
принципиально выдаёт картинку худшего качества
Что значит худшего качества? Картинка, в рамках поставленной задачи, может быть одна - как в Спектруме, только без клэшинга.
неудобна для приделывания к ней полезных расширений типа блиттера
Польза от расширений, софт для которых будет написан "потом" - имхо, сомнительна.
"Масса" - эта скока? Парочку примеров хотя бы?
Ну уже упоминавшийся RamboIII, да остальные игрухи от Andrew Deakin - Athena, RenegadeIII, Adams Family etc. тоже сделаны на этом принципе. Да и все, что имеет статический фон, тоже выгодно делать таким образом. Экономия памяти и процессора. Памяти под буфер нужно не на весь экран, а только по размеру спрайта. А разворачивать фон из тайл-мапа, даже по размеру объекта - процессор просто не успевает.
Буфера! Если буфер есть, то спрайты туда рисуют. А уж буфер после переносится на экран.
Это что получается, надо взять фон, перенести его в буфер, нарисовать сверху спрайт и то, что получилось перенести в экран? Но зачем эти лишние движения, если фон уже на экране, а все, что надо это сохранить кусочек фона в буфере и нарисовать спрайт?
Ну при чем тут "положение спрайта"?? Нужно только знать адреса, где может храниться графика. Даже безразлично, в какой раскладке.
Вы упорно не замечаете простой вопрос: "как стереть спрайт не перерисовывая всё?" Если вы будете спрашивать, "Зачем это нужно?" - стразу ответ: существующие игры так делают.
Вот смотрите есть процедура вывода курсора мыши. Она работает до смешного просто. В буфер запоминается фон из того места экрана, где будет выводиться спрайт стрелочки. Затем рисуется стрелочка, с наложением на фон. В следующем цикле из буфера в экран возвращается сохраненное изображение, стирая курсор мыши, и цикл рисования повторяется в другом месте.
Теперь у нас есть экранные слои. Что надо поменять в данном алгоритме? Всего две вещи. Перед процедурой устанавливаем активным слой 1. Дальше, таже самая процедура читает нули из экрана (потому, что стандартное изображение находится в 0м слое, а в 1м слое кроме изображения курсора мыши у нас никогда ничего не бывает) , как и раньше, сохраняет эти нули, думая, что это фон, в тот же самый буфер, и рисует спрайт стрелки, точно так же, как и раньше, даже не подозревая, что он попадет не на фоновое изображение, а в пустой слой №1. Всё, устанавливаем активным 0й слой и возвращаемся в основную программу. Спрайт стрелки будет виден над основным изображением, без всякого клэшинга. Теперь, чтобы спрятать курсор мыши, устанавливаем активным 1й слой и вызываем старую процедуру стирания. Она как и раньше перенесет в экран из буфера нули, думая, что это сохраненный фон, тем самым сотрет изображение стрелки. Делаем активным слой 0, возвращаем управление основному коду.
Как видите, все изменения - только в переключении слоев до и после отрисовки. Все остальное остается неизменным.
Хотелось теперь услышать от вас, как вы собираетесь адаптировать этот же алгоритм мышиного курсора под свою систему.
- - - Добавлено - - -
предлагается поверх каждого квадрата навесить еще несколько слоев похожих квадратов в которых нету PAPER (а значит и FLASH).
Точно. Слой - это обычный спектрумовский экран с прозрачным PAPER. Таких экранов несколько, они находятся друг над дружкой, поэтому для них предпочтительнее термин "слой". Нижние "просвечивают" через прозрачный PAPER верхних. Текущий доступный для процессора экран(слой) переключается значением в порт. Переключение в стандартной области $4000-5AFF. Переключение на отображение не влияет никак, только на доступный для чтения/записи экран(слой). Самый нижний, нулевой слой - стандартный экран (т.е. с непрозрачным PAPER и с FLASH) Вот такая упрощенная схема.
Возникает вопрос, если ранее программа заносила 9 байт то теперь будет заносить еще по 9 на каждый новый слой?
Нет количество байт для программы не меняется. То, что рисовалось на одном стандартном экране, теперь разносится по слоям, но общий объем выводимой графики не меняется (за исключением мелких нюансов).
- - - Добавлено - - -
В таком виде, для отображения не слишком многоцветной картинки в пределах одного знакоместа - можно использовать несколько "дополнительных" экранов.
Задача не в том, чтобы нарисовать 16 цветную картинку. Согласен, для этого 16 слоев не самый лучший способ.
Задача - устранить клэшинг в существующих программах с минимальными усилиями и без перерисовки графики.
Почему так часто упоминаются спрайты? Так, если фон еще как-то можно распределить с учетом знакомест, то со спрайтами дело совсем плохо. Поэтому основной упор в деле борьбы с клэшингом и делается на спрайты.
Titus, Как будем составлять список?
Каждый будет предлагать свой вариант?
Предлагаю свой:
Техники вывода графики, приводящие к клешингу, и возможные решения.
1) XOR - спрайты. [Lode Runner, Dizzy_1] Решается ZXInno 0.1 (http://zx-pk.ru/threads/26792-novyj-printsip-ustraneniya-kleshinga.html?p=881868&viewfull=1#post881868)- однобитный слой Иноземцева. Работа_Z80 не меняется.
2) Спрайты с маской. [RamboIII - персонажи, Dizzy_2..6..] Решается ZXInno_0.2 - двубитный слой Иноземцева - цвет с маской. Работа_Z80 плюс минус. (маску можно не накладывать/вычислять, если один спрайт на слой или спрайты на слое гарантированно не пересекаются, но маску нужно отдельно передавать в видеокарту)
3) Отрисовка фона по знакоместам [RamboIII - бочки на полу] Нужно вводить дополнительную информацию. ZX-poly, spec256, colorBit от Lethargeek-а и некий мифический ZXprop.
Тяжкие обстоятельства.
1) Предварительный вывод в буфер.
2) Упакованная графика фона.
Да, Titus, как смог написал, что в голове крутилось. :) Надеюсь другие расширят и дополнят.
(Всё время забываю написать про уровни, но подразумеваю их)
3) Отрисовка фона по знакоместам [RamboIII - бочки на полу] Нужно вводить дополнительную информацию.
А какая проблема с фоном по знакоместам?
- - - Добавлено - - -
Решается ZXInno_0.1
Ссылка есть?
Ссылка есть?
ZXInno_0.1 (http://zx-pk.ru/threads/26792-novyj-printsip-ustraneniya-kleshinga.html?p=881868&viewfull=1#post881868)
А какая проблема с фоном по знакоместам?
Про бочки на полу там же на картинке, и сразу далее мы обсуждаем.
Готовая(запечёная) графика, сразу с клешингом.
Про бочки на полу там же на картинке, и сразу далее мы обсуждаем.
Готовая(запечёная) графика, сразу с клешингом.
Мне кажется, для всего, кроме XOR'а замечательно подойдет подход типа ZX-Poly.
Lethargeek
20.09.2016, 22:01
Не требует. Вряд ли единицы мегабайт RAM можно считать большим аппаратным ресурсом.
...на колу мочало, начиная сначала :v2_dizzy_facepalm:
а повышенная частота памяти, чтобы в кадре их успеть прочитать - это не больший аппаратный ресурс?
или неведомая схема "внутреннего z-буфера" - это не больший аппаратный ресурс?
Как раз наоборот, трудозатраты минимальны, графика и процедуры остаются родными.
Только для нескольких удобных для схемы случаев. Причём в их удобстве надо убедиться, копаясь в логике.
Что значит худшего качества?
Цветов меньше, фон и спрайты только двухцветные.
Картинка, в рамках поставленной задачи,
Кем, как именно? Если как:
Задача - устранить клэшинг в существующих программах с минимальными усилиями и без перерисовки графики.
- то лично я уже с постановкой не соглашусь (даже не касаясь пока что не доказанной "минимальности")
Мне вот хочется плавной регулируемости усилий (и результатов, соответствующих усилиям).
может быть одна - как в Спектруме, только без клэшинга.
Без клэшинга - уже значит не "как на Спектруме". Если речь об обязательной двухцветности объектов - то с какой стати?
Польза от расширений, софт для которых будет написан "потом" - имхо, сомнительна.
Не "потом", а польза блиттера несомненна и в деле ускорения старых игр.
Ну уже упоминавшийся RamboIII, да остальные игрухи от Andrew Deakin - Athena, RenegadeIII, Adams Family etc. тоже сделаны на этом принципе.
Это мы еще посмотрим, насколько точно. :v2_dizzy_coder:
Да и все, что имеет статический фон, тоже выгодно делать таким образом. Экономия памяти и процессора.
Нет, невыгодно. "Таким образом" получаем процессорное время в КАЖДОМ игровом кадре на КАЖДЫЙ спрайт = SaveBack + PutSprite + RestoreBack. Если же "чистый" фон заранее единожды создан в буфере, получается только PutSprite + RestoreBack (с незаметной ОДНОКРАТНОЙ задержкой только при переходе в новый экран). Что экономичнее для процессора?
Памяти под буфер нужно не на весь экран, а только по размеру спрайта.
По максимальному общему размеру максимального числа спрайтов, способных оказаться на экране одновременно.
Причём в случае разного размера и формы спрайтов и код сложнее, и возможно, памяти нужно больше.
А разворачивать фон из тайл-мапа, даже по размеру объекта - процессор просто не успевает.
И с чего бы вдруг процу-то не успевать? При не совсем уж мелких объектах расход времени на поиск нужных тайлов будет меньше времени SaveBack. Расход памяти также будет скорее меньше - не нужны буфера для фона под каждым спрайтом.
Это что получается, надо взять фон, перенести его в буфер, нарисовать сверху спрайт и то, что получилось перенести в экран? Но зачем эти лишние движения, если фон уже на экране, а все, что надо это сохранить кусочек фона в буфере и нарисовать спрайт?
Хехехе, но ведь "существующие игры так делают" :D В основном потому, что (даже без прокрутки фона) не успевают обновить все спрайты и прочие объекты игрового логического кадра за тв-кадр (и даже за несколько тв-кадров). Вот и приходится сначала сначала рисовать в буфер, а потом перебрасывать весь буфер на экран синхронно с лучом, чтобы ничего не мерцало. Также в буфере может адресация быть другой, не совпадающей с экранной спектрумовской раскладкой.
Вы упорно не замечаете простой вопрос: "как стереть спрайт не перерисовывая всё?"
Ответ был таков же, как и вопрос, но кое-кто, похоже, его не понял :rolleyes:
Вот смотрите есть процедура вывода курсора мыши. Она работает до смешного просто. В буфер запоминается фон из того места экрана, где будет выводиться спрайт стрелочки. Затем рисуется стрелочка, с наложением на фон. В следующем цикле из буфера в экран возвращается сохраненное изображение, стирая курсор мыши, и цикл рисования повторяется в другом месте.
Сферическая процедура в вакууме. На практике может оказаться совсем не так. Ну да ладно, можно и такой пример обсудить.
Теперь у нас есть экранные слои. Что надо поменять в данном алгоритме? Всего две вещи. Перед процедурой устанавливаем активным слой 1. Дальше, таже самая процедура читает нули из экрана (потому, что стандартное изображение находится в 0м слое, а в 1м слое кроме изображения курсора мыши у нас никогда ничего не бывает) , как и раньше, сохраняет эти нули, думая, что это фон, в тот же самый буфер, и рисует спрайт стрелки, точно так же, как и раньше, даже не подозревая, что он попадет не на фоновое изображение, а в пустой слой №1. Всё, устанавливаем активным 0й слой и возвращаемся в основную программу
...даже не подозревая, что прерывание нагадило в слой №1 с непредсказуемыми последствиями или вместо нужных данных прочло нули :p
Спрайт стрелки будет виден над основным изображением, без всякого клэшинга. Теперь, чтобы спрятать курсор мыши, устанавливаем активным 1й слой и вызываем старую процедуру стирания. Она как и раньше перенесет в экран из буфера нули, думая, что это сохраненный фон, тем самым сотрет изображение стрелки. Делаем активным слой 0, возвращаем управление основному коду.
Как видите, все изменения - только в переключении слоев до и после отрисовки. Все остальное остается неизменным.
Хотелось теперь услышать от вас, как вы собираетесь адаптировать этот же алгоритм мышиного курсора под свою систему.
А я вообще не буду адаптировать алгоритм и старый код совсем никак не буду менять))) Адаптировать следует конфигурацию (не путать с прошивкой) видеодевайса к этому коду. Достаточно сообщить видеокарте основные ключевые точки графпроцедур, типо: здесь читается полоска фона, здесь маска спрайта, а здесь обратная запись байта фона с кусочком спрайта. Фактически сообщаем смысл сигналов системной шины при выполнении процессором команды с этого адреса. Реализовать возможно по-разному, например, как массив кодов внутренних (немногочисленных и простых) команд видеокарты, осуществляющих аналогичные операции над полосками полноцветных пикселей и внутренним аналогом атрибутов. Основную часть массива заполнить "нопами", а команды загрузить перед игрой спецпроцедурой-конфигуратором (можно даже до загрузки самой игры).
Вот на что ресурсы ПЛИС потратить имеет смысл, вместо имитации пачки Спектрумов! :v2_dizzy_roll:
- - - Добавлено - - -
Мне кажется, для всего, кроме XOR'а замечательно подойдет подход типа ZX-Poly.
Атрибутные эффекты?.. но это мелочь, основные недостатки zx-poly и подобных решений - нерациональность и неудобство расширения-улучшения.
"Абсолютно для всего" (ну, разве что, кроме слишком хитро самоизменяющегося кода) подойдёт подход, только что описанный мной чуть выше ^
(вообще, кстати, применимый при любой структуре внешней видеопамяти, в том числе при б-гомерзкой многослойной... :v2_dizzy_biggrin2: только зачем?) :v2_sick:
Зачем? ну зачем переделывать старые добрые игры на ZX, их не хватает в цвете на других платформах? откуда они портированы, Вы по сути делаете 4 шага назад и 0 вперед.
"Абсолютно для всего" (ну, разве что, кроме слишком хитро самоизменяющегося кода) подойдёт подход, только что описанный мной чуть выше ^
Где именно? В бесконечных диалогах с Иноземцевым трудно выцепить суть) Нужно отдельное описание)
Lethargeek
21.09.2016, 00:22
Где именно?
ну, ё-моё...
только что
чуть выше
перед "--- добавлено ---"
zx-poly и подобных решений - нерациональность и неудобство расширения-улучшения.
забачно, zx-poly и "ему подобные решения" единственные кто сохраняет обратную совместимость и дает программеру возможность самостоятельно делать решения (в отличии от решений видеокарт где мы дадим мегажелезо и протокол, а делать всё будет видяха гдет внутри) и при этом упрекается в неудобстве расширения-улучшения :) ну дак спектрум вообще то это платформа которая вообще не предназначена к расширению-улучшению еще на старте, это её фича, что там всё расширение не благодаря, а вопреки
Lethargeek
22.09.2016, 19:47
забачно, zx-poly и "ему подобные решения" единственные кто сохраняет обратную совместимость
И в чем же (якобы) "несовместимость" других решений?
и дает программеру возможность самостоятельно делать решения (в отличии от решений видеокарт где мы дадим мегажелезо и протокол, а делать всё будет видяха гдет внутри)
Какой-то бессмысленный набор слов. Что такого "несамостоятельного" в управлении девайсом по протоколу? Чем оно принципиально отлично от управления процессором Z80 через протокол его машинного языка (вместо, скажем, непосредственного контроля над его четырёхбитным АЛУ)))
и при этом упрекается в неудобстве расширения-улучшения ну дак спектрум вообще то это платформа которая вообще не предназначена к расширению-улучшению еще на старте, это её фича, что там всё расширение не благодаря, а вопреки
А разъём Expansion фирменного Спектрума, стало быть, назвали так шутки ради? :D
NEO SPECTRUMAN
22.09.2016, 22:59
А разъём Expansion фирменного Спектрума
для поключения переферии
принтер, джойстик...
врятли он для видеокарт задумывался...
Lethargeek
23.09.2016, 00:15
принтер, джойстик...
и зачем им полный доступ к системной шине?
врятли он для видеокарт задумывался...
то есть видеосигналы на разъёме - это для принтера :D
Bedazzle
23.09.2016, 12:32
то есть видеосигналы на разъёме - это для принтера :D
для 3д принтера :) чтобы реальные модельки печатал с клешингом :D
inozemcew
23.09.2016, 14:17
а повышенная частота памяти, чтобы в кадре их успеть прочитать - это не больший аппаратный ресурс?
7 МБайт/с для восьми слоев, которых по-уши хватит, чтобы расклэшить практически все - это много?
или неведомая схема "внутреннего z-буфера" - это не больший аппаратный ресурс?
Так. Отставить. Цифра 250 была приведена чисто показать, что фантастические требования к памяти - это не соответствует действительности. Необходимости в таком количестве слоев просто нет, хотя и его можно реализовать без фантастических запросов к объему и быстродействию памяти.
Кстати, а вам сколько ресурсов понадобится, чтобы реализовать соответствие "буфер - экран" и отслеживать шину? Я так подозреваю, что мелкой логикой тут не обойдешся..
Только для нескольких удобных для схемы случаев.
Для остальных вариантов удобных случаев еще меньше.
Если речь об обязательной двухцветности объектов - то с какой стати?
Потому, что с перерисовкой графики уже соовсем другая песня. Добавляются такие непростые вопросы "где хранить?", "как загружать?", "как выводить?". И да, есть ZX-Poly/Spec256 и это направление, имхо лучший вариант в таком случае.
польза блиттера несомненна и в деле ускорения старых игр.
Как раз сомнительно, что старые игры нужно ускорять, но это дело хозяйское..
Если же "чистый" фон заранее единожды создан в буфере, получается только PutSprite + RestoreBack
Нужен отдельный буфер для хранения фона. Даже для 2/3 экрана - это 10% от имеющейся памяти.
А разворачивать фон из тайл-мапа, даже по размеру объекта - процессор просто не успевает.
И с чего бы вдруг процу-то не успевать? При не совсем уж мелких объектах расход времени на поиск нужных тайлов будет меньше времени SaveBack
С чего бы это меньше? Фон обычно хранится не сплошняком, а как список тайлов с координатами их вывода. Так просто компактнее. "Дерево, x=2, y=5", "Кустик, x=10, y=12", "Лестница, x=8, y=3, длина=10". Правда думаете, что процедить такой список совсем просто?
По максимальному общему размеру максимального числа спрайтов, способных оказаться на экране одновременно.
Причём в случае разного размера и формы спрайтов и код сложнее, и возможно, памяти нужно больше.
Не спорю. Но в подавляющем большинстве существующих игр спрайты можно пересчитать по пальцам.
даже не подозревая, что прерывание нагадило в слой №1 с непредсказуемыми последствиями или вместо нужных данных прочло нули
С чего бы это? Найти начало и конец обработчика прерывания и выставить там нужный слой - задача совсем не сложная.
Вот и приходится сначала сначала рисовать в буфер, а потом перебрасывать весь буфер на экран синхронно с лучом, чтобы ничего не мерцало.
Согласен, тяжелый случай. В буфере нет информации, о том, какому объекту какой пиксель принадлежит. В любом случае потребуется более глобальная переделка.
Ответ был таков же, как и вопрос, но кое-кто, похоже, его не понял
Ответ был в стиле "С точки зрения банальной эрудиции.." Похоже вы сами не совсем понимаете, как это можно сделать..
А я вообще не буду адаптировать алгоритм и старый код совсем никак не буду менять))) Адаптировать следует конфигурацию (не путать с прошивкой) видеодевайса к этому коду. Достаточно сообщить видеокарте основные ключевые точки графпроцедур, типо: здесь читается полоска фона, здесь маска спрайта, а здесь обратная запись байта фона с кусочком спрайта. Фактически сообщаем смысл сигналов системной шины при выполнении процессором команды с этого адреса. Реализовать возможно по-разному, например, как массив кодов внутренних (немногочисленных и простых) команд видеокарты, осуществляющих аналогичные операции над полосками полноцветных пикселей и внутренним аналогом атрибутов. Основную часть массива заполнить "нопами", а команды загрузить перед игрой спецпроцедурой-конфигуратором (можно даже до загрузки самой игры).
Вот на что ресурсы ПЛИС потратить имеет смысл, вместо имитации пачки Спектрумов!
Это правильно. Но это только уровень общения игры, её доработки и карты. Игра остаётся фактически не тронутой и ничего не знает о карте. Конкретная доработка, в загрузчике, обучает карту работе с конкретной игрой. Карта-же способна смотреть все события на шинах и интерпретировать. Это почти ZX-prop, не хватает ещё способности в нужный момент выдать нужные данные на шину данных вместо данных из ОЗУ, и как код_операции и как данные.
В этой-же теме, "новый принцип устранения клешинга", интересен уровень рассмотрения возможностей карты для устранения клешинга.
И Lethargeek, и inozemcew предложили свои наборы возможностей, это хорошо, но зачем-то цепляются к друг другу, это плохо. Скучно вас читать, когда вы пытаетесь доказать что другой не прав.
Слои Иноземцева, это хорошо. Это понятно программисту и хакеру. Это требует нетрудного хакерского внедрения в программу.
Есть затык с играми, бросающими на экран кадр из буфера. Пока просто не берём такие игры, и всего делов-то. :)
Есть затык с передачей самой маски в карту, общего решения нет, придётся попыхтеть.
Идея Lethargeek-а.
Восстановление фона через ту-же процедуру, что и рисует фон... это занятно, но ИМХО слишком специфично, либо требует серьёзной переделки большинства игр. А поскольку это специфично, это более отпугивает от начала работы. Хакеру-же нужно преодолеть некоторый порог уверенности в успехе. Побоится, что вот он вроде посмотрит, всё тайлами смотрится, всё вроде получается переделать, он проделает работу, а возле финального боса какой нибудь спецэффект не получится переделать, и он войдёт в эстетический диссонанс с проделанной переделкой, и впечатление смажется.
Lethargeek
23.09.2016, 21:16
7 МБайт/с для восьми слоев,
во-1 для двухбитнопиксельных (это если с маской) слоёв - вдвое больше
которых по-уши хватит, чтобы расклэшить практически все - это много?
во-2 не хватит: сходу контрпример из классики - Cybernoid, в котором по экрану мало что летают тучи мелких объектов (притом часть - с непостоянными атрибутами), так еще и бонусы падают на землю и там накапливаются :v2_dizzy_rain:
Так. Отставить. Цифра 250 была приведена чисто показать, что фантастические требования к памяти - это не соответствует действительности. Необходимости в таком количестве слоев просто нет,
Ну как же нет)) для того же киберноида дофига понадобится слоёв, если (как предложено было ранее) после каждого спрайта брать чистый слой. А иначе - долго возиться в коде и пилить динамический диспетчер спрайтов для "нефантастического" числа, а потом еще упихивать его в память и следить, чтоб не было побочных эффектов.
хотя и его можно реализовать без фантастических запросов к объему и быстродействию памяти.
"Похоже вы сами не совсем понимаете, как это можно сделать.." (с)
Кстати, а вам сколько ресурсов понадобится, чтобы реализовать соответствие "буфер - экран" и отслеживать шину?
да уж точно меньше, чем для многослойной схемы схожих возможностей
Я так подозреваю, что мелкой логикой тут не обойдешся..
какой "мелкой"? на дворе 2016 год!
Для остальных вариантов удобных случаев еще меньше.
"остальные" с киберноидом лучше справятся :p
Потому, что с перерисовкой графики уже соовсем другая песня. Добавляются такие непростые вопросы "где хранить?",
а что, есть какие-то варианты, кроме памяти видеокарты (лучше уж на это её потратить, чем на полсотни унылых монотонных слоёв, всё равно которых где-нибудь, да не хватит)
"как загружать?", "как выводить?"
молча, блин! (вот каков вопрос, таков и ответ!) ...что конкретно кажется "непростым"?
И да, есть ZX-Poly/Spec256 и это направление, имхо лучший вариант в таком случае.
Лучший разве что по критерию "как бы применить побольше аппаратных ресурсов, но при этом так и не решить проблему клэшинга во всех случаях". Эмулировать кучу параллельных синхронных Спектрумов ради этого ну совершенно необязательно.
Нужен отдельный буфер для хранения фона. Даже для 2/3 экрана - это 10% от имеющейся памяти.
минус память, которая нужна была бы на куски фона, так что меньше (и порою весьма существенно)
С чего бы это меньше? Фон обычно хранится не сплошняком, а как список тайлов с координатами их вывода. Так просто компактнее. "Дерево, x=2, y=5", "Кустик, x=10, y=12", "Лестница, x=8, y=3, длина=10". Правда думаете, что процедить такой список совсем просто?
думаю, что проще брать адрес тайла по двум координатам карты экрана (формируемой при переходе в другую комнату, заодно выполняющей и функцию карты проходимости, например)
Не спорю. Но в подавляющем большинстве существующих игр спрайты можно пересчитать по пальцам.
уточняю: в подавляющем большинстве игр в персональной выборке Иноземцева :)
С чего бы это? Найти начало и конец обработчика прерывания и выставить там нужный слой - задача совсем не сложная.
при несложных обработчике и контексте... и выглядит гораздо менее "минимально"
Согласен, тяжелый случай. В буфере нет информации, о том, какому объекту какой пиксель принадлежит. В любом случае потребуется более глобальная переделка.
и не надо, хватит и цвета пикселя, получаемого видеодевайсом при отрисовке (безразлично - в буфер или в экран)
В любом случае потребуется более глобальная переделка.
переделка мЫшления потребуется, чтоб понять, что переделка кода вообще не требуется :v2_dizzy_turn:
Ответ был в стиле "С точки зрения банальной эрудиции.." Похоже вы сами не совсем понимаете, как это можно сделать..
похоже, кое-кто здесь не понимает, что мои сообщения следует дочитывать до конца :rolleyes:
(и ведь не впервые уже такое, начинает даже на умышленную тактику походить)
- - - Добавлено - - -
Это почти ZX-prop,
На самом деле лучше, чем "ZX-prop" (ZX-poly?) именно потому, что видеокарта не обязана выполнять точные аналоги оригинальных "однобитнопиксельных" команд (что позволит, в частности, бороться с глюками ксорок).
не хватает ещё способности в нужный момент выдать нужные данные на шину данных вместо данных из ОЗУ, и как код_операции и как данные.
Чисто для обесклэшивания игр чтение с девайса совсем не нужно, да и новые эффектные игродемы вполне можно без него делать. Зато полностью пассивный девайс попроще и не требует лезть с ножом и паяльником в потроха компов.
Слои Иноземцева, это хорошо. Это понятно программисту и хакеру. Это требует нетрудного хакерского внедрения в программу.
Ну, вот он я, программист и немножко "хакер" :) (покопавшийся когда-то в коде игрушек в ходе написания эмулятора) - и не могу придумать ну вот никак, за каким бы хреном мне могли бы понадобиться слои, и зачем вообще в программу что-то "внедрять", если можно этого избежать.
Восстановление фона через ту-же процедуру, что и рисует фон... это занятно, но ИМХО слишком специфично, либо требует серьёзной переделки большинства игр.
Ты о чём, какой еще "переделки"? Старый код необязательно трогать же. Только сообщить видеокарте, где подменить несколько команд пересылки и обработки пикселей (таковых команд в типичных играх совсем немного)
NEO SPECTRUMAN
23.09.2016, 22:01
"как бы применить побольше аппаратных ресурсов, но при этом так и не решить проблему клэшинга во всех случаях"
а бутта эта монстроподелка избавляет от клешинга во всех случаях
да еще и придется пол кода переправлять...
да и для такого подхода как spec256 не обязательно лепить 16 спектрумов вместе...
Lethargeek
24.09.2016, 00:02
а бутта эта монстроподелка избавляет от клешинга во всех случаях
да еще и придется пол кода переправлять...
явно не по адресу обращение (с "моим" способом в старом коде не пришлось бы править ни байта)
да и для такого подхода как spec256 не обязательно лепить 16 спектрумов вместе...
предлагали где-то слепить вместе только регистры, но по размеру это вышло бы не намного меньше, чем 16 целых z80
Ты о чём, какой еще "переделки"? Старый код необязательно трогать же. Только сообщить видеокарте, где подменить несколько команд пересылки и обработки пикселей (таковых команд в типичных играх совсем немного)
Прости, вообще не понимаю. Разжуй пожалуйста на примере. Вот допустим у нас некий Lode Runer. В пиксельном плане персонажи рисуются и стираются по XOR. В атрибутном плане цвет персонажа красит знакоместа в режиме "моляр", восстанавливается из 768 байтного буфера.
ВОПРОС. Как будет работать переделка, того типа как ты описываешь?
Вот моё недоумение. Старый код не трогаем, кода восстановления фона под спрайтами не было изначально, так откуда он возьмётся и восстановит нам фон?
NEO SPECTRUMAN
24.09.2016, 23:37
предлагали где-то слепить вместе только регистры, но по размеру это вышло бы не намного меньше, чем 16 целых z80
все таки в конечном итоге конструкция будет по проще чем >16 спеков стуленных вместе
Lethargeek
25.09.2016, 05:52
Прости, вообще не понимаю. Разжуй пожалуйста на примере. Вот допустим у нас некий Lode Runer. В пиксельном плане персонажи рисуются и стираются по XOR. В атрибутном плане цвет персонажа красит знакоместа в режиме "моляр", восстанавливается из 768 байтного буфера.
ВОПРОС. Как будет работать переделка, того типа как ты описываешь?
Вот моё недоумение. Старый код не трогаем, кода восстановления фона под спрайтами не было изначально, так откуда он возьмётся и восстановит нам фон?
Надо разбираться с конкретным кодом. Лодераннер я поверхностно посмотрел. Вообще можно с ксорками по-разному поступать.
1) Просто побитно ксорить многобитные пиксели, результат примерно будет похож на spec256 или zx-poly (смотря по кодированию цвета, индекс или непосредственно RGB). То есть на чёрном фоне - правильные цвета, при накладках - разноцветное месиво. Зато проще всего вспомогательный код в памяти видеокарты, и сами команды этого кода - аналоги спектрумовских чтения, записи и ксорки.
2) Та же самая побитная ксорка пикселей, но только с индексированным цветом и особенным подбором палитры - цвет определяется несколькими старшими битами для всех возможных комбинаций значений младших бит. (Фактически так имитируются слои)))
Для простой игры типа лодераннера второй способ вполне достаточен, но просто "повторить возможности слоёв без самих слоёв" не так уж интересно, и к тому же в более сложных случаях может не хватить цветов на все спрайты, потому что их слишком много, или хочется улучшить расцветку спрайтов. Тут возможны компромиссные варианты, например, однотипные объекты могут грязно ксориться друг с другом по первому способу, но не с фоном и не с объектами других типов. Или же -
3) Условная замена пикселя вместо ксора. В том же лодераннере в процедуре обновления человечка сначала старый спрайт стирается ксоркой, а потом сразу же выводится новый спрайт, и так поочерёдно все человечки. То есть, если бы не ксором печатать их, а нормальным наложением сверху, да еще разными цветами, то в конце могли получить картинку, когда от самого первого человечка видно только несколько пикселей. Вот их-то в следующем игровом кадре и нужно чистить, не трогая остальные, - по условию попадания индекса в определённый диапазон. Таким образом можно выделить на каждый спрайт десяток-другой цветов и накладывать хоть сотни поочерёдно.
Причем "чистить" - значит, заменять на пиксели неподвижного фона. Получить его можно тоже разными способами, например, еще в коде формирования фона находим место, где байт фона выводится в экран (а видеокарта параллельно пишет полоску пикселей), и во вспомогательном коде ставим следующей командой - "и скопировать, что только что записали, в такой же адрес видеопамяти, сдвинутый на константу" (мы же можем в пару спектрумовским командам поставить любые вспомогательные). Вот и получили копию фона и потом, при чистке пикселей по условию, можно так же со сдвигом на константу от текущего адреса экрана читать её.
На правах примера) Варианты разные могут быть, всё же ксорки - это самый неприятный и трудный случай, если ставится задача убрать дырявость.
- - - Добавлено - - -
все таки в конечном итоге конструкция будет по проще чем >16 спеков стуленных вместе
Полагаю, ненамного. Так избавимся только от повтора блока ветвлений и частично флагов, а все регистры, пересылки, логика и арифметика повторяются.
Вообще можно с ксорками по-разному поступать.
Фу, ясно. Я уж думал твой метод, когда фон под персонажем восстанавливается тем-же кодом, что и строит фон - универсальный "философский грааль" для всех спрайтовых игр, непонятный мне. Ан нет, это просто вы с Иноземцевым в порыве софистического азарта начинаете требовать от оппонента, чтобы методика того работала почти всегда... Да не нужно нам всего. Давайте хоть Dizzy, Lode Runer расклешуем для начала. А там посмотрим.
ZX_NOVOSIB
25.09.2016, 09:39
Предлагаю о легендарных, но примитивных играх вообще не заморачиваться (лоде рунер, джет сет вилли и т.п. маникминеры). Не надо их трогать. Предлагаю вообще забить на игры 82-85 гг., рассматривать только начиная с 86 г. В нормальных играх ксор редко встречается, на ум токо диззи-1 приходит.
ZX_NOVOSIB, просто для отработки технологии. Потренируемся на кошках.
Порисовал Lode Runer-а. Какой он есть, и каким я его хочу видеть. Задумывался о спецэффекте исчезновения экрана...
- - - Добавлено - - -
Порисовал Dizzy 5.
Как он есть, и каким он смог-бы стать.
С красными конечностями, конечно, при перерисовке графики (хакер-художник нужен :) ) и трёхцветных слоях, как в Метеоре у zst.
А по простому - с белыми конечностями, просто хакерскими методами. Дозволяла-бы карта, например, включить второй слой Иноземцева, и рисовать ГГ на нём.
- - - - - - - - -
Хотел 2 поста сделать, каждый со своими картинками, но робот сайта всё слепил в кучу.
Lethargeek
25.09.2016, 12:40
Предлагаю о легендарных, но примитивных играх вообще не заморачиваться (лоде рунер, джет сет вилли и т.п. маникминеры).
таким хватит и второго метода, есичо
Предлагаю вообще забить на игры 82-85 гг., рассматривать только начиная с 86 г. В нормальных играх ксор редко встречается, на ум токо диззи-1 приходит.
В тех же киберноидах тоже ксор. Он оправдан, если много мелких движущихся объектов, их тогда можно в разных кадрах перемещать, глюки-дырки из-за быстрого движения малозаметны (сильно режет глаз только на упавших призах).
С красными конечностями, конечно, при перерисовке графики (хакер-художник нужен ) и трёхцветных слоях, как в Метеоре у zst.
да не нужны ни слои для такой картинки, ни тем более переписывание кода (особенно как метеора)
таким хватит и второго метода, есичо
В тех же киберноидах тоже ксор. Он оправдан, если много мелких движущихся объектов, их тогда можно в разных кадрах перемещать, глюки-дырки из-за быстрого движения малозаметны (сильно режет глаз только на упавших призах).
да не нужны ни слои для такой картинки, ни тем более переписывание кода (особенно как метеора)
зачем? ну еще раз, при 7 Мгц, что максимум может клон, ему заботиться еще о фоне, слоях?
Lethargeek
02.10.2016, 02:04
зачем? ну еще раз, при 7 Мгц, что максимум может клон, ему заботиться еще о фоне, слоях?
ЧТО "зачем"? Зачем слои НЕ нужны? И при чём тут мегагерцы каких-то клонов. Даже не касаясь переделки старья, сколько новых игр выходит сейчас на Спеке? Ведь весьма прилично! А какие нестандартные режимы они поддерживают? Да практически никакие, разве только ULA+ у буржуев, а почему? Потому что людям лень фактически пилить две игры, под стандартный Спектрум и под расширенный (а выпускать только под расширенный смысла нет, аудитория никакая). Потому новая графическая железка получит софт лишь когда к ней (как к вышеупомянутой ULA+) легко и быстро можно адаптировать версию для голого стандартного Спека. А это значит - скорость и способ обработки пикселей должны быть аналогичны оригиналу.
ZX_NOVOSIB
03.10.2016, 10:58
Интересная мысль - zx-pk.ru/threads/915-interesnaya-mysl.html
blackmirror
03.10.2016, 13:07
Если делать устройство, не требующее изменение кода игры, а отслеживающее рисование спрайта и подставляющее нужную маску, по заранее загруженной конфигурации, то для получения маски можно поступить следующим образом:
1) делаем себе копию Z80 и его памяти и выполняем программу параллельно с ним, чтобы знать состояние внутренних регистров
2) в момент начала рисования спрайта(это определяем в конфигурации) делаем две копии памяти RAM0 и RAM1 и две копии Z80 - CPU0 и CPU1
3) для всех ячеек RAM0 и RAM1 устанавливаем битовые флаги, означающие что записи в ячейку с момента создания копий еще не было
4) запускаем CPU0 и CPU1 в ускоренном режиме до окончания функции рисования спрайта(тоже определяем в конфигурации)
5) при записи ячейки в RAM0 или RAM1 устанавливается соответствующий этой ячейке флаг
6) если CPU0 читают ячейку с экрана и в неё не было записи, то ему подсовывается 00, иначе данные берутся из RAM0
7) если CPU1 читают ячейку с экрана и в неё не было записи, то ему подсовывается FF, иначе данные берутся из RAM1
8) когда Z80 будет что-то записывать в некоторую ячейку экрана, смотрим соответствующие ячейки в RAM0 и RAM1, единицы в RAM0 и нули в RAM1 означают что эти точки были перезаписаны точками спрайта, значит их и нужно будет выводить.
В реальности полные копии памяти можно не создавать, можно сделать многоуровневые флаги, например 256 бит отвечающих за блоки ячеек по 256 байт и на втором уровне 256x256 бит отвечающих за отдельные ячейки. Очистили глобальные 256 флагов, значит память копии совпадает с памятью Z80, записываем что-то в ячейку, проверяем глобальный флаг, если еще не установлен, значит чистим 256 флагов на втором уровне, потом устанавливаем флаг ячейки. При чтении если флаг установлен, читаем данные из копии, если нет, то читаем из памяти Z80 или выдаём 00 или FF, если это чтение экранной области и в неё не было записи. Если Z80 что-то записывает в ячейку не попадающую в экранную область, которую CPU0 и CPU1 не перезаписывали, значит данные из неё нужно перенести в RAM0 и RAM1 и тоже поставить флаги.
В общем смысл в том, что при рисовании спрайта создаются два клона, один быстро рисует спрайт на экране из нулей, а другой на экране из 1, а когда дойдёт очередь до реального спрайта, уже будет ясно какие точки относятся к спрайту, а какие к фону. Возможно данный алгоритм сможет победить и рисование одиночных объектов в буфере, если можно пометить область откуда читается фон чтобы подсовывать 00 или FF, и перенос на экран будет достаточно оперативным.
Если делать устройство, не требующее изменение кода игры, а отслеживающее рисование спрайта и подставляющее нужную маску, по заранее загруженной конфигурации, то для получения маски можно поступить следующим образом:
ну в zxpoly создаются четыре клона, при таких объемах памяти и раскрашивании старых игр нет смысла париться с флагами и бороться с дубликацией, так как старая игра новые возможности юзать не начнет
Lethargeek
03.10.2016, 20:37
Если делать устройство, не требующее изменение кода игры, а отслеживающее рисование спрайта и подставляющее нужную маску, по заранее загруженной конфигурации
В общем смысл в том, что при рисовании спрайта создаются два клона, один быстро рисует спрайт на экране из нулей, а другой на экране из 1, а когда дойдёт очередь до реального спрайта, уже будет ясно какие точки относятся к спрайту, а какие к фону. Возможно данный алгоритм сможет победить и рисование одиночных объектов в буфере, если можно пометить область откуда читается фон чтобы подсовывать 00 или FF, и перенос на экран будет достаточно оперативным.
Ну зачем так сложно-то, ё-моё... :v2_dizzy_facepalm: Ведь достаточно одной лишь только "заранее загруженной конфигурации", где по найденным (весьма немногочисленным) адресам прописаны расширенные "восьмипиксельные" команды для выполнения устройством вместо оригинальных "восьмибитных" команд z80 (в том числе - любых команд отрисовки в буфер и переброски буфера на экран)
Ну зачем так сложно-то, ё-моё...
Затем, что минимизируется ПЗК (предварительно загруженная конфигурация). Нужно знать только адреса начала и конца вывода спрайта.
Но возрастает потребная вычислительная мощь карты.
- - - Добавлено - - -
Если-же расчитывать на более слабую карту. С неким навороченым, но ещё не придуманным, ПЗК 8-битных команд.
То и тут предложение blackmirror можно использовать в инструментах кроссплатформенной доработки игры. Я уже писал о мечте об инструменте, который позволит дорабатывать игру не программисту и не хакеру и даже не особо художнику, просто тыкая мышкой в экран.
Lethargeek
04.10.2016, 09:11
Затем, что минимизируется ПЗК (предварительно загруженная конфигурация)
вряд ли разница даже в несколько десятков байт (да и то не факт) имеет какое-то значение
а тем более - ценой потери тонкого контроля над отрисовкой на уровне пиксельных операций
важней время на работу по адаптации (и в основном оно уйдёт на трассировку и поиск кода)
Нужно знать только адреса начала и конца вывода спрайта.
вот тут неясно, что считать "началом и концом вывода"
у кода собс-но "вывода" может быть много веток, входов и выходов
если подниматься выше - дольше разбираться в коде придётся
и нагрузка на железо тоже растёт
Но возрастает потребная вычислительная мощь карты.
как минимум до уровня непрактичности (если не до невозможности вообще)
чего стоит одна только операция "сделать две копии памяти в момент начала рисования спрайта"
Если-же расчитывать на более слабую карту. С неким навороченым, но ещё не придуманным, ПЗК 8-битных команд.
То и тут предложение blackmirror можно использовать в инструментах кроссплатформенной доработки игры. Я уже писал о мечте об инструменте, который позволит дорабатывать игру не программисту и не хакеру и даже не особо художнику, просто тыкая мышкой в экран.
это как? если предварительно как раз и потребуется хакерскими способами найти "адреса начала и конца вывода" :)
в общем же на примере эмулей с раскрасками видно, что "нехакерская" доработка в принципе не всегда возможна
и может времени потребовать больше "хакерской"; а для начинающего хакера есть снапшоты и визуализация памяти
(вот где стоит поработать над большей наглядностью и удобством)
на примере эмулей с раскрасками видно, что "нехакерская" доработка в принципе не всегда возможна
Примеры, когда не возможна - в студию.
То и тут предложение blackmirror можно использовать в инструментах кроссплатформенной доработки игры. Я уже писал о мечте об инструменте, который позволит дорабатывать игру не программисту и не хакеру и даже не особо художнику, просто тыкая мышкой в экран.
ну дак в zxpoly я так и раскрашивал
https://raw.githubusercontent.com/raydac/zxpoly/master/docs/zxpoly_sprite_editor.gif
blackmirror
04.10.2016, 14:25
как минимум до уровня непрактичности (если не до невозможности вообще)
чего стоит одна только операция "сделать две копии памяти в момент начала рисования спрайта"
Не знаю на счёт мелкой логики, а для ПЛИС или программной эмуляции операция вполне реальная, чистить ведь только нужно флаги верхнего уровня, копировать небольшой блок памяти, чистить и устанавливать флаги на следующем уровне потребуется только при записи одним из процессоров. Для эмуляции на x86 очистка 256 флагов потребует всего трёх SSE-команд. При чтении нужно проверить два уровня флагов, чтобы определить можно ли брать данные из памяти клона, еще один флаг чтобы проверить не нужно ли подменить данные на 00 или FF и тремя командами cmov выбрать нужное значение. При записи проверяем флаг верхнего уровня, если не установлен, то ставим и очищаем 256 флагов нижнего уровня, потом проверяем флаг нижнего уровня, если не установлен, значит ставим и копируем ячейку в память клонов(возможно с подменой на 00 и FF), после чего спокойно записываем что собирались.
Но два клона для адаптации конечно слишком мало, если идти по пути ZX-poly, то инструмент для адаптации должен позволять сделать примерно следующее:
1) запускаем автоматическую трассировку, которая для каждой ячейки запомнит адрес команды которая её читала или записывала, после чего смотрим какие команды записывали в видеопамять.
2) смотрим код и находим начало и конец функций записывающих видеопамять, может тут придётся походить по шагам чтобы понять куда мы вернёмся и откуда оно вызывается.
3) просматриваем буфер трассировки и выясняем, какие ячейки читались командами относящимися к нашей функции, из них выкидываем все ячейки с переменными способными повлиять на выполнение функции, оставляем помеченными только массивы в которых могут быть спрайты.
4) создаём пару десятков клонов в зависимости от того, сколько требуется разрядов чтобы можно было адресовать все биты эмулируемого адресного пространства(если у нас 64К, нам достаточно 16+3 клонов, если 1Мб, значит 20+3)
5) в те биты, которые мы пометили как потенциальные спрайты, мы записываем их номера, по одному биту номера в соответствующий бит клона
6) запускаем клоны до конца функции и собираем из видеопамяти номера оказавшихся там бит, то есть ткнув в некоторую точку на экране мы можем определить откуда она здесь взялась
7) если на экран данные рисуются из какого либо буфера, значит по результатам трассировки нужно смотреть где он записывается, потом выяснять откуда, ну а дальше править биты, чтобы понять какие из них попадут на экран
В общем трассировка должна давать возможность для любой области памяти отслеживать откуда она читалась и/или записывалась, для группы или отдельных команд отслеживать откуда они читают и куда пишут. Еще нужно производить над полученными множествами логические операции, добавлять и удалять элементы, а так же создавать клоны и нумеровать биты из некоторого множества, чтобы можно было отслеживать их перемещения. В тот момент, когда мы смогли пометить все ячейки занимаемые спрайтами и пронумеровали их биты, для точки на экране можно определить откуда она взялась и перекрасить её в нужном спрайте.
Lethargeek
04.10.2016, 20:31
Не знаю на счёт мелкой логики, а для ПЛИС или программной эмуляции операция вполне реальная, чистить ведь только нужно флаги верхнего уровня, копировать небольшой блок памяти, чистить и устанавливать флаги на следующем уровне потребуется только при записи одним из процессоров. Для эмуляции на x86 очистка 256 флагов потребует всего трёх SSE-команд. При чтении нужно проверить два уровня флагов, чтобы определить можно ли брать данные из памяти клона, еще один флаг чтобы проверить не нужно ли подменить данные на 00 или FF и тремя командами cmov выбрать нужное значение. При записи проверяем флаг верхнего уровня, если не установлен, то ставим и очищаем 256 флагов нижнего уровня, потом проверяем флаг нижнего уровня, если не установлен, значит ставим и копируем ячейку в память клонов(возможно с подменой на 00 и FF), после чего спокойно записываем что собирались.
Второй уровень уже придётся в память писать, это 32 байта разом только для одного клона, а их ведь несколько, а потом при почти каждой записи кроме собс-но записи байта данных нужно соответственный байт флагов второго уровня прочитать-модифицировать-записать, да еще "в ускоренном режиме" (насколько ускоренном?), да еще для кучки клонов одновременно, а ведь всем им мало в плисину поместиться (кстати, сколько полных клонов z80 может влезть в недорогую сегодня?), шину-то одну на всех придётся делить. Нереально, даже эмуляция под вопросом.
И самое главное - зачем весь этот путь боли ради поиска графики в игре (да еще и с точностью до бита), когда уже после второго шага:
1) запускаем автоматическую трассировку, которая для каждой ячейки запомнит адрес команды которая её читала или записывала, после чего смотрим какие команды записывали в видеопамять.
2) смотрим код и находим начало и конец функций записывающих видеопамять, может тут придётся походить по шагам чтобы понять куда мы вернёмся и откуда оно вызывается.
...нам известны адреса отдельных команд, пишущих или читающих байты графики - "переводим" их в расширенную форму для "ПЗК" и в эмуле логируем адреса, с которыми они отработали (если графику потом раскрашивать захотим)
- - - Добавлено - - -
Примеры, когда не возможна - в студию.
Уже были - ксорки, атрибутные перекраски, set/res еще. Не, формально "доработка" возможна - в смысле просто цветов добавить, но результат выходит неполноценным.
Уже были - ксорки, атрибутные перекраски, set/res еще. Не, формально "доработка" возможна - в смысле просто цветов добавить, но результат выходит неполноценным.
Ну, set/res - это только векторные или точечные эффекты.
Lethargeek
05.10.2016, 10:41
в целом процедурная графика: генерация кустов-травы, например, или фоновой текстуры чисто из регистров; динамичные эффекты; возможно, grax
в целом процедурная графика: генерация кустов-травы, например, или фоновой текстуры чисто из регистров; динамичные эффекты; возможно, grax
Лучше привести примеры конкретных игр.
blackmirror
05.10.2016, 13:56
Lethargeek, для плис можно увеличить количество уровней, а блоки флагов во внешней памяти уменьшить хоть до байта, остальные флаги хранить в блоках памяти внутри плис, скажем на нижнем уровне 8192 блока по 8 флагов, остальное уже в плис - 512 блоков по 16 флагов, далее 32 блока по 16 флагов, а на верхнем уровне регистр в 32 бита. Доступ к памяти без клонирования будет требовать дополнительно(кроме операций внутри плис) только прочитать байт флагов, а запись с клонированием будет требовать RW для флагов и RWW или RWWW(если пишет Z80) для данных, то есть 5 или 6 операций. Цифра на первый взгляд дикая, но столько операций делает только один из клонов, остальные только две, поэтому если поделить на троих, получится в среднем около 3х операций.
Что касается количества клонов Z80 влезающих в плис, то реально требуется один полноценный клон, полноценный в том смысле, что выполняет программу параллельно с Z80, мы всегда знаем что у него в регистрах и можем создавать в нужный момент еще два клона CPU0 и CPU1 которые будут рисовать на фоне из 0 и 1 соответственно. Можно попробовать обойтись и одним клоном, который будет рисовать на инверсном фоне, и считать что к спрайту относятся совпавшие точки, но в этом случае будут сложности с определением спрайтов рисуемых в режиме XOR. Что касается того, насколько быстро должен работать клон, то это требуется только если из-за изменения фона выполнение программы пойдёт другим путём, например после сдвига перенос бита в другой регистр делается не через ADC, а через условный переход и INC, хорошо если к моменту записи на экран клоны тоже успели до этого дойти и мы знаем какие из записанных точек фон, а какие спрайт.
В реальности такой путь боли конечно не нужен, поскольку есть zx-poly и spec256, а эмуляция двух десятков клонов позволит отслеживать точки и раскрашивать для них спрайты прямо на экране. Можно даже попробовать отслеживать точки не изучая код игры:
0) запоминаем начальное состояние нашей системы
1) эмулятор выполняет программу и записывает в лог все выполненные инструкции и обращения к памяти(чтобы потом было проще, можно записывать полный адрес, с учётом всяких страниц)
2) далее начиная с начального состояния, эмулятор запускается в режиме воспроизведения лога, выполняя только операции записи в память, а когда в буфере экрана появится интересная нам картинка воспроизведение останавливаем
3) создаём 32 клона и в каждый бит записываем его номер (кроме тех областей из которых судя по логу выполнялся код) умноженный на некоторую константу, допустим на 419, чтобы нумерация поместилась в 32 бита, но не имела в памяти клонов регулярной структуры
4) в памяти сначала располагаем нулевые байты всех клонов, потом первые, вторые и так далее до конца их адресного пространства
5) запускаем воспроизведение лога, при этом для всех клонов повторяем указанные в логе команды используя SSE регистры, но для команд читающих и записывающих память используем адреса из лога
6) из флагов при воспроизведении можно эмулировать только флаг переноса, поскольку нужен для всяких ADC, а остальное слишком сложно поэтому нафиг
7) когда мы дойдём до интересной нам точки, то для каждого бита извлекаем из памяти клонов его номер умноженный на нашу магическую константу 419 и если полученное число нацело не делится, значит нельзя сказать откуда оно взялось, если число не менялось, значит в этот бит программа еще ничего не записывала, ну а если число изменилось, но делится на 419, значит мы точно знаем откуда оно здесь взялось
8) конечно, при таком упрощённом подходе, спрайт отражённый через таблицу отследить мы не сможем, но с другой стороны где-то он наверно выводился и в нормальном виде и воспроизведя лог до другой точки может получиться раскрасить и его
Hacker VBI
05.10.2016, 14:28
чуваки, вы это серьёзно?
давайте уже распаралеливайте всё ака нейросеть, чо
Lethargeek
06.10.2016, 10:49
Лучше привести примеры конкретных игр.
лучше быть богатым и здоровым и с кучей времени на поиск таких примеров)) сходу так из старенького - уже упомянутый здесь Thanatos, ядерная смесь из спрайтов (притом выводимых с выборочной очисткой фрагментов фона), векторной графики и атрибутной заливки (причём кривой, даже пробовал поправить её когда-то)
Можно даже попробовать отслеживать точки не изучая код игры:
...
вот, ей-ктулху, проще код немного поизучать :D
лучше быть богатым и здоровым и с кучей времени на поиск таких примеров)) сходу так из старенького - уже упомянутый здесь Thanatos, ядерная смесь из спрайтов (притом выводимых с выборочной очисткой фрагментов фона), векторной графики и атрибутной заливки (причём кривой, даже пробовал поправить её когда-то)
Под такой частный практически единичный случай затачивать всю систему нет смысла)
Lethargeek
06.10.2016, 20:15
Под такой частный практически единичный случай
Этот "случай" - сочетание (пусть и редкое) не таких уже и редких отдельных случаев. Та же выборочная чистка фона применяется и в чисто спрайтовых играх для снижения заметности клэшинга (очевидные примеры типа trapdoor) и перспективна для создания новых игр. Это процедурный эффект, нежелательный после раскраски спрайтов и неустранимый только лишь перекраской.
затачивать всю систему нет смысла)
Смысла нет затачивать систему под частный случай, когда есть общее решение многих случаев.
blackmirror
06.10.2016, 22:06
Смысла нет затачивать систему под частный случай, когда есть общее решение многих случаев.
И какое здесь общее решение? Можно растащить спрайты и векторную графику по слоям, можно сделать очень много слоёв, хоть 256, хоть 512, можно даже маски полуавтоматически вытаскивать, заставляя программу рисовать в пустом буфере и считая всё что за краями спрайта прозрачным, но вот перекраска 64 точек при изменении атрибутов оптимизма не внушает. Или такое безобразие нужно оставлять в слое со стандартным экраном?
Lethargeek
06.10.2016, 22:39
И какое здесь общее решение? Можно растащить спрайты и векторную графику по слоям, можно сделать очень много слоёв, хоть 256, хоть 512, можно даже маски полуавтоматически вытаскивать, заставляя программу рисовать в пустом буфере и считая всё что за краями спрайта прозрачным, но вот перекраска 64 точек при изменении атрибутов оптимизма не внушает. Или такое безобразие нужно оставлять в слое со стандартным экраном?
много раз уже повторял - атрибут на пиксель, слоёв не нужно
перечитай здесь мои последние сообщения и эти старые из темы про метеор:
http://zx-pk.ru/threads/21462-bystraya-videokarta-quot-meteor-2013-quot.html?p=869225&viewfull=1#post869225
http://zx-pk.ru/threads/21462-bystraya-videokarta-quot-meteor-2013-quot.html?p=870718&highlight=#post870718
Выложите готовые прототипы с примерами, посмотреть интересно...
Выложите готовые прототипы с примерами, посмотреть интересно...
По-моему результат обсуждения в этом треде свелся к тому что "слои" добавленные поверх zx экрана дело безперспективное, потому что:
1) нет скорости у z80 их обслуживать;
2) с ними потенциально можно упростить вывод одноцветных спрайтов но данная фича неактуальна (2016-й год на дворе);
3) переделка программ путем 100% замены процедур вывода на экран + самой графики сложнее, но дает возможность использовать ЛЮБОЙ видеоадаптер.
Lethargeek
19.10.2016, 09:59
3) переделка программ путем 100% замены процедур вывода на экран + самой графики сложнее, но дает возможность использовать ЛЮБОЙ видеоадаптер.
здесь как раз от нужности масштабной переделки уйти хотели
должна быть только необязательная возможность
сейчас некогда, но скоро напишу и примеры
Господа, я не смог дочитать это до конца, но вы мучительно изобретаете IBM EGA и слизанную с него в сильно упрощенном виде видеосистему Корвета.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot