Когда есть, но не знаешь где - это все равно, что нету.
Не-не.. Скорее Векторовские битпланы.
Конечно, маска спрайта. Совершенно правильно, имеется два варианта. Либо выводим в нижележащий слой как обычную маску, либо в промежуточный слой, как черный спрайт. Ничего тут стремного нет. В каждой игрушке, использующей маскИрованные спрайты такая процедурка есть. Единственное, это когда вывод спрайта и маски делается сразу для каждого отдельного байта. Тут надо или немного изменить процедуру вывода и разнести вывод маски и спрайта (по процессорному времени это будет практически одинаково), либо да, таки переключать плоскости. Тут можно придумать, для ускорения процесса, триггер четный/нечетный, который будет менять плоскости n и n-1 через каждый записанный байт.
Мощьность для чего? Чтобы сделать OUT (порт),<плоскость для спрайта>? Так ее не очень и много-то надо
Расставить OUT (порт),<плоскость для спрайта> перед процедурой вывода спрайта. Достаточно STSа, даже дизасемблер не нужен.
- - - Добавлено - - -
Да, 8 битная память тут никак. Для 4 слоев надо уже 32 бита.
Позиционный шифратор и мультиплексор, чтобы из 2,4 или 8 INKов выбрать один.
и для этого тоже и для того что цпу надо будет пересылать гораздо больше байт памяти чем он привык и для чего расчитан, так как цвета из ничего не бываютМощьность для чего? Чтобы сделать OUT (порт),<плоскость для спрайта>? Так ее не очень и много-то надо
Кто будет извлекать данные из памяти для построения картинки на экране? В обычном спектруме, чтением данных и атрибутов из памяти - этим занимается процессор z80.
Основное, что мне в этом методе "не нравится" - он не обеспечивает "честного" режима цвет-на точку в пределах знакоместа. Т.к., для него - слоев надо, минимум 8! И, вот тут мы подошли к вопросу, относительно атрибута знакоместа - яркость... как быть с ним?
Последний раз редактировалось null_device; 14.08.2016 в 16:22.
Когда есть, но не знаешь где - это все равно, что нету.
Любое изменение программы - условно равносильно написанию новой программы.
Поясню мысль: чтобы вставить что-то куда-то - надо найти свободное место.
значит в то место где нужно вставить OUT надо будет вставить CALL на свободное место где будет исходный кусок программы (как минимум 3 байта) + OUT + RET.
Есть другой вариант: дизасм всё и вся, и сборка обратно.
Кто эти будет заниматься ?
Чисто аппаратными средствами (без изменения программы) не добиться результата...
Посему "новый вариант устранения клешинга" - это фикция.
Реально борьба с клешингом - это создание физически другого компьютера и написание нового софта. Другого способа нет и не будет.
Кому "нужен" такой "новый вариант устранения клешинга" ?
Последний раз редактировалось AlexG; 14.08.2016 в 16:32.
AlexG, насколько я понял, целью и было:
А также: возможностью запуска старых программ без получения "недокументированных эффектов" на экране. Написании "новых" с учетом, изобретенной "мульки" и правка "старых" программ, насколько это возможно и оправданно - без обратной соместимости.
Когда есть, но не знаешь где - это все равно, что нету.
запуск "старых" оригинальных программ на другом железе для устранения клешинга не возможна без модификации "старых" программ.
вот и получаем "новые" программы на другом железе...
На ПК уже давно нет клешинга
В чём профит этого "нового способа" ??? если всё "новое" должно быть ? с таким успехом можно взять любую другую платформу и писать на неё программы сразу без клешинга.
Я могу в теории написать (портировать) любую игру на ПК и "вуаля - клешинг отсутствует"!!!
были ж программы портированые на атари коммнодоре спектруме.
В чём новизна(идея) сего "патента"? в том что "новыми словами" описываются уже существующие реалии ?
Дык это попахивает плагиатом...Какая здесь борьба за нравственную чистоту ?
Почему-то это напоминает мне "палату №6", ну или комплекс наполеона...
Сорри за оффтоп. По мне тема высосана из пальца и к "физической реализации не пригодна"
Последний раз редактировалось AlexG; 14.08.2016 в 17:14.
Не-не-не.. все намного проще.. Никто никуда ничего дополнительно не пересылает.
Как это работает в обычном спеке? Сначала рисуется фоновый лес и заливается атрибутом с зеленым INKом, правильно? Потом, на фоне этого леса рисуется персонаж и атрибуты поверх него устанавливаются в белый, с соответствующим клэшингом. Что предлагается, прежде чем рисовать героя надо переключить экранную плоскость, дальше все тоже самое - рисование спрайта, установка атрибутов, где тут дополнительные байты для пересылки?
Весь фокус в том, что обычном спеке прорисовка экрана под персонажем происходит дважды. Сначала рисуется фон и его атрибуты, а потом он же затирается спрайтом героя и его атрибутами. Идея ж в том, что при том же объеме данных, они не затирают друг друга, а идут в разные плоскости, что и позволяет разрулить клэшинг.
А разве это требовалось? Суть задачи - убрать клэшинг с максимально возможной совместимостью с существующим софтом.
Вы ошибаетесь. Изменения, которые потребуется внести, ничуть не сложнее, скажем, переделки записи сохранения на ленту под ТР-ДОС.
- - - Добавлено - - -
А что за проблема с ним?
На каждом слое мы имеем в области цветовых атрибутов бит яркости и мерцания. Для стандартного экрана спектрума они задаются для всего знакоместа. Как они будут интерпритироваться в вашей реализации?
Как минимум, нужно вместо записи в одну область памяти, "щелкать" портом - переключая слои и пересылать туда данные. При этом, надо выводить ОДНОВРЕМЕННО (либо, квазипараллельно - не суть) состояние всех слоев в виде точки растра на экране (существенную часть времени, процессор спектрума, занят именно этим). Техническая реализация, подразумевает, что отрисовка всех слоева будет укладываться по тактам в процедуру вывода стандартного экрана.
Когда есть, но не знаешь где - это все равно, что нету.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)