Edge Grinder для ZS GMX

[izzx]

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

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

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

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

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

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

[reddie]

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

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

[izzx]

Почти два раза дольше, учитывая сдвиги байтов =) Получается, что улучшенный скролл (карта со сдвигом и без) будет жрать в 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 байт перекинуть.

[reddie]

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

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

[izzx]

Судя по коду, неправильно обрабатывается переменная 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 ;кол-во строк

[reddie]

Там число 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
Когда перебираем смещение, выводим обе части. Как только дошли до "края" - делается переключение страницы и обнуляется сдвиг, правая часть превращается в левую.
Так что эту проверку на ноль в левой части можно выкинуть, она там никогда не должна срабатывать. Если правильно прописана обработка переменных.

[izzx]

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

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

[reddie]

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

[izzx]

Ещё немного обновил на облаке. На сегодня хватит.
Отрисовка карты раньше занимала 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

[reddie]

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