Люди, вы хоть итожте в каком-то посте текущие наработки) А то сложно понять весь смысл предлагаемой конструкции, размытый по десятку страниц)
Люди, вы хоть итожте в каком-то посте текущие наработки) А то сложно понять весь смысл предлагаемой конструкции, размытый по десятку страниц)
Сообщение от Lethargeek
нада отдельная тема со списком ускоренных игр
Lethargeek, Мне кажется ты сильно упрощаешь "слежение за шиной". Рассмотрим типичную ситуацию отзеркаливания байта через 256-байтный буфер. Я не представляю, как "следильщик за шиной", не имея искусственного интеллекта, правильно отзеркалит цвета.
Вот в ZX-Poly всё понятно. Каждый из 4 процессоров свой байт отзеркалит через таблицу, и всё правильно получиться.
А мне кажется, что ты снова путаешь отрисовку и переброску буфера (каковую в принципе вовсе лучше поручать блиттеру). Зеркалирование относится к отрисовке, а там всё зависит от особенностей реализации (может, маска зеркалится отдельно и всё двухцветное) и можно явно устанавливать режим вывода (в данном случае - с разворотом полосок пикселей).
Зато непонятно, как поступать с атрибутными эффектами или ксоркой (и даже с возможностью рассинхрона, если вдруг пиксель проверяется через флаг). У каждой схемы есть какие-то недостатки.
Прихожу без разрешения, сею смерть и разрушение...
Предлагаю составить список задач и типов вывода графики, которые надо учитывать при разработке метода устранения клешинга и раскраски. Например:
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 на каждый новый слой? Откуда взять дополнительную скорость\память для этого?
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Эти вопросы, я задавал еще в самом начале топика.
В таком виде, для отображения не слишком многоцветной картинки в пределах одного знакоместа - можно использовать несколько "дополнительных" экранов. Но, ТС периодически заводит речь о спрайтовых экранах, наложении, масках и громоздкости цвета на точку. Напомню, при реализации через стандартные экраны с атрибутами знакоместа - для отображения всех базовых цветов нужно 16 экранов - на каждый цвет и режим яркости (это при самом "худшем" варианте).
Последний раз редактировалось null_device; 19.09.2016 в 05:29.
Когда есть, но не знаешь где - это все равно, что нету.
Не согласен.
Вариантов вывода весьма ограниченное число, под которое попадет 99.9% игр.
Их надо понимать, и лучше иметь список.
Не требует. Вряд ли единицы мегабайт RAM можно считать большим аппаратным ресурсом.
Как раз наоборот, трудозатраты минимальны, графика и процедуры остаются родными.
Что значит худшего качества? Картинка, в рамках поставленной задачи, может быть одна - как в Спектруме, только без клэшинга.
Польза от расширений, софт для которых будет написан "потом" - имхо, сомнительна.
Ну уже упоминавшийся RamboIII, да остальные игрухи от Andrew Deakin - Athena, RenegadeIII, Adams Family etc. тоже сделаны на этом принципе. Да и все, что имеет статический фон, тоже выгодно делать таким образом. Экономия памяти и процессора. Памяти под буфер нужно не на весь экран, а только по размеру спрайта. А разворачивать фон из тайл-мапа, даже по размеру объекта - процессор просто не успевает.
Это что получается, надо взять фон, перенести его в буфер, нарисовать сверху спрайт и то, что получилось перенести в экран? Но зачем эти лишние движения, если фон уже на экране, а все, что надо это сохранить кусочек фона в буфере и нарисовать спрайт?
Вы упорно не замечаете простой вопрос: "как стереть спрайт не перерисовывая всё?" Если вы будете спрашивать, "Зачем это нужно?" - стразу ответ: существующие игры так делают.
Вот смотрите есть процедура вывода курсора мыши. Она работает до смешного просто. В буфер запоминается фон из того места экрана, где будет выводиться спрайт стрелочки. Затем рисуется стрелочка, с наложением на фон. В следующем цикле из буфера в экран возвращается сохраненное изображение, стирая курсор мыши, и цикл рисования повторяется в другом месте.
Теперь у нас есть экранные слои. Что надо поменять в данном алгоритме? Всего две вещи. Перед процедурой устанавливаем активным слой 1. Дальше, таже самая процедура читает нули из экрана (потому, что стандартное изображение находится в 0м слое, а в 1м слое кроме изображения курсора мыши у нас никогда ничего не бывает) , как и раньше, сохраняет эти нули, думая, что это фон, в тот же самый буфер, и рисует спрайт стрелки, точно так же, как и раньше, даже не подозревая, что он попадет не на фоновое изображение, а в пустой слой №1. Всё, устанавливаем активным 0й слой и возвращаемся в основную программу. Спрайт стрелки будет виден над основным изображением, без всякого клэшинга. Теперь, чтобы спрятать курсор мыши, устанавливаем активным 1й слой и вызываем старую процедуру стирания. Она как и раньше перенесет в экран из буфера нули, думая, что это сохраненный фон, тем самым сотрет изображение стрелки. Делаем активным слой 0, возвращаем управление основному коду.
Как видите, все изменения - только в переключении слоев до и после отрисовки. Все остальное остается неизменным.
Хотелось теперь услышать от вас, как вы собираетесь адаптировать этот же алгоритм мышиного курсора под свою систему.
- - - Добавлено - - -
Точно. Слой - это обычный спектрумовский экран с прозрачным PAPER. Таких экранов несколько, они находятся друг над дружкой, поэтому для них предпочтительнее термин "слой". Нижние "просвечивают" через прозрачный PAPER верхних. Текущий доступный для процессора экран(слой) переключается значением в порт. Переключение в стандартной области $4000-5AFF. Переключение на отображение не влияет никак, только на доступный для чтения/записи экран(слой). Самый нижний, нулевой слой - стандартный экран (т.е. с непрозрачным PAPER и с FLASH) Вот такая упрощенная схема.
Нет количество байт для программы не меняется. То, что рисовалось на одном стандартном экране, теперь разносится по слоям, но общий объем выводимой графики не меняется (за исключением мелких нюансов).
- - - Добавлено - - -
Задача не в том, чтобы нарисовать 16 цветную картинку. Согласен, для этого 16 слоев не самый лучший способ.
Задача - устранить клэшинг в существующих программах с минимальными усилиями и без перерисовки графики.
Почему так часто упоминаются спрайты? Так, если фон еще как-то можно распределить с учетом знакомест, то со спрайтами дело совсем плохо. Поэтому основной упор в деле борьбы с клэшингом и делается на спрайты.
Titus, Как будем составлять список?
Каждый будет предлагать свой вариант?
Предлагаю свой:
Техники вывода графики, приводящие к клешингу, и возможные решения.
1) XOR - спрайты. [Lode Runner, Dizzy_1] Решается ZXInno 0.1- однобитный слой Иноземцева. Работа_Z80 не меняется.
2) Спрайты с маской. [RamboIII - персонажи, Dizzy_2..6..] Решается ZXInno_0.2 - двубитный слой Иноземцева - цвет с маской. Работа_Z80 плюс минус. (маску можно не накладывать/вычислять, если один спрайт на слой или спрайты на слое гарантированно не пересекаются, но маску нужно отдельно передавать в видеокарту)
3) Отрисовка фона по знакоместам [RamboIII - бочки на полу] Нужно вводить дополнительную информацию. ZX-poly, spec256, colorBit от Lethargeek-а и некий мифический ZXprop.
Тяжкие обстоятельства.
1) Предварительный вывод в буфер.
2) Упакованная графика фона.
Да, Titus, как смог написал, что в голове крутилось.Надеюсь другие расширят и дополнят.
(Всё время забываю написать про уровни, но подразумеваю их)
Последний раз редактировалось Reobne; 20.09.2016 в 12:59. Причина: добавил ссылку
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
