GameNoname

[ivagor]

1) 1 й спрайт xor 2, 2) 1 xor 2 xor 3, 3) 1 xor 2 xor 3 xor 4
1 xor 2 xor 3 xor 4 xor 4=1 xor 2 xor 3 - вернулись к шагу 2)
1 xor 2 xor 3 xor 3=1 xor 2 - вернулись к шагу 1)
Но в местах наложения нескольких спрайтов на экране каша.

[svofski]

Самое крутое ксоренье мне запомнилось из clrs b2m'a. Я на самом деле до сих пор не понял, как это было сделано =)

В общем четное количество ксоров чего угодно расксорятся потом обратно. Но в промежутке-то на их месте получается полный фарш. А с цветами так и совсем печалька.

[parallelno]

svofski, если я все правильно понимаю то xor это инверсия по маске, поэтому и проворачивается фарш обратно при двойном xor. Только нужно держать цвет инвертированным.
О, понял. Действительно будет быстрее, так как маскирование при отрисовке нового спрайта не нужно делать. А старый спрайт стирать с той же скоростью.

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

Размышляя о том куда копать дальше понял что преследуя изначальную задумку загнал себя в тупик.
Изначально я придумал что у каждого спрайта есть счётчик показывающий в какие кадры его нужно рисовать, а в какие нет. Это цикличный байт типа 00010001 для монстра и 01010101 для героя. В каждый кадр этот счётчик скролился в право и если 1 попадал во флаг переноса, то мы рисуем.
Это дало возможность рисовать спрайты с разным fps, но привело к тому что непонятно как их корректно блендить. Плюс нет двойной буферизации. Это я решил излечить меняя порядок отрисовки. В итоге как и говорил
svofski, это сложно контролировать. То есть это работает если на экране с 6-8 спрайтов, но не работает с 2.
Дальше я планировал добавить другие штуки Аля пули и т.п. что ещё больше усложнит убегание от луча. Плюс ко всему этому ещё то что этот подход хоть техническии и не запрещает прерывания, но все же полагается на них чтобы работало убегание от луча. В итоге я экономлю перформанс на разном fps для спрайтов, но трачу его на синхронизацию с прерываниями и иду по пути очень сложного и не стабильного рендера. В общем все взвесил и решил что попробую сделать с двойной буферизацией, если будет ещё медленнее или хуже, то просто забью на бленд спрайтов и буду рисовать без маски и с запасом чтобы новый спрайт стирал свою старую копию на экране.

[metamorpho]

parallelno, а это обязательно, чтобы движущиеся объекты проходили "насквозь" друг друга ?
Если я правильно понял обсуждаемую проблему то есть вариант сделать - что два движущихся объекта столкнувшись расходятся в разные стороны, т.о. нет перекрытия спрайтов. Так сделано во многих играх. Такой подход упростит задачу.

[jerri]

блин 30 лет технологий и снова сочиняем велосипеды, самокаты и прочие велобеги.

1 синхронизация по прерываниям.

1.1
50 раз в секунду выполняются прерывания.
выбираем кратность и например со скоростью 1 через 2 выполняем обработку всех персонажей на экране.
результат обаботки записываем в один из двух списков выводимых спрайтов

1.2
во внешнем рендере выбираем один из двух списков и отрисовываем все спрайты по списку выбранным способом

плюсы - стабильная скорость персонажей, стабильная скорость героя.


Теперь об отрисовке
На примере игры Jack the Nipper 2
вывод спрайтов с маской поверх фоновой графики и других спрайтов
также возможен спрайт за предметами Фореграунда

Титульный экран


состоит если присмотреться из блоков 32*32 которые состоят из элементов 8*8



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

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

на экран выводятся либо модифицированные элементы, либо фоновые которые надо восстановить

[parallelno]

metamorpho, ага, спасибо. Но хотелось бы иметь возможность пересечения спрайтов.

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

jerri, спасибо за почву для размышления.
Изобретение велосипедов эта один из элементов вдохновения для меня, так что все ок!

[Advertiser]

[b2m]

При таком способе xor тоже быстрее? Мне видится что нет, но может я что-то упускаю.

Нет, что OR, что XOR, работают одинаково быстро. Я к тому, что при использовании XOR при выводе спрайтов не нужно заботиться о пересечении спрайтов. К тому-же, используется одна и та-же процедура, как для вывода, так и для стирания (главное стирать в тех-же координатах).

[Stl75]

Привет всем...

Обычно мерцание спрайтов - буфером устраняется...
Но тут видать - вариант особый...

Для особого варианта - можно сделать так...

1. Делаем карту экранов.
То есть - каждый экран делим на области.
Экран задействован не весь, поэтому делим через массив...

2. Смещаем персонажей - не по номерам,
а по областям экрана, в которых они находятся...

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

???

[BlaireCas]

А вот в exolon кстати как сделано? Там тупой xor вроде если смотреть на спрайты. Ну тайлы да, иной раз сверху перекрывают (иной раз нет). И плохо не выглядит и быстро, зачетно.
Правда в нем нет background-a ...

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

видать - вариант особый...

Буфера скушают много памяти, 16 цветов ведь. Если полностью буферизировать. Там и так на прешифт спрайтов потратится ого..

Jerri собственно всё расписал как делается с буферизацией и раскладкой по кускам буферов обновлять/не обновлять/обновлять, но потом. Но имхо спек-то побыстрее да и он "одноцветный"

[svofski]

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