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

[S_V_B]

/* Иначе слишком много времени тратится на подготовку данных для вывода на экран. */
При движении спрайта (сдвиге) все равно приходится слова разделять, поскольку в слове лежат две плоскости..

[Advertiser]

[hobot]

поскольку в слове лежат две плоскости..

имеется в виду два плана? давайте на одном языке говорить - плоскости = это тригономнтрия какая-то )))

[Black Cat / Era CG]

плоскости = это тригономнтрия какая-то )))

Стереометрия.

[S_V_B]

"плоскости" отражают суть процесса, а "план"..

[Manwe]

Кстати, на счёт плоскостей. Возможно, придётся развернуть алгоритм на 90°
Раньше я перебирал все объекты (спрайты) и заполнял графическими данными массив строк. Проблема была в том, что непонятно какой длины получится каждая строка.
Но, возможно, правильней во внешнем цикле перебирать экранные строки, а во внутреннем цикле для каждой строки смотреть что за объекты в неё попадают, брать из соответствующих спрайтов только по одной строчке графических данных и заносить в массив. Это вроде бы дольше, но зато конечный вывод массива будет «вжух!»

[Manwe]

Попробовал идею со строками. Назвал этот подход "scanlines".
Для компьютеров с маленьким объёмом памяти идея очень вдохновляющая: двойной буфер экрана, размер которого... не зависит от размера основного экрана! А зависит лишь от площади присутствующих на экране анимированных спрайтов. В моём эксперименте с семью спрайтами размер буфера получился всего 776 байт.

Но как обычно, есть и потери: скорость снизилась раза в три по сравнению с прошлым алгоритмом. Надо думать как оптимизировать.
Может быть более эффективно отсекать объекты, которые не попадают в scanline. Возможно, отслеживать когда спрайт полностью нарисован и ставить ему признак "сразу пропускать" для следующих сканлайнов.
Вторая причина тормозов: обращение к спрайту происходит не один раз за кадр, а много раз (столько, сколько строк на экране), и каждый раз вычисляется смещение в спрайте, чтобы выбрать соответствующую строку пикселей. Попробую запоминать прошлый указатель на графические данные спрайта, а не пересчитывать его заново при каждом обращении.
В целом такие оптимизации помогут ускорить раза в два, наверное. Перспективы есть

P.S. ещё идея со сканлайнами интересна тем, что она решает проблему выхода (полного или частичного) спрайта за пределы отображаемой области.

[Manwe]

S_V_B, достаточно шестнадцати движущихся объектов для каждого экрана? Если да, то попробую массив слов, в которых каждый бит отвечает за 1 объект - присутствует он в данной экранной строке или нет.

[S_V_B]

7 объектов максимум.

Как вычисляются экранные координаты для отрицательных Х?

[Manwe]

7 объектов максимум.

Считая всякие искрящиеся разряды?

Как вычисляются экранные координаты для отрицательных Х?

Пока никак. Сканлайны отсекат только координату Y.

[S_V_B]

/* Считая всякие искрящиеся разряды? */
Да.

я сначала хотел вращать спрайты там же где они лежат, что бы каждый раз только один сдвиг делать, двигаемся же по одной точке.
потом сделал ASHC.
Чтобы не моргало через буфер фон->BIC (x-1)->BIS(X)->MOV.
В итоге ломаю голову как с периферийным процессором подружиться (диспетчер процессов) чтобы два экрана переключать.
Так будет проще и быстрее.

"Аппаратные" спрайты УКНЦ.. вещь сомнительная, скорее всего под знакогенератор заточена.