BlaireCas, есть более эффективные способы расхода процессора. алгоритмы ннада?
BlaireCas, есть более эффективные способы расхода процессора. алгоритмы ннада?
С уважением,
Jerri / Red Triangle.
Было-бы интересно просто на словах.
Допустим берем только один цвет (не все 8). Как в спеке пусть будет. 8точек = байт. Есть спрайт+маска (2 байта). Есть фреймбуфер и там бекграунд.
Вроде особо много чего тут и не придумать. Сдвигаем байт маски на нужное число пикселей либо через таблицы либо командами сдвигов (таблицы быстрее). Получаем два байта, маскируем их в буфере. Повторить то-же самое для байта цвета.
Затем измененные части буфера на экран и вернуть буферу исходное состояние.
Где-то в деталях (навроде спрайты можно прешифтить заранее, анимацию заранее со сдвигами заготовить) могут быть различия, но вроде алгоритм какой-то такой
Соответственно для 4-х цветов будет все это повторено для фреймбуфера 2-го цветового бита, для 8-ми цветов еще и для третьего цветового бита. Поэтому общую задачу достаточно решить только для 1-битного цвета для начала видимо (ну в УКНЦ вообще без вариантов ибо один из цветовых планов экрана может рисовать лишь второй процессор)
Последний раз редактировалось BlaireCas; 29.10.2021 в 13:48.
Отделил в отдельную тему и перенёс в правильное место все сообщения, касающиеся демки игры для УКНЦ.
С уважением, Станислав.
bakka(29.10.2021)
Придется видимо доделывать раз уж тема появилась
- - - Добавлено - - -
Собственно по выводу спрайта (ширина 16 пикселей) с маской в один из цветовых планов буфера ..
Код с таблицами сдвигов вот такой (кусок кода для сдвига на 4 пикселя, для других сдвигов оно похожее, только смещения таблиц сдвигов другие).
Спрайт (каждые 8-пикс) идет в виде .BYTE маска, цвет, маска, цвет и тут зарыта гигантская собака ибо маска одинаковая для всех цветовых планов, а у меня маска для скорости размножена по каждому цветовому плану памяти. Это надо будет как-то чинить а то так памяти не напасешься.
В чем тут можно ускорить .. Черт его знает.Код:BSFB04: ; 4-pix shift, R0-spr addr, R5-buf addr, R3-height, R4=30. clr R1 ; bisb (R0)+, R1 ; mask byte -> R1 clr R2 ; bisb (R0)+, R2 ; sprite byte -> R2 bicb ShiftTable1(R1), (R5) ; shift and apply mask bisb ShiftTable1(R2), (R5)+ ; shift and apply color bicb ShiftTable2(R1), (R5) ; same for out-of-byte shifted pixels bisb ShiftTable2(R2), (R5) ; repeat for second 8-pix sprite part clr R1 ; bisb (R0)+, R1 ; mask byte -> R1 clr R2 ; bisb (R0)+, R2 ; sprite byte -> R2 bicb ShiftTable1(R1), (R5) bisb ShiftTable1(R2), (R5)+ bicb ShiftTable2(R1), (R5) bisb ShiftTable2(R2), (R5) add R4, R5 ; R4=30., buffer next line addition sob R3, BSFB04 return
CityAceE(29.10.2021), Oleg N. Cher(03.11.2021), Titus(29.10.2021)
Шикарный движок, графика и сама игруха!
А на EmuStudio вообще летает)
Надо доделывать.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Если заменить
add R4, R5
на
add #30., R5
то замедление сравнительно небольшое, зато можно использовать R4 для адреса маски и избавиться от лишнего дублирования маски.
Разница в отображении? Наверное никакой нету. Только дефолтно EmuStudio "скушивает" последние 8 (что-ли) строк экрана и приходится жать shift-del чтобы они показались. А также сканлайны конечно винтажны, но для разработки мешают (без них пиксели виднее что-ли). Поэтому приходится два раза еще и жать ctrl-del.
А какая еще разница? Звука нет, дебага нет, да это думается ты знаешь-же. (в UKNCBTL еще и в восьмеричной системе всё в дебаге, что нереально удобно).
nzeemin(30.10.2021), Oleg N. Cher(03.11.2021)
Еще можно разделить процедуры на две ветки. При нечетном R5 делать как сейчас, а при четном - словами вместо байтов (тут нужны будут альтернативные таблицы сдвигов).
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)