Пишу шедевр для «Вектора 06Ц»

[ivagor]

В итоге вся разница в том, что в моем варианте будут видны только 9 полных строк, а в твоем еще и "частичные" строки.

[KTSerg]

Или уменьшить размер ячейки лабиринта по вертикали до 22-ух или 20-ти строк.
Даже при высоте 22 строки, это на экране 10 строк лабиринта в высоту, и 36 строк ширмы. Достаточно, чтобы полностью спрятать уходящие за предел экрана элементы, без необходимости резать вывод спрайтов.

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

А сколько строк спрайта лабиринта прячется под ширмой, при подготовке для скроллинга, 8 строк ?
Получается, 22 строки - уходящий за ширму элемент, плюс 8 строк - с другой стороны для подготовки лабиринта... между ними зазор 6 строк...
Если не будет ситуации, когда два элемента уходят за пределы экрана одновременно в одной колонке лабиринта, то артефактов быть не должно. А с другой стороны, даже если они за ширмой что-то друг с другом сделают... этого-же ни кто не увидит

[jerri]

В итоге вся разница в том, что в моем варианте будут видны только 9 полных строк, а в твоем еще и "частичные" строки.

Ну да. Я о чем и говорю. главное это ширма и возможность скрываться за ней врагов. то что некоторые строки будет видно частично - только плюс
на экране технически может отображаться до 11 разных строк - просто верхняя и нижняя всего по 8 линий.

[metamorpho]

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

[jerri]

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

ага красиво

рисовать шторку через стек - дорого по тактам
надо по другому

у тебя спрайты какого размера?

переход от битплана к битплану очень дорого

надо змейкой - слева направо битплан 1, справа налево битплан 2, слева направо битплан 3, потом вниз
потом наоборот

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

почему враги визуально подвисают при движении героя?

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

ivagor, можешь вот это на векторский перевести?
interrupt.zip

и например обьяснить как этим правильно пользоваться

[ivagor]

ivagor, можешь вот это на векторский перевести?

Как понимаю, речь опять про способ/метод Медноногова. PPC уже переводил на векторовский, надо вспомнить выкладывал ли он исходник, но обсуждение точно можно найти в ветке Robotz, она не такая уж большая.

[KTSerg]

ivagor, можешь вот это на векторский перевести?
interrupt.zip
и например обьяснить как этим правильно пользоваться

Сколько смотрю на этот алгоритм, не могу понять, как можно восстановить испорченные стеком данные.
С моей точки зрения, сделать это на 100% - это не возможно.

Пример.
Есть на экране картинка. Я с помощью стека вношу в неё изменения.
Только-что полностью закончил вывод спрайта, и собираюсь восстановить указатель стека, который в данный момент указывает на фоновую картинку под выведенным спрайтом... И тут пришло оно... прерывание... Адрес возврата из прерывания пишется в стек, т.е. прямо на мою фоновую картинку, о содержимом затёртого стеком ни кто, ни как знать вообще не может...
Подпрограмма "восстановления" в прерывании загоняет за место двух затёртых байт фоновой картинки содержимое пары ВС (если я правильно понял), и вот на фоновой картинке под спрайтом появляется артефакт...
А если я только занёс в ВС данные для спрайта, но не выполнил PUSH BC... и произошло прерывание, то оно сделает это за меня, испортив два предыдущих байта в спрайте?
Выход только один, в своих подпрограммах вывода спрайта, постоянно запрещать и разрешать прерывания... а будет ли при этом выигрыш от использования стека, вот в чём вопрос ?

[jerri]

Сколько смотрю на этот алгоритм, не могу понять, как можно восстановить испорченные стеком данные.
С моей точки зрения, сделать это на 100% - это не возможно.

Пример.
Есть на экране картинка. Я с помощью стека вношу в неё изменения.
Только-что полностью закончил вывод спрайта, и собираюсь восстановить указатель стека, который в данный момент указывает на фоновую картинку под выведенным спрайтом... И тут пришло оно... прерывание... Адрес возврата из прерывания пишется в стек, т.е. прямо на мою фоновую картинку, о содержимом затёртого стеком ни кто, ни как знать вообще не может...
Подпрограмма "восстановления" в прерывании загоняет за место двух затёртых байт фоновой картинки содержимое пары ВС (если я правильно понял), и вот на фоновой картинке под спрайтом появляется артефакт...
А если я только занёс в ВС данные для спрайта, но не выполнил PUSH BC... и произошло прерывание, то оно сделает это за меня, испортив два предыдущих байта в спрайте?
Выход только в своих программах постоянно запрещать и разрешать прерывания... а вудет ли при этом выигрыш от использования стека, вот в чём вопрос ?

Ну над этим алгоритмом работал один из гениев программирования спектрума.

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

Для этого нужна другая процедура рисования спрайтов. Более быстрая. С прокачкой данных через стек.

Стек не на экране. Стек на спрайтах.

[KTSerg]

...
Для этого нужна другая процедура рисования спрайтов. Более быстрая. С прокачкой данных через стек.

Стек не на экране. Стек на спрайтах.

Вот с этим согласен.
Если стек на спрайте, а не на экране. Есть вероятность корректной работы алгоритма.
Для этого как минимум нужно разрешить прерывание только после установки стека на спрайт и чтения первых байт спрайта. А перед переходом на другой спрайт запрещать.
Иначе спрайтам - кирдык.
Можно конечно выкрутиться, и подогнать, что-бы все спрайты начинались и заканчивались одинаково... тады...

[jerri]

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

Прерывания разрешены всегда.
Просто сначала заряжаешь основной регистр под графику, потом уже стек.