Иногда так делают для монохрома:
Берут по XOR накладывают спрайт на экран... Потом его же накладывают ещё раз по XOR и фон восстановлен.
Не уверен точно, насколько эта метода применима тут...
Так когда-то "живой курсор" реализовывал на графиках.
Иногда так делают для монохрома:
Берут по XOR накладывают спрайт на экран... Потом его же накладывают ещё раз по XOR и фон восстановлен.
Не уверен точно, насколько эта метода применима тут...
Так когда-то "живой курсор" реализовывал на графиках.
... потому что уже есть.
- вот так звучит контекст полностью.
Alex, да. Знаю об этом способе.
- - - Добавлено - - -
Для человека, далёкого от УКНЦ, самым естественным способом вывода спрайта или картинки будет именно такой, как я запросил выше. Но нет, мне предлагают извращаться ;-)
- - - Добавлено - - -
Хитрые способы я не отрицаю, но они вспомогательные. Основной... ну, мне нужен быстрый вывод тайлов 10x11 с перекрытием одной поверх другой, и отнюдь не по OR. Так вот, универсальная процедура могла бы делать и такой вывод, пусть и не столь быстро, как узко заточенная именно под этот размер тайла.
1. Не делай дырок внутри спрайта или заполни их другим цветом.
2. Продемонстрируй на своем примере (со своими тайлами), что именно не устраивает.
Тогда уже можно будет разбираться, а то только разговоры разговариваешь. Сначала у тебя вообще процедуры вывода спрайта не было, теперь есть.. опять не нравится.. то "гранаты не той системы"
- - - Добавлено - - -
Если у тебя тайлы 10х11 проще и быстрее сделать наоборот спец процедуру с заготовленной маской на каждый сдвиг. Будет летать, а универсальная с таким подходом - это как раз изврат.
БK 0010-01, БК 11М, БК11М+,МС 0511 (УКНЦ)х3, Atari 65XE, Commodore 64, AMIGA 500 (HDD), ZX EVO
Молодец что выложил на гитхаб. А то я долго-бы разбирался как запустить чортов паскуаль под RT-11 и как там делать вставки на макро.
ТЗ норм - вывод спрайта с ЦП. Спрайт пусть буден кратен 8-ми пикселям по X. Вывод в любое место.
Чужие пиксели не трогать при выводе.
Кроме mov R0,@#176642 никаких других записей в планы. (никаких bic R0, @#176642 - иначе может мигать).
От себя добавлю - никаких "круглых" спрайтов (то-есть скругленные углы карт например БУДУТ оставлять черные дырки, иначе вместе со спрайтом хранить маску, некруто). Для начала "квадратный спрайт", но вывод в любое место до пикселя.
(да, надо будет читать планы, читать графоний, шифтить цвета, складывать, записывать обратно в планы mov-ом, но думается это не архимегасложно, правда это будет тормозно, но вообщем попробую помочь там переделать твое PutSpr, я конечно не спец по оптимизации)
Последний раз редактировалось BlaireCas; 17.03.2020 в 17:26.
Oleg N. Cher(17.03.2020)
Там будет и BIC и BIS и COM, а в варианте до 16 пикселей, только они и будут. (MOV будет если >16 пикселей).
Поэтому я и говорю, что лучше сделать до 16 ти пикселей отдельную процедуру.
- - - Добавлено - - -
Не нужно читать планы, просто нужна маска (в PutSpr сдвиговая маска уже есть- ее можно использовать), зачем в дебри лезть.
- - - Добавлено - - -
И каким же волшебным способом ты их будешь накладывать?
БK 0010-01, БК 11М, БК11М+,МС 0511 (УКНЦ)х3, Atari 65XE, Commodore 64, AMIGA 500 (HDD), ZX EVO
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Попробовал на 8-ми пикселях. (сама карта полного размера как спрайт, просто отрисовывается первые 8 пикс (столбец) но с любым сдвигом по x, y.
PutSpr(21, 20, Spr);
PutSpr(25, 26, Spr);
Как видно "уголок" второй карты затер первую черным цветом. Но остальное норм.
Теперь надо как-то зациклить до полной карты и нарисовать отдельно "задник".
Там только команды mov при записи в планы (чтение есть, но при записи используется только mov).
Жутко нехватает регистров, да и больше извраты паскаля приходится изучать.
Ну да, чуть-чуть поморочились, но там всё цивильно - вполне можно юзать. Порождаемый асм-файл легко посмотреть, вставки на асме организованы хорошо, поэтому OMSI Pascal признаем вполне годным инструментом.
Согласен, но полезность подпрограммы будет сильно выше для спрайтов, не кратных 8 по ширине. Пусть он лучше будет по ширине >= 8 пикселей, т.е. гарантированно байт - для упрощения вывода. Более узкие спрайты, пожалуй, вряд ли понадобятся, по крайней мере, для задуманной игры.
При выводе спрайта через логические операции AND/OR/XOR подпрограммой S_V_B кратность ширины спрайта восьми некритична, поскольку чужие пиксели не затираются, а происходит наложение данных спрайта на данные на экране. Но при замещении точек на экране точками спрайта гораздо полезнее (хотя и сложнее в реализации, и даже несколько медленнее) будет вывод спрайта любой ширины, не обязательно кратной восьми. Хотя конечно первую версию подпрограммы можно сделать и с кратной.
Просто если портировать со спека, то тайловая карта 32x24 в разрешении УКНЦ диктует размер тайла 10x11. Тут есть по сути два подхода:
- 1. Придерживаться оригинального Спеко-разрешения, как следствие - мириться с неполным заполнением экрана и некоторым искажением пропорций графики из-за нарушения соотношения точек - из-за их неквадратности.
- 2. Вариант с адаптацией графики под разрешение УКНЦ, что конечно потребует её доработки, но в целом видится более желательным.
Согласен. Для круглых спрайтов у нас есть вывод с логическими операциями. Подпрограмма S_V_B здесь очень подходит.
Не страшно, если будет не прям супер-мега-оптимально, главное чтобы работало. Скорости для карточной игры должно хватить.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)