BlaireCas, есть более эффективные способы расхода процессора. алгоритмы ннада?
Вид для печати
BlaireCas, есть более эффективные способы расхода процессора. алгоритмы ннада?
Было-бы интересно просто на словах.Цитата:
Сообщение от jerri
Допустим берем только один цвет (не все 8). Как в спеке пусть будет. 8точек = байт. Есть спрайт+маска (2 байта). Есть фреймбуфер и там бекграунд.
Вроде особо много чего тут и не придумать. Сдвигаем байт маски на нужное число пикселей либо через таблицы либо командами сдвигов (таблицы быстрее). Получаем два байта, маскируем их в буфере. Повторить то-же самое для байта цвета.
Затем измененные части буфера на экран и вернуть буферу исходное состояние.
Где-то в деталях (навроде спрайты можно прешифтить заранее, анимацию заранее со сдвигами заготовить) могут быть различия, но вроде алгоритм какой-то такой
Соответственно для 4-х цветов будет все это повторено для фреймбуфера 2-го цветового бита, для 8-ми цветов еще и для третьего цветового бита. Поэтому общую задачу достаточно решить только для 1-битного цвета для начала видимо (ну в УКНЦ вообще без вариантов ибо один из цветовых планов экрана может рисовать лишь второй процессор)
Отделил в отдельную тему и перенёс в правильное место все сообщения, касающиеся демки игры для УКНЦ.
Придется видимо доделывать раз уж тема появилась :)Цитата:
Сообщение от CityAceE
- - - Добавлено - - -
Собственно по выводу спрайта (ширина 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
Шикарный движок, графика и сама игруха!
А на EmuStudio вообще летает)
Надо доделывать.
Кстати я его вполне себе использую чтобы "побыстрому посмотреть результат" (для дебага юзается UKNCBTL).Цитата:
Сообщение от Titus
Уже даже привык нажимать shift-del, ctrl-del, ctrl-del при его запуске - и вот бы их какими-нибудь параметрами задать.
А в чем разница с UKNCBTL?Цитата:
Сообщение от BlaireCas
Если заменить
add R4, R5
на
add #30., R5
то замедление сравнительно небольшое, зато можно использовать R4 для адреса маски и избавиться от лишнего дублирования маски.
Разница в отображении? Наверное никакой нету. Только дефолтно EmuStudio "скушивает" последние 8 (что-ли) строк экрана и приходится жать shift-del чтобы они показались. А также сканлайны конечно винтажны, но для разработки мешают (без них пиксели виднее что-ли). Поэтому приходится два раза еще и жать ctrl-del.Цитата:
Сообщение от Titus
А какая еще разница? Звука нет, дебага нет, да это думается ты знаешь-же. (в UKNCBTL еще и в восьмеричной системе всё в дебаге, что нереально удобно).
Еще можно разделить процедуры на две ветки. При нечетном R5 делать как сейчас, а при четном - словами вместо байтов (тут нужны будут альтернативные таблицы сдвигов).