Просмотр полной версии : Программный вертикальный скролл
Всем привет!
Одолела меня ностальгия, и я решил попробовать сделать программный вертикальный скролл. Программный - потому что аппаратная прокрутка сдвигает весь экран сразу, а в играх как раз зачастую скроллируется только часть экрана, представляющая собой игровое поле, а информационная часть остается неподвижной (например, как в "1942" и "1943" на ZX Spectrum).
Увы, даже если ограничиться 21 столбцом по горизонтали и одной экранной плоскостью, в прерывание вписаться не удается - даже применяя частично развернутые циклы и пересылку экранной памяти через стек :( Может быть, кто-то из опытных вектористов глянет на мой код и скажет, где проблема? (надеюсь, не в ДНК :) )
Можно двигать чуть быстрее, если вместо
pop\ mov \ inr \ mov \ inr (44 такта на пересылку 2х байт)
сделать
pop\ shld (32 такта на пересылку 2х байт)
только придется отдать 4 байта для процедуры пересылки на каждые 2 пересылаемые байта
теоретический предел в этом случае: 312(строк)*192(такта в строке)/32(такта)*2(байта)=3744 байта можно переслать за промежуток между прерываниями. Только времени ни на что больше не останется и процедура пересылки займет более 7000 байт.
Если речь идет не о переносе с другого компа и движок пишется с нуля, то может стоит прикинуть - если площадь скролируемого участка экрана больше площади неподвижного(ых) участка(ов) то выгоднее применять аппаратный скролл и программно обновлять "неподвижные" участки. Принцип относительности :).
Если речь идет не о переносе с другого компа и движок пишется с нуля, то может стоит прикинуть - если площадь скролируемого участка экрана больше площади неподвижного(ых) участка(ов) то выгоднее применять аппаратный скролл и программно обновлять "неподвижные" участки.
:v2_thumb: Я тоже думал о таком способе (тем более, что в "Полете" именно так и сделано). Припоминаю, что в студенческом возрасте даже пытался подобное реализовать, но безуспешно, поскольку про "джедайские приемы" вроде вывода через стек я тогда и не слышал.
Отдельное спасибо за формулу расчета количества тактов на прерывание!
Если заюзать Z80 то там есть циклические команды блокового перемещения данных
если площадь скролируемого участка экрана больше площади неподвижного(ых) участка(ов) то выгоднее применять аппаратный скролл и программно обновлять "неподвижные" участки
Попробовал воплотить в кодах, работает (если интересно, см. вложение). Правда, "неподвижные" участки пришлось выводить не через стек, т.к. если записывать в видеоОЗУ через PUSH, то на границе номеров строк 00/FF будут глюки. А если каждый раз проверять текущее значение SP и его корректировать при достижении границы, то это мне показалось накладным по тактам... В случае чего, задействую стек для чтения спрайтов из ОЗУ (пока что, правда, спрайт один и он жестко зашит в коде :) )
P.S. Файл с расширением .MAC во вложении - это исходник на ассемблере. Я пользуюсь дисковым ассемблером M80, для которого именно это расширение стандартное. Сначала было .ASM, но я замучался его постоянно вручную дописывать при компиляции :)
Я так понимаю, что River Raid-у на Векторе всё-таки быть =)
Ещё раз про программный скроллинг, гляньте кому интересно, код писал под Z80
Я так понимаю, что River Raid-у на Векторе всё-таки быть =)
В плане графики - точно ничего не мешало. В своё время от идеи написания этой игры меня отвернуло только то, что я не сумел найти способ генерировать шум самолёта и взрывов. На Atari для этого был специальный "музыкальный процессор", на Векторе потом тоже появился AY, но это уже было значительно позже. А делать полуфабрикат - очень не хотелось.
Обалденный горизонтальный скролл в демке From Sunset To Dawn (http://www.sensi.org/~svo/scalar/ware/16), если кто не видел.
Наверное все и так знают, но на всякий случай -- на обновление переменной цикла, проверку и переходы тратится уйма времени, поэтому выгодно разворачивать циклы: целиком, или хотя бы частично.
К слову сказать, в 1990-раннем году я был бы готов стерпеть River Raid без правильных звуков =) Но мне кажется, что с графикой тоже все не так уж просто. Если и возможно достаточно плавно обновлять экран, то умения это должно потребовать немалого.
горизонтальный скролл в демке From Sunset To Dawn
Такое решение годится только для демки, к сожалению. Сложно представить игрушку, в которой движущаяся часть экрана состоит из одинаковых фрагментов высотой 6 точек.
Заинтриговало меня, насколько быстро можно рендерить уровни в играх.
Потратил месяц (поэтому ничего сюда не постил) и написал рендерер уровней из спрайтов. Уровни могут содержать до 256 спрайтов и иметь максимальный размер 255x255 спрайт. Организация спрайтов -
2x на 2y на depth, где
x - байты
y - пикселы
depth - количество плоскостей.
Пришлось отдельно написать грабилку и конвертилку спрайтов, потому что формат спрайта довольно-таки заморочный, зато полностью исключает использование add/sub при выводе в плоскости. Для вывода на экран используются только inc,dec и push. Рендеринг возможен во viewport любого размера (от размера спрайта до всего окна)
О скорости рендеринга судите сами. В примере рендерится в 3 плоскости т.е. 8 цветов на экране. Скорость можно ещё увеличить, прописав custom interrupt handler. Я не заморачивался с этим вообще, важен алгоритм. Поэтому просто взял и использовал PPCLIB (поэтому .com файл немного раздуло из-за ненужного фонта).
Уровень находится в файле level001.map
Из readme:
Run under MicroDOS
KEYS:
Arrows : level scrolling
Plus key : render level at full screen
Minus key: render level in viewport
ESC (AP2): exit to MicroDOS
А перерисовываются ли те спрайты (тайлы), которые при скроллинге не меняются? Или можно за счёт этого ещё ускорить?
А перерисовываются ли те спрайты (тайлы), которые при скроллинге не меняются? Или можно за счёт этого ещё ускорить?
Да, перерисовывается всё, весь viewport (в пределе-экран). Скроллинга, как такового нет, он достигается перерисовкой. В принципе, можно помудрить и ускорить, если после "скроллинга" в новом месте такой-же спрайт, как был до этого.
На всяк случай, вот код отрисовки одного спрайта. Ассемблер нужен m80 (я макросы люблю).
StkMvUp Macro
pop d
mov m,e
inr l
mov m,d
EndM
StkMvDn Macro
pop d
mov m,e
dcr l
mov m,d
EndM
SpMvUp Macro _height
Rept (_height SHR 1) - 1
StkMvUp
inr l
EndM
StkMvUp
EndM
SpMvDn Macro _height
Rept (_height SHR 1) - 1
StkMvDn
dcr l
EndM
StkMvDn
EndM
NextPlane Macro
mov a,h
add b
mov h,a
EndM
CSEG
PUBLIC PutSp16
; Non-reentrable
; Needs disabled interrupts
; <HL> - sprite address
; <DE> - screen address
; <C> - number of planes 1-4
PutSp16:shld ldSpr+1
lxi h,0
dad sp
shld sp16ex+1
xchg ; <HL> - screen address, <DE> - return address
mvi b,20h
ldSpr: lxi sp,0
sp16lp: SpMvUp 16
inr h
SpMvDn 16
dcr c
jz sp16ex
NextPlane
SpMvUp 16
dcr h
SpMvDn 16
NextPlane
dcr c
jnz sp16lp
sp16ex: lxi sp,0
ret
End
Так мы скоро дойдем до портирования After the War :)
After The War 2 (http://youtu.be/llAfKrNEhfE)
Авторы оригинала, скорее всего, очень не зря ограничились игровым пространством в пол-экрана. Ну и монохромная графика в игровом пространстве нам тоже очень на руку.
Так мы скоро дойдем до портирования After the War :)
При желании, да наличии времени-вполне реализуемо. Причём можно даже в 4х цветах сделать. При этом рендерер заметно быстрее работает, чем c 8-ю цветами, даже полноэкранный вывод почти не напрягает.
Тут видятся 2 проблемы:
1. Как сделать плавные оверлеи (ну все эти летающие гады поверх карты уровня).
Думаю, можно соорудить frame buffer из 2х пар плоскостей, и переключать эти пары (прошивкой палитр) поочереди, отрисовывая overlays в затемнённую в данный момент пару. Визуально перемещение оверлеев при этом должно вроде выглядеть очень плавно.
2. Как добиться музыки с AY без затыков. Ведь по крайней мере, во время вывода спрайта по методу выше прерывания должны быть запрещены, и могут появиться небольшие audio glitches. Я в плавном воспроизведении музыки не копенгаген, может кто поделится идеями/соображениями?
Попробую, пожалуй написать поддержку фраме буфера.
1. Как сделать плавные оверлеи (ну все эти летающие гады поверх карты уровня).
Так а этих гадов можно как раз в отдельную экранную плоскость отрисовывать, у которой, путем программирования палитры, всегда приоритет над фоновыми 4мя цветами карты.
Собственно, все движущиеся спрайты можно в этой плоскости и держать. А если тактов хватит - то и две плоскости под спрайты отвести, тогда не только фон, но и герои будут 4х цветными.
Только вот в оригинале, судя по видео, горизонтальный скроллинг не умещался в одно прерывание в одном цвете, и это с Z80 на борту. На Векторе мы можем сэкономить на AND/XOR с маской для оверлеев, но даст ли это достаточный запас скорости? Учитывая более тормознутый i8080, без LDIR'ов, да еще и с неоптимальной Векторовской схемой тактирования?
Так а этих гадов можно как раз в отдельную экранную плоскость отрисовывать, у которой, путем программирования палитры, всегда приоритет над фоновыми 4мя цветами карты.
Тогда они как раз не будут плавными, потому что будет видно их стирание/отрисовка. Я как раз именно этого и хочу избежать. Придётся конечно xor-ить, и жестоко, но надеюсь что быстродействия на отрисовку пары-тройки гадов хватит.
Тогда они как раз не будут плавными, потому что будет видно их стирание/отрисовка.
Если во время обратного хода луча отрисовывать, то все должно быть плавно ИМХО. В "Полете" же такая схема применяется, и самолетик очень даже плавно летает.
Единственное что - скорее всего придется скролл фоновой карты делать за одно прерывание, потом пересчет координат героя, гадов и снарядов, и их отрисовка - уже в следующее прерывание. Могу ошибаться, но мне кажется, горизонтальный скролл по 2м плоскостям "съест" почти все такты, доступные в интервале ОХЛ.
Если во время обратного хода луча отрисовывать, то все должно быть плавно ИМХО. В "Полете" же такая схема применяется, и самолетик очень даже плавно летает.
[snip]
Могу ошибаться, но мне кажется, горизонтальный скролл по 2м плоскостям "съест" почти все такты, доступные в интервале ОХЛ.
"Это всё правильно, даа ... бумага написана справедливо" (с) Кавказская Пленница.
Но есть некоторые моменты...опять-же я только моё маленькое ИМХО, take it with a grain of salt.
В "Полёте" самолётик маленький, его размер не меняется, и это всего-лишь 1 спрайт. Такого не жаль выводить хоть во время каждого ОХЛ, он не изменит сильно время выполнения обработчика прерываний, и не повлияет сильно на плавность кода вне прерывания.
Отрисовывать всех гадов во время ОХЛ за раз накладно, да и нет смысла: всё равно 50-ти кадров в секунду от engine мы не добъёмся.
Считать, сколько тактов можно максимум использовать для вывода спрайтов в ОХЛ ИМХО нет смысла, всё равно кому-нибудь понадобиться вывести "ну ещё один спрайтик, Кешенька" ;)
Затачивать универсальный (до разумных пределов) engine под 5 спрайтов и ни-ни, а то-расстрел не вижу смысла. Потом, своё положение/вид они меняют реже чем раз в 20ms. Значит-нужно делать pipeline, т.е. очередь отрисовки, и за каждое прерывание вынимать из очереди, скажем, не больше 2х гадов. Учитывая, что размеры гадоы разные, и очередь часто будет пустая, а иногда забита, engine будет то тормозить, то ускоряться. Кстати это конкретно видно на той спековской игрушке. Скорость-то есть, а вот плавности-нет. Это всё миллисекунды, но на скроллинге, который вне прерывания визуально скажется.
Безусловно, спрайты отдельно от уровня и проще (нет xor-ов) и быстрее. Но frame buffer, c другой стороны, позволяет полностью спрятать весь процесс отрисовки (и уровеня и гадов). Кста, pipeline там тоже возможно сделать (если не было команды на скроллинг уровня).
В общем, если время позволит, будем посмотреть, потому как надо экспериментировать и так и эдак.
Just my 5c.
При известном количестве плоскостей можно сэкономить ещё около 8 тысяч CPU states на полный экран. Зааттачил рендерер для 2х плоскостей. Вроде шустро, но всё равно есть visual glitches при скроллинге. Будем всё-ж делать framebuffer.
StkMvUp Macro _rp
IFIDN <'&_rp'>,<'d'>
pop d
mov m,e
inr l
mov m,d
ELSE
pop b
mov m,c
inr l
mov m,b
ENDIF
EndM
StkMvDn Macro _rp
IFIDN <'&_rp'>,<'d'>
pop d
mov m,e
dcr l
mov m,d
ELSE
pop b
mov m,c
dcr l
mov m,b
ENDIF
EndM
SpMvUp Macro _rp,_count
Rept (_count SHR 1) - 1
StkMvUp _rp
inr l
EndM
StkMvUp _rp
EndM
SpMvDn Macro _rp,_count
Rept (_count SHR 1) - 1
StkMvDn _rp
dcr l
EndM
StkMvDn _rp
EndM
CSEG
PUBLIC Spt216
; Non-reentrable
; Needs disabled interrupts
; <HL> - sprite address
; <DE> - screen address
Spt216: shld ldSpr+1
lxi h,0
dad sp
xchg ; <HL> - screen address, <DE> - return address
ldSpr: lxi sp,0
sp16lp: SpMvUp b,16
inr h
SpMvDn b,16
mov a,h
adi 20h
mov h,a
SpMvUp b,16
dcr h
SpMvDn b,16
xchg
sphl
ret
End
Собственно вот.
Аппликуха содержит 2 рендерера, чтоб их было проще сравнивать и охаить :D
1. Обычный рендерер (оранжевый цвет уровня)
2. Frame-Buffered рендерер (красный цвет уровня)
Переключнение между рендерами - пробелом.
Остальное-как раньше - стрелки, плюс - rendering на весь экран, минус - во viewport. Заранее прошу извинить за глюк - после переключения vieport-fullscreen возможен пустой экран и часто будет необходимо нажать какую-нить клавишу-стрелку для отрисовки.
АР-2 (esc) - выход в МикроДОС.
Разница между рендерерами особенно заметна на полном экране.
Мне лично больше нравится рендеринг с фрэйм буфером. Он хоть и *слегка* помедленнее, зато у него отсутствуют глюки ОХЛ при строчной развёртке. В общем, рад буду вашим комментам.
Следующий этап:
- поточить frame-buffered renderer на предмет плавности (всё определяется кодом в ISR, его количеством и стабильным числом тактов в ней)
- вывод оверлеев. Чувствую, это будет отдельная песня.
PPC, Если включить эмуляцию багов програмирования палитры (ну или смотреть на реале), то новый рендер глючно работает
А мжно выложить вертикальный скролл для того чтобы он мог снизу вверх поднимать анимированные спрайты разного размера ? Левая часть экрана под это дело задействована. Правая картинка. Грубо говоря напополам.
Желательно в Аласм
PPC, Если включить эмуляцию багов програмирования палитры (ну или смотреть на реале), то новый рендер глючно работает
Пасиб, это я поторопился когда писал custom ISR, и забыл Rept/EndM при программировании палитры поставить. Вот исправленная версия. Пишет в 0С 8 раз при переключении палитры. В принципе, я встречал тяжёлые случаи, когда и 8 было мало, но в любом разе этот код-промежуточный вариант.
Например, в зааттаченной версии, проц останавливается после отрисовки в скрытые плоскости, а сейчас у меня уже есть работающая версия, где проц бежит дальше до прерывания, делая весьма полезную background работу и не теряя такты.
Но однако, плавный вывод оверлеев оказался очень крепким орешком. Дело даже не в быстродействии (его то вроде достаточно), а в плавности всего рендеринга. Я уже начинаю подумывать о синхронизации через i8253 и создании multithreaded отрисовки.
В идеале видится самосинхронизирующийся код, который при выводе оверлеев, требующих перерисовки принимает решение, уместится ли перерисовка конкретного оверлея по тактам сейчас, до прерывания, или надо ждать следующего, пытаясь отрисовать сейчас более мелкие спрайты.
Реально прошу у всех помощи с музыкой. Нужен source как можно более быстрого плейера для AY с учётом векторовских wait states. Желательно, чтобы плейер умел играть какие-нить распространённык форматы. У меня есть сорцы старых плейеров времён демок Lyra, но уж очень они ветвисты. Заранее спасибки!
А мжно выложить вертикальный скролл для того чтобы он мог снизу вверх поднимать анимированные спрайты разного размера ? Левая часть экрана под это дело задействована. Правая картинка. Грубо говоря напополам.
Желательно в Аласм
Так ведь уже в зааттаченных примерах уровень скроллится во viewport произвольного размера. Пол-экрана ничем не хуже, чем "окно" в примерах.
А насчет спрайтов - я как раз над этим работаю. Анимированные спрайты разного размера и будут оверлеями поверх движущегося скролящегося (по всем направлениям) уровня.
Как сделаю более-менее плавный вывод, выложу версию где размер вьюпорта можно будет выбирать прямо из меню проги.
Есть даже более амбициозная идея: попытаться сделать поддержку многоплановости как в нинтендовских игрушках.
То есть имеется передний план уровня, движущийся с большей скоростью и задний - с меньшей. Векторовская архитектура видеоплоскостей идеально для этого подходит. Даже с фрейм-буферизированным выводом, можно задействовать по одной плоскости для заднего плана, и по 2-для переднего.
Насчёт кода, планирую выложить не только сорцы, но и тулкит для получения спрайтов. Чтобы сэкономить такты, формат спрайта сделан немного заморочной змейкой, и обычные редакторы так байты спрайта не тасуют.
В общем-то все мои плясы со скроллингом есть не что иное как в том числе и попытка создать тулкит для написания векторовских игр. Посему, если доведу до более-менее плавно работающего кода, выложу всё, ничего не утаю :) Но пока это всё в такой зачаточной стадии, что сорцы ещё рано выкладывать даже для совместной open source разработки.
VNN уже сделал спрайты разного размера которые снизу летят вверх и машут тем чем надо махать.
Вопрос в следующем, а как скодить чтобы:
http://s006.radikal.ru/i213/1106/47/0ca9eb33bb6b.jpg
В играх, например так летают враги в самолетных играх. По разным траекториям. Как оно скодить ? Спрайты в свою очередь должны спрайтить, а не быть одной фазой.
VNN По разным траекториям. Как оно скодить ? Спрайты в свою очередь должны спрайтить, а не быть одной фазой.
Со спрайтами - просто. Вверх/вниз проблем на Векторе двигать нет, можно хоть на пиксель.
Берётся спрайт и решается, насколько плавно он должен двигаться вбок. Скажем, если вбок надо тоже 1 пиксель, то прямо в runtime создаютя ещё 7 битмапов спрайта, сдвинутых на нужное количество пикселов.
Затем пишется код, переводящий текущие координаты, скажем, левой нижней точки спрайта в адрес начальной плоскости на экране и адрес сдвинутого на n бит спрайта из 8 подготовленных. В качестве примера, посмотрите мои сорцы аж бородатого 93 года с образа PPCLIB.fdd:http://sensi.org/~svo/scalar/ware/829/
Подойдут pixel.mac, line.mac, rectangl.mac
Там-же пример маскирования плоскостей (прозрачности частей спрайта)
Если говорить о скролле и забыть о том, что вывод тайлов через lxi + push все равно быстрее, то на 6128 применение недокументированных команд может оказаться оправданным.
Скролл вниз - pop h + shlx + inr e + inr e. По скорости и размеру, казалось бы, получается аналогично pop h + shld, но зато достаточно развернуть процедуру сдвига одного столбца, а не всех, как в случае shld, т.е. размер будет в {количество столбцов} раз меньше. В связи с отсутствием на 6128 квазидиска это особенно актуально. На ВМ1 inr по 8 тактов, что уже не так интересно.
Скролл вверх на 4 такта медленнее - lhlx + push h + dcr e + dcr e, но выигрыш по размеру остается.
Года 2 назад я самоуверенно утверждал (http://zx-pk.ru/showpost.php?p=642335&postcount=82), что субтайловый рендерер на Векторе просадит скорость до неиграбельной.
Озвучу ниже некоторые свои соображения по поводу субтайлового скролла применительно к Вектору, сидящие уже года полтора в мозгах дабы поправить досадное недоразумение.
Мне думается, что очень легко сделать программный скролл тайлмапа с дискретностью в 8 пикселов, и практически такой же скоростью как в Роботах. То бишь чистый скроллерный движок тайлов (без спрайтовых оверлеев, музыки и т.п.), может в теории давать 17-18 кадров в секунду во вьюпорт размером 208x160 пикселов при сохранении двойной видео буферизации. Тайлы - такого же размера, как и в Роботах: 16x16 пикселов, 2 бита на пиксел, змейкой.
Идея в том, что необходим рендерер как выше (http://zx-pk.ru/showpost.php?p=392196&postcount=21) (стеком), но имеющий 2 дополнительные ветки кода для вывода только левой половины тайла (1 байт по горизонтали) и для вывода правой половины тайла. Дискретность рендерера устанавливается в 8 пикселов (сдвиг по горизонтали побайтно). При выводе первой и последней вертикальной колонки тайлов используются 2 новые процедуры, выводящие по пол тайла (правая половина тайла для первой колонки и левая половина тайла для последней) или по целому тайлу в зависимости от чётного и нечётного кадра. Получаем субтайловый 8-пиксельный рендерер со скоростью как в Роботах. Вывод оверлеев, привязанных к координатной сетке тайлмапа (т.е. спрайтов, но с не произвольной координатой, типа батареек в Роботах), при этом становится сложнее так как им тоже нужно делать клиппинг, но к счастью по такому же 8-пиксельному алгоритму, то бишь, без сдвигов.
При определённых серьёзных ухищрениях, можно сделать и рендерер с субтайловой точностью в 2 пиксела и скоростью вывода наверное не хуже, чем в 2 раза по сравнению с Роботами (на самом деле-практически сравнимой). Для этого нужно при загрузке сдвинуть все тайлы на 0,2,4,6 бит, заполнив сдвинутые биты нулями и уложить полученные сдвинутые изображения в 4 банка RAM-диска в соответствии со сдвигом. При выводе нужен будет рендерер, получающий изображение тайла сложением (OR-ом) сдвинутых изображений для смежнных тайлов из 2х банков. Вывод оверлеев при 2-х пиксельной субтайловой точности придётся делать также используя клиппинг и заготовленные сдвинутые части битмапов.
рендерер с субтайловой точностью
Не знаю, будет ли это реализовано на векторе, но можно посмотреть (http://www.youtube.com/watch?v=E_Yr0Hsr7Xw), как это сделали на спеке.
Очень недурно, но на Векторе можно и вертикальный скролл замутить, и весь вьюпорт заполнить тайлами. Так как памяти на рамдиске дофига. Только вот рендерер получится довольно заморочный. А по скорости, думаю получится даже быстрее. Плюс с двойной буферизацией вообще никакого мырганья. На видео пару раз тайлы всё-таки мыргнули.
Двойная буферизация это большой плюс, но насчет скорости трудно согласиться. Из преимуществ вектора разве что удобная организация экрана.
Хотя в такого рода играх на векторе еще можно немного выиграть по скорости за счет плоскостей и почти полного отказа от разноцветности. Если тайлы и спрайты (кроме гг) выводить в одной плоскости, а гг в другой, то его можно рисовать без всяких логических операций. Если он не перемещается а что-то делает на месте, можно ничего не стирать, просто выводить другую фазу движения. При перемещении можно стирать только на различающихся позициях. Плюс если есть тайлы и спрайты которые заведомо не могут пересечься с гг их тоже можно рисовать в "его" плоскости с теми же упрощениями. Можно даже попытаться решать это на ходу, тогда правда от разноцветности придется совсем отказаться
В Роботах последовательно выводится:
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
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot