Тогда можно цвет и через порт задавать, не делая несколько плоскостей, как выше написал. Разве что, можно сделать одну плоскость на фон и одну на все спрайты с прозрачным цветом. Будет задаваться цвет и прежней процедурой выводиться однобитная картинка, получая нужный цвет.Сообщение от inozemcew
проблема векторной реализации в том что что спрайты нарисованные в одном плане однобитные без маскиТак вы и предлагаете по сути нечто похожее на векторовскую реализацию. Там тоже при разбивке на слои получается по 1 цвету на однобитный слой. Но там немного проще оперировать со слоями. Разве что, самый нижний слой будет уступать по количеству цветов вашей реализации.Можно даже просто взять 4-8 битовых планов и обычную палитру, и затем заполнив эту палитру специальным образом, получить псевдополупрозрачные слои. Именно так это делается на "Векторе". Плюс еще там 16-256 цветов на точку и т.д. и т.п.
чтоб нарисовать разноцветный спрайт с маской придется отрисовывать спрайт несколько раз в разных планах(переключать банки\пересчитывать\изменя ть адреса)
более интересный вариант был бы
4 плана по 2 бита на точку в каждом
но а дальше все как у вектора
в итоге было бы 4 плана со всеми преимуществами вектора
всякими масками\полупрозрачностям
и возможность быстро отрисовывать многоцветные спрайты
правда проблема что в конечном итоге
на один слой всего по 3 цвета палитры
и 4 цвета для фона
что как то маловато...
вторая проблема чтобы оставить совместимость с адресацией спековского экрана
придется уменьшить количество пикселей по горизонтали (широкие комодорские пиксели).
и нужно будет переписывать все процедуры отрисовки спрайтов тк теперь один байт экрана на 4 широких пикселя
Можно конечно, но..
Во первых, потребуется как минимум 4 бита дополнительно на каждый пиксель. Так что сильно сэкономить на памяти не получится.
А во-вторых, самое неудобное, после вывода изображения этим способом, понять какая точка имеет какой цвет невозможно. Допустим два спрайта накладываются по XOR. Теперь один спрайт надо стереть. Делаем еще раз вывод по XOR, но как понять, какого цвета должны быть восстановленные пиксели - цвета фона или цвета заданного по OUT? Тоже самое для процедуры вывода спрайта, которая запоминает пиксели под спрайтом в буфере - например рисование указателя мыши. Когда курсор рисуется в отдельном слое - никаких проблем, даже восстанавливать ничего не надо. Но как вы восстановите пиксели, цвет которых не знаете?
4 плана по 2 бита на точку в каждом но а дальше все как у спектрума - атрибут на знакоместо, но для каждого плана свой. У вектора цвет точки определяется комбинацией битов в 4 планах. Такое не нужно. Нужно определить, точка какого плана является видимой, вот из этого плана и взять атрибут - это и будет цвет точки.
На спектруме нет многоцветных спрайтов. Ждать, что их кто-то раскрасит, как показывает практика, можно до 2го пришествия.
Это тоже ненужно. Как раз запись маски можно сделать через порт, это сработает, в отличие от вывода цвета через порт.
так (относительно) легко-то потому что тайминги те же самые
а тут надо вдвое больше тянуть из памяти, то есть либо дорогую быструю память, либо параллельные банки, что снижает надёжность (а Спек и так сперва не отличался большой надёжностью) и удорожает настройку (что в конечном итоге выливается в повышение цены и противопоказано массовому производству), да и самой памяти нужно больше (а Спек начинался с 16кб)
- - - Добавлено - - -
всё я понял, написал же сразу:
для игр, пишущих атрибуты перед пикселями, достаточно таким (одним) портом считать всю область атрибутов памяти Спека
для пишущих атрибуты после - либо изменить порядок вызова процедур, либо сначала явно цвет устанавливать, либо сочетать
плоскости для этого не нужны, и активные два цвета можно выбирать любой разрядности, как девайс по максимуму сумеет
Прихожу без разрешения, сею смерть и разрушение...
Почитал повнимательней(бегло пробежался глазами).
Способ конечно интересный.
Хотя как задается цвет для спрайтов я не увидел (не дочитал)
но предположу что или для каждого слоя своя палитра из 2-х цветов
или что палитра задается как то перед отрисовкой спрайта
тогда для простоты адаптации нужно
дополнительный порт для конфигурации
- выбор типа маски 00111100 и инверсная 11000011.
- выбор обнулять регистр маски после записи или нет (не всегда же нужно и быстрее)
- как\чем "обнулять" регистр маски 00000000 или 11111111 или это должно определятся на основе выбора инверсная\не инверсная маска
дешифрация порта маски должна быть по младшим 8 битам
для быстрого засылания туда значений при помощи out ($**),a
так как занимать BC для дополнительного out-а сильно жирно
и все вроде бы хорошо
а теперь вопрос как теперь стирать и перемещать то что нарисовано где то там в слое который отображается поверх?
или нули маски будут и стирать содержимое слоя при повторной записи?
а еще нужно чтоб спрайты не мигали поверх фона
и тут вся эта конструкция начинает внезапно увеличиваться в размерах
уже нужен как минимум 2-й экранный буфер
и больший разбор и изменение кода
и в конечном итоге под этот новый видеорежим
придется переписывать весь вывод графики
хотя вот какая нибудь automainia переделается на ура
но оно того стоит??
и есче
что делать с играми которые сначала рисуют в бекбуфер?
а потом быстро перекидывают экран
сам буфер может быть и вверх ногами))
есть игры которые рисуют в бекбуфер
несколько слоев графики
а потом сверху игрока
а потом переносят на экран только несколько знакомест с изображением игрока
и все в буфере вверх ногами при этом)))
это сколько нужно будет найти и переписать...
и кто это будет делать?
это только на первый взгляд кажется что там подменить процедуру вывода и все
на практике вылезет столько подводных камней...
с таким же успехом все это проще переписать под тсконфу
но под неё что то особо никто ничего и не адаптирует
и сколько будет этих девайсов 10? 15?
3Ы: а тем временем spec256 конфа пилиться, вроде как, для ReVerSE-U16
а разукрашивать игры под неё...
Последний раз редактировалось NEO SPECTRUMAN; 21.08.2016 в 00:25.
Все проще. У каждого слоя своя область атрибутов. Цвет спрайта берется оттуда. Перед отрисовкой спрайта цвет задавать не обязательно, можно сделать это и после.
- всегда инверсная, которая накладывается по AND.
- обнулять обязательно, в смысле заносить 11111111. При чтении байта из пикселей слоя заносить маску в регистр маски. При записи в порт маски, складывать старое и новое значение по AND. Это позволит выводить несколько спрайтов в один слой.
- дополнительный порт для конфигурации не нужен.
Очевидно, запись байта в более нижний слой должна обнулять байты вышележащих слоев. Но, думаю, достаточно только очистки спрайтовых слоев при записи в слой фона.
Ничего. в бекбуфере нет информации о том какому объекту какой пиксель принадлежит. Как это обойти, я, к сожалению, не знаю.
Безусловно. Без предварительной обкатки на эмуляторах не и речи о воплощении всего этого в железе.
Дополнительные изменения в код, понятно.
так без них в общем случае никак не получится, потому важно, чтоб эффект от изменений был наибольшим
и в зависимости от оригинального кода вплоть до 100% изменений можно вынести в отдельный загрузчик
Прихожу без разрешения, сею смерть и разрушение...
нужен нужен- всегда инверсная, которая накладывается по AND.дополнительный порт для конфигурации
- выбор типа маски 00111100 и инверсная 11000011.
- выбор обнулять регистр маски после записи или нет (не всегда же нужно и быстрее)
- как\чем "обнулять" регистр маски 00000000 или 11111111 или это должно определятся на основе выбора инверсная\не инверсная маска
- обнулять обязательно, в смысле заносить 11111111. При чтении байта из пикселей слоя заносить маску в регистр маски. При записи в порт маски, складывать старое и новое значение по AND. Это позволит выводить несколько спрайтов в один слой.
- дополнительный порт для конфигурации не нужен.
процедура рисования спрайта может
как брать байт из экрана 10101010
делать and 11000011 маска
и or 00011000 спрайт
так и с точностью на оборот
делать or 00111100 маска
и and 11100111 спрайт
понадобиться находить и менять сами спрайты и их маски
а это может вызвать дополнительные проблемы и артефакты (я как то ужо инверсировал графику в игре...)
а если вся графика запакованная?
для облегчения работы не помешал бы порт конфигурации
не обязательное обнуление позволит немного оптимизировать\ускорить отрисовку
зачем каждый раз засылать маску если процедура печати её, к примеру, по просту не меняет
например она вот такая
11110000
11110000
11110000
11110000
11110000
11110000
11110000
11110000
- - - Добавлено - - -
а почему при этом спрайты не будут мигать поверх фона?
а они будут мигать
то есть на уровне каждого слоя будет свой клешинг??
не в принципе терпимо
Позвольте не согласиться. ИМХО важнее всего минимум изменений в коде - максимально возможная адаптация под имеющийся софт.
Честно говоря, такого не встречал. Но, в принципе, учесть такой вариант можно. Только никаких портов конфигурации. Достаточно, скажем, установить старший бит в номере слоя.
Вообще-то, никто не проверяет "а не изменилась ли маска?", лично я такого не видел. Проще взять и вывести, чем проверять.
Не будут. В оригинале же не мигают. Значит авторы игрухи уже позаботились, чтобы отрисовка шла в нужный момент.
В каждый слой выводить спрайты одного цвета. Отсюда больше 16 слоев нужно разве что чисто теоретически.
Ой, а с клэшингом зачем бороться тогда, раз единственный критерий - абсолютно минимальные изменения? С ним-то изменений вообще не нужно))) Или всё-таки эффект имеет значение, но тогда он должен быть наибольшим для любого уровня переделки. Кстати, чем это выбор слоя перед печатью спрайта "минимальнее" выбора активного цвета? Ведь фактически выбор слоя - тоже способ выбора цвета, только неинтуитивный и расточительный.
Прихожу без разрешения, сею смерть и разрушение...
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием