Пока есть время, напишу логику движка.
Во первых, всё строится на двух классах (Базовых объектах, если по-русски): класс тела и класс мира. Первый класс довольно прост: он содержит в себе значение позиции, скорости, силы, действующей на него в это мгновение. Также он содержит методы (
Причастия действия, которые выполняет объект, или выполняются над ним. При этом эти действия заложены в самом объекте. Пример: при нажатии на игрушку-пищалку "вызывается" её "метод" "пищания"), которые выполняют базовые операции над вышеперечисленными величинами (Найти радиус из плотности и массы и т.д.). Сразу хочу сказать, что в САМОМ движке графической части НЕТУ, все картинки выводятся на экран доп. кодом. Это сделано для того, чтоб заинтересовавшимся людям (Или мне
) было легче копипастить движок в другие программы, не таща с собой графические библиотеки. Ладно, про физ. объект рассказал (Собственно, если вы не поняли сами, они нужны как прослойка между интерфейсом и движком).
Теперь перейдём к самой сложной части, к тому, что все расчёты и делает. Класс мира! Вся и всё физики моего движка. В нём хранятся процедуры ньтоновской гравитации, коллизии, перемещения тел и прочие вкусняшки. Я думаю, всё кроме коллизии (Столкновений) понятно и я не буду останавливаться на них. Расскажу поподробнее о коллизии. Хотя, что тут рассказывать, всё до меня ещё сделали:
MrKerbMan, Объекты круглые? Тогда при просчете следующего положения создавать виртуальный прямоугольник длиной равной перемещению объекта и шириной, равной диаметру круга. Собственно, нужен не сам прямоугольник, а координаты его вершин. Зная размер и положение объекта, направление и величину его скорости, можно без труда найти эти координаты. Так вот, в конце каждого кадра проверять на пересечения эти прямоугольники(я точно не помню алгоритм, поищи сам, но он весьма элементарен, особенно для 2д и не ест много ресурсов). Нет пересечения - все спокойно, можно давать следующий кадр. Есть - возможны пересечения и тут нужно рассматривать отдельно эти объекты на предмет столкновения. Для этого разбить виртуально кадр на гораздо меньшие куски времени и на каждом куске мерять расстояние между центрами двух объектов. Как только это расстояние меньше либо равно сумме диаметров объектов - поздравляю, имеем столкновение, причем известно точное его время и положения объектов - считай не хочу новые траектории. Более того, учитывая линейность движений внутри кадра, как только расстояние начнет увеличиваться, дальше можно не считать, ибо столкновения не будет. Недостатком модели есть то, что один объект за один кадр не сможет столкнуться больше чем один раз. Достоинство - с прямыми руками кодера, даже калькулятор потянет расчет.
Складываем модули скоростей. Как вариант, складываем по модулю проекции скоростей на оси отдельно и выбираем сумму по той оси, которая будет больше. А еще можно из большей по модулю скорости вычесть(векторно) меньшую скорость и взять модуль результата... и еще есть с десяток вариантов, чеснослово, не знаю, что подойдет лучше по соотношению сложность/точность. В любом случае, всегда лучше брать немного больше, чем немного меньше.
Далее суммируем радиусы объектов и полученное значение делим на вышерассчитанную теоретически максимальную скорость сближения. Полученное число и есть оптимальный отрезок времени, который гарантирует, что момент столкновения не будет проморган. Как вариант взять 0,9, 0,8 или даже 0,5 от этого значения, чтобы наверняка.
Всё сделано АБСОЛЮТНО так, как написал Лякуша.
Ну, думаю самое "интересное" объяснил.
Код движка потом залью.