Edge Grinder для ZS GMX

[izzx]

Но тогда получается, что затираем сразу два "пикселя" экрана (карты), даже если один из них пустой в спрайте. Или там у спрайтов все "пиксели" по два шириной?

Да, сразу по два пикселя. Может спрайты нарисованы с учётом этого, не заметно.

Не, это другие команды. LD (NN),HL подходит для переброса карты через стек по 2 байта сразу, а вот спрайты без стека и побайтово, через LD (HL),N - стек не трогается.

Да, перепутал команды. Для спрайтов LD (HL),N.

Но если выводим вертикально - зачем брать следующий адрес из таблицы?

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

зы. Попробую переформатировать спрайты, чтобы выводить по линиям. За счёт переходов хотя бы ускоримся.

[izzx]

Теперь должны быть стабильные 25 кадров.
Переделал формат спрайтов для вывода по частям.
Оптимизировал пару процедур и сделал так, чтобы в тот момент, когда проседал FPS, второстепенный код не выполнялся.
Выложил тест. Если не укладывается в два прерывания, мигает (мигал бы) красным.

[reddie]

сделал так, чтобы в тот момент, когда проседал FPS, второстепенный код не выполнялся

Если он "второстепенный" и не критичен для работы - может, его вообще убрать? =))
Поглядел изменения - не во все въехал. Трудновато вникать в чужие исходники, да еще переписанные по диагонали (эт я про адаптацию с Амстрада).
Но озадачил вот этот момент (файл EG_Sprites10.asm):

; sprites are 6 bytes wide, so repeat another 5 times
    ld a,(hl)
    ld (de),a
    inc e;
;    res 3,h
;---
	push de
	ld de,80
	and a
	sbc hl,de
	pop de
;---
    ldi
;    set 3,h
;---
	push de
	ld de,80
	add hl,de
	pop de
;---
;
    ld a,(hl)
    ld (de),a
    inc e
;    res 3,h
;---
	push de
	ld de,80
	and a
	sbc hl,bc
	pop de
;---
    ldi
;    set 3,h
;---

Если это вывод спрайтов - он так и остался вертикально-побайтово. Но даже если это что-то иное - процедура значительно похудеет и ускорится, если убрать LDI оттуда.
Заменяем LDI на 4 команды (LD A,(HL):LD (DE),A:INC E/DE:INC L/HL), зато освобождаем пару BC, и можно убрать PUSH-POP DE, заменив в сложении/вычитании DE на BC:

	and a
	sbc hl,bc

Еще и не нужно будет каждый раз загружать число 80 в BC.

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

Подумал - LDI можно оставить, просто после каждого LDI добавить команду INC C (чтобы восстановить значение 80) - это быстрее и короче, чем 4 команды вместо LDI.
Достаточно загрузить один раз 80 в начале процедуры и все. Основное же изменение останется (уборка PUSH-POP DE и замена DE на BC).

[izzx]

Если он "второстепенный" и не критичен для работы - может, его вообще убрать? =))

Второстепенными я посчитал обновление счётчика рекорда и жизней для второго экрана. У меня просто копируются эти области командами ldi на второй экран. Иначе будет разница. Печатается то на одном экране.
И плюс ещё звёзды перестают мерцать во время взрыва игрока. Это самый загруженный момент. FPS проседало тут.

Если это вывод спрайтов - он так и остался вертикально-побайтово. Но даже если это что-то иное - процедура значительно похудеет и ускорится, если убрать LDI оттуда.

Да, это две процедуры SaveSpriteBG и RestoreSpriteBG, они выполняются только после выигрыша. Их я не правил ещё, хорошо что напомнили. Им, кстати, не важен формат вывода, просто надо сохранить кусок экрана и потом вернуть. Там уже не используется два экрана, только на одном рисуется.
Может ещё что забыл, надо просмотреть.

[reddie]

Еще один файлик для возможной оптимизации - EG_Sprites_Player вроде это вывод спрайтов игрока.

	inc ixl
	inc ixl

	ld l,(ix+0)  ;2я строка
	ld h,(ix+1)
	;ld (hl),0
	inc hl
	;ld (hl),0
	inc hl
	;ld (hl),0
	inc hl
	;ld (hl),0
	inc hl
	;ld (hl),0
	inc hl
	;ld (hl),0
	and a
	sbc hl,bc  ;1я строка
	;ld (hl),0
	inc hl
	;ld (hl),0
	inc hl
	;ld (hl),0
	inc hl
	;ld (hl),0
	inc hl
	;ld (hl),0
	inc hl
	;ld (hl),0

Все инструкции LD (HL),0 закомментированы, и там куча пустых строк с ними.
Проверить бы всю строку, если она пустая - зачем щелкать HL, можно сразу переходить на следующую.
И еще, какие-то извращенские методы доставания адреса строк через IX, это жрет много времени =)
Получается, что на каждую вертикальную координату экрана своя таблица адресов?
Сколько ж эти таблицы жрут? Или я не догоняю логику работы процедуры вывода?
Саму процедуру можно ускорить, для начала заменив IX и работу с ним на DE:

	EX	DE,HL
	LD	E,(HL)
	INC	L
	LD	D,(HL)
	INC	HL
	EX	DE,HL

Выигрыш где-то 20 тактов на переход. Немного, но... либо задействовать DE во втором ускорении ниже.
Второе: в коде куча повторяющихся байт, наиболее частый, вроде, 45. Можно распихать самые частые по регистрам.
Свободных регистров у нас получается три: A, E и D (если оставить IX), либо только A.
То бишь пишем в память не числа, а регистры. Получится строка типа такой (заменив 45 на аккум):

	ld l,(ix+0)  ;2я строка
	ld h,(ix+1)
	;ld (hl),0
	inc hl
	ld (hl),a
	inc hl
	ld (hl),41
	inc hl
	ld (hl),a
	inc hl
	ld (hl),a
	inc hl
	ld (hl),8
	and a
	sbc hl,bc  ;1я строка
	ld (hl),9
	inc hl
	ld (hl),a
	inc hl
	ld (hl),61
	inc hl
	ld (hl),63
	inc hl
	ld (hl),a
	inc hl
	ld (hl),a

	inc ixl
	inc ixl

Выигрыш тоже небольшой, однако по чуток, да набирается экономия, если еще и адреса из DE брать.

[izzx]

Проверить бы всю строку, если она пустая - зачем щелкать HL, можно сразу переходить на следующую.

Вот это правильная мысль, конечно. У меня в генераторе на C# код стругается, теоретически можно бы сделать что угодно.

Получается, что на каждую вертикальную координату экрана своя таблица адресов?

SpriteAddrHigh ds 170 ;адреса спрайтов по 2 байта для каждых 10 пар строчек и одной последней = 22 байт на спрайт *7 штук и 16 на лазер
То есть рассчитывается адрес начала каждой второй строчки. 1,3,5,..21.
Потом при печати берём адрес второй строчки, рисуем её, поднимаемся на строку выше, рисуем её. Так перешло от версии амстрад.
Я выше говорил, что это нужно для частичной печати спрайта на верхней и нижней границе экрана.

Саму процедуру можно ускорить, для начала заменив IX и работу с ним на DE:

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

То бишь пишем в память не числа, а регистры. Получится строка типа такой (заменив 45 на аккум):

Идею понял, но это хитро надо генератор на C продумывать ). Чтобы он такой умный код выдал.

ps. Да, если смотреть исходники с подсветкой синтаксиса, то закомментированное не так бросается в глаза. Я вот в Notepad++ редактирую.

ps2. Вот тут в прошлый раз так оптимизировал расчёт координат спрайтов, в случае когда регистры, кроме IY и IX, заняты и запись через стек. Нужно сдвинуть DE на 80 вниз.
Было:

;---
	ld (TempHL),hl  ;16 на строку вниз
	ld hl,80		;10
	add hl,de		;11	
	ex de,hl		;4
	ld hl,(TempHL)	;16
; ;---
        push de 		;11 ; place address into address list pointed to by sp
				;68

Стало:

	ld iy,80		;14
	add iy,de		;15
	push iy		;15
				;44

[izzx]

Очередная оптимизация.
Теперь формат спрайтов полностью линейный и последовательный.
Формат шрифтов и значков жизней остался Amstrad.
Финальная заставка и затемнение картинки загрузчика сделаны через два экрана.

Закомментированы лишние команды inc hl при выводе спрайтов, когда строчка пустая.

SpritesPrint0
    ld bc,80-5
    ;ld l,(ix+0)  ;1я строка
    ;ld h,(ix+1)
    ;ld (hl),0
    ;inc hl
    ;ld (hl),0
    ;inc hl

Спрайты в прямом формате
0 1 2 3 4 5 6
7 8 9 ...
............125

Вместо конструкции типа

and a
sbc hl,bc

везде стало

add hl,bc

Сэкономили целых 8 тактов.
Кроме того, без лишних переходов процедура подсчёта адресов спрайтов сразу похудела тысячи на 4 тактов.

Ещё не все советы от reddie реализованы, можно оптимизировать долго ).