Не знаю, будет ли это реализовано на векторе, но можно посмотреть, как это сделали на спеке.Цитата:
Сообщение от PPC
Вид для печати
Не знаю, будет ли это реализовано на векторе, но можно посмотреть, как это сделали на спеке.Цитата:
Сообщение от PPC
Очень недурно, но на Векторе можно и вертикальный скролл замутить, и весь вьюпорт заполнить тайлами. Так как памяти на рамдиске дофига. Только вот рендерер получится довольно заморочный. А по скорости, думаю получится даже быстрее. Плюс с двойной буферизацией вообще никакого мырганья. На видео пару раз тайлы всё-таки мыргнули.
Двойная буферизация это большой плюс, но насчет скорости трудно согласиться. Из преимуществ вектора разве что удобная организация экрана.
Хотя в такого рода играх на векторе еще можно немного выиграть по скорости за счет плоскостей и почти полного отказа от разноцветности. Если тайлы и спрайты (кроме гг) выводить в одной плоскости, а гг в другой, то его можно рисовать без всяких логических операций. Если он не перемещается а что-то делает на месте, можно ничего не стирать, просто выводить другую фазу движения. При перемещении можно стирать только на различающихся позициях. Плюс если есть тайлы и спрайты которые заведомо не могут пересечься с гг их тоже можно рисовать в "его" плоскости с теми же упрощениями. Можно даже попытаться решать это на ходу, тогда правда от разноцветности придется совсем отказаться
В Роботах последовательно выводится:
1.Тайлмап на весь вьюпорт тайлами 16×16. При этом части тайлмапа динамически меняются (вентиляторы, двери, подъёмники)
2. Спрайты с размерами, кратными тайлу, привязанные к координатной сетке тайлов (батарейки и т.п.)
3. Главный герой с альфой размером 16×40
4 Поверх-спрайты с произвольной координатой
5. Поверх всего этого - тайлмап с альфой для создания участков переднего тайлового плана разной прозрачности с просвечивающим задним планом и окрашенными "стёклами". Пробег идёт по всему вьюпорту, правда выводятся не каждый тайл.
Скролл достаточно быстр, чтобы поделённый на 4 был не медленнее, чем на видео.
Не надо никаких решений "на лету". Это внесёт чоппинесс. Как и не надо использовать плоскости отдельно, нет такой необходимости: 2х-битные спрайты с альфой и так достаточно быстро выводятся. Ты прочти ещё раз алгоритм для 2х пиксельной субтайловой точности, который я описал: это по операциям практически рендерер Роботов, за исключением одного ORA М в 3х четвертях случаев. 8 тактов на байт. Плюс выборка второй половинки байта из другого банка. Если вместо пункта 5 выше поставить такую выборку и отказаться от тайлмапа для переднего плана, скорость будет сравнима с той, как сейчас в Роботах/4. По прикидкам-быстрее, чем на видео. Ну, или сравнимо.
Я старался писать не конкретно про роботов, а в принципе. Если переведешь роботов на субтайловую точность - это будет очень здорово!
Спасибо. Я знаю, как всё сделать, но страшно браться. Объём переделок не кислый. А если делать такой скроллер как на видео, то да, наверное придётся мутить с плоскостями. Но и в этом случае, как ты написал, нужно будет продумывать алгоритмы клиппинга и стирания отрисованного чтобы было хотя бы сравнимо со скоростью на видео. Ясно, что так быстро при этом вряд ли получится: объём видеопамяти чудовищный по сравнению со спекки.
Может для пробы стоит попробовать умеренный вариант:
1. Точность вывода до 8x8, соответственно хранение графики можно не трогать и процедуры вывода тайлов оставить
2. Можно даже не писать отдельные ветки процедур для вывода по краям - после вывода всего в игровое поле выводить боковые "панели", которые затрут половинки
Имхо больше сил чем вывод займет коррекция логики, т.к. в таком варианте гг будет взаимодействовать с игровым полем по полтайла. Хотя можно упростить себе жизнь и оставить "логический" шаг перемещения потайловым, просто разбить его на две фазы, чтобы выглядело плавнее
Да, именно такой путь я и перетираю сейчвс в голове: оставить логику тайловой, и менять только рендеринг. Правда всё-же с двумя дополнительными ветками для вывода по пол тайла. Они всяко могут пригодиться. Хотя, у твоего предложения с боковыми панелями тоже есть несомненное достоинство - равномерность скорости вывода. С другой стороны, вывод боковых панелей-это тоже такты. Там ведь, кстати, тоже тайлы ;). Всё обрамление тайловое, и отрисовывается один раз. Только индикаторные бары изменяются в соответствии с полученными повреждениями или когда power-ups берутся. Я тяжёл на подъём, буду много думать :). Может и решусь. Но путь видется именно таким-сначала сделать байтовый рендеринг, и только потом на его основе пиксельный.
PS. Мне, кстати, в какой-то момент понадобится распаковщик полноэкранных изображений из банков электронного диска. Мы с тобой как-то прикидывали, какой подойдёт, вроде даже пришли к консенсусу. Но я тогда отказался, предпочтя скорость блиттинга размеру. Надо бы почту поднять, поглядеть наши обсуждалки. Вопрос в следующем:насколько сложно будет перетолмачить алгоритм распаковщика чтобы выхлоп шёл в видеопамять, а чтение стеком из банка? Я просто на имплементации не смотрел ещё, а ты вроде с ними игрался тогда активно.
Sent from my SM-P900 using Tapatalk
Ответил почтой