Спрайты

[tnt23]

КДПВ:



(Пре-альфа арканоида растет там же, где и тетрис на гитхабе)

[Advertiser]

[jerri]

tnt23, а какое строение экрана у Океана?

[tnt23]

tnt23, а какое строение экрана у Океана?

256 строк по 512 пикселей в строке в монохромном режиме, и 256 пикселей в строке в цветном режиме. Экран начинается с адреса 4000h и растет с левого верхнего угла вниз до 40FFh, затем следующая колонка 4100h-41ffh и так далее. В монохромном режиме один бит - один пиксель.

В цветном режиме цвет каждого пикселя задается двумя битами: одним с адреса 4000h (если взять для примера верхний левый угол), а другим с адреса 4100h. Получается, что в цветном режиме есть два цветовых битплана, которые "перемешаны" друг с другом: один битплан занимает адреса 40xxh, 42xxh, 44xxh..., второй занимает адреса 41xxh, 43xxh, ... .

По поводу рисования спрайтов. Сейчас для будущего Арканоида взята без изменений процедура PaintBitmap из Тетриса, которая просто выводит на экран цветной битмап 8x8 пикселей:

; *************************************************
; PaintBitmap - нарисовать битмап 8х8
; HL - адрес битмапа
; BC - X и Y
; A - биты плоскостей
; *************************************************

В аккумуляторе передаются биты плоскостей, которые нужно нарисовать. Сам битмап кодируется просто: в памяти последовательно идут 8 байт для первого битплана, следом за ними 8 байт для второго битплана. Если установлен бит 0 в аккумуляторе, то выводятся (копируются) байты для первого битплана, для установленного бита 1 - то же для второго битплана.

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

; *************************************************
; PaintBitmap - нарисовать битмап 8х8
; HL - адрес битмапа
; BC - X и Y
; A - биты плоскостей
; *************************************************
PaintBitmap
        di
        push    bc
        push    de
        
        push    a
        ; Отключаем ПЗУ для доступа к экранному ОЗУ
        mvi     a, ENROM
        out     BANKING
        
        push    hl
        lxi     h, SCREEN
        mov     d, b
        mvi     e, 0
        dad     d       ; hl = SCREEN + X*256
        mvi     d, 0
        mov     e, c
        dad     d       ; hl = hl + Y
        pop     de       ; de = адрес битмапа

        pop     a       ; плоскости
        
Plane1
        rrc
        jnc     Plane2
        call    Copy8
Plane2        
        rrc
        jnc     PlaneDone

        ; Второй план битмапа
        push    h
        lxi     h, 8
        dad     d
        xchg

        ; Перейдем ко второму плану экрана
        pop     h
        inr     h
        call    Copy8

PlaneDone
        ; Включаем ПЗУ обратно
        xra     a
        out     BANKING
        
        pop     de
        pop     bc
        ei
        ret

Copy8
        push    h
        push    d
        push    a
        mvi     c, 8
PBLoop  ldax    d
        mov     m, a
        inx     d
        inx     h
        dcr     c
        jnz     PBLoop
        pop     a
        pop     d
        pop     h
        ret

[свернуть]

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

[ivagor]

Экран начинается с адреса 4000h

С 4000h он в основном для пзушных процедур начинается, игрушкам работающим в озу имхо удобнее использовать экран с 0C000h (сам я в океанских программках только такой вариант и использовал).

[tnt23]

С 4000h он в основном для пзушных процедур начинается, игрушкам работающим в озу имхо удобнее использовать экран с 0C000h (сам я в океанских программках только такой вариант и использовал).

Да, это я перепутал. Экранное ОЗУ находится по адресу 0C000h, конечно.

[tnt23]

По мотивам обсуждения с ivagor переделал простой вывод мячика на более сложный, буферно-слоёный. Теперь мячик рисуется не прямиком на экран, а в отдельный буфер 8x16 пикселей:

• сначала в буфер рисуется фон. Пока он исключительно черный, но в перспективе ничто не мешает вместо нулей подложить изображение размером с игровое поле или вообще во весь экран;
• затем в буфер отрисовываются кирпичи из ближайших к мячику окрестностей;
• затем в буфер отрисовываются несуществующие пока спрайты несуществующих еще врагов;
• и апофеозом по OR туда лепится мячик. Я уже морально созрел добавить маску мячика (в виде множества фаз) и лепить его в буфер по AND маски и OR спрайта.

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



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

[ivagor]

tnt23, признайся, ты специально провоцируешь мою занудную компоненту? Если есть различие по направлениям, то это анизотропия.

[tnt23]

tnt23, признайся, ты специально провоцируешь мою занудную компоненту? Если есть различие по направлениям, то это анизотропия.

Я не специально у меня помесь лени с дизлексией. Помнил про анизотропность, но ленился проверить, то ли это или нужен антоним (надеюсь, с применением слова "антоним" я не облажался)

[ivagor]

Откуда я помню этот ненужный термин
1. Анизотропное шоссе у Стругацких.
2. Каждый год много лет долбил про диффузное (однородное и изотропное) звуковое поле, в итоге даже сам запомнил.

[tnt23]

1. Анизотропное шоссе у Стругацких.

Собственно, и я оттуда же. Но когда читал, не заострился на выяснением точного значения. (заканчиваю оффтопить)