Sea Dragon

[ace210]

ты уже решил проблему со стиранием\рисованием спрайтов под лучем?

Думаю. Но кажется, врубаюсь. В этот буфер самое главное на 1 объект записывается адрес обработчика-рисователя и данные за этим адресом. Данные имеют формат специфичный для каждого обработчика-рисователя.
Потом снимаем с этого буфера адрес, если он не 0, то передаем управление этому адресу, т.е. jp.
И так для каждой строки знакоместной вслед за лучом.

Вот только сколько этих буферов? Для каждой строки свой, заполненный ранее? Или он один и заполнение происходит после разбора этого буфера при выводе каждой строки?

---------- Post added at 14:38 ---------- Previous post was at 14:33 ----------

Вот размышляю, какой размер тайла все же нужен?
Если 16на16, то будет клэшинг аттрибутов просто огромный. 8на8 меньше, но тоже будет.
16на16 ландшафт занимает в 4 раза меньше места, но при выводе каждого тайла надо выводить в 3 раза больше байтов. (в прошлом посте я ошибся). Т.е. 3 байта ширина и 16 байт высота = 48 байт выводится. В случае 8на8 2 байта ширина и 8 высота, 16 байт выводится. Теперь и понятно почему общее время у тебя ровно в 3 раза больше моего.

Где-то я читал в каком-то журнале, что для спектрума 16на16 размер тайла самый идеальный. Не последовать ли этому совету?

[Advertiser]

[jerri]

поправочка - у меня 2 байта ширины и 8 байт высоты
но выводится 2 на 16 да
так что 16х16
чтобы не было такого клэшинга надо еще 4 байта на каждый тайл под цвет

[ace210]

у меня 2 байта ширины и 8 байт высоты

Получается 32 байта выводится при печати тайла. Непонятно тогда, почему у тебя так долго. К тому же у тебя количество тайлов меньше раза в 1,5. Можешь посмотреть у себя почему так долго? Можно ли как нибудь существенно ускорить?

В противном случае ты рискуешь не успеть отрисоваться за прерывание. Т.к. сложность экрана приведенного мной - типичная. Есть еще пещеры. Там в 2 раза больше тайлов получится.

[jerri]

процедуры не оптимизированные
у меня демонстрация алгоритма а не демонстрация движка
сейчас дорисую версию 7 и посмотрим

[jerri]

Версия 7
1 оптимизирована карта 0 - не отображается
2 оптимизирован вывод на экран, жестко

[ace210]

Что-то не пойму. Все равно 45Ктактов процедура Refresh работает. Нужно существенное ускорение. Чтобы хотя бы за 30Ктактов.

[jerri]

голубой бордюр - время отрисовки данных на экране
остальное время занимают расчеты
в 1 фрейм ты по любому не уложишься
значит в 1 фрейм надо вывести все на экран
с учетом количества объектов и способа вывода можно все прекрасно успеть вывести

[ace210]

в 1 фрейм ты по любому не уложишься

Почему? У меня всего 15Ктактов. Еще с лихвой времени стереть спрайты, и нарисовать их. Всё в 1 фрейм.

А ты хочешь за 2 прерывания - 1 перерисовку? Жаргон этот мне не очень превычен. Это называется 2 фрейма?

[jerri]

fps - frame per second
обновление экрана
25 fps - 25 кадров в секунду
50 fps - максимум для Спектрума

15к тактов при отсутствии активных действий на игровом поле
для того чтобы сравнить скорость необходимо сравнивать модели в идентичных условиях

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

кроме того оптимизация ради оптимизации - ересь
сейчас необходимо сделать реальный уровень со всеми переходами и уже посмотреть как оно будет

[ace210]

15к тактов при отсутствии активных действий на игровом поле
для того чтобы сравнить скорость необходимо сравнивать модели в идентичных условиях

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

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

Да, у меня пока этого нету. Думаю. Надо сделать вывод фона по строкам, а не по столбцам как у меня сейчас. Буду переделывать однозначно. Я ведь только сейчас врубился, как же этот Zynaps устроен.

Я твой движок понял. В конечном итоге у меня будет примерно так же как и у тебя. Просто я хочу понять, где можно соптимизировать существенно чтобы уложиться во фрейм. Ведь в Zynapse 1 фрейм?

Оригинал Sea Dragon Atari есть еще 3-й уровень сложности. Там скорость скролла в 2 раза выше, но тоже на 2 пиксела. Вот поэтому и надо стремиться к 1 фрейму. Вот поэтому я тебя и напрягаю, ты не обижайся. Ведь свой код ты лучше знаешь - быстрее переделываешь. А я в это время параллельно свои исследования делаю.

Тут у нас классическая ситуация память-скорость. У меня ландшафт занимает больше памяти, но выводится быстрее. У тебя, наоборот, мизер памяти под ландшафт, но выводится в 3 раза дольше. Надо найти золотую середину.

---------- Post added at 17:53 ---------- Previous post was at 17:50 ----------

Так что такое 1 фрейм? я не понял. Это время между прерываниями?

---------- Post added at 17:56 ---------- Previous post was at 17:53 ----------

сейчас необходимо сделать реальный уровень со всеми переходами и уже посмотреть как оно будет

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

---------- Post added at 18:03 ---------- Previous post was at 17:56 ----------

ломаться постоянно в одном и том же месте

Тут надо еще угадать - как бы луч не прошел по строке в которой стерты спрайты, но еще не нарисованы. Ведь сейчас ты убрал из своего начального движка вывод пустого места. Ты не забыл, что спрайты надо еще стереть перед выводом фона?