ZXNet эхоконференция «code.zx»


тема: Коллизии с ландшафтом



от: Valery Grigoriev
кому: All
дата: 14 Jan 2006
Hello, newart

Обычно такие задачи решаются математически, а не в лоб.

Я не совсем понял из постановки задачи, что нужно - графически (по пикселам на
экране) определить столкновение с ландшафтом или математически?

Если известно направление, известна позиция, известно в какую сторону должен
переместиться персонаж, то математически такая задача очень просто решается.

Вначале производится анализ - возможно ли перемещение, в принципе так как
вектор движения известен можно прсмотреть какие препятствия находятся рядом,
составить обыкновенное уравнение и выполнить сравнение, если в результате
получается превышение - тогда дальше не едем/не катимся/не летим. Если же нет
превышения - движения продолжаем.

Сам объект/персонаж будет характеризоваться габаритами - высотой и шириной.
Hачальная точка будет приниматься откуда угодно (хоть с низу хоть с верху).

Тогда тебе нужно при движении персонажа влево оценивать по крайней левой грани,
при движении вправо по крайней правой, вниз соответственно по нижней вверех по
верхней.

При комбинированной движении оценивать сразу по двум направлениям.

Сами препятствия тоже можно оценить по габаритам. Тогда они автоматически
станут как бы выпуклыми - т.е. если препятствие есть то оно и слева и справа и
снизу и сверху будет непроницаемым для персонажа.

Вот есть Базисная система отсчёта - например крайний левый верхний угол экрана.
Отсчёт ведётся по оси X вправо и по оси Y вниз.

Есть персонаж у которого известны:
X1 - позиция X - берётся тоже крайне левый верхний угол персонажа
Y1 - позиция Y
deltaX1 - ширина персонажа по X
deltaY1 - высота по Y

Аналогично для препятствия: X2, Y2, deltaX2, deltaY2.

Известно, что персонаж должен сместится на N пикселей вправо.

Возможно ли перемещение?

Если ( (Y1>Y2 и Y1Y2 и Y1+DeltaY1 [проверка по вертикали] - тогда два объекта - препятствие и персонаж -
находятся на одном уровне, а значит надо проверять их столкновение по X:

Если (X2X1) [проверка по горизонтали] тогда нельзя
осуществить перемещение (будет коллизия).

Во всех остальный случаях можно перемещаться вправо сколько влезет.

Математика очень простая - в смысле что нет необходимости использовать
калькулятор и т.п., можно все процедуры написать готовыми самому.

от: lvd
кому: All
дата: 14 Jan 2006
Hello, newart

new> Делая игру сталкнулся с небольшой проблемой.
new> Герой и враги двигаясь по ланшафту должны
new> плавно его огибать (как в Dizzy 7).

Что касается спрайтов ландшафта, то можно просто помечать, что он
проходимый/непроходимый. И во второй слой соотв-но рисовать/не рисовать его. А
что касается движений на несколько пикселов сразу - можно выпустить "щупальца"
длиной, равной шагу перемещения, и если они натыкаются на препятствие, то
соотв-но решать, то ли герой убился об стену, то ли подпрыгнул на 1 пиксел и не
заметил, етц.

Ещё радикальный вариант - потратить полдня на ковыряние анрылом в той же диззе.
=)

от: lvd
кому: All
дата: 14 Jan 2006
Hello, newart

new> Ты немного не понял. Второй слой он не рисуется на экран, он только
new> для проверки коллизий предназначен. Если спрайт 0 то он пустой,
new> тоесть целиком проходим.
new>

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

> Что касается "щупальцы", чем это отличается от моего метода?

Тем, что 1 раз на каждое произвольное изменение координат делается.

от: rasmer
кому: All
дата: 14 Jan 2006
Hello, lvd

lvd> Ещё радикальный вариант - потратить полдня на ковыряние анрылом в той
lvd> же диззе. =)

А ещё лучше - дизассемблировать движок из VAVовской демодиззи - он тама нетак
уж и много весит - и переработать его...

от: Александр Шушков
кому: All
дата: 14 Jan 2006
Hello, newart

new> Единсвенный выход которйя я пока нашел, это вызывать подпрограмму
new> провекрки коллизии столько раз на сколько надо переместить спрайт,
new> но это явно не оптимальный метод, особенно если на экране много
new> врагов который работают по такому же принципу.

Раз все действие происходит на одном экране, то врагов не должно быть очень
много, так что скорости должно хватить. Ведь не стотня же героев у тебя будет
одновременно там бегать.

А вообще у тебя под боком есть Gogin. Спроси, у него опыт уже есть.

от: Вячеслав Калинин
кому: All
дата: 14 Jan 2006
Hello, All

Делая игру сталкнулся с небольшой проблемой.
Герой и враги двигаясь по ланшафту должны
плавно его огибать (как в Dizzy 7).
Так-же возможны вертикальные прыжки, во время
которых ланшафт над головой не является препядствием,
тоесть герой может какбы сковзь него вертикально
пролететь.
По скольку на ланшафте будет травка и прочаи украшательства,
я решил создать дополнительный набор спрайтов, c контурами
ланшафта. Тоесть карта уровня состоит из двух слоев.

При прыжке пока герой летит вверх столкновения можно вообще
не обрабатывать. Hо когда герой после прыжка начинает падать
каким образом отличить вертикальные (я пометил их синим цветом)
препядствия (которые служат для ограничения движения влево-вправо)?
В принципе можно на пиксель отводить по 2 бита (как в примере
красный (1) горизональное, синий (2) пвертикальное, и 0 выключеный
пиксель. Поскольку спрайтов препядствий довольно немного, можно
даже не парится с битами а отвести на пиксель по байту.

Hо есть еще одна проблема, допутим герой после прыжка падает,
ну или даже просто бежит, причем дискретность перемещения
несколько пикселей допустим 4. Легко догадаться, что в таком
случае герой может просто проскочить скозь препядствие.
Ведь на колиззию с ланшафтом проверяеться далеко не весь герой,
а лишь несколько пикселей (по середине в районе ног).
Единсвенный выход которйя я пока нашел, это вызывать подпрограмму
провекрки коллизии столько раз на сколько надо переместить спрайт,
но это явно не оптимальный метод, особенно если на экране много
врагов который работают по такому же принципу.

Может чего-нибудь посоветуете?
Возможно мой способ в корне не верен?
Хакер из меня никакой, поэтому я не стал
ковырять игры и смотреть как это там сделано.

Файл: collision.png http://zx.pk.ru/attachment.php?attachmentid=2218

от: Вячеслав Калинин
кому: All
дата: 14 Jan 2006
Hello, lvd

lvd> Тем, что 1 раз на каждое произвольное изменение координат делается.

Hеврубаюсь, обьясни поподробнее.
Hапример известно, что спрайт в данный фрейм должен передвинуться (за раз)
на 4 пикселя.
Каковы действия?

от: Вячеслав Калинин
кому: All
дата: 14 Jan 2006
Hello, lvd

lvd> Что касается спрайтов ландшафта, то можно просто помечать, что он
lvd> проходимый/непроходимый. И во второй слой соотв-но рисовать/не
lvd> рисовать его. А что касается движений на несколько пикселов сразу -
lvd> можно выпустить "щупальца" длиной, равной шагу перемещения, и если
lvd> они натыкаются на препятствие, то соотв-но решать, то ли герой убился
lvd> об стену, то ли подпрыгнул на 1 пиксел и не заметил, етц.
lvd>
lvd> Ещё радикальный вариант - потратить полдня на ковыряние анрылом в той
lvd> же диззе. =)

Ты немного не понял. Второй слой он не рисуется на экран, он только для
проверки коллизий предназначен. Если спрайт 0 то он пустой, тоесть целиком
проходим.
Что касается "щупальцы", чем это отличается от моего метода?
А в дизи, там вроде как раз сканируется экран.

от: Вячеслав Калинин
кому: All
дата: 14 Jan 2006
Hello, lvd

lvd> Это ты немного не понял. Я тебе говорю - если спрайт видим но
lvd> проходим то не рисовать его в тот слой, а если непроходим, то
lvd> рисовать тот же, что и на экран (возможно, с постобратокой типа
lvd> заливки или утолщения).

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

от: Вячеслав Калинин
кому: All
дата: 14 Jan 2006
Hello, rasmer

ras> А ещё лучше - дизассемблировать движок из VAVовской демодиззи - он
ras> тама нетак уж и много весит - и переработать его...

Он ниемеет ничего общего с тем что делаю я.
У меня размер спрайтов карты фиксирован, и карта размером с экран.

от: aprisobal
кому: All
дата: 15 Jan 2006
Hello, newart

newart, может тебе подойдет следующая схема:
1. Есть буфер (назовем "буфером коллизии") 6144байт, в который, при входе на
локацию, отрисовываются спец. маски спрайтов локации. Как у тебя на скриншоте.
2. Также есть второй буфер коллизии. По формату он должен быть как у экранных
аттрибутов, размер 768байт. В зависимости от типа спрайта, в него заносятся на
4 байта(если спрайт 16х16пкс) данные: 0 - пусто, 1 - гориз. полка, 2 - вертик.
стена. Этот буфер заполняется тоже только при входе на локацию.
3. При прыжке (в буферах коллизии не надо ничего перерисовывать, как тут
советовали) отключаешь процедуру проверки на коллизию с гориз. полками, а как
только герой начинает падать, то включаешь её. Эта процедура гориз. коллизии
должна быть следующая:
1) добавляем объекту 1 пиксель по Y. Если нужно сместиться на 4 пкс, то
вызываем данную процедуру 4 раза. По-другому не получится - возможен перелет
или придется постоянно поднимать героя на высоту спрайта, а в твоем случае это
равноценно вызову данной процедуры коллизии.
2) пересчитываешь пискельные координаты в знакоместовые и проверяешь во
втором буфере коллизии присутствие горизонтальной полки.
3) проверяешь на коллизию в первом буфере инструкциями типа: LD A,(IX):OR
A:JR Z,sleduyschiybayt:LD A,(HL):AND E:CP (HL):JR NZ,chtotoest:INC HL:INC
IX.... ( и так три раза для спрайта 16пксл) где HL - адрес координаты (X героя
+ смещение на нижнюю линию спрайта героя) в первом буфере коллизии, E,... -
маски(уже просколлированные) нижней линии спрайта героя.
4) зацикливаешь.....

Максимум на одний объект будет 1000 тактов. 10х1000=10000 тактов.




Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Похожие статьи:
Новости - новые проекты на Спектруме: Легенды о Кирандии, Dune 2, Модемные Шахматы, Спртнтер, Домен ОС, Новый графический редактор для СПРИНТЕРА.
Интервью - Интервью с группой из Феодосии - X-THEME.
The end - Редакторы и авторы.
Пишите письма - Письмо от AiR'a с отзывом о журнале.
Обзор - Несколько моментов с выставки видео и аудиотехники Video FAIR, проходившей осенью в С-Пб.

В этот день...   29 марта