Вывод атрибутов из буфера

[ALKO]

можно даже смещение для следующей строки хранить рядом с байтами размера

Не стоит забывать, что я убер-ламер в прогинге
И исходя из такого совета наваяю что-то вроде
Push hl
ld h, (Sprite_addr+3)
add h
...
Pop hl

Что значительно прибавит тактов.

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

Хотя... Наверное можно предварительно загнать в exx перед входом в процедуру.

[goodboy]

загнать в exx

не забудь что для бейсика важно значение HL`

[ALKO]

не забудь что для бейсика важно значение HL`

Если в Бейсцык RETиться не собираюсь, то не страшно ведь?

[Bedazzle]

Если в Бейсцык RETиться не собираюсь, то не страшно ведь?

Смотри, как было предложено выше, формат спрайта
Первый байт ширина
Второй байт высота
Дальше идут все байты спрайта.

При вызове процедуры печати берёшь первый байт, вносишь его значение в то место, где инициализируется цикл, отвечающий за проход по ширине.
Также вычисляешь смещение по горизонтали, вносишь туда, где идёт приращение адреса.
Берёшь второй байт, вносишь туда, где инициализируется цикл, отвечающий за кол-во строк по высоте.
Дальше используешь свою процедуру, которую ты приводил в начале.

P.S.
если спрайтов дофига, и нужно экономить память, то если размер не превышает 16х16, можно кодировать размер в один байт - ширина 4 бита, и высота 4 бита.
Скажем, так

sprite:
    db %WWWWHHHH
    db ..... .....    ; тут идут данные спрайта  


    ld hl, sprite
    ld a,(hl)
    and %00001111   ; получили высоту
    ld (DRAW_SPRITE2-1), a
    
    ld a,(hl)
    rrca
    rrca
    rrca
    rrca
    and %00001111    ; получили ширину
    ld (DRAW_SPRITE1-1), a

    ld c, a
    ld a, 64                   ; buffer_width
    sub c                      ; вычислили ширину приращения в буфере
    ld (SCREEN_ADD-1), a

    inc hl

    и дальше отрисовка спрайта

[Lethargeek]

Не понял. В hl же адрес экрана должен быть? Зачем оттуда читать?

адрес никому ничего не должен, где удобней, там и располагаем, можно в de

Ну, это зависит можно ли раздувать память под спрайты.

ох, раздули, плюс один байтик на спрайт, караул!
не волнует, у нас всё-таки не быкашка))

И оно будет медленнее, чем модифицирующийся хардкод.

с чего вдруг? хардкод нужен только где в регистры всё не влезает, например:

; hl - адрес в буфере, de - адрес спрайта

		ld a,(de)	; смещение
		ld c,a
		inc de
		ld a,(de)	; ширина
		ld (#),a
		inc de
		ld a,(de)	; высота

_0		exa
		ld b,#	; только здесь хардкодим

_1		inc de
		ld a,(de)
		or a
		jr z,_2
		ld (hl),a
_2		inc l
		djnz _1
		add hl,bc
		exa
		dec a
		jp nz,_0
		ret

вместо inc de везде можно чуть быстрее inc e если спрайты не пересекают #XX00

но вообще мне что-то кажется, с такой графикой спеку заведомо и памяти хватает, и скорости

[ALKO]

Усë уже. Разобрался.
Только вместо inc de, я сразу жахнул la a,(addr_spr+1).
Правда не знаю, как воспримет это компиль на уровне маш. кодов.

но вообще мне что-то кажется, с такой графикой спеку заведомо

Очень хотелось бы в это верить...Всë-таки пиксели расходуются слишком расточительно. Целый байт на пиксель слишком жырно. Фактически VGA. А цветопередача на порядок хуже.

[Advertiser]

[reddie]

Целый байт на пиксель слишком жырно. Фактически VGA. А цветопередача на порядок хуже.

Зато куча псевдоцветов через шахматку, пусть и ужасными 8х8 квадратами =)
Вот если бы Синклер вместо бесполезного Flash потратил этот бит на яркость бумаги, чтобы яркость INK и PAPER была раздельной - "цветов" было бы еще больше.
Да и вообще, графика в таком режиме довольно интересно смотрится. Дорабатывал свой Скорпион в давние времена, всего-то одна кнопка П2К c фиксацией.

[Lethargeek]

Только вместо inc de, я сразу жахнул la a,(addr_spr+1).

да нормально должен воспринимать, просто это же и длиньше, и медленней
по возможности структуры данных надо косвенно-последовательно адресовать

Целый байт на пиксель слишком жырно. Фактически VGA.

да не жырно, пикселей намного меньше же общим счётом