Остался у меня незакрытый гештальт с прошлой домашки. Неприятно было осознавать, что я не знаю как правильно сделать ускорение.
Вот вроде просто — к вектору скорости добавлять вектор ускорения. Но его же надо увеличивать, а значит где–то накапливать. И обнулять после детача от веревки? Все так и получилось.
Но для перемещения я использовал Lerp и с ним у меня ничего не работало.
Для реализации ускорения, пришлос переписать весь код PhysZipline. Теперь интерполяция осуществляется с помощью FMath::VInterpConstantTo(Start, End, DeltaTime, Speed)
Сложность была в том, чтобы узнать правильную конечную точку. Недостаточно взять точку, расположенную на вершине второго столба!
Start находится в GetActorLocation(), это середина тела персонажа. Но если от вершины второго столба опуститься на половину высоты капсулы (да еще учесть оффсет, задаваемый вручную, чтобы рука точно попадала на веревку), все равно не удается правильно спозиционировать персонажа — к концу движения он непременно оказывается либо ниже веревки, либо выше.
Помог код изначального аттача к веревке:
1 получаем вектор от начала к концу веревки, вычитанием точек. Нормализуем
2 получаем проекцию вектора от первого столба к центру игрока, на веревку — DotProduct
3 проекция это float, умножаем его на вектор из п.1, получаем вектор от начала веревки до текущей точки на ней, где расположен персонаж
4 положение игрока = первый столб + вектор из п.3 + вручную задаваемый оффсет
В PhysZipline рассчитываем точку End:
— берем второй столб, к нему прибавляем вектор из п. 3
— очевидно получается вектор, идущий из второго столба дальше по направлению веревки
Также рассчитываем момент, когда перед вторым столбом, персонаж отпускает веревку
Для этого сравниваем проекцию текущего положения игрока на веревку (сколько "проехали") с длиной веревки, из которой вычтен вручную задаваемый оффсет с конца (чтобы отцепляться от веревки не у самого столба, а чуть раньше)
if (GetActorToZiplineProjection(NewLoc) > (CurrentZipline–>GetSize() — CurrentZipline–>GetZiplineDetachOffset()))
{
DetachFromZipline();
}
Уф, сам до конца не понимаю как все работает. И есть ощущение, что код можно значительно сократить. Но пока этого достаточно, нужно двигаться вперед.
Мозгу требуется время, чтобы в нем укоренились все абстрактные конструкции, которыми мы оперируем, чтобы он мог использовать их быстро и эффективно.
Вот вроде просто — к вектору скорости добавлять вектор ускорения. Но его же надо увеличивать, а значит где–то накапливать. И обнулять после детача от веревки? Все так и получилось.
Но для перемещения я использовал Lerp и с ним у меня ничего не работало.
Для реализации ускорения, пришлос переписать весь код PhysZipline. Теперь интерполяция осуществляется с помощью FMath::VInterpConstantTo(Start, End, DeltaTime, Speed)
Сложность была в том, чтобы узнать правильную конечную точку. Недостаточно взять точку, расположенную на вершине второго столба!
Start находится в GetActorLocation(), это середина тела персонажа. Но если от вершины второго столба опуститься на половину высоты капсулы (да еще учесть оффсет, задаваемый вручную, чтобы рука точно попадала на веревку), все равно не удается правильно спозиционировать персонажа — к концу движения он непременно оказывается либо ниже веревки, либо выше.
Помог код изначального аттача к веревке:
1 получаем вектор от начала к концу веревки, вычитанием точек. Нормализуем
2 получаем проекцию вектора от первого столба к центру игрока, на веревку — DotProduct
3 проекция это float, умножаем его на вектор из п.1, получаем вектор от начала веревки до текущей точки на ней, где расположен персонаж
4 положение игрока = первый столб + вектор из п.3 + вручную задаваемый оффсет
В PhysZipline рассчитываем точку End:
— берем второй столб, к нему прибавляем вектор из п. 3
— очевидно получается вектор, идущий из второго столба дальше по направлению веревки
Также рассчитываем момент, когда перед вторым столбом, персонаж отпускает веревку
Для этого сравниваем проекцию текущего положения игрока на веревку (сколько "проехали") с длиной веревки, из которой вычтен вручную задаваемый оффсет с конца (чтобы отцепляться от веревки не у самого столба, а чуть раньше)
if (GetActorToZiplineProjection(NewLoc) > (CurrentZipline–>GetSize() — CurrentZipline–>GetZiplineDetachOffset()))
{
DetachFromZipline();
}
Уф, сам до конца не понимаю как все работает. И есть ощущение, что код можно значительно сократить. Но пока этого достаточно, нужно двигаться вперед.
Мозгу требуется время, чтобы в нем укоренились все абстрактные конструкции, которыми мы оперируем, чтобы он мог использовать их быстро и эффективно.
👍1
Настало время продолжить изучение стримов по UE. Всего их 3 части, первую я смотрел ранее, сегодня планирую осилить 2 и 3.
Тогда до НГ мне останется только сделать 6й спринт по С++, опционально читать Essential math и паттерны программирования игр.
Не хочу браться за раздел с оружием в предновогодней суете, потрачу это время на доп. материалы
Тогда до НГ мне останется только сделать 6й спринт по С++, опционально читать Essential math и паттерны программирования игр.
Не хочу браться за раздел с оружием в предновогодней суете, потрачу это время на доп. материалы
вот мой конспект по первой части стрима про UE.
Не знаю насколько он читабельный для вас.
На Игропром такое выкладывать стыдно, а сюда - в самый раз 😃
Не знаю насколько он читабельный для вас.
На Игропром такое выкладывать стыдно, а сюда - в самый раз 😃
XYZ interview UE.docx
4.3 MB
Уф, наконец-то я одолел все 3 стрима по вопросам по UE на собеседовании
Мой конспект возможно не очень читабельный для других, но что-то из него почерпнуть можно.
Сами стримы выложить не могу, так как они на платформе XYZ School.
Мой конспект возможно не очень читабельный для других, но что-то из него почерпнуть можно.
Сами стримы выложить не могу, так как они на платформе XYZ School.
Forwarded from XashNT
Традиционно подведу итоги уходящего года.
Наверное это был самый неинформативный год в плане разработки Ксаша.
Ну что поделать? Мои планы не поменялись, я по прежнему считаю, что графический интерфейс следует размещать внутри виртуальной машины.
Разумеется это не я первый придумал, это давно практикуется с явой и шарпом. Вот только ни один из уже существующих скриптовых языков меня не устроил. Я бы мог пуститься в пространные рассуждения почему сложилась такая ситуация, но не стану. Вы всё равно ничего не поймете. Не потому что глупые, а потому что вам это абсолютно неинтересно. Но если всё же кому-то будет интересно, я распишу дополнительно ниже. Пока что отмечу тот факт, что собственный скриптовой язык открывает замечательные возможности. недоступные ни на Яве ни на Шарпе, поскольку в этих языках обязательно не будет того, что нужно, и придётся ждать, когда оно там появится, неизвестно в какой форме оно там появится и как после этого сломается совместимость. В качестве примера могу привести тот же Unity, где смена мажорного номера версии ознаменовала собой переход на новую версию Шарпа. То есть разработчики целиком и полностью зависят от сторонних библиотек, сужая и без того невеликое пространство решений.
Впрочем даже выбирая Lua или AngelScript вы всё равно оказываетесь в зависимости от авторов этих библиотек. Были, как вы знаете два движка с собственными скриптовыми языками - это Unigine и Godot. Первый пытался частично эмулировать функционал С++, но к сожалению использовал порочную модель Шарпа и Явы (всё - объект), что разумеется сказалось на его производительности. Поэтому большой объемный код на таких скриптах не напишешь. Впрочем в Unreal до третьей версии включительно сохранялась та же самая ситуация. Скрипты есть, а их производительность не годится для написания чего-то боле-мене серьезного. У Годота язык старался быть похожим на Питон, который использует ту же самую объектную модель со всеми вытекающими. И с той же низкой производительностью. Как итог все движки предлагают альтернативу - использование С++ библиотек, что полностью ломает первоначальную задумку и вносит элемент хаотичности.
В Ксаше я поступил иначе. Мой язык изначально планировался как скриптовой и с высокой нагрузочной способностью. Грубо говоря это песочница с синтаксисом и поведением С++, но при этом имеющая такие возможности, которые в самом С++ реализованы не будут никогда. А если и будут, то очень коряво и неудобно. Разумеется всё это успешно обходят - прописывая подобные вещи вручную. Но ведь смысл как раз в том и заключается, чтобы автоматизировать очевидное, получив при этом новые возможности. Практически весь 2022-й год я и бился над решением этой задачи. Пока ещё рано говорить с полной уверенностью, но мне определённо нравится то, что у меня получилось.
И теперь я наконец-то смогу вернуться к своей изначальной цели - написанию универсального редактора и универсального вьювера, интерфейсы которых будут реализованы на том самом скриптовом языке, а значит смогут быть отредактированы юзерами, если им вдруг захочется поменять расположение контролов или вообще создать новые окна.
Но, как вы понимаете, сам скриптовой язык предлагает куда более широкие возможности, нежели правка исходного кода таких меню. Теперь так же будет доступна возможность редактирования внешнего вида из текстовых файлов, причём изменения в исходном коде потребуются минимальные - т.к. сама виртуальная машина уже обеспечивает весь необходимый функционал. Да и сохранение абсолютно всех настроек как редактора, так и вьювера теперь стали весьма простым делом.
Наверное это был самый неинформативный год в плане разработки Ксаша.
Ну что поделать? Мои планы не поменялись, я по прежнему считаю, что графический интерфейс следует размещать внутри виртуальной машины.
Разумеется это не я первый придумал, это давно практикуется с явой и шарпом. Вот только ни один из уже существующих скриптовых языков меня не устроил. Я бы мог пуститься в пространные рассуждения почему сложилась такая ситуация, но не стану. Вы всё равно ничего не поймете. Не потому что глупые, а потому что вам это абсолютно неинтересно. Но если всё же кому-то будет интересно, я распишу дополнительно ниже. Пока что отмечу тот факт, что собственный скриптовой язык открывает замечательные возможности. недоступные ни на Яве ни на Шарпе, поскольку в этих языках обязательно не будет того, что нужно, и придётся ждать, когда оно там появится, неизвестно в какой форме оно там появится и как после этого сломается совместимость. В качестве примера могу привести тот же Unity, где смена мажорного номера версии ознаменовала собой переход на новую версию Шарпа. То есть разработчики целиком и полностью зависят от сторонних библиотек, сужая и без того невеликое пространство решений.
Впрочем даже выбирая Lua или AngelScript вы всё равно оказываетесь в зависимости от авторов этих библиотек. Были, как вы знаете два движка с собственными скриптовыми языками - это Unigine и Godot. Первый пытался частично эмулировать функционал С++, но к сожалению использовал порочную модель Шарпа и Явы (всё - объект), что разумеется сказалось на его производительности. Поэтому большой объемный код на таких скриптах не напишешь. Впрочем в Unreal до третьей версии включительно сохранялась та же самая ситуация. Скрипты есть, а их производительность не годится для написания чего-то боле-мене серьезного. У Годота язык старался быть похожим на Питон, который использует ту же самую объектную модель со всеми вытекающими. И с той же низкой производительностью. Как итог все движки предлагают альтернативу - использование С++ библиотек, что полностью ломает первоначальную задумку и вносит элемент хаотичности.
В Ксаше я поступил иначе. Мой язык изначально планировался как скриптовой и с высокой нагрузочной способностью. Грубо говоря это песочница с синтаксисом и поведением С++, но при этом имеющая такие возможности, которые в самом С++ реализованы не будут никогда. А если и будут, то очень коряво и неудобно. Разумеется всё это успешно обходят - прописывая подобные вещи вручную. Но ведь смысл как раз в том и заключается, чтобы автоматизировать очевидное, получив при этом новые возможности. Практически весь 2022-й год я и бился над решением этой задачи. Пока ещё рано говорить с полной уверенностью, но мне определённо нравится то, что у меня получилось.
И теперь я наконец-то смогу вернуться к своей изначальной цели - написанию универсального редактора и универсального вьювера, интерфейсы которых будут реализованы на том самом скриптовом языке, а значит смогут быть отредактированы юзерами, если им вдруг захочется поменять расположение контролов или вообще создать новые окна.
Но, как вы понимаете, сам скриптовой язык предлагает куда более широкие возможности, нежели правка исходного кода таких меню. Теперь так же будет доступна возможность редактирования внешнего вида из текстовых файлов, причём изменения в исходном коде потребуются минимальные - т.к. сама виртуальная машина уже обеспечивает весь необходимый функционал. Да и сохранение абсолютно всех настроек как редактора, так и вьювера теперь стали весьма простым делом.
Сегодня закончил шестой спринт по С++ курса Яндекса 💥💥💥
Радует что удаётся проходить спринты в кратчайшiя сроки - 5й я одолел за 3 дня, 6й - за 4.
А в целом, на каждый спринт студентам выделяется по 2 недели.
Радует что удаётся проходить спринты в кратчайшiя сроки - 5й я одолел за 3 дня, 6й - за 4.
А в целом, на каждый спринт студентам выделяется по 2 недели.
В 6м спринте изучал скорость роста сложности алгоритмов (все вот эти О(эн квадрат) и О(N log N)
7й спринт манит интересной темой - устройство памяти в С++.
Еще на курсах степика мне очень понравилось ковыряться в памяти со смещениями и указателями, и создавать визуальное представление того, как классы и объекты хранятся в памяти.
7й спринт манит интересной темой - устройство памяти в С++.
Еще на курсах степика мне очень понравилось ковыряться в памяти со смещениями и указателями, и создавать визуальное представление того, как классы и объекты хранятся в памяти.
В общем я дал слабину и изменил язык надписей в Ведьмаке с польского на русский. Слишком уж тяжко разбираться во всех хитростях создания зелий и прочих механиках игры на польском. Хотя моего польского и хватало, чтобы понимать диалоги.
Даю себе обещание вернуться к польским текстам, когда ориентироваться в игре станет попроще.
А пока придется распознавать озвучку на слух - субтитры, niestety, тоже теперь на русском.
Даю себе обещание вернуться к польским текстам, когда ориентироваться в игре станет попроще.
А пока придется распознавать озвучку на слух - субтитры, niestety, тоже теперь на русском.