Где-где... в экране :) Каждые 8 кадров, простой процедурой (хотя можно и похимичить)Цитата:
Сообщение от jerri
А что решать, там не тайл уходит, а последний пиксель сдвигается в никудаЦитата:
Сообщение от jerri
Вид для печати
Где-где... в экране :) Каждые 8 кадров, простой процедурой (хотя можно и похимичить)Цитата:
Сообщение от jerri
А что решать, там не тайл уходит, а последний пиксель сдвигается в никудаЦитата:
Сообщение от jerri
я так понимаю это адреса в спискеЦитата:
^установка на первую строку
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход растровых строк
^скроллер1 голова
^скроллер1 хвост
^переход тайловой строки
^скроллер2 голова
^скроллер2 хвост
итд
вопрос - как удалить из списка последний обьект ушедший за экран
и как добавить в список новый обьект вышедший из-за экрана?
если можно то кусочек кода пожалста
Йопт :rolleyes: это список стартовых адресов процедурЦитата:
Сообщение от jerri
Здесь они только коректируются (не все)
Ни порядок, ни кол-во не меняются
Способ же модификации самих процедур зависит от способа хранения ландшафта
Ну что ж, до мин недолеча осталось.
Встроил в печать ландшафта печать буфера спрайтов.
- Подготовка лодки к печати - 1150 тактов
- Печать лодки с проверкой на столкновение - 2700 тактов
- Стирание ксоркой - 1900 тактов
Не стал я лодку урезать до 4 знакомест, сделал 5. Но некоторые байты спрайта пропущены. Печатаю змейкой.
Буду метиться на дискретность в 1 пиксел, а там посмотрим.
Есть 2 нюанса
1. перенеси весь исполняемый код выше #8000
2. чего у тебя весь экран одного цвета? :) лодка должна быть белая
---------- Post added at 10:30 ---------- Previous post was at 09:45 ----------
ладно :)
раз уж дошли до момента когда надо рисовать спрайты
вот технология для быстрого сортирования обьектов
итак
создаем таблицу 256 байт (чтоб работать удобнее было)
можно конечно и поболее таблицу создать но это надо смотреть по месту
итак 256 байт
первые 12 байт - счетчики обьектов в строке
последующие 240 байт - данные по обьектам в строках
итак обрабатываем какойто обьект
например мину
Цитата:
в С - номер обьекта
ну или еще какой регистр
ld h,table_object/256
берем координату Y
делим на 16 получаем число 0 до 11
and #f0
rra
rra
rra
rra
ld l,a
inc (hl)
ld a,(hl)
add a,a
add a,(hl)
add a,a
add a,a
//умножаем на 12
add a,l
ld l,a
ld (hl),c //номер обьекта
и теперь обработка обьектов
ld hl,table_object
ld b,12
obj_
ld a,(hl)
берем количество обьектов
or a
jr nz,object_proceed
inc l
djnz obj_
object_proceed
ld b,a количество обьектов
ex de,hl
ld hl,12
add hl,de
hl - список обьектов
переход к следующему обьекту
add hl,12
естественно перед выходом hl восстановить
Другой вариант
в С - номер обьекта
ну или еще какой регистр
ld h,table_object/256
берем координату Y
делим на 32 получаем число 0 до 11
and #e0
ld l,a
inc (hl)
add a,(hl)
ld l,a
ld (hl),c
после отработки получается примерно такая таблица
#8000
#00,#00,#00,....
#8020
#01,#05,.......
#8040
#02,#01,#02,....
т.е строка 1 - координаты Y от 0 до 31 - 0 обьектов
строка 2 - координаты Y от 32 до 63 - 1 обьект ID5
строка 3 - координаты Y от 64 до 93 - 2 обьекта ID1 ID3
зачем это надо
для того чтобы при отрисовке перед лучом нарисовать сначала обьект №5 с координатой 32
а потом уже рисовать №1 с координатой 64 и №3 с координатой 90
ld hl,table_object
ld b,#8
obj_
ld a,(hl)
берем количество обьектов
or a
jr nz,object_proceed
ld a,l
add a,32
ld l,a
djnz obj_
object_proceed
ld b,a количество обьектов
inc l
hl = список обьектов
эт потом. Еще мины должны ведь черные. А они еще и в шахтах. Тут много вариантов:Цитата:
Сообщение от jerri
1) подкрашивать спрайты. Т.е. можно сделать вкл/выкл. режима подкрашивания наподобие "7дней в раю"
2) Мины будут красные пока они не всплывают. Потом- подкрашивать черным, при этом шахта будет вся в квадратиках.
3) Еще много вариантов.
Короче, не знаю я, что же делать с цветами. Надо экспериментировать. Но пока нет мин - не имеет смысла.
ничче не понял.Цитата:
Сообщение от jerri
Зачем сортировать объекты в строке?
Ключ сортировки - это X что ли?
Беглым взглядом - это алгоритм вставок какой-то.
Куда потом применять эту таблицу 256 байт?
Какие данные содержаться в этой таблице?
Что такое 12?
Мне бы лучше алгоритм сортировки (разбивки) объектов по знакострокам и заполнения буфера для последующей печати. Т.е. ключ - Y объекта. А то я сделал лодку - не очень доволен как у меня получилось. Буду скорее всего переделывать.
ошибся я там - :) естественно Y
но есть ограничение - не более 20 обьектов на строку для первого алгоритма
или не более 31 обьекта на строку для второго алгоритма
Мысли по цветности
Во-первых, предусмотреть ее отключение
черным по синему тоже уже неплохо, взрывами можно помигать,
букафки сверху-снизу цветные - совсем уныло не будет
Во-вторых, прокрутка атрибутов
Можно сдвигать все сразу одновременно, но тогда получится
многовато пустых квадратиков, которые будут зря окрашивать спрайты
С другой стороны, пусть мы не можем двигать атрибут
"с точностью до пикселя", зато можем "с точностью до кадра"
То есть атрибуты смещаем каждый кадр, но не все!
А чтобы лучше совпадали с кромками ландшафта
Здесь какие-то хитрые процедуры не нужны, хватит универсальной
Формат данных в буфере атрибутов (здесь лучше слева направо):
- пропуск до следующего сдвигаемого
- кадр, на котором его нужно сдвинуть
И при прокрутке знаколинии (перед спрайтами) быстро пробегаем
(информацию о кадре сдвига можно к тайлу привязать)
В-третьих, окраска спрайтов
Мины "подкрашивать черным" просто так не нужно, само же получится
Если уж подкрашивать, то в красный и весь спрайт целиком
чтобы цвет потом сменился скачкообразно - так лучше смотрится
А вот лодка, то и дело мигающая красным, уже получится некрасиво
Или можно атрибутный конфликт разрешить простой моргалкой по четности кадра
Что правда усложнит проверку столкновения и стирание, да и дольше будет
С другой стороны, если по скорости есть запас - почему бы нет?
Думаю, сначала лучше добавить неравномерный сдвиг атрибутов, а там видно будет
Караул!
Не успел отрисоваться.
Почти в самом конце, где куча шахт подряд. Около 200 тайлов там. Не помогли даже стрип-тайлы.
Короче, всё окно практически рисуется. Из теории помним, что экран на спектруме за прерывание, ну, никак не успеть перебросить.
В этом месте, если хотим сделать 1 фрейм, придется отступить от оригинала.
Хехе, у меня прокруткой все равно примерно 30000 получилось :p
Да, действительно, 30000 получается.
Ну что? Попробовать реализовать этот JIT scroller? Уж больно заманчивые тайминги. Нигде мы не просчитались? со спрайтами потом проблем не возникнет? Там еще сталактиты падающие, стреляющие пушки, лазеры...
Тут с печатанием тайлов я вроде всё поджал. Особо быстрее, видимо, не получится. Эти шахты рисуются 62000 тактов. А обработка - 26000. Причем, обработку размазать по кадрам нельзя. Ее надо сразу всю делать тут.
---------- Post added at 18:31 ---------- Previous post was at 18:25 ----------
Только я вот тут чуть чуть не понял:
Зачем на 2 части разбивать? Как кольцуется?Цитата:
Сообщение от Lethargeek
Если надо, я подробно все напишу
Только не дави на меня :)
Дай вздохнуть дня два
А. Всё. Разобрался. Это когда голова кончается, то головой становится хвост, и хвост начинает расти заново.Цитата:
Сообщение от ace210
Немного просчитался - последний пиковый около 33000
Причем прокрутками по одной строке почти столько же получилось
Так что может быть лучше перейти на однострочную прокрутку?
Корявый ландшафт, конечно, больше схавает, но не слишком
(до такого пикового с шахтами не дотянет все равно)
зато его можно будет подрихтовать ;)
А также подготовка и сами процедуры упрощаются
Установка регистров:
Фрагменты однострочного скроллера:Код:Один раз на весь экран:
B = правый обрыв (или левая стенка шахты)
С = левый обрыв (или правая стенка шахты)
В начале строки:
HL = адрес начального (правого) байта
A = L; Carry = бит из подрисовки
К тому же выйдет короче, так что возможно выгодно ужеКод:обязательный переход на шаг (4 такта)
dec l
или пропуск трех и более знакомест (11 тактов)
sub N
ld l,a
(N так же не всегда равно кол-ву пропускаемых)
правый обрыв или левая стенка шахты (7 тактов)
ld (hl),b
левый обрыв или правая стенка шахты (7 тактов)
ld (hl),с
(условно) правый склон после пропуска (15 тактов)
sla (hl)
(условно) левый склон после пропуска (15 тактов)
sli (hl)
продолжение прокрутки (15 тактов)
rl (hl)
не заморачиваться с закольцовкой и разрезанием скроллера
а просто сдвигать его на том же месте (или в другой набор)
таким образом избавимся от пары рестартов на строку
Может, даже выиграем немного, позже посчитаю
Всё, да не всё.Цитата:
Сообщение от ace210
1) Печать стрип-тайла всегда ограничивается шириной в 1 знакоместо! Раньше я этого не учитывал, шлепал лишнее знакоместо.
Теперь, соответственно, пиковый экран печатается в 2 раза быстрее, так как там почти одни только стрип-тайлы. Получилось 34500 такта. Это без учета рисования спрайтов.
2) Далее. На 0 кадре обыкновенные тайлы тоже можно сделать не 2 знакоместа печатать, а 1. Только нужно сделать тайл так, чтобы он на кадре предшествующем 0-му уже затер землю (нарисовал землю) сплошняком в знакоместе справа. Мне пришлось подкорректировать только 2 тайла. Их сейчас можно увидеть даже невооруженным взглядом (они нессиметричные, на 1 пиксель имеют лесенку).
Тоже выиграл немного времени. Но это не так уж нужно. Но зато когда печатается 0 кадр то и обработка ландшафта тоже выполняется на этом кадре. Поэтому получается некая компенсация.
3) Немного оптимизировал обработку. Выиграл на пиковом экране 4000 тактов. Сейчас 23000 тактов кушает.
Во фрейм уложился, но итого осталось в пиковом экране на отрисовку мин около 6000 тактов.:(
Всё равно маловато. Эх, жаль, что обработку нельзя размазать по кадрам. Там корректируются адреса экрана печати тайла, поэтому никак. :(
Пока, наверное, не буду пробовать реализовывать JIT Scroller. Еще неизвестно что в конечном итоге там выйдет. Может быть как нибудь потом, как вдохновение появится.
Сейчас лучше пущу усилия на спрайты. Хочется уже пострелять.
А на цвет запас? ;)
Ладно, я пока буду дорабатывать потихоньку
Может, тест напишу (пиковый экран замкну в кольцо)
Погляжу, что выйдет
Хм, похоже, что двойной скроллер удастся ужать до 26000 в пике
Йоу, Блэр! (с)Цитата:
Сообщение от ace210
Красиво получилось! И очень обнадеживающе!
Насчет стрип-тайлов и шахт: мне кажется, что если печатать шахты не в виде тайлов (даже стрип-тайлов), а с помощью специализированных процедур, которые максимально быстрым образом рисуют вертикальный столбик - то может быть удастся еще что-нибудь выиграть.
Ты имеешь в виду то, что во время обработки нельзя рисовать текущие кадры из-за того, что состояние структур данных находится "в процессе изменений"? А что если использовать два набора данных, один рисуется, а второй обрабатывается? Если обработка делается один раз на 8 кадров - то должен быть способ ее размазать по кадрам, хотя бы ценой дополнительной памяти.Цитата:
Сообщение от ace210
К сожалению, печать идет строго по знакострокам чтобы пристраиваться за лучом. Поэтому - никак нельзя.Цитата:
Сообщение от Barmaley_m
Идея хорошая, но в мою структуру данных ландшафта вряд ли впишется. На досуге подумаю.Цитата:
Сообщение от Barmaley_m
Насчет спрайтов.
Естественно, чтобы печать шла по знакострокам, нужно заполнить буфер спрайтов в формате приблизительно: адрес процедуры печати знакостроки спрайта, адрес экрана для вывода, адрес спрайта.
Есть 2 метода организации.
1) Один буфер. Как только знакострока кончается, то в буфере вместо адреса процедуры ставим 0.
В этом случае очень усложняется заполнение этого буфера, т.к. Нужно сначала спрайты разбить на объекты - знакоспрайты, потом их отсортировать по Y, потом уже заполнять последовательно буфер.
2) На каждую знакостроку - свой буфер спрайтов. В этом случае спрайты не нужно сортировать. А, последовательно перебирая их, разбивать на объекты-знакоспрайты, и записывать сразу в буфер нужной знакостроки. Недостаток метода 2) - в том, что нужно держать указатели на окончания всех 20 буферов и при записи в буфер соответственно корректировать эти указатели.
Сейчас подлодка печатается по методу 2). Получилось 1000 тактов на заполнение буфера. Много. Правда я еще не особо оптимизировал. Лодка имеет в высоту - 12 пикселей. В ширину - 5 знакомест. К тому же еще не применяется клиппинг.
На обработку мин уйдет больше времени, т.к. там еще нужно обсчитывать клиппинг.
Думаю мины можно не стирать, а печатать с маской поверх старого изображения, затирая маской соседние 2 пикселя справа и снизу.
У кого какие мысли? Может еще есть какие способы, методы?
Цитата:
Сообщение от ace210
вот это примерный алгоритмКод:pop hl,de,ix
ld sp,hl
ex de,hl
dup 3
pop bc
ld a,(hl)
xor c
ld (hl),a
inc h
ld a,(hl)
xor b
ld (hl),a
inc h
edup
pop bc
ld a,(hl)
xor c
ld (hl),a
inc h
ld a,(hl)
xor b
ld (hl),a
ld sp,ix
ret
эта процедура должна использоваться для отрисовки левого и правого края обьекта (мины?)
для отрисовки середины можно использовать такую же, но просто с копированием
pop hl,de,ix
ld sp,hl
ex de,hl
dup 3
pop bc
ld (hl),c
inc h
ld (hl),b
inc h
edup
pop bc
ld (hl),c
inc h
ld (hl),b
ld sp,ix
ret
естественно перед тем как так рисовать
надо создать таблицу вида
#8000 адрес_обработчика, адрес_спрайта, адрес_на экране, #8008
#8008 адрес_обработчика, адрес_спрайта, адрес_на экране, #8010
#8010 конец обработки строки
как создавать такую таблицу и как к ней обращаться - об этом чуть позже
Да не "маской затирать", а просто разницу ксорить - примерно как у jerriЦитата:
Сообщение от ace210
Только зачем там 4 раза pop? С двойными строками нужно только 4 байта
Разве что мины по-другому нарисовать (что все равно не стоит возни со стеком)
ну эт на случай если хочется сделать красиво :)
кстати вопрос такой - по вертикали мины будут всплывать со скоростью 2 пикселя так?
и пули из пушек тоже? а сталактиты?
а в оригинале как?
не будет ли нехватать скорости о сравнению с оригиналом
Там не пули, там лучи из тайлов походуЦитата:
Сообщение от jerri
Подозреваю даже, что оригинал юзает текстовый режим для фона
Ну, пик я уже до 25000 ужал, так что запасной вариант у вас всяко будет ;)Цитата:
Сообщение от jerri
(даже с запасом на моргалки и прочие извращения)
В оригинале есть 4 уровня сложности:
1) Yeoman - 2,5 фрейма
2) Ensign - 2 фрейма
3) Captain - 1,5 фрейма
4) Admiral - 1 фрейм
Примечательно, что тайминги у платформы Atari совпадают с Spectrum. Т.е. если расположить рядом 2 эмулятора и запустить одновременно, то ландшафты скроллируются синхронно!;)
---------- Post added at 18:52 ---------- Previous post was at 18:34 ----------
Мины всплываю в 2 раза быстрее чем лодка. Т.е. получается за 1 фрейм - 2 пикселя.
Пули еще быстрее летят. Там да, что-то типа прерывистого луча из пуль получается.
Сталактиты - то же самое как мины.
Скорости нормально. В чем проблема-то может возникнуть? Как надо будет, так и оптимизируем.
---------- Post added at 18:54 ---------- Previous post was at 18:52 ----------
Я совсем не знаю платформу Atari, но слышал, что там есть аппаратная поддержка спрайтов.Цитата:
Сообщение от Lethargeek
Мне показалось 1)=2) и 3)=4) только мины злее всплываютЦитата:
Сообщение от ace210
А фреймы умножь на два из-за низкого разрешения
наш реальный пиксель в два раза меньше
Они у всех компов, рассчитанных на PAL, совпадают :)Цитата:
Сообщение от ace210
На спеке только плавней получится
Спрайты убогие, зато есть настоящий строчный видеопроцессорЦитата:
Сообщение от ace210
Можно каждую строку ставить новый аппаратный режим
в том числе текстовые с графическими мешать
Набил тупую проверку нового скроллера для зацикленного экрана
только прокрутка без подготовки, зато без оптимизации смены строк
и без блокировки обработчика MASK-INT (емнип 1720 тактов)
Здесь ровно 384 вертикальных "тайла" (против 204 на пиковом)
Хавает 44922+ без задержек и 48063 c задержками юлы-48
Соответственно (за минусом MASK-INT) на пиковом получается
примерно 23300 без задержек и около 25000 с задержками
(зависит от строки, с которой рисование начинается)
Кстати, Revision31 с медленной памятью на пике все-таки запинается
мой способ не пойдет с данной технологией
вопрос такой - хватит ли скорости для отрисовки и удаления полного спрайта?
т.е 16*3 или 12*5
т.е не бить его на куски
а перед скроллом местности убрать все что есть
прорисовать 2 строки
и после прорисовки нарисовать все спрайты
---------- Post added at 13:54 ---------- Previous post was at 12:42 ----------
единственное - необходимо 2 раза сканировать спрайты выводимые на экранКод://организация спрайтов
//адреса даны примерно
sp_line1 equ #6000
//как организовано?
//сначала в кучку друг за другом все первые линии обьектов
//потом все следующие линии обьектов в следующем параграфе
//и тд
sub_beg equ #00 //8*5 =#38
mine_beg equ #38 //8*3=#18
gunl_beg equ #50 //8*3=#18
gunr_beg equ #68 //8*3=#18
stal_beg equ #80 //8*3=#18
//здесь начинаем рисовать строку спрайтов
beg_line
//вот здесь можно сделать проверку на необходимость отрисовки
//чтото вроде
ld (sprdraw_sp),sp
ld sp,(sprites)
ret
end_line
ld (sprites),sp
ld sp,(sprdraw_sp)
ret
sprites dw 0
//отрисовка обьекта шириной 1
draw_sp1
pop hl //адрес Y
pop de //адрес на экране
pop bc //B высота С координата X
ld (store_sp1),sp
ld sp,hl
loop_sp1
pop hl
ld a,c
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (hl),a
pop hl
ld a,c
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (hl),a
inc d
djnz loop_sp1
ld sp,0
store_sp1 equ $-2
ret
//отрисовка обьекта шириной 2
draw_sp2
pop hl //адрес Y
pop de //адрес на экране
pop bc //B высота С координата X
ld (store_sp2),sp
ld sp,hl
loop_sp2
pop hl
ld a,c
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (hl),a
inc l
ld a,(de)
xor (hl)
ld (hl),a
pop hl
ld a,c
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (hl),a
dec l
ld a,(de)
xor (hl)
ld (hl),a
inc d
djnz loop_sp2
ld sp,0
store_sз2 equ $-2
ret
//отрисовка обьекта шириной 2
draw_sp3
pop hl //адрес Y
pop de //адрес на экране
pop bc //B высота С координата X
ld (store_sp3),sp
ld sp,hl
loop_sp3
pop hl
ld a,c
add a,l
ld l,a
dup 2
ld a,(de)
xor (hl)
ld (hl),a
inc l
edup
ld a,(de)
xor (hl)
ld (hl),a
pop hl
ld a,c
add a,l
ld l,a
dup 2
ld a,(de)
xor (hl)
ld (hl),a
dec l
edup
ld a,(de)
xor (hl)
ld (hl),a
inc d
djnz loop_sp3
ld sp,0
store_sз2 equ $-2
ret
один раз для рисования - смотреть где находится нижняя часть спрайта
другой раз для стирания - смотреть где находится верхняя часть спрайта
но здесь нужно уже иметь на руках структуры объектов - как-то так :)
кстати :)
1. сколько фаз у взрыва?
2. как решать проблему ухода спрайта за экран? координаты то от 0 до 255 и если с клиппингом справа все нормально, то слева надо чтото решать
что-то ничего не понял. Ты словами на паЛЦАХ разъясни, что придумал.
Можно тупо дать лучу нужную фору, те же 16 строчек (~3600 тактов)Цитата:
Сообщение от jerri
Хотя хрен его знает, может даже перед лучом успеем, он и не догонит
(если с прошлого фрейма все заранее подготовить для быстрой печати)
Я уже думал, чтобы не бить на знакостроки - не получается с тросами. Их точно надо бить если не на знакостроки, то на части. А если на части, то - это получается почти что то же самое, что и на знакостроки. Так уж лучше всё под одну гребенку сразу делать да и всё. Т.е. - знакостроки.
Если 1 фрейм - то однозначно надо перед лучом рисовать (у меня сейчас так). Это если бы 2 фрейма, тогда да - надо за лучом. А если 1 фрейм - то ПЕРЕД ЛУЧОМ и не надо мучиться высчитывать, пристраиваться, фору давать... Однозначно не догонит.
---------- Post added at 17:40 ---------- Previous post was at 17:07 ----------
это как? Если просто мина сдвигается влево - то понятно. А если еще и всплывает вверх? то что ксорить? какова разница в этом случае? А если мина еще и взрывается в конце?Цитата:
Сообщение от Lethargeek
---------- Post added at 17:43 ---------- Previous post was at 17:40 ----------
видимо, придется отступить от оригинала. Посмотрим что будет с минами, там видно будет.Цитата:
Сообщение от Lethargeek
---------- Post added at 17:47 ---------- Previous post was at 17:43 ----------
Я же предлагаю - давайте маской стирать при выводе, а? Будет экономится на вытаскивании адресов экрана и спрайта?Цитата:
Сообщение от jerri
Эти клиппинги всегда уйму тактов жрут. Если б захотел, послал бы их куда подальше...Цитата:
Сообщение от jerri
Байта для координаты явно недостаточно. Значит надо 2 байта. Предлагаю 1-й байт - координата знакоместа, 2-й - смещение 0...7. Будем думать, пробовать.
---------- Post added at 17:53 ---------- Previous post was at 17:47 ----------
5 фаз. Меняются каждые 2 фрейма.Цитата:
Сообщение от jerri
Или можно тросы тупо забить в ландшафт и не страдатьЦитата:
Сообщение от ace210
Если мина уничтожена, заменяешь тайл на пустой
(в моем случае можно просто стереть в экране)
Только если успеешь после фона еще и спрайты отрисоватьЦитата:
Сообщение от ace210
которые, даже отсортированные, могут скопиться наверху
То есть луч до ВЕРХНИХ строк не должен успеть дойти
Но даже 4-я знаколиния ~ 22000 тактов с начала кадра
Блииин... ну наксорь одну целую картинку на другую, это и будет разницаЦитата:
Сообщение от ace210
Наксорь эту разницу на любую из двух исходных картинок, получишь вторую
О масках вообще забудь, не нужны они здесь
Лучше подожди, пока я добью свой скроллер до вменяемого исходникаЦитата:
Сообщение от ace210
Или отступать придется далековато :)
Что там сложного - печатай столбиками, начинай не с первого, вот и всеЦитата:
Сообщение от ace210
Вместо смещения брать циклически следующий адрес сдвинутого спрайта
(или процедуры, которая рисует нужную фазу)
вот картинка :)Цитата:
Сообщение от ace210
перед тобой проскроленныый спрайт прямоугольника 8*16
в том самом виде в каком он будет хранится в памяти
т.е переход к следующему ряду = inc h
переход по горизонтали - inc l
что дает такой способ хранения - нет необходимости в спец процедурах для клипирования просто берешь и выводишь тупо задавая ширину
далее переход между строками экрана
в стеке - таблица адресов и мы оттуда достаем по 1 и корректируем
так проще?
я вот тут про JITScroll подумал
Lethargeek, а как ты собирался вообще собирался код генерить для компактного выполнения?
просто как я смотрю это же должен быть чистый код. не?
чтото вроде
ld e,l
rl (hl)
ldd
ld e,l
rl (hl)
ldd
dec l
dec l
dec l
ld e,l
rl (hl)
ldd
ret
и в начало добавлять новые элементы?
или я чтото не так понял?
хотя конечно если точно знать - а мы знаем
то можно упростить до
rl (hl)
ldd
rl (hl)
ldd
dec l
dec l
dec l
ld e,l
rl (hl)
ldd
ret
а ld e,l добавлять перед очередным большим блоком
а карту паковать с управляющими кодами
Да все мы знаем конечно
Там на скроллер каждой строки должен быть дескриптор
Типо адреса начала-конца, отступ справа, левый столбец
А потом каждый восьмой кадр отступ либо увеличить
либо закрыть (записать нужный кусок для пропуска)
и дописать в начало еще кусок любым способом
Нужный кусок можно по-разному выбирать
можно отдельным потоком, можно прямо по номеру тайла
(если нужно, возможны одинаковые с виду с разными номерами)
Потом смотрим, где последний столбец и кусочками режем хвост
(по концевому байту однозначно видно, когда обрезку прекратить)
Также можно сразу же корректировать оценку быстродействия
(для вставки задержек, если за лучом рисовать)
Сам код будет несколько другой, подогнал еще под ландшафт
ну есть пара идей относительно генерения
правда декрунчер получается слишком психаделический
Для начала лишь бы работало
хоть через таблицу переходов
Кодить некогда...
Код:;JIT алгоритм
;кстати что значит JIT?
итак изначально имеем рабочую область 160 на 256
т.е 20 тайловых строк
итак производим генерацию кода для обработки тайловой строки
для начала определяемся как все будет
итак
буфер под код 256 байтов
при максимальной загрузке
вида
ld e,l
rl (hl)
ldd
5*32 - 160 байтов
буфер должен выглядеть как то так
rl (hl)
ldd
rl (hl)
ldd
dec l
dec l
dec l
dec l
ld e,l
rl (hl)
ldd
ret
l_init
;h-старший байт адреса
звполняем таблицу
ld l,-1
;инициируем таблицу переходов
ld b,32
ld (hl),-27
dec l
djnz $-3
;создаем ссылку на текущий байт в таблице переходов
ld (hl),-1
dec l
;закручиваем скроллер в кольцо
ld (hl),1
dec l
ld (hl),h
dec l
ld (hl),#c3
dec l
ld (hl),#c9
ld a,l
ld l,0
;инициируем трамплин
ld (hl),a
ret
l_proc
;обработчик
ld l,0
ld l,(hl)
ld (jmp_item),hl
ex de,hl
ld a,l
call $+3
call $+3
call $+3
call $
jmp_item equ $-2
ld l,a
ret
l_gen
;генератор
d-старший байт
a-статусный байт
;статусы
0-пустота (камень или вода)
1-начало линии
2-середина линии
3-конец линии
add a,a
add a,jmp_gen
ld l,a
adc a,jmp_gen/256
sub l
ld h,a
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
jp (hl)
jmp_gen dw jit_0,jit_1,jit_2,jit_3
jit_0
ex de,hl
ld l,-32
ld a,(hl)
dec a
or #e0
ld c,a
ld (hl),a
ld b,h
ld l,0
ld l,(hl)
ld a,l
dec a
call z,corr_jitb
dec l
ld (hl),#2d dec l
ld a,l
ld (bc),a
ld l,0
ld (hl),a
ret
corr_jitb
ld a,l
ld l,-33
ld (hl),a
dec l
ld (hl),h
dec l
ld (hl),#c3
ret
jit_1
ex de,hl
ld l,-32
ld a,(hl)
dec a
or #e0
ld c,a
ld (hl),a
ld b,h
ld l,0
ld l,(hl)
dec l
call z,corr_jitb
ld (hl),#5d ld e,l
ld de,#cb16 rl (hl)
call place_word
ld de,#eda8 ldd
call place_word
ld a,l
ld (bc),a
ld l,0
ld (hl),a
ret
place_word
ld a,l
cp 3
call c,corr_jitb
dec l
ld (hl),e
dec l
ld (hl),d
ret
както так
это предварительные прикидки - позже наверное напишу остальное да и багу выловить надо :)
Just In Time? т.е. "реального времени"
---------- Post added at 17:50 ---------- Previous post was at 17:48 ----------
От ldd Lethargeek в свое время отказался, т.к. получается дольше с ней (как ни странно) и сложнее.
лучше перевести - "по ходу дела", т.е. как только понадобилосьЦитата:
Сообщение от ace210