Делаю игрушку, нужно сделать пульки, (я их уже сделал, но коллайдеры у них в виде шариков), сделал условие пересечения пульки и игрока (чтобы проверить, попала ли пулька в игрока).
Сейчас думаю как сделать пульки не в виде шариков, а в виде листочков / нормальных снарядов / полосок (см на скриншот).
Проблема состоит в том, что не могу придумать, как проверить, пересекается ли игрок (круг) и эта йоба-фигура.
Бампаю 10 раз и иду шкодить свою парашу
Да?
А нагуглить готовый алгоритм пересечения полигонов не вариант?
Коллизия круга и отрезка -- простая хуйня. Суть в том, что ищешь ближайшую точку на прямой до центра круга. Потом смотришь, попадает ли в отрезок. Потом проверяешь расстояние до центра круга.
Если я задам пульку в виде 6ти отрезков, и таких пулек будет около 1к, насколько твой способ окажется эффективным?
каким методом посоветуешь искать ближайшую точку?
всю школьную алгебру забыл к хуям
В душе не ебу как это называется поэтому не вариант)
Либо да, замутить полноценные полигоны по форме твоих этих "пуль" и спиздить где угодно алгоритм коллизий полигонов.
пульки могут быть как на скриншоте, хочу иметь возможность задать ее хоть квадратной (хоть в виде ромба)
Тогда другой вопрос с игрком, сейчас он у меня его коллайдер в виде круга сделан (как и все впрочем), есть ли сложности в проверке пересечения окружности и полигонов?
Попробую так сделать
Для каждой пули вычисляешь ближайшую точку от игрока до прямой линии в основе отрезка этой пули. Проверяешь, попадает ли точка в сам отрезок.
Вычисляешь расстояние между этой точкой и позицией игрока. Условиями на это расстояние можно и учесть размер круга игрока, и сэмулировать ширину пули.
Я думал упростить, но в голову приходило сделать несколько отрезков с толщиной / несколько кружков на пульку
Типо так: (оранжевое - отрезок с толщиной, то, что ты предложил)
А в алгоритме проверять пересечение с каждым коллайдером "пульки"
>>237881286
А для длинных пулек сделать 2 отрезка
>>237881286
с учетом этого*
Пишу сам, на жс, могу гитхаб скинуть
о, это санто стефано маленькая?
Типо так:
У нас пулька задана в виде ромба, есть длина и ширина
Вычисляем так:
Находим близжайшую точку до окружности, а затем проверяем:
1 - Расстояние между отрезком и центром круга
2 - Ширину отрезка в точке (легко найдем, тупо умножив ширину на коефф. который вычисляем при задании длины и ширины (ширина / длина или типо того)) и радиуса круга
Если 1 < 2, то пересекаются
Я все верно понял?
Хз, можно ударть молотком проверить))
если зелёное расстояние (общее минус сумма синих расстояний) меньше нуля, есть коллизия
В /gd/, животное.
Зун, ты? Когда 18я часть?
Собственно сам гихтаб:
https://github.com/GeorgiyO/JS_DanMaku_Engine
Это бред тут можно все)
Не зун
>>237881555
>>237881602
Сейчас рассматриваю эти два варианта, какой лучше?
Или совместить и сделать оба?
Если пишешь на жс, и у тебя тыщи пуль, надо чтоб быстро считалось. Так что пули аппроксимируй, либо кругами делай, либо отрезками с толщиной, то есть чтоб в три строки кода и десяток матопераций можно было коллизию с игроком считать, ведь тебе надо всю эту тыщу раз 60 в секунду коллизить с игроком.
Может тебе даже стоит партиционировать весь массив пуль в пространстве, самое тупое сетку секторов сделать, чтоб не проверять коллижен с теми, что гарантированно далеко.
Или какую нибудь очередь заебошить чтобы пули обсчитывались по приоритету те что ближе к игроку.
В этом то и проблема.
А еще я эту хуйню решил в браузере сделать, так что у меня в кармане только 1 процессорный поток доступен.
Но варианты с отрезками с толщиной и ромбами выглядят довольно приятно, и не должны занимать убер дохуя времени. Хотя не знаю алгоритм поиска близжайшей точки до точки у отрезка.
>>237882139
Думаю добавить в проверку какое-нибудь условие, чтобы скипать пульки, которые далеко находятся. Пока в голову приходит что то типа (длина + ширина > расстояния до игрока = идти нахуй)
Ты в какой сыроварне хоть все это мастеришь?
Пока что у меня все это в массиве валяется и проверяется forEach'ем, насчет приоритетной очереди - думаю выйдет дороже перестраивать ее каждый раз, поскольку игрок двигается и пульки тоже, и расстояния каждый раз меняются
А хрен его знает. Ибо большинство пуль летят мимо игрока и далеко(больше 3Хразмера пули) от него. Проведи эксперимент и прикинь писю к носу нужна ли приоритезация и с каких количеств пуль и скроростей игроков с пулями.
Что ты имеешь ввиду?
>>237882527
Думаю куда проще (и выгодней) окажется добавить условие перед проверкой, которое по времени будет занимать меньше времени самой проверки (писал тут) >>237882265
Все может и можно, но куда логичнее и проще было бы узнать нужную информацию в специальном разделе, посвященном этой тематике, а не в борделе по интересам.
Если считать расстояние до игрока приблизительное то почему и не сделать возможность приоритета. Пули которые далеко - идут нахуй и внизу очереди. Пули которые близко считаются подробно и находятся вверху очереди.
там народа меньше, к тому же мне в падлу искать нужный раздел и пытаться не обосраться с правилами, так что извиняй
>>237882702
А смысл тогда очереди, если можно просто скипать это говно?
А ты пробовал сначала то же самое, только с простейшими фигурами провернуть?
Да, их считать подробно не надо. Но проверять грубым методом тех кто ближе сначала.
Взял бы готовый данмакуфу и на нем соорудил бы
Неа, но тут подкинули идейки как упростить, см выше, так что буду пробовать сделать проще
Проблема в том, что нужно определять тех кто ближе, а смысл вообще в том, чтобы проверять тех кто ближе?
Можно точно так же их отсортировать кто ближе, а потом проверять первого, но это такое себе
Нахуя вы так ебетесь, переизобретая велосипед? Используйте готовые движки и API. Пиздец, каждые два дня говнокод-тред, каждый раз их посылают курить готовое, а они все копротивляются.
>>237883054
Это не интересно, вопрос закрыт?
Тогда и заработок в геймдеве тебе не интересен. Проебешь время на всю эту хуйню, а в итоге выйдет кал, затратный по ресурсам.
Я делаю это не для работы или денег, мне просто интересно и все.
Считай что это хобби типо рисования или гитары
Все пульки придется проверять сразу, тут никак не изьебнешься.
Был бы статичные объекты - можно было бы bvh дерево и аабб боксами ускорить, а так хуй.
Но вообще когда я на xna параше в 10ых делал данмаку, оно легко в 60фпс ~5кк пуль успевало оценивать на бюджетном коре. Так что влепи тупой перебор да попробуй, уверен десятка три тысяч легко вытянет
Они у меня сразу же выкидываются из памяти.
Насчет "игрок не успеет добежать" тут хз, поскольку пули по любой траектории могут лететь (В том числе так, как на скриншоте, только сложнее). И как в таком случае просчитывать возможность долететь до пули?
Так оттбросится примерно половина необходимых вычислений.
1. проверяешь d
из v0 и v1 получаешь коэффициенты прямой a b c, нормализуешь по (a2 + b2) ии в принципе можно на все время существования прямой длинной пули эти коэффициент и использовать
можно даже вообще наоборот, из а б с порождать отрезок, чтобы а б с были заранее известны и предопределены, один хуй ты вектор в том или ином виде задаешь когда пулю пускаешь
2. если d меньше какого-то порога - проверяешь dot (v0 - v1, v0 - p) и dot (v1 - v0, v1 - p) - если оба скалярных произведения дают косинус больше нуля - фиксируешь коллизию, если больше - нет коллизии
пули меняют направление движения, в этом случает коэф. пересчитывать?
рисунок красивый. но нихуя не понятно
>пули меняют направление движения, в этом случает коэф. пересчитывать?
Ты же их задаешь когда пускаешь пулю или меняешь направление, той же матрицей.
Для хитрожопо закрученных отрезковых пуль придется каждый фрейм считать.
я на матрицах в вузе спал, можно по проще пожалуйста?
>не зун
Кидаешь скриншоты из симулятора цирка и при этом не знаешль кто такой Зун лул.
Геометрию в школе не проходил что ли? Если пересекаются линии. значит есть пробитие; если нет - то и нет пробития.
Хорошо, что такое dot, w0, w1?
>>237885978
>оба скалярных произведения
Заебош им всем круглые коллайдеры. Может, у пули-листочка самая смертоносная часть - круглое ядро из обогощённой НЕНАВИСТИ в середине, а острые носик и хвостик - это чисто визуальные эффекты, которые образуются вокруг ЯДРА НЕНАВИСТИ при движении.
вопрос в том, как проверить пересечение максимально эффективным способом.
Кто такой зун знаю, я не зун
Такое себе
Достаточное в принципе, у зуна от еосд до емнип фудзироку все длинные или формовые пули были тупо набором точек.
>не могу придумать, как проверить, пересекается ли игрок (круг) и эта йоба-фигура.
Так а нахуя? Пускай коллайдеры остаются кругами, в определении столкновений с проджектайлами точность нахуй не нужна.
Набор точек, описывающих фигуру или набор кружочков?
Ага, и игрок будет выживать когда должен сдохнуть, или сдыхать, когда должен выжить
Точка, кружочек получается только на этапе проверки на заданный радиус от точки.
вот например, 4 точки легко описывают форму челена
Я думал об этом, см здесь (+ еще другие идейки подкинули, которые тоже простые и будут легче описывать, например, свастоны или длинные пульки)
>>237881483
>>237881555
>>237881602
Не будет, у тебя есть игрок, и есть пуля, которая летит к нему ебалом вперёд. Достаточно покрыть коллайдером ебало пули по всей её ширине. Сценарий, при котором у тебя игрок догоняет жопу уже пролетевшей пули и насаживается на неё, маловероятен и костылить какую-то залупу из-за него нецелесообразно.
Ты собираешься длинную хрень с начала поста описывать сотней шариков?))
Когда можно описать одним ромбом
А, так эта длиная хуйня тоже проджектайлы? Ну так хуярь эллипсы вместо кругов, какие проблемы? Тупо будет поправка радиуса в вычислениях, и всё.
Алсо, нахер ты вообще полез изобретать велосипед, если давно существуют сотни движков с готовыми коллизиями?
Насчет эллипсов не думал....в принципе могут подойти, но считать коллизию будет еще заебанней чем с ромбом, так что думаю ромбой и обойдусь
про движок тут -> >>237883241
>Когда можно описать одним ромбом
ромб это 4 точки, но процесс вычисления коллизии 4 точек в заданном участке потребует того же времени, сколько несколько десятков шариков.
коллизиия между точкой игрока p0 и точкой пули d0:
1. вычислить расстояние d = p0 - d0
2. сравнить d с хитбоксами пули и игрока
3. запустить солвер
Коллизия между отрезком формируемой точкой b0 b1 и точкой игрока p0
1. вычислить а из b0.x и b1.x
2. вычислить b из b0.y и b1.y
3. вычислить с из a b и b0 и b1
4. вычислить квадрат расстояния d2 между прямой ax+by+c = 0 и точкой p0
5. проверить d2 на порог по хитбоксу и параметры бокса отрезка b0 b1
6. если d2 меньше порогов хитбокса игрока и бокса отрезка, проверка на вхождение в отрезок:
6.1 вычислить вектор w0 = b0 - p0
6.2 вычислить вектор w1 = b1 - p0
6.3 вычислить вектор bb = b0 - b1
6.4 вычислить вектор bb' = b1 - b0
6.5 вычислить скалярное произведение dot(bb, w0)
6.6 вычислить скалярное произведение dot(bb', w1)
6.7 проверить dot первый на > 0
6.8 проверить dot второй на > 0
6.9 если оба > 0 - регистрируем коллизию запускаем солвер
причем сами операции dot и в чеке расстояния до прямой еще всякие квадраты имеют деления которые тоже не очень уж и быстрые, т.е. можно смело раза в 2 увеличивать число операций. соотношение времени проверки точка-точка к точка-грань примерно 1/10 а то и больше.
Т.е. за то же самое время можно успеть проверить несколько десятков точек, причем даже десятком точек вполне можно описать весьма сложную форму, без ввода полигональных пулей
Нахуя такие сложности, не проще ли так:
1) Вычислить расстояние от прямой до игрока
2) Проверить, входит ли точка А в отрезок (можно по одной из координат х или у проверить)
3) проверить расстояние до точки и игрока и сравнить это дело с шириной отрезка (или ромба, там не особо больше сложности прибавляется) плюс радиусом игрока
Хотя можно и 100 шариков на длинную хуйню захерачить, никто не запрещает же. Может и правда будет эффективнее, кто знает
Вот я это так и раскидал тебе
>1. вычислить расстояние до прямой
это на само деле:
>1. вычислить а из b0.x и b1.x
>2. вычислить b из b0.y и b1.y
>3. вычислить с из a b и b0 и b1
>4. вычислить квадрат расстояния d2 между прямой ax+by+c = 0 и точкой p0
>5. проверить d2 на порог по хитбоксу и параметры бокса отрезка b0 b1
>2) Проверить, входит ли точка А в отрезок (можно по одной из координат х или у проверить)
вычисление координаты точки А - это еще на 5-6 операций (векторных, замечу)
>3) проверить расстояние до точки и игрока и сравнить это дело с шириной отрезка (или ромба, там не особо больше сложности прибавляется) плюс радиусом игрока
ну и еще 4-5 векторных операций и сравнений
со скалярным произведением побыстрее немного, т.к. там не надо находит пересечение прямой и перпендикуляра до прямой с игрока (т.е. точку А), а сразу по скалярному произведению определяем, входит ли точка игрока в грубо говоря область отрезка.
С эллипсами кстати норм тема.
Уравнение эллипса известно, там чета типа ellipse(x, y, e0, e1) = 1 e0 e1 - фокусы элипса
Точка игрока p известна.
Тупо постдавляешь p в уравнение эллипса px и py и смотришь результат
если ellipse(p.x, p.y, e0, e1) > 1 - пересечения нет
если ellipse(p.x, p.y, e0, e1) <= 1 - пересечение есть
Только эллпис конечно надо будет повертеть как-то
Повертеть == сместить по координатам на время вычислений?
Это подойдет для вычисления "радиуса" эллипса?
Если да, то получится следующее:
Вычисляем радиус, и тупо сравниваем расстояние и радиусы>>237889248
Угол А задается внутри самой пули, тупо достаем из поля
Угол B вычисляется довольно легко (пик 2)
Угол t = A + B
This. С уравнением в формате ax+by+c=0 провести эти вычисления для нескольких линий параллельно - вообще не проблема.
Что ты имеешь ввиду под параллельно?
Тут челик расписал, почему этот метод хуета, и его лучше заменить на пару десятков кругов (или я подумал можно даже эллипс прикруить) -> >>237888323 >>237889008
>Проблема состоит в том, что не могу придумать, как проверить, пересекается ли игрок (круг) и эта йоба-фигура.
Но нахуя? Так никто не делает, либо делаешь коллайдер сложной геометрически пульки из нескольких коллайдеровно это оверинжиниринг, либо просто делаешь коллайдер примерно по размеру пули, потом подгоняешь на этапе тестирования
>Что ты имеешь ввиду под параллельно?
Я имел в виду - длинный прожектайл описать 4, 6, 8 линиями.
Для каждой линии пересечение с кругом считается элементарно. Современные компиляторы могут оптимизировать это так, что обсчёт для 8 линий можно сразу выполнить параллельно.
Подумаю
(напишу и затесщу)
Переводишь уравнение линии в форму ax + by + c = 0. Нормализуешь коэффициенты.
Уравнение перпендикуляра к линии - -ax + by + c = 0, подставляя x и y игрока, находишь точку пересечения перпендикуляра с отрезком, измеряешь длину, смотришь, находится ли точка пересечения в пределах отрезка, если длина меньше радиуса игрока и точка в пределах - то есть коллизия.
Посмтрю, щас проверю несколько вариантов, и затесщу какой лучше, если тред не умрет - результаты выложу сюда, если умрет - создам новый с результатами с сылкой на этот тред
Вот этот дело говорит. Иногда бывает довольно интересно/полезно разобрать игру до винтика и понять принцип ее строения.
>>237889824
А как он сам эллипс такой задаст?
С наклоном?
Да, с наклоном, проблемы?
> Современные компиляторы могут оптимизировать это так, что обсчёт для 8 линий можно сразу выполнить параллельно.
Ты походу пропустил
>>237882265
>А еще я эту хуйню решил в браузере сделать, так что у меня в кармане только 1 процессорный поток доступен.
Он хочет на жс наговнокодить.
Нет, с наклоном как уточнение имелось в виду, а не а чем-то.
Как он элипс с наклоном задаст?
Эллипс без наклона + угол поворота в самой пульке.
В качестве рисовки на экран может использоваться текстурка, опять же повернутая на тот же угол поворота.
>Эллипс без наклона + угол поворота в самой пульке.
Без наклона он будет вот так с таким уровнением.
Хотя допер, всё.
Норм, а то я начал думать что сам где то обосрался.
И это странно, что ты ко мне обращаешься как к "нему".
Я ОП, тут омжно как то помечаться, что я ОП? Чтобы никто не думал, что я вообще левый чел
А, блин, я проебался.
Уравнение перпендикуляра - -bx + ay + c = 0
Не, я долго в >>237889946 пялился и пытался понять, что за А и B и откуда выбран отсчет для них посередке, недопер что зеленая горизонтальная линия - она абсцисса
Это просто я кривовато нарисовал))
Художник из меня впрочем как и гейдевелопер
Я бы разве что убрал корень из >>237889824 можно сравнивать чисто квадрат расстояния, минус затратная операция
Учту
>>237893832
Квадраты расстояний?
С^2 <= A^2 + B^2
Типо так?
Если подводных нет, то это довольно хорошее решение, т.к. избавляемся от корня при подсчете в 'B' и в 'C', т.к. они изначально как сумма квадратов по х и у высчитываются, а радиус (то есть 'A') вовзодим в квадрат
И тут и тут >>237889824 rэ получается можно квадратом оставить
И тупо сравнивать квадраты
Должно сработать, щас попробую
хотя оно по большей части сосет во время рисовки, а не выполнения логики как таковой
ты хоть видеокартой рисуешь и вебглом или какую-то хуйню творишь?
canvas drawCircle
Я вот щас сижу и думаю, может мне это все к хуям на c++ переписать?
(подводный камень в виде того что я с++ не знаю)
лол
но вообще хуйня какая-то учи вебгл, иначе так и будет тормозить
Я и собираюсь через вебгл все это делать, просто щас пока логику пишу, ебашу через канвас нарисуй хуй.
Даже делал нормаль на сиськи с фонариком (могу подыскать кста, если хочешь).
Когда перепишу на вебгл, все должно пофиксится? Разве нарисуйХуй не использует его под капотом?
Логичнее систему координат перенести в центр эллипса тогда уж - круг тогда не придётся поворачивать.
А так уравнение пересечения круга и эллипса под произвольным углом довольно сложное получается.
да он вообще ничего не поворачивает.
просто находит параметр, из него считает радиус эллипса, а дистанцию от центра эллипса до игрока известно, и тупо сравнивает сумму rэ(t)+rp с дистанцией
параметр эллипсе легко вычисляется - наклон эллипса прописан просто в поле эллипса, ничего не надо вертеть, а второй угол - от абсциссы мира и центра эллипса считается.
В любом случае, там используются синусы/косинусы.
В случае с аппроксиммацией линиями - там только умножение и деление, должно быть быстрее.
Ну 2 синуса-косинуса при вычислении rэ через параметр (причем давно уже есть быстрые синусы и косинусы, ему хватит и ограниченной точности зато быстра) и один атангенс, ну или акосинус от дота, ну или дот
один хрен у него в графику упор, пусть сначала учиться красиво и быстро рисовать миллион пулей, со спецэффектами, постэффектами, триде на фоне, как у зуна, запилит менеджер состояний игры, а потом уже пулькам логику прикручивать
Найди его просто потом на архиваче.
Если тригонометрия дорогая, посчитай её в LUTы. Или ты для некроконсолей пилишь?
Это игра или симуляция боевых ранений?
Что такое луты?
Это игра
Заданная таблица синусов косинусов тангенсов атангесов акосинусов асинусов чтобы не ебаться каждый раз с тригонометрией а тупо доставать циферки из памяти.
LookUp Table. Считаешь, к примеру, 65535 значений sin, записываешь их в массив - у тебя есть sin и cos за пару операций.
>>237902048
Тогда ты переусложняешь.
Задавай хитбоксы кривыми.
Кривые Безье довольно дорогие.
Так надо сначала вычислить какие ближе тогда. А чтобы по сетке делать надо вычислить какая пуля в каком секторе.
Тогда как все делают - прямоугольники и круги лепишь вокруг пули чтобы примерно подходило по форме и все. Алгоритмы коллизии с кругами и прямоугольниками дешевые.
Подумаю об этом
Кстати да, с современными компами можно коллизию хоть в 4к тупо попиксельно проверять, щас не 98 год уже. С другой стороны это решение очень грязное.
>>237903485
Вот именно, насколько это затратно будет тупо каждый кадр обновлять массив коллизий для каждого пикселя на поле?
Уравнения по исследованию функций на общие точки, не?
короче по простому попробуй загуглить пересечение графиков функции
>>237903613
Почему грязное? Это просто бессмысленно для таких одинаковых объектов как пули.
С современными компами и кривые Безье будут ок, их раза в три дороже чем прямые считать.
У тебя это распараллеливается как-нибудь?
Слишком сложно, тут уже подсказали и я сам решил рисовать коллайдеры через простые фигуры, с помощью которых легко считать пересечения, (эллипсы / отрезки с "шириной")
Нет, не распаралелливается, один процессорный поток, ебашу на JS в браузере
И как ты это описать собрался?
синусы и косинусы можно закинуть и в LookUp Table, состоящую например из 20 значений для разных углов
>Делаю игрушку,
я тоже.
Чето муть какая то, мог бы просто сделать проверку на совпадения координат
>е могу придумать, как проверить, пересекается ли игрок (круг) и эта йоба-фигура.
Мы то откуда знаем?
Записывать в буффер "опасные" точки, а потом проверять находится ли в них игрок?
Думал но это скорее всего будет слишком затратно каждый кадр записывать данные в буффер
С OpenGL/GLSL такое делают.
Если всё-таки функционально заданные пули выбираешь, я бы все проверял сначала на пересечение окружности игрока с координатами пуль, если пересечение есть, уже просчитывал бы пересечение геометрии этой пули с игроком.
Эти все просчеты уже есть во все API
там по масками или спрайтам коллизию просчитывает. Ты в чем игру делаешь?
Байтаеб чтоли? У тебя и так координаты положения тел будут
Т.е. ты предлагаешь через GLSL заполнять буффер, а затем проверять все это дело в этом буффере?
Можешь тогда подсказать, как таким методом работать. На GLSL Только 3д сиськи делал и все
>>237904492
Координаты есть. Есть форма. Нужно проверить пересечение. Я конечно могу просто взять и проверять каждый пиксель, но это будет слишком неоптимизированно
> Я конечно могу просто взять и проверять каждый пиксель
Ебнутый что ли, у тебя есть переменная которая отвечает за положение по xy если это 2д, которая меняется
вот ты и сравниваешь эти переменные, чтобы объект не рассматривался как точка прикручиваешь уравнение нужной фигуры
Какая то хуйня
>через GLSL заполнять буффер, а затем проверять все это дело в этом буффере?
Я так понял, тебе зачем-то нужны именно функционально описанные хитбоксы, поэтому нет, я предлагаю считать сначала точки и если точки попадают в окружность, просчитывать для них геометрию.
Я собираюсь сделать хитбоксы в виде кружков / эллипсов.
И думаю как наиболее эффективно их проверять
Тогда какие ещё вопросы?
Дрочись дальше через костыли. вместо того чтобы понимать код
Я не представляю как можно эффективно посчитать пересечение 2000 функций с игроком-кружком
наследование
Про распараллеливание средствами OpenGL/GLSL тебе уже сказали.
Уравнение окружности ты знаешь. Эллипс отличается от окружности в данном контексте тем, что у него, грубо говоря, два радиуса (фокальные точки не нужны, потому что мы не карандашом и нитками его собрались чертить). Проверяешь сначала, входит ли координата пули в окружность игрока, для этого берёшь радиус окружности игрока + максимальный радиус эллипса пули. На этом этапе ты проверил столкновение двух окружностей. Если столкновение окружностей есть, надо проверить, есть ли столкновение твоей окружности теперь уже с эллипсом. Для этого тебе понадобится понять, как зависит изменение радиуса эллипса с углом его поворота. Эта зависимость - sin.
Довольно не плохо
Осталось только понять, как распаралелить средствами OpenGL / GLSL
И что именно паралеллить?
Вычисления попадания в коллайдер?
GLSL довольно простой, если нет религинозной непереносимости.
>>237914180
На GLSL тебе придётся написать, собственно, проверку коллизий, поскольку объектов дохрена. Вообще, можно всю игру на нём написать, JS использовать только как фронтенд и для чтения ввода.
Я на глсл писать нормали для сисек, так что с ним на уровне дошкольника знаком (использова Three.js, если не ошибаюсь)
Вот только не пойму как именно сделать првоерку коллизий. Разве видеокарта не умеет только рисовать на экране?
А вообще примерно представляю как это будет работать:
Я закидываю в видеокарту массивы точек и радиусов, а получаю в ответ массив булинов? Если все булины = false, то столкновений не произошло, а если есть true, значит под индексами с true произошло столкновение.
Но как получить в ответ массив булинов?
>Разве видеокарта не умеет только рисовать на экране?
Серьёзно? Про майнинг биткоинов на видеокартах думаешь шутка? У OpenGL пиздец какой хитровыебанный пайплайн, на одних только шейдерах можно практически всё что угодно считать, но обычно для векторизации (распараллеливания) используют.
Сложно сказать, какую часть лучше пилить на шейдерах и какую на JS по твоему описанию задачи. Можно координаты всех объектов в VBO хранить, средствами OpenGL же их обрабатывать и даже рендерить (видеокартой рендерить, охуеть, да? до чего только техника не дойдёт). Описанный тобой способ имеет смысл, если ты ещё какие-то хиртые нераспараллеливаемые операции собираешься производить, но тогда не зная, что это, я не могу сказать, как лучше.
Зачем тебе целый массив Булевых значений? В любом случае, если ты из JS будешь шмалять GLSL'ем, уверен, есть библиотеки с документацией.
Понял, все равно у меня пиздец (на скрине выше фпс падает после 2к+ пуль видно, что на логику игры затрачивается порядка 100 мс, то есть 10% от всего времени, так что думаю сейчас занятся рисовкой через glsl а не canvas.нарисуйХуй().
Можешь подсказать годные туториалы / документацию по glsl, чтобы не обосраться?
Не могу. Я пытался в него вкатываться, но плевался и дропал каждый раз.
Понял, спасибо за совети енивей, а я попробую вкатится.
А так знаешь, настроение такое, что хуй знает чего хочу от жизни.
Вроже бы как геймдев завлекает, нравится писать код и задачки разные решать (поэтому собственно и пишу игрушку), но с другой стороны больше веб знаю, чем тот же геймдев. И хер его знает, то ли идти полностью в геймдев, то ли ебашить веб после того как игрушку сделаю (думаю для резюме будет неплохим бонусом вкупе с различными сайтиками).
А еще тетя шлюха ебаная меня сегодня с нихуя в чс кинула. рот ее ебал. (не еот (мб и еот но ток ненамного)).
Ладно, пойду спать, спасибо за совету, завтра буду в архиве перечитывать что тут писали. Удачи тебе!