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

[Manwe]

Думаю над хитрой буферизацией экрана под движущимися объектами. Хочу уложить всё в объём памяти стандартной БК-0010.
Пока идея такая:

1. Определять начальные адреса экрана для левого верхнего угла каждого спрайта.
2. Для каждой строки экрана считать сколько спрайтов на неё приходится. Это буфер из полторы сотни байтов.
3. Сортировать спрайты в порядке отрисовки сверху вниз и слева направо.
4. Формировать массив вида «содержимое, адрес». Для 10 спрайтов шириной в 3 слова и высотой в 10 пикселей получается массив 300*2 слов. В 16 раз меньше, чем полный буфер экрана.
5. Поскольку спрайты отсортированы, при отрисовке легко проверять массив на несколько элементов назад: а не записывалось ли уже по этому адресу содержимое других спрайтов. Если не записывалось - делаем просто MOV. Если записывалось - смешиваем содержимое (с применением масок если хватит памяти на них или без, просто XOR’ом).
6. Помимо отрисовки новых спрайтов, одновременно стираем старые, оставшиеся с предыдущего кадра. Таким же образом, с сортировкой и сравнением адресов.
7. На выходе получаем небольшой массив, который по сути содержит дельта-информацию: чем новый кадр отличается от старого. Выводим этот массив на экран MOV (R1)+,@(R1)+ Так у нас сделано в демке «Good Apple». Это гораздо быстрей, чем копировать полный экран.

Плюсы такого подхода:
+ При выводе спрайтов на экран ничего не мерцает.
+ Нужно мало памяти. Сможем сделать даже на БК-0010.
+ Быстрее, чем рисовать в экранном буфере и потом копировать его.

Минусы:
- Нужно продумывать детали. Неизведанная территория, так никто ещё не делал.
- Сортировка и поиск в массиве могут оказаться медленными. Суммарного выигрыша в скорости не получится.

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

[S_V_B]

Идея интересная, но скорее всего с быстродействием проблемы будут, много предварительных расчетов. Хотя сам вывод и быстрее будет. Я вот схалтурил, просто при выводе спрайта со всех сторон по точке стираю, быстро и не мерцает. (перед этим спрайт в буфере сдвигаю и BISом накладываю)

[Manwe]

Я вот схалтурил, просто при выводе спрайта со всех сторон по точке стираю, быстро и не мерцает. (перед этим спрайт в буфере сдвигаю и BISом накладываю)

А если два спрайта пересекаются в одном экранном слове – неужели в этом месте не мерцает?

[S_V_B]

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

[Manwe]

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

Попробую придумать как во время отрисовки пушки проверять столкновения с точностью до пикселя (понятно что командой BIT, но непонятно пока - для любых спрайтов или отдельно для пушки).

[S_V_B]

Меня удручает быстродействие. В итоге мудреные алгоритмы придется откинуть. Нужно минимум действий - максимум эффективности.
Я бы сделал с двумя экранами, но пока не могу придумать как их переключать достаточно синхронно.. ПП живет своей жизнью
Тогда можно было проверять пространство под спрайтом при выводе (поскольку фон черный) зная квадрат врага выводить пока не будет 1-1.

Кстати в версии для PC просто стирают фон в предыдущем расположении спрайта и никаких морганий.. нам такая роскошь недоступна

[Manwe]

Меня удручает быстродействие. В итоге мудреные алгоритмы придется откинуть. Нужно минимум действий - максимум эффективности.

Да, вот сейчас думаю, что не нужна мне сортировка. Если движущихся объектов мало, то вместо сортировки проще тупо перебрать все объекты подряд, сравнивая не совпадает ли адрес.

[Manwe]

Пока что столкнулся с дилеммой.

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

Я составляю список изменений на экране (новый кадр по отношению к старому) в таком виде: значение1, адрес1, значение2, адрес2,.. значениеN, адресN. Если адрес уже встречался в списке, то значение перезаписывается поверх существующего (там коротенький поиск в пределах одной экранной строки).
Поскольку спрайты хранятся байтами, адреса вывода на экран могут быть нечётными. Соседние два байта будут храниться двумя записями с чётным и нечётным адресами. Выходит, что в этом списке все "значения" будут содержать по лишнему пустому байту. Тратится лишнее место. Но главное, что вывод командой MOVB (R1)+,@(R1)+ становится невозможным, так как R1 будет переставляться на следующую запись неправильно.
Придумал хитрость: если адрес нечётный, то переделывать его в чётный и класть "значение" в старший байт. Тогда все адреса в списке получаются чётными, всё круто. Но! Теперь оказывается, что невозможно заранее посчитать сколько слов у нас получится при выводе. Так как чётные и нечётные смешиваются непредсказуемо (зависит от X-координаты каждого спрайта). Раньше с байтами было просто: ширина спрайта (+1 с учётом сдвига) и так для каждого спрайта, приходящегося на эту экранную строку. В сумме знаем сколько байт надо вывести в каждую экранную строку. А теперь при смешивании байтов в слова уже не знаем.

И вот дилемма: придумывать какой-то костыль для правильного подсчёта? Это затормозит работу алгоритма.
Либо хранить спрайты не байтами, а словами, тогда проще подсчёт и проще обращение со списком изменений. Но тормознутей сдвиг спрайтов (потому что становится возможным сдвиг уже не на 3, а на 7 пикселей).

Какой путь выбрать?

[nzeemin]

Manwe, во всех своих проектах на УКНЦ использую для тайлов/спрайтов хранение словами -- каждое слово это 8x1 пикселей в 4 цвета -- для вывода через ЦП передачей слова сразу в порт. Иначе слишком много времени тратится на подготовку данных для вывода на экран.

[Manwe]

Так-то да, но ведь место жалко. Я хочу уложиться в 16 kb БК-0010.