В дополнение к плану максимуму:
1) Графика - векторная, flat.
2) Музыка - ambient
3) Сюжет основан на идее об одиноком исследовании космоса.
По физике:
Я много игрался с движком, по этому в нем есть много всякого, что не будет использовано в игре:
1) Электрические заряды и электромагнитные поля.
2) Физика газов.
3) Реализация различных методов численного интегрирования.
Кому интересно, спрашивайте.
1) Графика - векторная, flat.
2) Музыка - ambient
3) Сюжет основан на идее об одиноком исследовании космоса.
По физике:
Я много игрался с движком, по этому в нем есть много всякого, что не будет использовано в игре:
1) Электрические заряды и электромагнитные поля.
2) Физика газов.
3) Реализация различных методов численного интегрирования.
Кому интересно, спрашивайте.
На пикче видны мои потуге в Illustrator'е. С графикой, пожалуй, будет труднее всего.
Благо, этот спрайт сжимается до 16 x 11 px и только в таком виде присутствует в игре.
Благо, этот спрайт сжимается до 16 x 11 px и только в таком виде присутствует в игре.
Прикольно. Можно и вправду сделать интересный паззл про маняврирование в газах и ЭМ-полях.
>Учитывая, что ЕГЭ не за горами
>ЕГЭ
>Уже где-то месяц делаю небольшую 2D игрушку на C++ и SFML.
Мазохист.
Из-за того, что центр камеры прикреплен к кораблю, вообще не очень выразительно видно орбитальное движение.
Там "не", правда, стоит, но учитывая твои слова, я пересмотрю свое отношение к данным фичам.
Вы все на 500 баллов претендуете, я не понимаю? ЕГЭ - тупейший экзамен, чистое дрочево тестиков.
Завтра сниму нормальный геймплей с разным крепежом камеры.
Я в МФТИ хочу, там не ниже 290.
Жесть, ну удачи, вперед к мечте. Я бы не осилил учебу в МФТИ.
Земля пухом
Осилил бы. Сложность (и нужность) учебы в МФТИ сильно преувеличены. Но это оффтоп, а потому - до свидания.
Я к тому, что он школота.
Ладно, насчет геймплея я, конечно, немного соврал...
На видео показано:
1) Летание (к сожалению, его плохо видно, так как спрайт выхлопа двигателя пока не завезли).
2) Врезание в планеты(?) (упругие шарики).
3) Переключение камеры на ближайшие к курсору тела (только что запилил)
4) Очередной тест точности ускорения времени.
Выглядит словно ты собрал простенькую сцену на гамаке/конструкте/фазере и сейчас пытаешься наебать гд типа что то там навелосипедил.
Если хочется пруфов и есть идеи для пруфов, могу предоставить.
Иначе, в общем-то, даже пофиг. Мне в любом случае хвастаться нечем.
Неупругие столкновения вместо упругих.
Новая проблема: сильно скачет скорость расчетов при уменьшении количества тел, приходится постоянно палец на кнопке замедления времени держать. Это нехорошо.
Новая проблема: сильно скачет скорость расчетов при уменьшении количества тел, приходится постоянно палец на кнопке замедления времени держать. Это нехорошо.
Годно, анончик. Пили дальше. А лучше заливай на github, авось местные кириллы, что-нибудь делать начнут(вряд ли)
Нахуя, рабивать степень на тонну умножений? Оптимизация? Открою секрет, извлечение корня в твоей функции расстояния занимает в тысячу раз больше времени, чем разница по времени между pow(a,12) и aaaaaaa*a...
Спасибо, но все уже подсчитано и учтено до меня:
1) Я не извлекаю корень. Все степени кратны двум, поэтому я просто возвожу квадрат расстояния в половину степени. Это для потенциала 6-12
2) pow рассчитана не только на целые степени (принимает в качестве аргумента double), так что и работает она не быстрее sqrt.
>Все степени кратны двум, поэтому я просто возвожу квадрат расстояния в половину степени
Ебать, ты жесткий.
>pow рассчитана не только на целые степени
Дык напиши свою степень, просто 12 умножений - это просто пиздец.
>просто просто
Нутыпонял
> 98% про быстрый инверсный квадратный корень от Кармака
Хуита начала 90-ых.
Сейчас так писать не следует.
>95% /gd/ не знают про разложения функций в ряд
На 1 семестре проходится.
>98% про быстрый инверсный квадратный корень от Кармака
Бля, ну это мем вообще. Стыдно не знать, если ты считаешь себя разработчиком игр.
Как считаешь взаимодействия между кучей тел?Методом Рунге-Кутты?
Ты, наверно, говоришь об экстраполяции координат и скоростей.
Это регулируется. На выбор предоставлены методы
1) Эйлера
2) Эйлера с ускорением
3) Верле-Штермера
4) Бимана
5) Бимана (модификация для лучшего поведения в ЭМ полях).
Рунге-Кутта ведет себя плохо в плане сохранения энергии при больших шагах симуляции, а также не даёт уж слишком сильных преимуществ при точном счёте, зато жрет где-то в четыре раза больше ресурсов процессора, поэтому он был когда-то реализован, но я его не стал переписывать, когда изменил код для хранения и обработки данных о телах, так что по факту его нет.
Прикрепленная пикча из старого кода, так что не начинайте новый срач, пожалуйста.
Зачем столько комментариев?
Почему комментарии не на английском?
Как считаешь взаимодействия между n-телами? Допустим есть планета на орбите звезды, и в ещё сторону движется тело, которое в теории должно выйти на орбиту, в таком плане, только объектов в разы больше
Все пока честно, без упрощений (никаких сфер влияния, замены траекторий коническими сечениями и пр.).
Формула на пикче считается для каждой пары тел (итого N(N-1)/2 вычислений). Далее, для каждого тела: зная силу и массу, считаю ускорение; зная ускорение и время одной итерации (dt), считаю dV и dr (приращения скорости и радиус-вектора). Формулы, по которым считаю dV и dr, можно видеть тут:
Чем меньше dt, тем точнее расчеты.
Может, мне в sci запилить тред конкретно по физике?
Не надо, лучше тут пиши что велосипедишь. Пробовал оптимизировать? Это побольше занимает времени ЦП, чем pow(a,12) ^_^
Я уже сравнительно близок к пределу оптимизации физики (так мне сказали, по крайней мере). Дальше, пожалуй, уже всякие хаки идут, ибо, по сути, я просто в цикле формулы прогоняю. Тут уже только грамотное распараллеливание.
Но:
1) Для игры, где мало тел, уже можно остановиться, ведь все достаточно точно считается даже при десятитысечных таймварпах и более.
2) Для чисто физических симуляций лучше послать CPU куда подальше и считать на GPU.
Забыл еще добавить всякие методы упрощения вычислений за счет уменьшения точности, но это уже не оптимизация.
Космос в 2д неинтересный, имхо. С приличной симуляцией физики можно было бы побаловаться с какими-нибудь гало-орбитами, или смотреть на прецессию орбиты в гравитационном поле не сферы, а эллипсоида вращения, например. Много интересностей двадэ вырезает, вот.
2D у меня искусственное. Так как все вычисления на векторах идут, я могу просто все векторы на трехмерные поменять и сразу же скомпилировать.
Я специально ввел ограничение на размерность пространства, так как:
1) Управление в трехмерном пространстве не настроить на мышь или тач, а я тут хочу аркадности.
2) Я не могу даже в треугольники на OpenGL, что уж говорить о 3D.
А для прецессии, вроде, все и в 2D работать будет.
> не могу в треугольники
https://learnopengl.com/
Тут всё очень понятно разжевано, вот.
По управлению -- сделай как в KSP сферу направлений, да и всё. Просто интересных орбит в 2д не будет.
>сделай как в KSP сферу направлений
Это даже для клавы неудобно, что уж говорить про тач.
>Просто интересных орбит в 2д не будет.
Пока что только гало-орбит и нет.
>https://learnopengl.com/
Спасибо за руководство. Я думаю, что в будущем никогда не поздно будет перейти на 3D, если действительно окажется скучно.
Сейчас же пока не до этого. Только что начал пилить пробную прогу на CUDA, если получится, добавлю вычисления на GPU в игру как опцию для Nvidia-бояр.
Хотя, может в игре оно и не нужно (разве что только если кому-нибудь не захочется в режиме песочницы из кучи камней запустить формирование планеты). Но мне в любом случае надо это в движке, так как я на нем не только игру пилю.
Короче, я закончил пока с CUDA. Мне мой прогресс в ней понравился, поэтому я чутка перераспределил время и в следующий раз больше внимания уделю наружностям игры, а не внутренностям (а то тред превращается в смесь /pr/ и /sci/).
Что же на видео? На видео видна примерная разница в скорости моделирования волн на тонкой мембране между CPU и GPU. Сей примерчик запилил дабы разобраться в основах CUDA и просто порадоваться перспективам прироста скорости. Ничего пока еще не оптимизировал (вообще), замерял время тупо на секундомер и характеристики компа выкладывать не буду, ибо это ничуть не бенчмарк, а просто так.
Если кому-нибудь интересно чуть больше:
Белое - мембрана сильно выгнута вверх.
Красное - просто выгнута.
Черное - не выгнута.
Синяя - выгнута вниз.
Что в основе:
https://ru.wikipedia.org/wiki/Волновое_уравнение
Быстрое вычисление дивергенции на сетке:
http://crecs.ru/ru/numlabs2/Wave_index.html
Дальше всё теми же методами:
Что же на видео? На видео видна примерная разница в скорости моделирования волн на тонкой мембране между CPU и GPU. Сей примерчик запилил дабы разобраться в основах CUDA и просто порадоваться перспективам прироста скорости. Ничего пока еще не оптимизировал (вообще), замерял время тупо на секундомер и характеристики компа выкладывать не буду, ибо это ничуть не бенчмарк, а просто так.
Если кому-нибудь интересно чуть больше:
Белое - мембрана сильно выгнута вверх.
Красное - просто выгнута.
Черное - не выгнута.
Синяя - выгнута вниз.
Что в основе:
https://ru.wikipedia.org/wiki/Волновое_уравнение
Быстрое вычисление дивергенции на сетке:
http://crecs.ru/ru/numlabs2/Wave_index.html
Дальше всё теми же методами:
А пока можете попроигрывать с моих "рисунков".
Хотя, нет, это еще не все.
Вопрос к знатокам Иллюстратора.
Поставил через CreativeCloud Illustrator 2017.3.
Вначале работает быстро, потом начинаются тормоза. При этом чем дольше программа работает, тем больше тормозит. Через полчаса тормозит даже палитра: цвет выбирается по пять секунд.
Насколько это нормально?
Хотя, нет, это еще не все.
Вопрос к знатокам Иллюстратора.
Поставил через CreativeCloud Illustrator 2017.3.
Вначале работает быстро, потом начинаются тормоза. При этом чем дольше программа работает, тем больше тормозит. Через полчаса тормозит даже палитра: цвет выбирается по пять секунд.
Насколько это нормально?
>Насколько это нормально?
Очевидно, не очень. Зачем он тебе вообще? У тебя же не очень сложные векторы, можно забить на этот старый кусок говна и рисовать их, например, в фигме.
Ты про это, что ли?
https://www.figma.com
Выглядит как какой-то WYSIWYG редактор вебстраничек. Я, наверное, ошибся, и ты что-то другое подразумевал.
Все верно. Нет, это не WYSIWYG для веб-страниц. Это редактор для запилки интерфейсов, типа Sketch. Вся база для работы с вектором там есть, плюс он бесплатный и оче удобный.
В чем проблема PS юзать?
Для работы с вектором он не ОЧ. Да и вообще не фонтан.
Для создания чего-то такого хватит с головой, разве нет? Может дело привычки, хз.
Первые попытки сделать рандомные кольца. Получилось что-то странное и страшное. Я, вроде как, все запрогал так, чтоб на равном расстоянии от тела кольца были одинаковой интенсивности, а получил какой-то шум, как будто каждый пиксель рандомом считается.
Хотя, я, кажется, даже знаю в чем проблема. Пошел фиксить.
Хотя, я, кажется, даже знаю в чем проблема. Пошел фиксить.
На пикче, кстати, можно наблюдать весьма загадочное явление - кольца внутри колец. Таких штук появляется от пяти до десяти. Я вообще не понимаю, что это такое и как так получается, что они тоже круглые.
Хотелось бы такие кольца, конечно...
1. Какие начальные скорости использовал? Подбором?
2. Все делал пропорционально пиксель=расстояние(пренебрегая размерами объекта), или просто подкорректировал константы типа гравитационной?
>1. Какие начальные скорости использовал? Подбором?
Ты про ту мини-звездную систему? Считая, что масса звезды велика в сравнении с массами планет (а так и есть, они отличаются на три-четыре порядка), считал скорости для круговых орбит (первая картинка). В конце генерации всей системы еще добавлял немного доп. скорости всем телам, чтоб ЦМ системы на месте стоял.
>2. Все делал пропорционально пиксель=расстояние(пренебрегая размерами объекта), или просто подкорректировал константы типа гравитационной?
Никаких пропорций пока нет. Все константы и размеры я выбрал как степени двойки (1, 2, 4, 8 и т.д.) просто из личных предпочтений. Если что-то надо будет согласовать с реальностью, то достаточно будет все константы сделать как в реальности в нужной системе единиц (например, СИ) и пиксели автоматом превратятся в метры, единицы массы - в килограммы и т.д.
Вторая картинка - все используемые и часть неиспользуемых констант.
Вообще, рано или поздно все придется перемасштабировать, чтоб было что-то похожее на это по размерам:
http://joshworth.com/dev/pixelspace/pixelspace_solarsystem.html
Это у меня пока все такое гигантское, чтоб всякие кольца да градиенты дебажить. Сейчас радиусы некоторых планет даже больше, чем их условная сфера влияния.
http://joshworth.com/dev/pixelspace/pixelspace_solarsystem.html
Это у меня пока все такое гигантское, чтоб всякие кольца да градиенты дебажить. Сейчас радиусы некоторых планет даже больше, чем их условная сфера влияния.
Еще поковырялся в графике.
1) Улучшил качество и скорость рендера колец. Теперь они чуть больше похожи на реальные, и не так видны пиксели при зуме (хотя все равно есть определенный предел, см. третье видео).
К сожалению (или к счастью), уже уперся в максимальный размер текстуры, и поэтому собираюсь кольца да свечение рендерить в динамическом качестве (зависящем от зума) и не полностью, а только как сегмент круга, вращая его так, чтобы он всегда был полностью в камере.
2) За пять минут сделал тень и спрайт планеты (нагло украденная у НАСА текстура Сатурна, свернутая в блин). К сожалению, видео плохо передают цвета, поэтому прикрепил еще и скриншоты.
1) Улучшил качество и скорость рендера колец. Теперь они чуть больше похожи на реальные, и не так видны пиксели при зуме (хотя все равно есть определенный предел, см. третье видео).
К сожалению (или к счастью), уже уперся в максимальный размер текстуры, и поэтому собираюсь кольца да свечение рендерить в динамическом качестве (зависящем от зума) и не полностью, а только как сегмент круга, вращая его так, чтобы он всегда был полностью в камере.
2) За пять минут сделал тень и спрайт планеты (нагло украденная у НАСА текстура Сатурна, свернутая в блин). К сожалению, видео плохо передают цвета, поэтому прикрепил еще и скриншоты.
Класс просто. Не Двач, а сказка.
Капча становится невалидна к моменту окончания загрузки видоса. Обожаю.
Лель.
Я же еще ничего особо-то не сделал.
Ты умничка, продолжай в том же духе.
Я уже универ закончил, но половины этой хуйни не знаю даже (хотя не особо и хотел когда-то, но скоро наверстаю).
Я уже универ закончил, но половины этой хуйни не знаю даже (хотя не особо и хотел когда-то, но скоро наверстаю).
Хотел-бы заняться на добровольной основе музыкой и аудио.
Чего умеешь?
Покажи.
ОП на связи.
С музыкой я уже примерно определился: хочу использовать работы 3six, многие из них бесплатны и, вроде, проблем с авторскими правами не будет, если я просто упомяну композитора. Если напишешь хорошую музыку и разрешишь её использовать, ничего не буду иметь против её добавления в игру.
https://youtu.be/vxvTddIzVFE
Проблемы пока только со звуками. Я в этой области умею только качать всякие библиотеки звуковых эффектов и не более. Тут уже твоя помощь будет неоценима, особенно если ты умеешь делать звуки работы двигателей (которые, скорее всего, будут не химические, поэтому для них звуки фиг достанешь), звуки стыковки, ударов о космическую пыль и пр.
Описал бы в тредике, что и как ты там пилишь. Например, как глоу реализован, как физику считаешь. Потом можешь в блогпост перепилить.
>pow рассчитана не только на целые степени (принимает в качестве аргумента double), так что и работает она не быстрее sqrt
Ээ... Вот только ты забыл, что сейчас 20!8, и компиляторы оптимизируют и инлайнят вызовы типа pow(x, n), где n - компайл-тайм константа. Так что на скриншоте у тебя эталонный говнокод, да.
Я отвечаю на все тематические вопросы, что мне задают. Про физику уже написал много, если интересует что-то еще, спрашивай.
Про свет:
Интенсивность пикселя обратно пропорциональна квадрату расстояния до центра (r). Там, где интенсивность больше 255, все заполняется белым (255). Где меньше 0.5 - прозрачным. Как входной параметр задается радиус белой области (R0).
Y = 255 x (R0 / r)2
И еще те условия на макс. и мин. интенсивность.
Я уже писал по этому поводу. Могу повторить вкратце:
Использую MS VS 15.
Дизасм и профилирование показало, что в том участке кода ничего не оптимизируется (из того, о чем мы говорим). Впрочем, это ведь очевидно, так как pow() принимает в качестве степени переменную типа double независимо от того, насколько качественно скомпилирована программа. А возведение в вещественную степень не быстрее извлечения квадратного корня.
>качестве степени переменную типа double независимо от того, насколько качественно скомпилирована программа
Ты не понимаешь, как работают оптимизирующие компиляторы.
Согласись, что программист может использовать в функции некоторые "хаки" или "магические константы", работающие только для определенного типа входных данных. Например, тот же самый быстрый квадратный корень. Если компилятор "насильно" заставит функцию работать с входными данными другого типа, то все сломается. В реале все сломается даже без хаков в силу того, что одни и те же операторы дают разный результат для разных типов (деление целых чисел дает целое, вещественных - вещественное).
Единственный вариант заставить заточенную под один тип функцию работать с другими типами так, как хочется - честно переписать. Насколько я понял, pow() использует взятие логарифма и экспоненцирование, заточенное под быструю работу с набором команд x86. Тут могу, конечно, ошибаться, но суть все равно остается та же: ни один компилятор это не переделает в цикл с умножением. Значит, и работать это быстрее не будет, что я и наблюдаю.
Возможно, я в корне ошибаюсь. В таком случае, буду рад узнать,
>как работают оптимизирующие компиляторы.
в моем случае.
Немного говнокодил подобное, но не так хардкорно как Оп. Подписался на тред.
https://github.com/Gitard/kosmach
>.html
)
>ни один компилятор это не переделает в цикл с умножением.
False.
Ну, точнее цикл тут не нужен, так что технически верно, но ты не это имел в виду.
Для того, чтоб оптимизировать цикл и превратить его в цепочку умножений, нужно сначала оптимизировать логарифм и экспоненту в цикл. Этого компилятор не сделает. Значит, и цепочки умножений не будет.
Иначе говоря, никаких оптимизацией из разряда целочисленного pow() не будет, пока, собственно, pow() не станет целочисленным, что может устроить только программист.
Если ты не про это, то я уже не знаю, про что.
Малаца оп. Продолжай, интересно наблюдать.
Дебил ты ебаный, pow(x,n) переводится в x...x для целочисленных литеральных n, сколько еще раз надо это написать
Хорошо, я решил еще раз изучить эту проблему.
Ссылка на аналогичный вопрос и бенчмарк:
https://www.quora.com/In-C-C++-is-there-any-performance-difference-to-compute-x-4-by-using-pow-x-4-or-xxxx-For-example-x-is-a-double-floating-number
На самом деле таких замеров куча, я просто взял один из самых недавних (конец 2017)
Прогнал код из верхнего ответа у себя с максимальными параметрами оптимизации по скорости (+ /fp:strict, хотя он, вроде, ни на что не повлиял):
x = 0.1, n = 4
std::pow(x, n)
Took 716.273 ms, error: 0
xxxx
Took 30.0069 ms, error: 1.35525e-20
tmp=xx; tmptmp
Took 31.4583 ms, error: 2.71051e-20
tmp=(long double)xx; tmp*tmp
Took 29.9972 ms, error: 2.71051e-20
Тут следует заметить две вещи:
1) "Ошибка" может сильно скакать с изменением тестируемого основания. Время же от этого не зависит.
2) У Microsoft double и long double идентичны, так что последние два теста - одно и то же.
Как видно, ничего тут не оптимизируется. А еще видно то, о чем я писал: pow(x, 4) и цепочка умножений xxxx дают разные результаты (error разный).
Пожалуй, я закрываю этот вопрос. Надоело уже вокруг одной строчки кода топтаться. Тем более все, что мне о ней пишут - какие-то общие мысли без доказательств.
P.S. Пока писал, решил проверить для n = 2. Тут pow() действительно заменяется умножением.
https://www.reddit.com/r/cpp/comments/70tl51/c11_performance_tip_when_to_use_stdpow/dn5t75w/
Мои замеры:
std::pow(x, 2)
Took 35.7014 ms, error: 0
xx
Took 35.8977 ms, error: 0
Однако, уже для pow(x, 3) скорость снова падает примерно в 20 раз.
std::pow(x, 3)
Took 719.445 ms, error: 0
xxx
Took 36.0844 ms, error: 0
https://www.reddit.com/r/cpp/comments/70tl51/c11_performance_tip_when_to_use_stdpow/dn6nctu/
>...or-xxxx-For...
Тут должны быть звездочки между x.
>Тем более все, что мне о ней пишут - какие-то общие мысли без доказательств.
Первая же ссылка в гугле с листингом сгенеренного асм: https://stackoverflow.com/questions/6321170/is-there-any-advantage-to-using-powx-2-instead-of-xx-with-x-double
Прочитай, пожалуйста, еще раз:
Можешь еще на ту самую строчку кода взглянуть, ведь там вовсе не в квадрат возводится.
GUI сам пишешь?
Да.
Правда, его ещё, как такового, нет.
Просто рисуются тела и не более.
Впечатляюще. А игровая составляющая планируется?
Конечно.
Вообще, если рассматривать чисто геймплей, то все будет сводится к полету куда надо за минимально возможное количество топлива.
Планирую сделать песочницу. Минимум одна полуслучайная звездная система с полной свободой выбора, куда лететь и что делать. В распоряжении будет что-то вроде очень навороченного космического корабля, на борту у которого есть челноки для сбора топлива и материалов.
Предполагается, что материалы будут нужны для починки корпуса корабля (если потребуется) и для создания ненаукомеких деталей и корпусов для различных исследовательских зондов. Наукоемких деталей будет ограниченное количество. Топливо, что очевидно, используется для полетов.
Материалы, скорее всего, будут собираться с астероидов. Топливо черпается с газовых гигантов (будет минимум один). Двигатели, скорее всего, будут термоядерными.
Конечная цель - исследовать всю систему, насажать зонды на планеты, навыводить спутники на орбиты, составить карты, узнать составы атмосфер, океанов и пр.
Но это все очень примерно, я до твоего вопроса сильно не задумывался над геймплеем. Скорее всего, все еще не раз поменяется. Или уточнится, а то тут только общие идеи.
Оп соснул
Але, блять, бамп.
>Учитывая, что ЕГЭ не за горами и что я пилю один
Видимо ОП готовится к ЕГЭ
Видимо ОП готовится к ЕГЭ
В целом, это можно назвать и так.
В свободное время больше занимался именно движком. В основном игрался с диполями (п1) и моделями реального вещества. Также пытался сделать быструю симуляцию вещества, состоящего из гранул (п2).
Еще чутка поковырял тени и изменил порядок отрисовки слоев, чтобы было красивее. В остальном все.
Тред почти утонул, лол.
В четыре раза меньше, чем на твоем видео. Но muzkaw использовал более продвинутый метод обнаружения столкновений - spacial hashing. Я же просто запоминал, кто с кем столкнулся на прошлом шаге. Если будет время, пойду дальше в этом направлении. Но пока в приоритете космос.
Точнее, не в 4 раза меньше, но ФПС у меня 60, а не 150, как у Muzkaw. Короче, у меня 4000 тел на 60 фпс.
Что нужно знать кроме програмирования чтобы такое делать? Математику , физику?
Писал топ ДАУН шутер на С++ и SFML, потратил дохуя времени и еле-еле получил играбельную демку. Забил хуй и сейчас делаю игры на юнити, что и тебе советую.
Если ты знаешь С++ то почему не делаешь игры на UE4?
Честно скажу, я не знаю. Я даже не совсем понимаю вопроса, ведь от физики тут только формулы для сил и второй закон Ньютона. Большую часть времени (~80%) у меня занимает именно программирование (отчасти это из-за навелосипеденной многопоточности). Физика, пожалуй, нужна больше для того, чтоб реально получать удовольствие от симуляций, чтоб были идеи, что симулировать.
Мои знания чуть выше 11 класса. Физику я учу углубленно, математику только как придаток к ней.
Пытался сначала на уе4 вкатиться, но почти не нашел нормального обучающего материала, да и он не заточен под 2д игры, которые я делаю, . В отличие от юнити у которого есть как и 3д так и 2д компоненты. + начал учить юнити, потому что где-то прочитал, что с него легче на уе4 вкотиться, да и после шараги, в которой учил кресты, я на них забил и начал учить шарп. Все звезды встали в ряд, короче
>Я даже не совсем понимаю вопроса
Я имел виду ты же брал готовые формулы из книг по физике как на пикче и внедрял в свою программу?
На Юнити нет CUDA. И нет нормального интерпретатора lua. И не охота учить шарп, особенно в 11 классе и в вузе, когда времени крайне мало. И вообще, зачем из пушки по воробьям?
И вообще, я не ориентирован на конечный продукт, о чем в первом посте и написал. У меня слишком мало времени для этого.
Брал готовые формулы, но с пониманием, откуда они и почему именно такие.
>sfml
>дохуя времени
это нужно специально постараться
Затеял, как обычно бывает, сделать первую игру неебически большой. В итоге жиденько обосрался.
Кстати, тут один анон спрашивал про то, буду ли я выкладывать все это на гитхаб. Я тут решил вернуться к этому вопросу и поэтому спрашиваю вас, есть ли в этом смысл? По идее, это только трата времени на залив апдейтов, вряд ли кто-то будет ковыряться в моем говнокоде ради с целью его улучшения. Короче, как это вообще работает на двачах? И зачем?
>ради с целью
*с целью
Хотят посмотреть на то, как ты реализовывал какие-то функции и поучится мудрости.
В шаражке у тебя времени куча будет, не беспокойся, полностью отдашься своему делу и воссоединишься с вселенной.
Петя из 9 класса хочет посмотреть как писать пограммы
>В шаражке у тебя времени куча будет
Ох ты лол блять. Ну в шаражке, наверное, да. Но в более-менее тех. вузах ДС-1/2 свободного времени до 5 семестра не больше, чем в школе.
> чем в школе.
Глупо выразился. Чем в 11 классе, когда помимо школы 100500 репетиторов и постоянная самоподготовка.
Времени не прибавилось, поэтому пока исправляю ошибки и немного ковыряюсь в графике.
Добавил всяких полезных астрономических функций. Теперь, зная расстояние между телами, их скорости и массы, могу находить полуоси орбит, периоды, сферы влияния, сферы действия, сферы Хилла. Это нужно для генерации реалистичных и, главное, стабильных звездных и планетарных систем. Особенно важна сфера Хилла. Вне ее у планеты не может существовать стабильных спутников.
Первая картинка - просто снимок экрана одной из простеньких звездных систем, вторая пикча - колебания орбитальных периодов трех массивных (10-3 массы звезды, примерно как Юпитер к Солнцу) планет с течением времени. Как видно, колебания гармонические и в среднем орбиты с целым отношением периодов обращения стабильны.
Нашел классный эмбиент - ЭМ-фон планет, переведенный в аудио-сигнал. Звучит круто и атмосферно, ИМХО. Я бы даже сказал, криповато.
https://youtu.be/oWTC7P1Dprw
https://youtu.be/X_JAvVjKeWI
Я тоже думаю, что если в хороший ВУЗ поступлю, то свободного времени будет мало.
Добавил всяких полезных астрономических функций. Теперь, зная расстояние между телами, их скорости и массы, могу находить полуоси орбит, периоды, сферы влияния, сферы действия, сферы Хилла. Это нужно для генерации реалистичных и, главное, стабильных звездных и планетарных систем. Особенно важна сфера Хилла. Вне ее у планеты не может существовать стабильных спутников.
Первая картинка - просто снимок экрана одной из простеньких звездных систем, вторая пикча - колебания орбитальных периодов трех массивных (10-3 массы звезды, примерно как Юпитер к Солнцу) планет с течением времени. Как видно, колебания гармонические и в среднем орбиты с целым отношением периодов обращения стабильны.
Нашел классный эмбиент - ЭМ-фон планет, переведенный в аудио-сигнал. Звучит круто и атмосферно, ИМХО. Я бы даже сказал, криповато.
https://youtu.be/oWTC7P1Dprw
https://youtu.be/X_JAvVjKeWI
Я тоже думаю, что если в хороший ВУЗ поступлю, то свободного времени будет мало.
Ебать, Артёмка. Ты уже сам движок написал и тред на гдаче сделал? Я в ахуе.
Это какие-то локальные мемы?
Нет, я просто отчим его.
Очевидно, ОП - не Артемка.
Это кому оно очевидно?
Я ОП и я официально и при свидетелях заявляю, что я не Артемка.
Пруфы или гтфо.
Пруфы того, что Артемка?
Ну ты определись уже.
Bump
бумп
оп-соснул
Что ты тут уже во второй раз забыл?
То, что оп-соснул.
Не Тони.
Bump
Ого, очередная хуета, ничего себе, молодец, оп, продолжай в том же духе, еще советую попробовать выпилиться.
Почему близкие диполи отталкиваются?
Экспоненциальное отталкивание из-за перекрытия электронных оболочек. На самом деле, в этом видосе особого физического смысла нет, просто тестил стабильность расчетов.
Я надеялся, что тред утонул...
Очень круто, прям кристаллизация.
Оп соснул!
У ОПа сессия.
Ебать, Оп уже не школьник! Пёрнул тебе в лицо
>switch в методе для интеграции
Ебать ты додик, про branch misprediction не слышал? Вообще не должно быть ветвлений в таком коде, если хочешь получить нормальную производительностью
>Вначале работает быстро, потом начинаются тормоза. При этом чем дольше программа работает, тем больше тормозит.
Скорее всего, ты поставил пиратку с майнером.
>что в том участке кода ничего не оптимизируется
А ты какую сборку дизасмил-то, не дебажную случаем?
Это вариант функции для дебага, с возможностью менять методы интегрирования на ходу. Для конкретных задач пишется отдельная функция, где есть только то, что будет использоваться, без ветвлений и вызова других функций.
Проблема уже решена но, тем не менее: нет, качал официально через CreativeCloud. Баг был уже в 14-дневном демо-режиме. Так и снес, не крякнув.
Релиз с максимальными настройками оптимизации времени выполнения.
Оп соснул!
Уже где-то месяц делаю небольшую 2D игрушку на C++ и SFML.
Большую часть времени потратил на самописную физику и отладку многопоточности, сегодня, наконец, перешел к графике, а потому решил создать тред-дневник.
Геймплей пока заключается в управлении космическим аппаратом в поле тяжести различных тел. Движение всех тел считается по закону всемирного тяготения, траектории не фиксированные, в отличии от, например, KSP.
Что есть:
1) Базовая физика.
2) Возможность летать на космокорыте.
3) Простенькие визуальные и аудио-эффекты.
План максимум:
1) Сделать хоть что-то играбельное (хотя бы просто физическую головоломку).
2) Написать сюжет, внедрить его в игру в виде .lua-скриптов (соответственно выучить Lua).
3) Перенести физику на GPU, если останусь на PC.
4) Сделать удобный интерфейс и все по максимуму оптимизировать (включает в себя переход на чистый OpenGL), если захочу продолжить на мобилках.
Учитывая, что ЕГЭ не за горами и что я пилю один,
Реальный план:
1) Перенести все основное управление аппаратом с WASD на мышку или тач.
2) Научиться базе C++ за время разработки.
3) Научиться базе CUDA за время разработки.
4) Запилить что-то более серьезное в плане физики.