Edge Grinder для ZS GMX

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

Да ).

Цитата:

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

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

Цитата:

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

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

Если есть желание, можете поругать вот эту часть кода - отрисовка фона, или карты. Занимает больше всего времени. Если использовать команду 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.

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

Оригинал:
https://pic.maxiol.com/thumbs2/16265...854.screen.png https://pic.maxiol.com/thumbs2/16265...584854.222.png

Конверсия:
https://pic.maxiol.com/thumbs2/16265...shot000000.png https://pic.maxiol.com/thumbs2/16265...shot000001.png

Супер!

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

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

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

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

https://i115.fastpic.ru/big/2021/071...fd412fef28.gif

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

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

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

Сообщение от Evgeny Muchkin

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

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

Цитата:

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

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

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

Цитата:

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

То есть в каждой банке памяти (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. Предложения по карте посмотреть интересно

Цитата:

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

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

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

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

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