Комментарии 23
Прикол с таймером для "отдышаться" лишний. Это точно никому не нужно. Если что, в крайнем случае у тебя ядро процессора будет долбиться в сотку с максимальным фпс. Но лагать ничего не будет.
"Как в Angry Birds" делается тремя событиями (pressed уже обрабатывается в коде): https://www.sfml-dev.org/tutorials/2.5/window-events.php#the-mousebuttonpressed-and-mousebuttonreleased-events и https://www.sfml-dev.org/tutorials/2.5/window-events.php#the-mousemoved-event . На pressed надо запоминать координату нажатия, на moved - рисовать стрелку между координатой нажатия и текущей координатой мыши, а на released -- создавать объект и давать ускорение.
По сути такой же делал в школе на turbo pascal 6.0
Аналогично.. Только паскаль был пятый))
Удивительно, что статьи на эту тему стабильно "лайкаются". Такое уже было на Хабре на разных языках. На JavaScript, например. И судя по комментам, каждый раз это вызывает восхищение, как от магии.
Одно время я тоже думал написать в песочницу подобную статью (ещё когда это небыло мейнстримом). Но видимо из-за повышенного уровня синдрома самозванца, мне казалось что такая банальная вещь не достойна целой статьи.
Накопление ошибок интегрирования? Не, не слышал.
Как я знаю вроде нету нормальных алгоритмов для такого? Ты либо энергию теряешь, либо фаза сдвигается постоянно, не?
Поясню то что "знаю" - когда ты меняешь состояние, ты пишешь типо "+2м/с" к объекту. Потеря энергии означает что сумма всех изменений не будет равна тому, что мы имеем в процессе интегрирования. А "фаза", как я это понял, то что изменения непостоянны/"слегка смещены" по времени, от чего график с интегрированными vs запись в массив, будет постоянно сдвигаться на какой-то шаг, хотя энергия может сохраняться.
PS за матан вообще не шарю, самоучка
Спасибо за информацию, буду читать что за ошибки интегрирования такие)
Не уверен, что алгоритм проверки столкновения отработает корректно, если за одну итерацию достаточно большое приращение координат "пропустит" момент, когда "расстояние между радиусами (dist) меньше сумм радиусов". Особенно на встречных, но смещенных от прямой курсах?
Делал такую симуляцию в детстве. Проблема была в том, что орбиты были неустойчивы. Возможно, дело не только в ошибках интегрирования, но и в том, что такая система дифференциальных уравнений сама по себе не является асимптотически устойчивой.
Больше всего мне хотелось бы реализовать силу и направление начального движения планеты через клик и оттягивание мыши (как в энгри бердс).
По нажатию мыши запоминаешь координаты x1, y1. По отпусканию получаешь координаты x2, y2. Вектор {x1 — x2, y1 — y2} будет и направлением, и скоростью движения, только домножь на нужный коэффициент, чтобы было адекватно остальной картине мира.
Я еще не совсем хорошо понимаю, как заливать куда-либо c++ проект вместе с его зависимостями, поэтому вам придется самостоятельно устанавливать либу и подключать ее, если вы захотите это потестить.
Вместе с зависимостями никто проекты не заливает. Достаточно выложить на github репозиторий с двумя файлами - исходником и CMakeLists.text/meson.build/Makefile в зависимости от того чем он собирается. По-хорошему ещё с лицензией и readme.
Для полноты картины хотя бы вставили гифку результата симуляции.
Также может быть интересна двумерная симуляция по другим законам тяготения:
В данном случае, конечно, не критично, учитывая специфику задачи, но тем не менее: использование pow для возведения в целые степени всегда режет глаз. А уж в квадрат...
Также: почему float, а не double?
По поводу pow - мне казалось наоборот каким-то оверхедом писать два раза одно и тоже, если можно воспользоваться готовой функцией.
По поводу float - не уловил разницы между ними, в силу своего нетипизированного пока еще мышления)
Как я понял, точности float должно хватить.
Почитайте вот это на досуге, получите удовольствие: https://stihi.ru/diary/datomir/2013-06-01
[Pet] Двумерная симуляция взаимодействия небесных тел на C++