Портирование игр с PC на БК

[Manwe]

Глюки порождают "современное искусство". Буду бороться с ним

[S_V_B]

Дизассемблирую программки для УКНЦ наткнулся на такую конструкцию:
seg001:006676 mov #2600, R0
seg001:006702 mov #2500, word_17414
seg001:006710 call sub_17420
seg001:006714 br loc_6676
.................................................. ..........
.................................................. ..........
seg001:017420 mov SP, word_17412
seg001:017424 call sub_56274
.................................................. ..........
.................................................. ..........
seg001:056274 sub_56274: ; CODE XREF: sub_12226↑P
seg001:056274
seg001:056274 mov (SP)+, #0
seg001:056300 mov R1, -(SP)
seg001:056302 mov R2, -(SP)
seg001:056304 mov R3, -(SP)
seg001:056306 mov R4, -(SP)
seg001:056310 mov R5, -(SP)
seg001:056312 call @sub_56274+2
seg001:056316 mov (SP)+, R5
seg001:056320 mov (SP)+, R4
seg001:056322 mov (SP)+, R3
seg001:056324 mov (SP)+, R2
seg001:056326 mov (SP)+, R1
seg001:056330 return
seg001:056330 ; End of function sub_56274

Для чего может использоваться такая процедура?

[Manwe]

Для чего может использоваться такая процедура?

Самое интересное, по-моему, пропущено (второй ряд многоточий).
Я так понимаю, call sub_56274 делает следующее: сохраняет в стек регистры с R1 по R5, возвращается чтобы выполнить команды, идущие после call sub_56274 (где многоточия). Потом, встретив команду return, процедура восстановит из стека регистры с R1 по R5 и продолжит выполнение. А что там дальше со стеком и возвратом в основную программу - непонятно. Скрыто за многоточиями.
То есть смысл всего этого - одной командой сохранить и восстановить регистры до и после вызова подпрограммы.

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


Выкладываю bin и исходники алгоритма вывода спрайтов без мерцания посредством дельта-буфера.
Получилось изящно, занимает мало памяти, но... жутко тормознуто. Для игр где много больших спрайтов не годится.
delta-algorithm.zip

[S_V_B]

Зачем она сама себя вызывает.. call @sub_56274+2..
многоточия это три разных процедуры.. начинается все с call sub_17420.. идет дальше на sub_56274..
а внутри нее call @sub_56274+2.. вот в чем вопрос..
...
то что они пытаются сделать PUSHA я догадываюсь этот вызов часто встречается..
и вообще такое ощущение что на ЯВУ написано, передача параметров через стек делается.. везде.


/* Выкладываю bin и исходники алгоритма */
Чуть бы побыстрее и было бы новое слово в игрописательстве..
На УКНЦ этот алгоритм наверное тоже не подойдет потому что все нужно будет делать 2 раза

[Manwe]

Зачем она сама себя вызывает.. call @sub_56274+2..

Она не себя вызывает, она берёт число #0 (только оно уже не 0, а заменено на адрес) и переходит по этому адресу.

и вообще такое ощущение что на ЯВУ написано, передача параметров через стек делается.. везде.

Похоже, да.

Чуть бы побыстрее и было бы новое слово в игрописательстве..

Если выполнять в статической памяти контроллера SMK, то будет намного быстрее.

На УКНЦ этот алгоритм наверное тоже не подойдет потому что все нужно будет делать 2 раза

А зачем два раза?

[S_V_B]

/* А зачем два раза? */
Ну плана ВОЗУ два же используем.. это в БК все за раз делается..
Да и с регистровым доступом все равно долго будет.

/* и переходит по этому адресу. */
А ну да.. что-то я торможу.. это действительно PUSHA..
в #0 .. лежит адрес возврата и когда делает call то возвращается в вызывающую процедуру но с сохраненными регистрами, а потом возвращается чтобы их восстановить.. точно ЯВУ.. потому что понатыкано где надо и где нет..

хотел подсмотреть как они в "NEWTET.SAV" периферийным процом общаются, но код тяжело читается..

[Advertiser]

[Manwe]

Попробую ещё одну идею вывода спрайтов.
Поскольку больше двух спрайтов вряд ли буду пересекаться в одном месте, а если и будут, то три наложенных спрайта – это уже непонятная каша, то можно попарно сравнивать спрайты и искать области пересечения. Если такие области есть, то дополнять изображение в соответствующей области каждого спрайта, взяв пиксели (целыми словами) из другого спрайта.
Если в какой-то области будет пересечение трёх и более спрайтов, то алгоритм обработает только первое найденное пересечение.
Спрайты сначала целиком копируются во временный буфер (с применением сдвига на сколько-то точек), потом запускается поиск пересечений по координатам и размерам, в конце происходит обмен пикселями (словами) в найденных областях.
Муторная выйдет подпрограмма вычисления области пересечения. Некрасивая.

update: можно придать чуть-чуть красоты, сравнивая попарно левые и правые границы двух спрайтов и устанавливая (или сбрасывая) один бит для каждого сравнения. Получим число (16 вариантов), которое можно использовать как индекс в таблице ссылок на разные процедуры (для разных типов пересечений).

[Hunta]

Дизассемблирую программки для УКНЦ наткнулся на такую конструкцию

Извращение какое то. (насколько я помню, но правильный вариант легко восстановим) Это делает так:

        JSR  R5, $SAVAL
        ...
        RETURN
        ...

$SAVAL: MOV R0, -(SP)
        MOV R1, -(SP)
        MOV R2, -(SP)
        MOV R3, -(SP)
        MOV R4, -(SP)
        MOV R5, -(SP)
        CALL @(SP)+
        MOV (SP)+, R4
        MOV (SP)+, R3
        MOV (SP)+, R2
        MOV (SP)+, R1
        MOV (SP)+, R0
        MOV (SP)+, R5
        RETURN

[jerri]

Попробую ещё одну идею вывода спрайтов.
Поскольку больше двух спрайтов вряд ли буду пересекаться в одном месте, а если и будут, то три наложенных спрайта – это уже непонятная каша, то можно попарно сравнивать спрайты и искать области пересечения. Если такие области есть, то дополнять изображение в соответствующей области каждого спрайта, взяв пиксели (целыми словами) из другого спрайта.
Если в какой-то области будет пересечение трёх и более спрайтов, то алгоритм обработает только первое найденное пересечение.
Спрайты сначала целиком копируются во временный буфер (с применением сдвига на сколько-то точек), потом запускается поиск пересечений по координатам и размерам, в конце происходит обмен пикселями (словами) в найденных областях.
Муторная выйдет подпрограмма вычисления области пересечения. Некрасивая.

update: можно придать чуть-чуть красоты, сравнивая попарно левые и правые границы двух спрайтов и устанавливая (или сбрасывая) один бит для каждого сравнения. Получим число (16 вариантов), которое можно использовать как индекс в таблице ссылок на разные процедуры (для разных типов пересечений).

помнится как-то видел такой алгоритм рисования

по маске удаляется старая фаза спрайта
потом поверх накладывается новая фаза
при пересечении выглядело занятно
если интересно игра со спека DanDare2

сама маска для удаления создавалась из спрайта

[Manwe]

Я сейчас пишу другую маленькую игру, отлаживаю на ней всякие сопутствующие моменты. Из полученного опыта вот что думаю на счёт Last Mission:
При переходе в новую комнату нужно не только рисовать лабиринт, но также генерировать все варианты используемых в этой комнате спрайтов врагов. Я имею в виду варианты спрайтов со сдвигом на 1,2 и 3 точки. Если есть такие варианты, то процедура вывода получится самой быстрой.
Хранить в памяти все возможные спрайты по 4 раза - расточительно, места не хватит. Но если только те, которые используются в данной комнате - может, и хватит.