Верёвки и прочую soft-body (если постараться то и rigid-body) физику можно писать используя интегрирование Верле.
Вся теория завязана на том, что скорость — разница между текущим и предыдущим её положением.
Применительно к задаче реализация сводится к следующему (псевдокод):
Есть набор точек (joints) связанных пружинками (links).
Задача каждой точки — двигаться согласно скорости.
joint.update
tempPos = pos // запоминаем текущую позицию во временную переменную
pos += pos - lastPos // прибавляем скорость
pos += gravity // и вектор гравитации
lastPos = tempPos
Задача каждой пружинки — поддерживать нужное расстояние между её joint'ами.
link.update
delta = joint[1].pos - joint[0].pos // вектор в сторону второй точки
length = sqrt(delta.x^2 + delta.y^2) // текущее расстояние между точками
delta /= length // нормализация вектора
delta *= length - LINK_LENGTH // LINK_LENGTH - расстояние которое следует поддерживать
delta *= FORCE // FORCE - коэффициент упругости пружинки (0..1)
// расталкиваем точки в противоположных направлениях
joint[0].pos += delta * 0.5
joint[1].pos -= delta * 0.5
Сама организация цикла обновления сводится к обновлению всех joint'ов, и нескольким иттерациям обновления всех link'ов (для стабилизации).
Таким незамысловатым способом можно создавать верёвки, рэгдоллы (ограничить углы между link'ами), волосы и даже некий аналог твёрдотельной физики. Реализация простая и никаких физических движков не требует. Пример работы такой физики.
А у нас разве ракеты при старте взрываются? Если считаешь, что достаточно десятка успешных запусков для отладки всего спектра решаемых сегодня задач… см. выше, ибо дискуссии нет никакой.
Система, находящаяся в разработке, по определению не может быть отлаженной. Изучай хронику. Сейчас процент наудачных запусков много меньше, чем в лихие годы космонавтики, когда уже работала идеализируемая тобою система образования.
Ты чего разнылся? Есть такой процесс — отладка, и от него никуда не денешься. Будут ломаться независимо от уровня образования и опыта конструкторов, не газеты ведь печатают.
Если тебе по какой-то причине кажется, что такого процесса в космонавтике быть не должно… не расстраивайся, 95% населения разделяют твою точку зрения.
Походу ужасность заметна лишь ценителям, т.к. их музыкальное восприятие в большей степени строится на шаблонах гармоник. Интересно как бы они отреагировали на youtube.com/watch?v=GtQdIYUtAHg
Разработчики не дураки, целевая аудитория достаточно казуальна, чтобы вести бой против сильного ИИ, потому нецелесообразно задирать планку его поведения. Сложные случаи дешевле и разумнее заскриптовать, дав тем самым необходимую геймдизайнеру предсказуемость, а порой даже гарантию, выигрыша игрока.
Мне не нравится политика Adobe по отношению к Flash как игровой платформе. Но судя по последним презентациям, они начинают исправляться, что очень радует. Так например, обещают реализовать захват мыши (для шутеров), обработку ввода в полноэкранном режиме, обработку всех клавиш мыши и другие вещи ранее доступные только в AIR.
Абстрактное описание архитектуры D3D — не есть туториал, а «водой» такую картинку перестали называть ещё лет 10 назад до появления программируемого конвейера.
Всё что показано шейдерами назвать можно лишь теоретически, т.к. формально оно не требует ничего выше FFP. Я искренне надеюсь, что это лишь ограничения XNA, ибо iOS / Android поддерживают до 8 текстур и полноценную Shader Model 2.0.
Писал side-шутер, ситуация была обратной, т.е. до перехода на Cirrus (ранее Stratus) пинги с мухосранском были в 5-10 раз выше и коннекты не пробивались через NAT.
Кстати, Cirrus ведь имеет ограничение на коммерческое использование?
Вся теория завязана на том, что скорость — разница между текущим и предыдущим её положением.
Применительно к задаче реализация сводится к следующему (псевдокод):
Есть набор точек (joints) связанных пружинками (links).
Задача каждой точки — двигаться согласно скорости.
joint.updatetempPos = pos // запоминаем текущую позицию во временную переменную
pos += pos - lastPos // прибавляем скорость
pos += gravity // и вектор гравитации
lastPos = tempPos
Задача каждой пружинки — поддерживать нужное расстояние между её joint'ами.
link.updatedelta = joint[1].pos - joint[0].pos // вектор в сторону второй точки
length = sqrt(delta.x^2 + delta.y^2) // текущее расстояние между точками
delta /= length // нормализация вектора
delta *= length - LINK_LENGTH // LINK_LENGTH - расстояние которое следует поддерживать
delta *= FORCE // FORCE - коэффициент упругости пружинки (0..1)
// расталкиваем точки в противоположных направлениях
joint[0].pos += delta * 0.5
joint[1].pos -= delta * 0.5
Сама организация цикла обновления сводится к обновлению всех joint'ов, и нескольким иттерациям обновления всех link'ов (для стабилизации).
Таким незамысловатым способом можно создавать верёвки, рэгдоллы (ограничить углы между link'ами), волосы и даже некий аналог твёрдотельной физики. Реализация простая и никаких физических движков не требует.
Пример работы такой физики.
Если тебе по какой-то причине кажется, что такого процесса в космонавтике быть не должно… не расстраивайся, 95% населения разделяют твою точку зрения.
Кстати, Cirrus ведь имеет ограничение на коммерческое использование?