Приседания — это вам не просто так. Если игрок нажал клавишу вниз, это еще не значит, что принц должен просто присесть. Если он при этом стоит спиной на краю плиты, а сзади пусто — надо не садиться, а слезать. Если он стоит лицом к яме и на самом краю, то он тоже не должен садиться — он должен спрыгнуть вниз. А вот если не на самом краю, а чуть дальше от края — надо сесть. Но тут тоже есть нюанс: когда принц будет вставать, он наклонится над этой ямой и по его передним координатам определится пустота, но он не должен туда упасть, ведь под ногами есть опора. Но эта опора может и уйти из-под ног, если там падающий пол…
Вот сколько вариантов обработки простого нажатия кнопки «вниз»….
Но в целом, принц движется шустрее, чем на старом движке 🙂
Немного ускорил процедуру, выдающую объект обстановки по координатам — теперь адрес в лабиринте определяется раз в 5 быстрее, благодаря табличке смещений. А процедура эта вызывается несколько раз на каждом кадре для определения объектов, окружающих принца.
Долго не мог понять почему принц не хочет цепляться руками за опору при прыжке. И так и сяк крутил — вроде и опору видит и летит рядом. Чего ж не цепляется? Оказалось, все дело в счетчике высоты — если принц пролетел больше двух этажей, то он уже не должен цепляться за попавшуюся опору. А счетчик показывал неверные данные.
«Вчера его пигалица перемахнула через куст. Он всю ночь рычал от счастья.» Мультфильм «Что случилось с крокодилом».
Постепенно принц научился заново залезать, слезать, не бегать сквозь стены 🙂 Но впереди самое сложное — подбор шага на краю (который раньше был), и подбор шага перед ловушками (которого раньше не было). А также вечный источник глюков — падение. Это просто россыпь возможностей влететь в стену.
Радует, что теперь вносить изменения в систему обработки препятствий гораааздо проще. Нет миллиона сравений, есть таблица. Не радует, что некоторые движения основаны на особенностях спрайтов. Это немного усложняет задачу.
Но в итоге принц (пока что) бегает шустрей, чем при прежней системе.
Мда, переделка обработки препятствий — это глобально. Всему надо принца заново учить. На новом механизме пока что он может только бегать и падать в ямы. Представляю, как с этим долго мучился Евгений в свое время — 104 движения и для каждого надо найти правильный вариант реакции на обстановку.
Самая страшная подпрограмма в принце — обработка препятствий. Изначально написал ее Евгений, когда обучал принца бегать по лабиринту. Сначала бегать, потом прыгать, потом слезать-залезать и так далее. На каждом этапе добавлялось проверок на то, какие где расположены объекты, можно ли за них зацепиться и надо ли… Потом в эту подпрограмму (OBST) уже я начал добавлять всякие проверки. Потом вдруг выяснилось, что некоторые движения невозможно реализовать, так как они были изначально неправильно попилены на части. Пришлось пилить дополнительно. Добавлять проверок. Женя уже тогда называл все это не иначе чем «спагетти». Да, страшное там дело в итоге получилось. И самое фиговое, что весь этот макаронный трешак вызывается на КАЖДОМ кадре игры, так как в любой момент принц может провалиться, напороться на стену и т.д. А значит, это все дает нихилый вклад в пожирание быстродействия. Пару раз я уже пытался оптимизировать OBSTacle, но там тронешь одно — рушится все )) Принц начинает сходить с ума, прыгать внутрь стен, проваливается в ПЗУ… Отвратительно себя ведет.
Но пришла мне в голову идея, как все это разом упростить и ускорить. Пока что идея мне нравится, посмотрим, что получится. А то бывает, что красивая идея на самом деле работает медленнее, чем миллион проверок, которые на самом деле срабатывают далеко не все и не всегда и в итоге работают быстрее 🙂
Для начала я решил нарисовать блок-схему имеющейся системы обработки препятствий. Рисовал часа два.
Вот что получилось:
Влезло почти все, что было в исходнике OBST1. Я порадовался. А потом вспомнил, что есть еще файл OBST2…. Рисовать его уже негде, так что придется обойтись тем, что есть.
Итак, завтра я полностью сломаю Принца 🙂 Если заработает новая версия и она будет быстрая, это будет круто. Если же круто не будет — придется вернуть старые спагетти.
Добавил управление от джойстика. Как играть с джойстиком в виде ручки, я слабо представляю, правда. Но вот с джойстиком в виде клавиш должно быть очень удобно. Можно жать кучу кнопок одновременно, а это то, чего не хватает клавиатуре БК. Теперь прыгать с разбегу стало значительно удобнее. Единственное, что пока нелогично — при отпускании на джойстике кнопки «висеть» — принц продолжает висеть, ожидая кнопки «вниз». Это надо подумать как реализовать. Дело в том, что сейчас клавиатура и джойстик обрабатываются одновременно, и если проверять на «на джойстике ничего не нажато», то неизвестно, отпустил ли игрок кнопку джойстика или может у него и джойстика-то нет )) Разве что завести флаг «зацепился, используя джойстик», тогда если в порту 177714 ноль — значит и отцепился на джойстике.
P.S. Сделал такой флаг, посмотрим, всегда ли логично будет работать.
Падающие плиты плавно перетекли в решетки — с древних времен была проблема с отображением изначально невидимой части решетки, которая становится видимой после того, как плита упала. К тому же, обломки плиты у основания решетки тоже затирали часть решетки. И падающая у основания решетки плита вызывала проблему — решетка продолжала отображать часть плиты, запомненной в качестве фона. Два дня ломания головы и проблема решена. Ура, товарищи!
Решетка курильщика:
Решетка здорового человека:
P.S. Да, принц проходит сквозь решетку в отладочных целях, иначе я заколебался бы попадать в нужные для тестов локации.
Продолжаю работу над падающими плитами. Обнаружилось, что если такая плита лежит перед закрытой решеткой, то после падения плиты, решетка выводится с куском уже несуществующей плиты. Это происходило потому что фон под решеткой запомнился тогда, когда плита еще была перед ней нарисована. Надо было это фиксить, конечно. Придумал как — надо читать фон еще когда этой плиты нет перед решеткой, при выводе окна. Ок, прочитал. Пропал верхний уголок над решеткой — потому что фон запомнился когда плиты еще нет, но при этом еще и нет обстановки над решеткой. В итоге потом черный кусок над решеткой. Ок, при выводе решетки читаем нижнюю треть фона, где уже нарисовано все без плиты, а после вывода всего окна — дочитываем верхнюю часть фона. Начинаю тестить — жуть, принц проваливается в пол, вместо решеток — куски памяти, вместо обстановки рисуется шизофрения. Ого! Такого размаха глюководства давненько я не наблюдал!
Если глюки такие масштабные, значит поверх памяти вкатил, наверное, эти половинки фона или стек, может, запортился. В общем, что-то типа этого начинаю искать. Ищу и не нахожу ничего криминального. Как обычно. Плюнул на все, лег спать. Утро вечера всякоразней.
Утром (ну как утром…. в три часа дня) посмотрел свежим взглядом — все супер, никаких ошибок нет. Но все-таки утро рулит — пришла в голову мысль, что эти грабли мне знакомы. А не вылез ли я за пределы страницы памяти? Смотрю размер файла с этими подпрограммами — так и есть, на 20 байт больше, чем влезает в страницу. Кусок программы просто отрезался при загрузке. Перетасовал подпрограммы по разным загружаемым файлам и все ок — фоны читаются, решетки не портятся.
Но пока я все это делал, то решил, что надо все делать по-другому )))
Засиживаюсь иногда до трех часов ночи, когда кажется, что вот-вот и задача будет решена. Ну да, часто так и бывает — или нахожу где ошибка или уже исправляю этот баг. Но иногда это выходит боком. Недавно заметил, что шипы в лабиринтах перестали убираться, когда принц уходит из их зоны действия. Так как я недавно много чего оптимизировал в выводе спрайтов, то решил, что где-то задел проверку на координаты принца при выводе шипов. Сегодня решил исправить. Прошерстил весь контроль шипов — все вроде нормально. Но они не убираются! Делаю отладку, вижу, что принц вышел из зоны. И программа видит это, начинает убирать шипы. Счетчики бегут, спрайты меняются, а на экране шипы как торчали, так и торчат. Что за бред? Начинаю смотреть еще внимательней — да все срабатывает, вот фазы шипов пошли новые, убирающиеся. На экране шипы торчат.
Попил чаю, подумал о вечном.
Смотрю еще раз и вдруг вижу, что старый фон шипов выводится не командами MOV, а BIS! Т.е. вместо затирания старых фаз сохраненным фоном, этот фон накладывается на выведенные шипы. И новые фазы так удачно рисуются, что не вылезают за пределы старых. На экране выглядит так, как будто шипы торчат, а на самом деле там уже нарисовалось еще кучу фаз убирания и шипы убрались.
Ну и откуда там взялся BIS? В исходниках недельной давности там MOV. А потому что нефиг в три часа ночи оптимизировать вывод спрайтов!
Сегодня весь день боролся с одним глюком. В 11м лабиринте есть место с большим количеством падающих плит, они там занимают два экрана. И вот, пробегаю я там для проверки и вижу, что одна плита почему-то не падает. Точнее, в одном экране плита остается висеть вверху, как будто я по ней и не пробегал, а в другом экране почему-то нет на одном месте обломков, хотя плита туда падала и они должны там валяться. Сначала я думал, что дело в том, что принц наступает на плиту, она начинает качаться и тут принц падает в окно ниже. Конечно, думал я, текущее окно сменилось, а фаза плиты, небось, еще не дошла до точки падения и при смене окна фаза обнулилась, что и вызвало застревание плиты. Но в процедуре смены окна вроде бы все было хорошо. Начал отлаживать, вижу, что при смене окна все-таки есть баг, в редком случае плита может еще не успеть упасть и текущее окно у нее не сменится. Исправил. Вообще ничего не изменилось. Снова сижу в отладчике, вылавливаю эту плиту. Все вроде упало, а плита в лабиринте не стерта! Конечно она там выводится, ведь если код плиты остался на месте, то она и должна вывестись! Смотрю место, где плита должна стереться, когда начинает падать. В отладчике дохожу до этой точки и вижу, что плита стерлась. Но через пару кадров она снова в массиве лабиринта появляется! Как так-то? Ага, ведь есть случай «mcfly», когда падающая плита падает на падающую плиту и тогда в лабиринт снова записывается код 15 (падающая плита). Неужели плита умудряется упасть «сама на себя»? Фиг его знает, может что напутал с координатами при смене окна… Но нет, эта подпрограмма не вызывается при трассировке…
Начинаю отслеживать тот момент, когда же вновь появляется код плиты в лабиринте на старом месте. И вижу, что это происходит при восстановлении фона для стирания плиты с экрана! Вот это поворот! Каким же боком восстановление сохраненного под плитой фона влияет на состояние элементов в лабиринте?? Оказывается, в 90х я не дописал толком эти самые падения плит — нет проверок на высоту спрайта плиты при проваливании плиты за границу экрана! Таким образом, когда плита подлетала к нижней границе экрана, фон для нее запоминался с куском данных ЗА этой границей, через адрес 100000. Со 100000 как раз подключена страница с лабиринтом. Фон запоминался, поверх экрана и лабиринта рисовалась плита (!), потом фон восстанавливался и лабиринт тоже. Поэтому и плиты «возвращались» на место — этот кусок данных возвращался на место.
Вот такой вот мегаглюк. Любимый переход через 100000, чтоб его.
Свежие комментарии