Вывод спрайта любой ширины с точностью до пикселя.

[DragonsLord]

бросание спрайта на экран 7 - это вообще ниачем.

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

Совокупные времянки работы с теневым экраном в классике ВЫШЕ времянок указанного гиморойного кидания сразу в экран. Потому что площадь, занимаемая выводимыми спрайтами, на порядок меньше всей площади экрана.

Мы так решили со Слипом и будем делать именно, как я говорю. И никак иначе.

С тайлами такой проблемы нет, они на 7 странице и лежат.

или спрайт с маской или без. с маской но без маски не бывает.

Я же говорю, сделать кидалку БЕЗ маски. Нам не нужна маска. У нас нет в памяти масок. Спрайты хранятся в 4х банках верхней памяти. Маски не нужны. Пиши в процедурах вывод по AND. Если мне надо я сам потом поменяю.

[Advertiser]

[drbars]

как ты собрался с одной страницы в другую кидать спрайты и тайлы БЫСТРО?

Да, да, кстати) У меня там реализовано как раз перекидывание спрайта из страницы в буфер со сдвигом на бит, чтобы ну хоть как-то побыстрее. Не знаю что там может быть кому-то непонятно, тут не матан и не лин.алгебра же) В теории можно ему как в Диззи сделать, спрайты по таблицам двигаются, а хранятся в 7ой банке с $db00... но там всего 9кб. Что-то быстрее и универсальнее уже сложно придумать...

[DragonsLord]

Предлагаю перенести обсуждение в тему Варика. Ссылка в моей подписи.
Я не делаю секрета из методик реализации проекта, посему могу свободно обсуждать что и как сделано. Более того, могу в конце дать исходник. Всем.

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

спрайты по таблицам двигаются, а хранятся в 7ой банке

Никаких копий. Всё делать в реалтайме.

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

Не знаю что там может быть кому-то непонятно, тут не матан и не лин.алгебра же)

Я 25 лет асм в глаза не видел. Уже привык кодить на языках с классами. Мне ваши крокозяблики в асме, как китайская грамота...
Да кодю помаленьку... да вспоминаю... но пока только самые базовые команды.
Так что - писалово низкоуровневых процедур и раньше было "не моё", а сейчас и подавно

[drbars]

В код барса трудно лапы свои пихать, потому что у него мания объединять ВСЁ в одну процедуру. В результате, только автор и понимает, как сие работает. Плюс нигде не озвучены такты. Посему никак не могу прикинуть, подходит ли мне это или нет.

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

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

Никаких копий. Всё делать в реалтайме.

У меня всё в реалтайме делается.

[DragonsLord]

У меня всё в реалтайме делается.

Нужен трезвый расчёт в цифрах. Если "по таблицам" будет быстрее - я выбираю таблицы.
Если разница вывода "по таблицам" и "реалтайм расчёт со сдвигами" не превысит 10% по времени, тогда без таблиц.

[drbars]

Нужен трезвый расчёт в цифрах. Если "по таблицам" будет быстрее - я выбираю таблицы.
Если разница вывода "по таблицам" и "реалтайм расчёт со сдвигами" не превысти 10% по времени, тогда без таблиц.

Я прикидывал, реалтайм немного медленее выходит. Тестить надо, сравнивать. Мне процедура не подошла по причине, что под каждую ширину спрайта 1,2,3,4 знакоместа надо было отдельную процедуру делать, чтобы быстро. Поэтому сделал универсальную себе с таблицами, а эту отдал в паблик.

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

Будет время может сделаю набор библиотек с примерами и демкой типа LaserBasic.

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

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

[jerri]

Нужен трезвый расчёт в цифрах. Если "по таблицам" будет быстрее - я выбираю таблицы.
Если разница вывода "по таблицам" и "реалтайм расчёт со сдвигами" не превысит 10% по времени, тогда без таблиц.

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

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

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

не максимально много, а один спрайт за раз.
как мышой рулить будешь?

Совокупные времянки работы с теневым экраном в классике ВЫШЕ времянок указанного гиморойного кидания сразу в экран. Потому что площадь, занимаемая выводимыми спрайтами, на порядок меньше всей площади экрана.

зависит от количества обьектов.

С тайлами такой проблемы нет, они на 7 странице и лежат.

а хватит?

Я же говорю, сделать кидалку БЕЗ маски. Нам не нужна маска. У нас нет в памяти масок. Спрайты хранятся в 4х банках верхней памяти. Маски не нужны. Пиши в процедурах вывод по AND. Если мне надо я сам потом поменяю.

смотрется будет как мазня.

[DragonsLord]

Ответ здесь:
https://zx-pk.ru/threads/32718-warcr...=1#post1110069

[drbars]

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

А смысл тут в стеке? Получается точно такой же буфер. Да, скопировать данные быстрее получится, а вот подготовить к выводу на экран уже заморочки. Либо сразу стеком рисуют на экраны, либо копируют в буфер, его обрадатывают и выводят на экран.

Все сдвиги спрайтов это расчет фазы сдвига от 0 до 7 точек.

Есть 3 популярных способа.

1) Прекалькуляция, т.е. в памяти мы храним 7 сдвинутых копий. Но тут если сам спрайт имеет анимацию, то она получится гвоздями прибитой к фазам сдвига и должна иметь соответствующую раскадровку.

2) Команды сдвига. Моя процедура использует небольшой трюк при работе с буфером спрайта, чтобы потом его быстро вывести процедурой вывода. Наборы спрайтов лежат в заданном банке памяти. Принцип сдвигов такой:

0 px - просто копируем спрайт в буфер, выводим.
1 px - копируем в буфер со сдвигом вправо на 1px, выводим.
2 px - копируем в буфер со сдвигом вправо на 1px, сдвигаем буфер на 1px вправо, выводим.
3 px - копируем в буфер со сдвигом влево на 1px, сдвигаем буфер на 4px влево (RLD), выводим. (+изначальное смещение в буфере на знакоместо)
4 px - просто копируем спрайт в буфер, сдвигаем буфер на 4px вправо (RRD), выводим.
5 px - копируем в буфер со сдвигом вправо на 1px, сдвигаем буфер на 4px вправо (RRD), выводим.
6 px - копируем в буфер со сдвигом влево на 1px, сдвигаем буфер на 1px влево, выводим. (+изначальное смещение в буфере на знакоместо)
7 px - копируем в буфер со сдвигом влево на 1px, выводим. (+изначальное смещение в буфере на знакоместо)

Из списка видно, что самые нагруженные части это сдвиг на 3 и 5 точек. RRD/RLD команды довольно быстрые, удобно ими пользоваться.

3) Таблицы движения. Тут принцип простой, есть таблица в 3+ Кб из фаз сдвигов. Нужно расчитать байт из спрайта в соответствии с фазой сдвига по таблице.
Берём данные спрайта, берем данные таблицы, полученный результат из регистра выводим на экран. Довольно быстро работает, но теряется память под хранение таблицы. Буфер не нужен.

Что же касается клиппинга, то тут удобнее спрайты хранить дампом (2048х64px), расчёт строки спрайта будет очень быстрым при клиппинге сверху экрана, но можно и умножением в общем-то.. по скорости может и быстрее будет. Клиппинг снизу это просто отсекаем строки вывода уходящие за границы экрана. А вот слева и справа уже сложнее без дампа, тут нужно считать сколько и каких столбцов спрайта не рисовать.

[Bedazzle]

Все сдвиги спрайтов это расчет фазы сдвига от 0 до 7 точек.

Может быть два набора 0 и 3. Тогда крутить меньше - максимум на +2/-2.