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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если (X2<X1+deltaX1+N и X2>X1) [проверка по горизонтали] тогда нельзя осуществить перемещение (будет коллизия).

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

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

Цитата:

---

Сообщение от newart

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

---

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

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

Цитата:

---

Сообщение от lvd

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

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

---

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

Цитата:

---

Сообщение от lvd

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

---

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

Цитата:

---

Сообщение от rasmer

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

---

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

Цитата:

---

Сообщение от newart

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

---

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

Цитата:

---

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

---

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

Цитата:

---

Сообщение от lvd

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

---

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

Цитата:

---

Сообщение от lvd

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

---

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

Цитата:

---

Сообщение от newart

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

---

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

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

Цитата:

---

Сообщение от axor

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

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

---

Врагов десяток, плюс куча частиц, 2 игрока...
А Gogin, где его искать, на мыло он молчит.
Да и в Dizzy, там не совсем то о чем я говорю.

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 тактов.

Всем привет! Хочу поднять тему из небытия. Как осознаётся перемещение игрока по ландшафту на современном уровне развития человечества? Интересует сценарий типа соника, с округлыми траекториями, экран скроллится.