Edge Grinder для ZS GMX

Цитата:

Сообщение от reddie

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

Да, так и есть. Рисуется экран, включается следующий банк и так до маркера конца карты.
Я ещё хотел сделать вторую копию карты, смещённую на пиксель. Процедура Fill_Buffer каждый раз смещает правый пиксель налево и рисует справа новый пиксель. Так вот, чтобы в итоге скрол был по пикселям, нужно нарисовать одну версию карты начиная с банка памяти, скажем #10, а каждый второй раз рисовать карту начиная с банка #40. Сейчас карта рисуется 15 секунд, тут будет немного дольше. А если ещё её переконвертить в другой формат, ждать долго ). Можно, конечно, один раз всю карту сделать и грузить потом с диска.

А так нужные процедуры в файле Block_Writer4.asm.
ProcessMapPointer - рассчёт.
В ней переменная scroll_step увеличивается каждый кадр, каждые 16 раз рисуется новый тайл.
Переменная MapPointer указывает на текущую позицию на карте.
Fill_Buffer - запоняет буфер.
Цикл 5 тайлов * 4 знакоместа в высоту * 4*2 пары пикселей знакоместо.
Copy_Buffer - перебрасывает на страницу в #c000.
В HL адрес куда рисовать.

Можно сделать в загрузчике копию этих процедур и ломать как надо. Но надо делать попиксельный скрол.

Цитата:

Сообщение от reddie

Первое, что сразу бросается в глаза: очень много лишних действий внутри циклов вывода строк.
Скажем, каждый раз вычисляется один и тот же адрес для IX, хотя задавать его нужно всего один раз _перед_ циклом.

Вот тут я сильно не доглядел ).

Цитата:

Сообщение от izzx

Процедура Fill_Buffer каждый раз смещает правый пиксель налево и рисует справа новый пиксель. Так вот, чтобы в итоге скрол был по пикселям, нужно нарисовать одну версию карты начиная с банка памяти, скажем #10, а каждый второй раз рисовать карту начиная с банка #40. Сейчас карта рисуется 15 секунд, тут будет немного дольше.

Почти два раза дольше, учитывая сдвиги байтов =) Получается, что улучшенный скролл (карта со сдвигом и без) будет жрать в 2 раза больше памяти. И если правильно въехал, с учетом заполнения "экрана пикселей" матрасом (0F0F), реальное разрешение идет блоками по 4х1 пиксель перерисовкой области атрибутов, а скролл экрана производится сразу целым байтом, т.е. на два "пикселя" 4х1. В принципе, это похоже на познакоместный скролл в обычном экране Спектрума, только тут а ля мультиколор.
Подозреваю, что процедуры сдвига буфера на полбайта и заполнения банков можно здорово ускорить =)
Как там успехи, получается мою процедуру встроить? Глюков не выловлено?

Цитата:

Сообщение от reddie

Почти два раза дольше, учитывая сдвиги байтов =) Получается, что улучшенный скролл (карта со сдвигом и без) будет жрать в 2 раза больше памяти. И если правильно въехал, с учетом заполнения "экрана пикселей" матрасом (0F0F), реальное разрешение идет блоками по 4х1 пиксель перерисовкой области атрибутов, а скролл экрана производится сразу целым байтом, т.е. на два "пикселя" 4х1. В принципе, это похоже на познакоместный скролл в обычном экране Спектрума, только тут а ля мультиколор.
Подозреваю, что процедуры сдвига буфера на полбайта и заполнения банков можно здорово ускорить =)

Всё верно.
Вот такая часть кода, которая сдвигает правый пиксель влево.

Код:

LowCharWrite ; this routine shifts the right pixel of a given character byte into the buffer ld c,7 ;85 ; right pixel mask ld a,4 ; each character is a column of 8 bytes, handled in pairs LowChrWrlp ex af,af' ;1 - save counter ld a,(hl) ;2 - get right pixel from byte and a,c ;1 - mask out left pixel ld b,a ;1 - save result in b ld a,(de) ;2 - get current byte from buffer and a,c ;1 - mask out left pixel rlca ;1 - shift previously right pixel to left rlca rlca or a,b ;1 - add new right pixel to buffer byte ld (de),a ;2 - write back to buffer inc h ;1 - point to next byte in character inc e ;1 - and next byte in buffer ld a,(hl) ;2 - get byte with next right pixel rrca ;1 - even bytes stored swapped, so shift left pixel to right rrca rrca and a,c ;1 - and mask out left pixel data ld b,a ;1 - store result in b ld a,(de) ;2 - get current byte from buffer and a,c ;1 - mask out left pixel rlca ;1 - shift previously right pixel to left rlca rlca or a,b ;1 - add new right pixel to buffer byte ld (de),a ;2 - write back to buffer inc h ;1 - point to next byte in character inc e ;1 - and next byte in buffer ex af,af' ;1 - get counter back dec a ;1 - repeat for all 4 byte pairs jr nz,LowChrWrlp ;2/3 - 33*4-1 = 131 per character, so around 41 scan lines for a whole column jp FillBufCharRet ; return to main loop

Цитата:

Как там успехи, получается мою процедуру встроить? Глюков не выловлено?

Вот пробую, но пока что сразу перескакивает в конец цепочки ldi. А первый раз должно бы в начало, чтобы сразу 78 байт перекинуть.

Цитата:

Сообщение от izzx

пока что сразу перескакивает в конец цепочки ldi. А первый раз должно бы в начало, чтобы сразу 78 байт перекинуть.

Судя по коду, неправильно обрабатывается переменная PrintMapCol. После компиляции в ней 0, и левая часть (половина) вообще не отрисовывается на первом фрейме.
Но это и в исходном коде так же работает, насколько понял. Там изначально должно лежать 78, а потом в процедуре do_scroll_new уменьшаться до 1 каждый фрейм.
Но после компиляции там лежит ноль. Можно попробовать поменять в переменную в шапке (вписать PrintMapCol dw 78 вместо 0).
Или затыка в другом месте?

Цитата:

Сообщение от reddie

Судя по коду, неправильно обрабатывается переменная PrintMapCol. После компиляции в ней 0, и левая часть (половина) вообще не отрисовывается на первом фрейме.
Но это и в исходном коде так же работает, насколько понял. Там изначально должно лежать 78, а потом в процедуре do_scroll_new уменьшаться до 1 каждый фрейм.
Но после компиляции там лежит ноль. Можно попробовать поменять в переменную в шапке (вписать PrintMapCol dw 78 вместо 0).
Или затыка в другом месте?

Там число RightCol+2 в переменную PrintMapCol потом загружается при старте. Надо просто наоборот сделать, чтобы левая часть сначала рисовалась на полную ширину, а правая 0.
Вот так я переделал пока что:

Цитата:

ld a,(PrintMapPag) ;включаем нужную страницу
call PageSlot2G
ld de, BaseScrAddr
ld bc, (PrintMapCol) ;ширина левой части
inc c
dec c
jp z,MapPrint3 ;если C=0, левую часть не рисуем. !JP вместо JR
ld a,80
sub c
ld (skip_R+1),a ;ширина пропуска правой части
rlc c ;умножаем на 2 (LDI - 2 байта)
ld hl,MapPr_L+78*2+2 ;адрес начала строки LDI'шек
and a
sbc hl,bc ;получаем в IX адрес прыжка
push hl
pop ix
ld hl,(PrintMapAddr)
ld a,160 ;кол-во строк

Цитата:

Сообщение от izzx

Там число RightCol+2 в переменную PrintMapCol потом загружается при старте.

Ах вот оно как, этот момент обговорен не был))

Цитата:

Надо просто наоборот сделать, чтобы левая часть сначала рисовалась на полную ширину, а правая 0.

А если попробовать вот так, чтобы без лишних преобразований:

Код:

ld bc, (PrintMapCol) ;ширина левой части inc c dec c jp z,MapPrint3 ;если C=0, левую часть не рисуем. !JP вместо JR ld a,80 sub c ld (skip_R+1),a ;ширина пропуска правой части rlca ld c,a ld ix,MapPr_L ;адрес начала строки LDI'шек add ix,bc ;получаем в IX адрес прыжка

Возможно, будет ошибка на один LDI, тогда скорректировать выражение после MapPr_L (дописать назад +2 либо -2 поставить), и все должно работать.
Я просто не учел логику работы построения адресов таблиц, которая была в изначальном варианте. Там она как бы наоборот сделана, от максимальной к минимальной.
Кстати, левая часть, по идее, рисуется _всегда_, не бывает такого, что выводится только правая. Когда мы в начале экрана - выводим 78 байт целиком, левая=78, правая=0
Когда перебираем смещение, выводим обе части. Как только дошли до "края" - делается переключение страницы и обнуляется сдвиг, правая часть превращается в левую.
Так что эту проверку на ноль в левой части можно выкинуть, она там никогда не должна срабатывать. Если правильно прописана обработка переменных.

Цитата:

Сообщение от reddie

А если попробовать вот так, чтобы без лишних преобразований:

Пока что дела, перерыв. Но уже ускорилось заметно! Теперь целый экран сдвигается почти за 7 секунд, как в оригинале. Осталось немного дожать. Оптимизировать ещё вывод спрайтов. Спасибо большое.
Выложил на облако текущую версию.

Главное, что есть результат =) Основной задачей было оптимизировать работу циклов, она выполнена.
Но если получится реализовать мою идею с выводом карты в одном цикле, выиграем еще 80+ тактов на линию. 160х80 = 12800, за это стоит побороться.
Как будет время, поковыряю исходники.

Ещё немного обновил на облаке. На сегодня хватит.
Отрисовка карты раньше занимала 138К тактов, сейчас 113К. В процедуре вроде бы всё по советам подчистил.
Теперь только из-за медленного вывода спрайтов стала видна неравномерная скорость. Когда спрайтов много, замедляется ).

Код:

;печать готовой карты из памяти MapPrint ld a,(PrintMapPag) ;включаем нужную страницу call PageSlot2G ld hl,(PrintMapAddr) ld de, BaseScrAddr ld bc, (PrintMapCol) ;ширина левой части ;inc c ;dec c ;jp z,MapPrint3 ;если C=0, левую часть не рисуем. !JP вместо JR ld a,80 sub c ld (skip_R+1),a ;ширина пропуска правой части rlca ld c,a ld ix,MapPr_L-2 ;адрес начала строки LDI'шек add ix,bc ;получаем в IX адрес прыжка ld a,160 ;кол-во строк MapPr_L jp (ix) ;начало цикла левой части dup 78 ldi ;перенос edup skip_R ld bc,0 ;в C загружена ширина пропуска, B=0 ex de,hl add hl,bc ex de,hl add hl,bc dec a jp nz,MapPr_L ;JP вместо JR, т.к. команды LDI развернуты в цикле - у JR не хватит смещения MapPrint3 ;печать (или не печать) правой части из след. страницы ld a,(PrintMapCol) cp RightCol+1 ret z ;!JP вместо JR. А по уму достаточно команды RET Z ld a,(PrintMapPag) ;включаем нужную страницу inc a call PageSlot2G ld hl,(PrintMapAddr) ld de,BaseScrAddr ;или ld d,BaseScrAddr/256 (нам нужен только старший байт) ld bc,(PrintMapCol) ld e,c ; ld b,0 ; ld a,78 ;сразу отнимаем 2, зачем лишняя команда (sub 2) ; sub c ld a,c rlca ;умножаем на 2 ld c,a ;смещение для jp (ix) ld ix,MapPr_R+2 add ix,bc ld a,80 sub l ld (skip_L+1),a ;пропуск левой части ld l,b ;b=0 ld a, 160 MapPr_R jp (ix) ;начало цикла правой части dup 78 ldi edup skip_L ld bc,0 ex de,hl add hl,bc ex de,hl add hl,bc dec a jp nz,MapPr_R ;JP вместо JR ;MapPrintE ; можно удалить метку и RET, если ниже MapPrint3 поставить RET Z вместо JP Z ret

Теперь вопрос на засыпку: в первом посте есть ссылка на эмулятор. Он там уже настроен под GMX, сразу можно будет игру запустить?
И второй вопрос: что там за файл 100 мегабайт весом в архиве? Первый раз его вижу, сам эмуль всегда копейки весил.