Descent - демо игры с 8-цветными спрайтами для УКНЦ

[BlaireCas]

Если заменить
add R4, R5

Вот да, для центрального проца (где в два плана надо записать) надо будет пожертвовать регистр на разделение адреса масок и адреса цвета. А для периферийного один план и как сейчас вроде ок.

при четном - словами вместо байтов (тут нужны будут альтернативные таблицы сдвигов)

Думал думал, но не придумал ничего. Видел такое разделение у manwe кажется в демке вывода спрайта для БК (как мне показалось). Но пока-что даже не знаю..

[Titus]

Разница в отображении? Наверное никакой нету. Только дефолтно EmuStudio "скушивает" последние 8 (что-ли) строк экрана и приходится жать shift-del чтобы они показались. А также сканлайны конечно винтажны, но для разработки мешают (без них пиксели виднее что-ли). Поэтому приходится два раза еще и жать ctrl-del.
А какая еще разница? Звука нет, дебага нет, да это думается ты знаешь-же. (в UKNCBTL еще и в восьмеричной системе всё в дебаге, что нереально удобно).

Это я знаю) Это разница в минус)
Я думал, что ты запускаешь на EmuStudio за каким-то плюсом)

[reddie]

спрайты можно прешифтить заранее, анимацию заранее со сдвигами заготовить

Такой вывод будет самым быстрым, но хватит ли памяти? Киньте ссылку почитать про организацию страниц на УКНЦ.
Пока нарыл, что памяти всего 192к, под видео три битплана (переключаемые страницы) по 32к, а как остальная память распределена?

[BlaireCas]

запускаешь на EmuStudio за каким-то плюсом

Плюс вполне есть - он быстрее, раз. Кнопку "запуск" не надо жать два.
В VS Code настроил компиляцию всего, закидывание в диск и запуск emustudio - вполне быстро и кошерно заценить сразу что накодилося.
UPD: еще нашел почему лучше - ниже написал про 177054 в ПП. ukncbtl чего-то все-же ведет себя кажется неправильно при подключении доп. ОЗУ

организацию страниц на УКНЦ

Увы, там нет страниц если в том плане как это сделано на спеке/бк0011/других компах той поры. Кстати дополнительная память вовсе не под видео. Она просто ну как-бы есть. Таблицей видеострок обычно отображение экрана назначают на нее, но это не прям обязательно, ее можно использовать, но неудобно (там не выполнить код, методы доступа к ней тоже не блещут скоростью).

Центральный процессор видит свои 64кб и для доступа к ней-же + дополнительным 64кб памяти делается mov #addr/2, @#176640 и потом по адресу 176642 делаешь что-то с двумя байтами адреса addr. То-есть поскольку addr/2 то ЦП может через этот регистровый механизм "полазить" по 64кб своего + 64кб дополнительного ОЗУ. (ну по своему ОЗУ смысла так лазить нету, а вот по адресам выше 177777 вполне нормально, обычно туда через таблицу строк назначают цветовые планы 1,2 для отображения на экран и через такой костыль он с ними работает)

Периферийный процессор аналогично только адреса регистров другие (177010(addr/2), 177014(data) - аналоги тех двух в ЦП, через них он лазает по всему ОЗУ ЦП + еще байтовый 177012 - через него можно добраться до последних 32кб дополнительного ОЗУ в которые не может попасть ЦП).

Еще в периферийном процессоре можно выполнить команду mov #161, @#177054 - тогда эти дополнительные 32кб ОЗУ отобразятся на адреса 100000-157777 периферийного процессора, но с одним приколом - туда можно будет записывать, а считывать оттуда не получится ибо по стечению обстоятельств ПЗУ не отключается и оно работает на чтение быстрее и читаться будет из ПЗУ + возможно складываясь по OR с ОЗУ.
Например отобразив так память в ПП команда bis #123, @#100000 сделает веселый результат - она считает с ПЗУ, установит бит, и запишет итог в ОЗУ.
Кстати этот момент упущен в эмуляторах (!) если еще не пофиксили. В эмулях было так что при отображении в ПП дополнительного ОЗУ на обычные адреса памяти - можно было и читать с него что на реальной машинке не прокатит.
UPD: проверил - в emustudio вроде пофикшено, в ukncbtl кажись бага на месте

[reddie]

там нет страниц если в том плане как это сделано на спеке/бк0011/других компах

А жаль, это бы решило проблему быстрого вывода "чуть более, чем полностью" (с)
То есть, получается, для кода каждому процу условно доступна половина адресного пространства (32К), а вторая - под экран?
Как там организованы эти битпланы, все равно не въеду... Разрешение 640х288 (плюс служебка) это, по идее, 2 цвета на точку (1 бит/пиксел), что и дает около 32к.
Соответственно, основной проц может полноценно работать только с одним битпланом, а остальные через "костыли"/ППроц ?

[jerri]

Было-бы интересно просто на словах.
Допустим берем только один цвет (не все 8). Как в спеке пусть будет. 8точек = байт. Есть спрайт+маска (2 байта). Есть фреймбуфер и там бекграунд.
Вроде особо много чего тут и не придумать. Сдвигаем байт маски на нужное число пикселей либо через таблицы либо командами сдвигов (таблицы быстрее). Получаем два байта, маскируем их в буфере. Повторить то-же самое для байта цвета.
Затем измененные части буфера на экран и вернуть буферу исходное состояние.
Где-то в деталях (навроде спрайты можно прешифтить заранее, анимацию заранее со сдвигами заготовить) могут быть различия, но вроде алгоритм какой-то такой

Соответственно для 4-х цветов будет все это повторено для фреймбуфера 2-го цветового бита, для 8-ми цветов еще и для третьего цветового бита. Поэтому общую задачу достаточно решить только для 1-битного цвета для начала видимо (ну в УКНЦ вообще без вариантов ибо один из цветовых планов экрана может рисовать лишь второй процессор)

все правильно.
шифт в регистрах дорого по времени, шифт в таблицах лучше.
прешифт спрайтов гораздо выгоднее, но его надо делать с умом.

вот например есть анимация персонажа.
4 фазы движения в сторону, одна фаза прыжка.

берем имеющиеся спрайты и смотрим
раскатываем спрайты движения и получаем 4 фазы анимации с шифтом в 2 точки.
берем фазу прыжка и также шифтим.

итого вместо спрайтов 16*16*5 штук.
получаем 16*24*8 штук. при этом получая значительный привес по скорости.

дальше движение в другую сторону
можно получать разворачивая спрайт через таблицу.

с учетом 3х битпланов спрайта и 1 битплана маски
выгоднее по скорости будет держать 2 битплана спрайта развернутыми.

как то так.

[reddie]

получаем 4 фазы анимации с шифтом в 2 точки

Это уже небольшое ограничение получается, т.к. вывод будет не попиксельный, а через пиксель, плюс"остановка" персонажа будет строго по нулевому сдвигу.
Он будет как бы шагать по знакоместам, если перевести на спектрумовский язык. Для большинства ситуаций подойдет, тут главное разрабатывать фон (карту) с учетом этого.
Только и прыжки придется привязывать к знакоместам, иначе собьется расстановка фаз основной анимации.
Впрочем, это будет максимально быстрый вывод из всех возможных, что перевешивает недостатки. Вопрос лишь в размере доступной памяти под спрайты.

[jerri]

Это уже небольшое ограничение получается, т.к. вывод будет не попиксельный, а через пиксель, плюс"остановка" персонажа будет строго по нулевому сдвигу.
Он будет как бы шагать по знакоместам, если перевести на спектрумовский язык.

ну скажем так. идеальное движение - попиксельное, поэтому движение на 50 точек за 1 секунду смотрится плавным.
При темпе игры в 25 фпс движение спрайта на 1/256 или 1/320 экрана производит ощущение тормознутости.

не надо привязывать знакоместное движение к спектруму - это было до, и было после.

Для большинства ситуаций подойдет, тут главное разрабатывать фон (карту) с учетом этого.
Только и прыжки придется привязывать к знакоместам, иначе собьется расстановка фаз основной анимации.

ну на самом деле проблемы нет. это проблема управления.
в Ханте после приземления персонаж выравнивает позицию делая шаг.

красота исчезает если использовать концепт нажал кнопку - есть реакция, отпустил - нет реакции.

тот же Принц обсуждаемый ранее использует концепцию шага.
при нажатии направления он делает шаг.

[reddie]

это проблема управления

Точнее, программы обработки управления (вывода анимации).
Но вопрос о размере памяти остается актуальным =) Если есть запас под сдвиги фаз - есть и быстрый вывод. Собственно, как и на Спектруме.

[jerri]

Точнее, программы обработки управления (вывода анимации).
Но вопрос о размере памяти остается актуальным =) Если есть запас под сдвиги фаз - есть и быстрый вывод. Собственно, как и на Спектруме.

не совсем верно. Если у тебя есть память под подробную анимацию, то есть и под сдвиги.
кроме того при прескролле спрайтов можно добавить пару пикселей по горизонтали
спрайт становится 10, 18, 26 точек шириной. для мелкой графики это актуально.