Портирование Asteroids

[svofski]

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

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

[ivagor]

Насколько я увидел, на экране больше всего астероидов, т.е. основное время тратится на них, соответственно если пробовать инлайнить, то только астероиды(камни). В камнях много повторов, поэтому можно инлайнить процедуру с lxi, учитывая, что при переходе к следующей паре байтов не всегда надо их менять. Иногда надо будет поменять только один байт из двух (mvi вместо lxi). Еще можно попробовать проанализировать более тщательно и задействовать вторую регистровую пару под самые частые байты в камне. Их достаточно задать один раз на спрайт. Как минимум стоит попробовать инлайнить самые большие камни.

[ivagor]

Вероятно стирание всего экрана это временное решение для прототипа, но на всякий случай обращу на него внимание. Переход на пообъектное стирание даст заметную прибавку скорости, а то сейчас очистка экрана отъедает >1/3 времени.

[nzeemin]

Вероятно стирание всего экрана это временное решение для прототипа, но на всякий случай обращу на него внимание. Переход на пообъектное стирание даст заметную прибавку скорости, а то сейчас очистка экрана отъедает >1/3 времени.

Я ещё подумаю.
Появилась ещё такая мысль: можно использовать ТРИ плана под игровой экран, переключая их по очереди, текущий ярко, предыдущий бледно - получим "эхо" для всех движущихся объектов.

[ivagor]

Если использовать много плоскостей, и если выбрать приоритетом скорость, то можно как написал svofski раскидывать спрайты по плоскостям. Готового механизма в игре нет, я представляю примерно так: при выводе очередного спрайта смотрим по координатам, если нет наложения, то используем основную плоскость+0, если есть, то плоскость+1, если и там уже есть, то +2, и т.д. (если хватит памяти) до +3. Если плоскости кончились, то или рисуем процедурой с xor или просто портим какую-то из плоскостей. Выигрыш за счет отказа от чтения экрана и логических операций, но, конечно, будет помигивать.
Вариантов много, вопрос в приоритетах - "безмигательность", скорость, наличие спецэффекта, наверно еще что-то можно придумать.

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

будет помигивать.

Если разделить плоскости 2+2, то можно использовать переключение страниц и мигать не будет, но вопрос наложения спрайтов становится более острым.

[nzeemin]

Можно ещё поиграть с вариантом когда держим группу флажков "мы тут рисовали" и очищаем только там где запачкали.

Но пока я всё это откладываю на потом - хочу сначала логику реализовать, хотя бы основную часть.

[Advertiser]

[ivagor]

Умозрительно представляется, что поблочное стирание эффективнее пообъектного при большом "коэффициенте перекрытия" спрайтов, но и пообъектное и поблочное стирание для asteroids явно должны быть эффективнее полноэкранного.

[nzeemin]

Сделал процедурное рисование для больших камней - спрайтов размером 32x32.
Пока набросал грубо, есть ещё возможность для некоторой оптимизации.
Объём кода процедур - 11164 байта, против 4*32*8*4 = 4096 байт данных спрайтов.
Результат: до того в 3 фрейма укладывалось 15 камней, сейчас 23 камня!
В эти 3 фрейма также входит стирание одного плана и обработка клавиатуры.

На ужасы нашего городка можно посмотреть тут: https://github.com/nzeemin/vector06c.../astrosprt.asm и метод WriteSprite32x32Code() в SpriteRotate.

Приложил превью с 23-мя камнями. Кораблик вращается клавишами влево-вправо. Клавиша вверх - эффект взрыва кораблика.

[svofski]

Игра смотрится уже очень круто!

[nzeemin]

Пробую применить переключение планов через смену палитры.
Но есть ощущение, что я что-то делаю не так. Потому что изображение заметно моргает.
Причём моргают не только движущиеся, но и статичные объекты.

UPDATE: Разобрался, исправил. Теперь картинка такая как надо. Красота неописсуемая. Оч доволен.
Превью-4 в аттаче. стрелочка вверх - показать пламя.