Edge Grinder для ZS GMX

[izzx]

А можно запилить видео прохождения (ну, в смысле, работы движка) на ютуб, например? А то без GMX и не посмотреть ))

На счёт видео подумаю. Не знаю пока чем и захватывать. А так, есть же ссылка на эмулятор, запустить не сложно. В эмуляторе, мне показалось, выглядит несколько плавнее, чем на железе, но в целом так же. Если ещё сделаю попиксельный скрол, будет получше.

Кстати, в списке схожих тем (внизу) выдало вот это https://zx-pk.ru/threads/28459-v-raz...e-grinder.html
Но там всего один пост с анонсом и на этом все. Хотя, походив по ссылкам, можно понять, что выходила версия под ZX Evo.
А вот для обычного Спека так и не понял, вышла или нет.

Что-то я тоже готовой версии для классики не видал.
Кстати, вопрос про версию для Base conf: там таки есть аппаратный скрол? Немного посмотрел в отладчике, там тактов мало уходит на каждый кадр.

Теперь понял, для чего был вопрос о процедуре перехода вниз на строку GMX =) Полагаю, именно для этой игрухи.

Да ).

Если у автора будет желание оптимизировать код или еще как-то улучшить игру - стоит сказать об этом здесь.

Я буду думать как оптимизировать вывод фона. Может тут выложу кусок кода с вопросом. Там надо склеить каждый кадр из двух половинок в разных страницах памяти.

Конечно, не обладая девайсом, желающие помочь проверить работу не смогут, но для процедурной оптимизации это и не нужно.

Эмулятор довольно не плох. Немного по тактам отличается и ещё нюансы есть небольшие.

[izzx]

Если есть желание, можете поругать вот эту часть кода - отрисовка фона, или карты. Занимает больше всего времени. Если использовать команду ldi в 16 тактов, фон размером 160*78 должен копироваться за 199680 тактов. А в режиме турбо всего тактов примерно 123872. Значит, могло бы уложиться в два прерывания. То есть, максимум 25 кадров в секунду где-то в теории. А у меня пока что 16 кадров.
Карта готовая лежит в памяти по 78 столбиков на странице.
Каждый кадр вызывается do_scroll_new для изменения переменных, а затем MapPrint для переброски карты на экран.
Думаю, тут слишком много "обвязки" и есть лишние переменные.

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

MapPrintTable equ #4000 ;таблица адресов команд копирования 1-78 байт
MapPrintCode equ #4100    ;наборы команд ldi от 1 до 78 подряд, и ret  в конце, формируется автоматически при старте, занимает 6240 байт

;печать готовой карты из памяти
MapPrint 
    
    ld a,(PrintMapPag) ;включим нужную страницу
    call PageSlot2G
    
    
    ld hl,(PrintMapAddr)
    ld bc,(PrintMapCol) ;сколько байт переносить левая часть
;    inc c
    ld de,BaseScrAddr
    ld a,80
    sub c
    cp 80
    jr nc,MapPrint3 ;пропустим если левую часть не надо рисовать
    ld (MapRightPart),a
    ld a,20*8 ;высота для переноса
    


MapPrint1    
    ;ldir
    push hl ;
    ld hl,MapPrintTable-2
    add hl,bc
    add hl,bc ;теперь известен адрес ссылки на цепочку ldi
    ld c,(hl)
    inc hl
    ld b,(hl)
    push bc ;сохраним адрес цепочки
    pop ix
    pop hl
    ld bc,MapPrint11 ;адрес возврата
    push bc
    jp (ix) ;переход на адрес
    
MapPrint11    
    ex de,hl ;пропустим правую часть
    ld bc,(MapRightPart)
    add hl,bc
    ex de,hl
    add hl,bc    
    ld bc,(PrintMapCol)
    dec a
    jr nz,MapPrint1
    
MapPrint3    
;теперь печать правой части из следующей страницы
    ld a,(PrintMapCol)
    cp RightCol+1
    jr z,MapPrintE ;пропустить если не надо
    
    ld a,(PrintMapPag) ;включим нужную страницу
    inc a
    call PageSlot2G
    
    ld hl,(PrintMapAddr)
    ld de,BaseScrAddr
    ld bc,(PrintMapCol)
    ld e,c
    ld b,0 ;сколько байт переносить правая часть
    ;ld c,l
    ld a,80
    sub c
    sub 2 ;минус два последних столбика не рисуются
    ld c,a
    ld (PrintMapCol2),bc
    ld a,80
    sub l
    ld (MapLeftPart),a
    ld l,0 ;правая часть карты должна копироваться с начала
    ld a,20*8 ;высота для переноса
    
    
MapPrint2    
    ;ldir
    push hl ;
    ld hl,MapPrintTable-2
    add hl,bc
    add hl,bc ;теперь известен адрес ссылки на цепочку ldi
    ld c,(hl)
    inc hl
    ld b,(hl)
    push bc ;сохраним адрес цепочки
    pop ix
    pop hl
    ld bc,MapPrint22 ;адрес возврата
    push bc
    jp (ix) ;переход на адрес
    
MapPrint22    
    ex de,hl ;пропустим левую часть
    ld bc,(MapLeftPart)
    add hl,bc
    ex de,hl
    add hl,bc    
    ld bc,(PrintMapCol2)
    dec a
    jr nz,MapPrint2
    
    
MapPrintE    
    ret
    
    
    
    
MapCopyMake ;формирует код быстрого переброса карты, т.е. цепочек ldi
    ld ix,MapPrintTable ;таблица переходов
    ld hl,MapPrintCode ;формируемый код
    ld a,78 ;всего строк
    ld c,1 ;начнём с одной ldi
MapCopyMake2
    ld b,c
    ld (ix),l ;запомнить адрес перехода
    inc ix
    ld (ix),h
    inc ix
MapCopyMake1    
    ld (hl),#ed
    inc hl
    ld (hl),#a0    ;код ldi
    inc hl
    djnz MapCopyMake1
    ld (hl),#c9 ;код ret
    inc hl
    inc c
    dec a
    jr nz,MapCopyMake2    
    ret
MapCopyMakeEnd    


    org #6ac0
do_scroll_new
;рассчёты для отрисовки готовой карты из памяти    
    ;сначала адрес вывода на экран
    ld hl,(PrintMapAddr)
    inc hl
    ld a,l
    cp RightCol+1 ;не дошло до края экрана?
    jr c,do_scroll_new1
    ld l,0
do_scroll_new1
    ld (PrintMapAddr),hl
    ;теперь столбик склейки двух частей    левой и правой
    ld a,(PrintMapCol)
    dec a
    jr c,do_scroll_new2
    ;пора на след.страницу памяти
    ld hl,PrintMapPag
    inc (hl)
    ld a,RightCol+1
do_scroll_new2
    ld (PrintMapCol),a
    ret


do_scroll_newEnd

Кстати, драйвер памяти для игры взят от TRDN, только не помню чья именно версия, а опрос клавиатуры от DragonsLord.

[izzx]

Нашёл глюк в своём конвертере графики и разобрался с палитрами. Теперь конвертирует идеально, на мой непросвещённый взгляд.

Оригинал:


Конверсия:

[Evgeny Muchkin]

Супер!

- - - Добавлено - - -

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

[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. Не запуская код и не имея представления о схеме карты. Прошу разъяснить.

[PATHNK]

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

[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) и текущий адрес вывода, причем мало будет просто задать координаты, - нужно, чтобы процедура понимала, что строит нижнюю часть, а не заново верхнюю половину. Наиболее простой выход - вклиниться в середину процедуры, сделав разбивку на части. Наподобие того, что применено в выводе карты на экран из банков (левая и правая части).

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