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

[Manwe]

Самое очевидное и выигрышное по скорости решение - хранить каждый спрайт 4 раза: оригинальный и заранее сдвинутый на 1, 2 и 3 точки. Да только вот памяти жалко. Хочется уложиться в возможности БК-0010.

Анимированная платформа у меня уже по экрану едет, надо только понять что с ней делать дальше. Может быть для движения влево и вправо использовать разные процедуры. Универсальная процедура даёт слабозаметный эффект растяжения спрайта при движении в одну сторону и сжатия при движении в другую. Если отслеживать луч, то этого видно не будет. Но на БК-0010 луч не отследишь (если только не грязными хаками), да и ограничивать fps не хочуется.

[Advertiser]

[nzeemin]

Самое очевидное и выигрышное по скорости решение - хранить каждый спрайт 4 раза: оригинальный и заранее сдвинутый на 1, 2 и 3 точки. Да только вот памяти жалко. Хочется уложиться в возможности БК-0010.

В исходниках Highway Encounter для УКНЦ есть процедуры вывода ч/б спрайтов 16x24 с маской, со сдвигом на -2/0/2/4 пикселов.

https://github.com/nzeemin/uknc-high...ter/HWYENC.MAC, ищите по "Draw sprite with shift".

[Manwe]

ищите по "Draw sprite with shift".

Немного не наш случай, но команда SWAB навела меня на мысль, что можно в одном слове хранить и маску, и цвет, в разных байтах. Для маленьких спрайтов это даст ускорение.

[Знахарь]

а за счет изменения размера меню под экраном нельзя ли нормально оставить спрайты как есть, без ужиманий? Меню-то не критично - ужали/разжали - там одни тексты...

[Manwe]

а за счет изменения размера меню под экраном нельзя ли нормально оставить спрайты как есть, без ужиманий? Меню-то не критично - ужали/разжали - там одни тексты...

Мы ужимаем по горизонтали. В оригинале 320 точек в ширину. У нас экран шириной всего 256.

[Manwe]

Измерил быстродействие: процедура рисования спрайта со стиранием точек в полтора раза медленней (11,7 мс ~ 85 раз в секунду) процедуры рисования по чёрному (8 мс ~ 124 раза в секунду).

Но самое интересное вот что: даже если рисовать тормознутой процедурой, платформа катается по экрану достаточно быстро. При этом анимация крутящихся гусениц сливается. Получается, эта анимация и не нужна вовсе. Чтобы разница между кадрами стала заметной, каждый кадр надо держать на экране раза в 3-4 дольше, а это уже слишком медленно для игрового процесса.

[S_V_B]

/*эта анимация и не нужна вовсе.*/
Это сейчас когда объектов на экране мало анимацию не видно, когда притормозит.. все будет ок. В оригинале ее тоже плохо заметно.. но все равно что-то мельтешит.. ощущается движение.. иначе будет совсем неживая аппликация двигаться. Кстати заметили в оригинале, что кроме гусениц по бокам платформы сверху типа "поршни" попеременно выскакивают.. то же оживляет..

[blackmirror]

Пришла тут одна мысль как двигать спрайт при помощи CRC, на словах это объяснить сложно, попробую на примере.

Если бы в байте было 4 бита, можно было бы использовать полином x^4+x+1, который выдаёт последовательность:
111100010011010(1111...)
в ней отсутствует комбинация 0000, поэтому воткнём еще один 0 там где их 3 и получим:
1111000010011010(1111...)
если взять по 4 битика, получится 16 уникальных комбинаций:
1111 1110 1100 1000 0000 0001 0010 0100 1001 0011 0110 1101 1010 0101 1011 0111
(выделено некоторое значение и где его биты оказываются при сдвиге)
если их засунуть в таблицу, а в спрайте вместо комбинации из 4 бит разместить индекс элемента из таблицы, то прибавив к нему n>0 можно получить индекс элемента сдвинутого влево(с мусором в младших разрядах), а вычитая n>0 сдвинутого вправо(с мусором в старших разрядах).
Вытащив элементы с индексами отличающимся на 4, и используя маску можно получить циклический сдвиг одного из элементов находящихся между ними. чтобы можно было сдвигать любой элемент на n<4 и не прочитать мусор, три элемента из хвоста таблицы нужно приписать до начала, а три элемента из начала после хвоста.

Если вернуться к 16 разрядным словам, то нужно будет сделать табличку в 256+14(+14 если будем двигать и в другую сторону) элементов полученных при помощи полинома восьмой степени. Значения генерируемые полиномом копируются в чётные биты, а нечётные остаются нулевыми. Слово спрайта разделяется на чётные и нечётные биты, и заменяется двумя байтовыми индексами, показывающими где такие значения можно найти в таблице. То есть для сдвига 8 точек спрайта потребуется:
Прочитать два индекса i1 и i2 из спрайта.
Вычислить слово сдвинутое влево: table[i1+shift] +table[i2+shift]*2
Вычислить слово сдвинутое вправо: table[i1+8-shift] +table[i2+8-shift]*2
Наложить маски и вывести на экран.
Если править код чтения из таблиц(его можно будет использовать и для следующей строки), то для вывода 8 точек вроде как требуется 16 команд, а прочитанных или записанных слов примерно раза в два больше(организация цикла сюда не входит).

[Manwe]

Если править код чтения из таблиц...

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

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

Это сейчас когда объектов на экране мало анимацию не видно, когда притормозит.. все будет ок.

В том-то и дело, что тормозить не хочется. Сейчас платформа проезжает экран примерно за 3 секунды. Сильно замедлять не хочется. Не в три же раза.

Кстати заметили в оригинале, что кроме гусениц по бокам платформы сверху типа "поршни" попеременно выскакивают.. то же оживляет..

Ого, надо будет посмотреть в DOSbox в замедленном режиме.

[S_V_B]

Первые успехи на УКНЦ, разобрался с прямым доступом к ВОЗУ (правда памяти сжирает.. но зато быстро) и есть косячек в виде мигающей строчки сверху.. буду думать кто туда чего пишет.

https://yadi.sk/i/fEaMpdl1ZibuVA