Edge Grinder для ZS GMX

[reddie]

Насколько понял, восстановление фона под спрайтами не производится, вместо этого перерисовывается весь экран (фон) целиком.
Зато не понял, почему при ширине экрана 80 байт пересылаются только 78. Или так и задумано?
Предположил, что крайний ряд является буфером скроллера, но идет же просто пересылка без сдвигов. Непонятно.
Указано, что карта лежит рядами по 78 байт. А почему так? Она еще и вверх-вниз может скроллиться в игре?
Или откуда эта цифра в 78 байт? Поподробнее о формате хранения куска карты в странице, если можно.

Начнем оптимизировать)) Первое, что сразу бросается в глаза: очень много лишних действий внутри циклов вывода строк.
Скажем, каждый раз вычисляется один и тот же адрес для IX, хотя задавать его нужно всего один раз _перед_ циклом.
Для пар IX/IY обмен с памятью жрет много + тут в цикле берем адрес из таблицы, - огромные потери, около 100 тактов на линию.
Перебрасываем 160 линий, 160х100=16000, если кусками лево-право (работают оба цикла) - уже 32000, это только приблизительно.
Убрав одно лишь задание IX внутри каждого цикла, можно выкинуть кусок кода в красной скобке. Стрелки - команды для оптимизации.



Второе: внутри каждого цикла по две команды LD BC,(nn) - очень расточительно в плане затрат времени. Выделено стрелками.
Команды LD BC/DE,(nn) и обратные - LD (nn),BC/DE - жрут на 4 такта и на байт больше памяти, чем такие же с HL,
поэтому везде, где можно, желательно для обмена с памятью использовать пару HL. Это общая рекомендация для любого кода.
Конкретно в этом примере чтение BC еще и вставлено в цикл, причем циклов два (левый и правый столбец) - теряем много тактов.
Напрашивается прямая загрузка в регистры вместо косвенной (из памяти), размещая переменные сразу в коде циклов.

Теперь посмотрим, как избавиться от таблицы переходов по цепочкам LDI, да и от шести килобайт с этими цепочками заодно.
Целых 6 кило места, которого и так вечно не хватает - слишком жирно. Есть способ скользить по коду намного проще.
Размещаем цепочки LDI с максимальной длиной строки (78) прямо в циклах, заодно убрав схему возврата (LD BC,nn:PUSH BC:RET)
и повторную загрузку после них BC из PrintMapCol, которая станет не нужна, т.к. IX будем задавать перед циклом:

        dup     78
        ldi
        edup

dup и edup с числом - директивы для повтора строк кода между ними, могут зависеть от конкретного ассемблера.
Процедур две (для левой и правой части), поэтому цепочек с LDI тоже будет две. 2 по 160 байт всяко лучше, чем 6 кило.
Осталось переделать обе процедуры "прыжка" в нужное нам место, и возврат по RET отпадает за ненадобностью.
Ниже новый листинг. Все исходные переменные в шапке оставил, но MapLeftPart, MapRightPart и PrintMapCol2 не используются.
Можно еще поиграть с размещением переменных из шапки в коде, но они будут вне циклов - на скорости уже не скажется.

Скрытый текст

BaseScrAddr     equ     #c000   ;адрес экрана
RightCol        equ     #4d     ;последний столбик справа (#4d=77)
MapLeftPart     dw      0       ;число столбцов в левой части экрана для карты  - не нужна, переделана в skip_L
MapRightPart    dw      0       ;число столбцов в правой части экрана для карты - не нужна, переделана в skip_R
PrintMapPag     db      0       ;страница памяти с которой начинается карта
PrintMapCol     dw      0       ;номер текущего столбика для печати
PrintMapCol2    dw      0       ;количество столбцов для переноса справа - не нужна, вычисляем IX до цикла
PrintMapAddr    dw      0       ;текущий адрес карты

MapPrintTable   ;эти две переменные больше не нужны
MapPrintCode    ;т.к. убираем таблицу адресов и цепочки LDI

;печать готовой карты из памяти
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    ;ширина пропуска правой части
        rlc     c               ;умножаем на 2 (LDI - 2 байта)
        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
        jp      z,MapPrintE     ;!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
        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

[свернуть]

Процедура обсчета следующей строки (do_scroll_new) остается без изменений.
Что еще добавить... код не проверялся (набивался в блокноте), возможны глюки =)) Если возникнут вопросы - задавай.
И все равно непонятна фишка с числом 78. Не запуская код и не имея представления о схеме карты. Прошу разъяснить.

[Advertiser]

[izzx]

Насколько понял, восстановление фона под спрайтами не производится, вместо этого перерисовывается весь экран (фон) целиком.

Да, каждый кадр копируется весь фон, а на него спрайты накладываются. В теневой экран, конечно.

Зато не понял, почему при ширине экрана 80 байт пересылаются только 78. Или так и задумано?
Предположил, что крайний ряд является буфером скроллера, но идет же просто пересылка без сдвигов. Непонятно.
Указано, что карта лежит рядами по 78 байт. А почему так? Она еще и вверх-вниз может скроллиться в игре?
Или откуда эта цифра в 78 байт? Поподробнее о формате хранения куска карты в странице, если можно.

В игре почему-то было 78 столбцов на экране. Последние два пустые всегда.
А карта перед стартом прорисовывается вся как на экран, по 78 столбиков. То есть готовая картинка. Хотя, можно было бы и 80 сделать. Потом всё равно склеивать из двух половин.
Буду изучать ваш код.

Так картинка ужасная.

А какая? Сконвертированная, изначальная или обе?

Касательно ГС. Если нужно, могу дать, так сказать, движок. По сути загружалка мода и семплов с их параметрами плюс резидент, упрощающий проигрывание всего загруженного; суть его работы такова, что для запуска какого либо звука, музыки или их остановки, нужно кинуть нужную цифру (команду) в порт #B3. Т.е. проверять служебные биты не требуется, что позволит избежать тормозов. ненужных.

Когда основное доделаю, надо будет посмотреть.

[reddie]

В игре почему-то было 78 столбцов на экране. Последние два пустые всегда.
А карта перед стартом прорисовывается вся как на экран, по 78 столбиков. То есть готовая картинка. Хотя, можно было бы и 80 сделать. Потом всё равно склеивать из двух половин.

То есть в каждой банке памяти (16кб) лежит кусок-экран 78х160?
Если скролла карты вверх-вниз нет (только вбок и все), получается 12кб из 16 занято в банке.
Могу предложить переделать формат карты, тогда картинка всегда будет выводиться в одном цикле (без право-лево).
Выигрываем кое-какое время на убийстве пересчета строк одного цикла, примерно 8 тысяч тактов. Вполне ощутимо.
Возможно, несколько возрастет занимаемая картой память, но с учетом 2мб это не проблема, полагаю.

[izzx]

То есть в каждой банке памяти (16кб) лежит кусок-экран 78х160?
Если скролла карты вверх-вниз нет (только вбок и все), получается 12кб из 16 занято в банке.

Да, кусок карты нарисованный. Скрол только вбок.

Могу предложить переделать формат карты, тогда картинка всегда будет выводиться в одном цикле (без право-лево).
Выигрываем кое-какое время на убийстве пересчета строк одного цикла, примерно 8 тысяч тактов. Вполне ощутимо.
Возможно, несколько возрастет занимаемая картой память, но с учетом 2мб это не проблема, полагаю.

Это может оказаться не просто. У меня сейчас используется родная процедура отрисовки карты. Расчёт координат, потом заполнение буфера шириной 1 байт высотой 160 и переброска буфера на экран. Так рисуется по одному все столбики перед началом игры. Но правда ещё вызывается два раза, потому что в одном байте два виртуальных пикселя.

    ld a,(scroll_step)
    inc a
    ld (scroll_step),a
    call ProcessMapPointer
    call Fill_Buffer


    ld hl,(paint_addr)
    inc hl
    ld (paint_addr),hl
    call Copy_Buffer

P.S. Предложения по карте посмотреть интересно

[reddie]

Это может оказаться не просто. У меня сейчас используется родная процедура отрисовки карты. Расчёт координат, потом заполнение буфера шириной 1 пиксель и высотой 160 и переброска буфера на экран. Так рисуется по одному все столбики перед началом игры.

То есть, насколько понял, карта рисуется поочередно экран за экраном в каждую банку памяти. В принципе, не проблема, если можно произвольно задавать любое смещение начала отрисовки (вплоть до конца карты). Просто компу придется делать двойную работу, сперва строя карту в виде экранов, а потом переводить эти экраны в другой формат. Вертикальный вывод ряда, это, конечно, расчет на аппаратный горизонтальный скроллинг, а вот на Спектруме такое не очень удобно. Для GMX идеально бы подошел вертикальный скролл, но это надо переписывать весь движок игры и переделывать графику.

А есть возможность изменить высоту строящейся пиксельной строки и координаты начала вывода? Суть в чем: для наилучшей переделки вывода под то, что я задумал, нужно разбить вывод экранов напополам, верхнюю и нижнюю часть. Соответственно, в процедуре построения нужно поменять два параметра: высоту строки (80 вместо 160) и текущий адрес вывода, причем мало будет просто задать координаты, - нужно, чтобы процедура понимала, что строит нижнюю часть, а не заново верхнюю половину. Наиболее простой выход - вклиниться в середину процедуры, сделав разбивку на части. Наподобие того, что применено в выводе карты на экран из банков (левая и правая части).

Если не получиться разобраться, могу попробовать сам, благо, исходники для Спектрума в первом посте, как понимаю.

[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. В принципе, это похоже на познакоместный скролл в обычном экране Спектрума, только тут а ля мультиколор.
Подозреваю, что процедуры сдвига буфера на полбайта и заполнения банков можно здорово ускорить =)
Как там успехи, получается мою процедуру встроить? Глюков не выловлено?