Добро пожаловать в тред любви, взаимопомощи, швецов, жнецов и на дуде игрецов!
Шапка: https://hipolink.me/godothread
Предыдущий: >>1040245 (OP)
Архивный: >>1030839 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>1040245 (OP)
Архивный: >>1030839 (OP)
>>8979 (OP)
Что надо сделать, чтобы увековечиться в шапке тредю?
Что надо сделать, чтобы увековечиться в шапке тредю?
>>8979 (OP)
Старый треллей, как-то уныло. Неужели нечем рисануться?
Старый треллей, как-то уныло. Неужели нечем рисануться?
>>8979 (OP)
На случай важных переговоров с издателем вашей игры, если вдруг спросят, а как вы будете удалять элементы из головы массива? Отвечайте, что быстрее будет реверснуть и удалять с хвоста.
На случай важных переговоров с издателем вашей игры, если вдруг спросят, а как вы будете удалять элементы из головы массива? Отвечайте, что быстрее будет реверснуть и удалять с хвоста.
5 Кб, 302x83>>9034
О, я после похожих тестов пришел к такому решению. У меня там обычно массив 10к, который я шринкаю до 1к раз в минуту, потом снова отращиваю его до 10к и снова шринкаю. Можешь тоже потестить и сравнить со своими бенчами.
О, я после похожих тестов пришел к такому решению. У меня там обычно массив 10к, который я шринкаю до 1к раз в минуту, потом снова отращиваю его до 10к и снова шринкаю. Можешь тоже потестить и сравнить со своими бенчами.
>>9034
А ну поменяй местами свои тесты
А ну поменяй местами свои тесты
Вообще можно делать так:
a1 = a1.slice(a1.size() - items_to_stay, a1.size());
Но подозреваю что тест наврал по времени и-за кеширования.
a1 = a1.slice(a1.size() - items_to_stay, a1.size());
Но подозреваю что тест наврал по времени и-за кеширования.
410 Кб, 512x512>>9037
Неправильно.
Нужно отвечать "А тебя это ебать не должно"
>На случай важных переговоров с издателем вашей игры, если вдруг спросят, а как вы будете удалять элементы из головы массива?
>Отвечайте, что быстрее будет реверснуть и удалять с хвоста.
Неправильно.
Нужно отвечать "А тебя это ебать не должно"
>>9034
Ты не поверил тому, что в документации написано?
Это проблема XY. Зачем тебе это вообще нужно?
Поясняю вкратце, исходя из исходников движка:
1. В pop_back() копирования вообще нет:
- вернуть значение последней ячейки массива;
- инициализировать массив с новым размером.
2. В pop_front() идёт копирование массива -1:
- вернуть значение первой ячейки массива;
- через for сдвинуть все значения влево.
3. В reverse() идёт копирование всего массива.
4. В slice() идёт копирование части массива.
Иными словами, если у нас есть две задачи:
А. Удалить 30 тысяч элементов в одном месте.
Б. Удалить 1 элемент из 30 тысяч разных мест.
Работа в случае задачи А:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 2 копирования, 30 тыс. + 2 вызовов.
- slice: 1 копирование остаточной части, 1 вызов API.
Работа в случае задачи Б:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 60 тыс. копирований, 90 тыс. вызовов.
- slice: 30 тыс. копирования части, 30 тыс. вызовов.
Итого, более точным решением будет:
Задача А: использовать API-функцию slice().
Задача Б: рефакторить архитектуру приложения.
Ты не поверил тому, что в документации написано?
Это проблема XY. Зачем тебе это вообще нужно?
Поясняю вкратце, исходя из исходников движка:
1. В pop_back() копирования вообще нет:
- вернуть значение последней ячейки массива;
- инициализировать массив с новым размером.
2. В pop_front() идёт копирование массива -1:
- вернуть значение первой ячейки массива;
- через for сдвинуть все значения влево.
3. В reverse() идёт копирование всего массива.
4. В slice() идёт копирование части массива.
Иными словами, если у нас есть две задачи:
А. Удалить 30 тысяч элементов в одном месте.
Б. Удалить 1 элемент из 30 тысяч разных мест.
Работа в случае задачи А:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 2 копирования, 30 тыс. + 2 вызовов.
- slice: 1 копирование остаточной части, 1 вызов API.
Работа в случае задачи Б:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 60 тыс. копирований, 90 тыс. вызовов.
- slice: 30 тыс. копирования части, 30 тыс. вызовов.
Итого, более точным решением будет:
Задача А: использовать API-функцию slice().
Задача Б: рефакторить архитектуру приложения.
>>9034
Ты не поверил тому, что в документации написано?
Это проблема XY. Зачем тебе это вообще нужно?
Поясняю вкратце, исходя из исходников движка:
1. В pop_back() копирования вообще нет:
- вернуть значение последней ячейки массива;
- инициализировать массив с новым размером.
2. В pop_front() идёт копирование массива -1:
- вернуть значение первой ячейки массива;
- через for сдвинуть все значения влево.
3. В reverse() идёт копирование всего массива.
4. В slice() идёт копирование части массива.
Иными словами, если у нас есть две задачи:
А. Удалить 30 тысяч элементов в одном месте.
Б. Удалить 1 элемент из 30 тысяч разных мест.
Работа в случае задачи А:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 2 копирования, 30 тыс. + 2 вызовов.
- slice: 1 копирование остаточной части, 1 вызов API.
Работа в случае задачи Б:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 60 тыс. копирований, 90 тыс. вызовов.
- slice: 30 тыс. копирования части, 30 тыс. вызовов.
Итого, более точным решением будет:
Задача А: использовать API-функцию slice().
Задача Б: рефакторить архитектуру приложения.
Ты не поверил тому, что в документации написано?
Это проблема XY. Зачем тебе это вообще нужно?
Поясняю вкратце, исходя из исходников движка:
1. В pop_back() копирования вообще нет:
- вернуть значение последней ячейки массива;
- инициализировать массив с новым размером.
2. В pop_front() идёт копирование массива -1:
- вернуть значение первой ячейки массива;
- через for сдвинуть все значения влево.
3. В reverse() идёт копирование всего массива.
4. В slice() идёт копирование части массива.
Иными словами, если у нас есть две задачи:
А. Удалить 30 тысяч элементов в одном месте.
Б. Удалить 1 элемент из 30 тысяч разных мест.
Работа в случае задачи А:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 2 копирования, 30 тыс. + 2 вызовов.
- slice: 1 копирование остаточной части, 1 вызов API.
Работа в случае задачи Б:
- pop_front: 30 тыс. копирований, 30 тыс. вызовов.
- reverse+back: 60 тыс. копирований, 90 тыс. вызовов.
- slice: 30 тыс. копирования части, 30 тыс. вызовов.
Итого, более точным решением будет:
Задача А: использовать API-функцию slice().
Задача Б: рефакторить архитектуру приложения.
>>9071
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>сделать быструю замену pop_at()
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>>9076
>>9067
>>9061
>>9039
>>9034
Вы не шарите, надо делать так:
Минимальные требования
ОС: Windows 11
Процессор (AMD): AMD Ryzen 7 3700X
Процессор (Intel): Intel Core i7-10700
Оперативная память: 16 ГБ
Видеокарта (AMD): AMD Radeon RX 6700-XT
Видеокарта (Nvidia): Nvidia RTX 3060Ti
Direct X: DX12
Подключение к Интернету: Да
Место на диске: :SSD — 80 ГиБ
Дополнительно: TPM 2.0 включён, Безопасная загрузка UEFI включена, Поддержка HVCI, Поддержка VBS
>>9067
>>9061
>>9039
>>9034
Вы не шарите, надо делать так:
Минимальные требования
ОС: Windows 11
Процессор (AMD): AMD Ryzen 7 3700X
Процессор (Intel): Intel Core i7-10700
Оперативная память: 16 ГБ
Видеокарта (AMD): AMD Radeon RX 6700-XT
Видеокарта (Nvidia): Nvidia RTX 3060Ti
Direct X: DX12
Подключение к Интернету: Да
Место на диске: :SSD — 80 ГиБ
Дополнительно: TPM 2.0 включён, Безопасная загрузка UEFI включена, Поддержка HVCI, Поддержка VBS
>>9089
Чтобы получить школоассетфлип, который запускается только на топовых печах, не обладая при этом графоном? Ну, допустим.
> надо делать так:
Чтобы получить школоассетфлип, который запускается только на топовых печах, не обладая при этом графоном? Ну, допустим.
>>9071
Не, тут только ситууационно что-то придумать можно, например тебе нужно из огромного массива размером N удалить много элементов например N/2.
Тогда можно вместо удаления делать их null, потом пробежаться по массиву двумя "курсорами" делая swap для null и не null значений, а когда один курсор дойдёт до конца массива сделать resize до позиции другого курсора.
Не, тут только ситууационно что-то придумать можно, например тебе нужно из огромного массива размером N удалить много элементов например N/2.
Тогда можно вместо удаления делать их null, потом пробежаться по массиву двумя "курсорами" делая swap для null и не null значений, а когда один курсор дойдёт до конца массива сделать resize до позиции другого курсора.
>>9093
Неплохо, реально неплохо. Потом реализую. А вот если мне в массиве нулль нужен, чем его заменить? Скажем, для указания на пустое место под удаление использовать класс-пустышку?
Неплохо, реально неплохо. Потом реализую. А вот если мне в массиве нулль нужен, чем его заменить? Скажем, для указания на пустое место под удаление использовать класс-пустышку?
>>9092
Он не это имел ввиду.
Я кстати без понятия что писать в системках, если когда-нибудь настанет день релиза. Возможно просто напишу конфиг моего компа. Похуй что он игру может хоть в 100 окон запустить.
Он не это имел ввиду.
Я кстати без понятия что писать в системках, если когда-нибудь настанет день релиза. Возможно просто напишу конфиг моего компа. Похуй что он игру может хоть в 100 окон запустить.
162 Кб, 365x441>>9099
Если вы бездомный - просто купите дом. Если вы бесхлебный - кушайте пирожные.
Если вы бездомный - просто купите дом. Если вы бесхлебный - кушайте пирожные.
>>9094
Variant() по идее можно
Можно какой-то другой массив создать, который будет хранить индексы удалённых элементов и в какой то момент его "применить" / "скоммитить"
т.е. есть исходный массив arr и массив удаляемых элементов del,
можно что-то вроде такого сделать:
(не проверял, но смысл чтобы собрать новый массив из кусков старого, за счёт памяти)
>А вот если мне в массиве нулль нужен, чем его заменить?
Variant() по идее можно
Можно какой-то другой массив создать, который будет хранить индексы удалённых элементов и в какой то момент его "применить" / "скоммитить"
т.е. есть исходный массив arr и массив удаляемых элементов del,
можно что-то вроде такого сделать:
>del.sort()
>var new_arr = []
>var ind = 0
>for d in del:
> new_arr.append(a.slice(ind, d))
> ind = d + 1
(не проверял, но смысл чтобы собрать новый массив из кусков старого, за счёт памяти)
>>9093 >>9094 >>9103
Прекращайте преждевременные оптимизации. Они усложняют код и могут оказаться хуже самого тупого решения в будущем. Если вам нужно произвольные элементы массива удалять, и код на GDScript, лучше пользоваться Dictionary и не париться. Скорость у встроенного Dictionary чуть-чуть медленнее Array, но операции добавления и удаления в середине будут значительно дешевле. Аналог обычного Array:
Добавление элемента:
Удаление элемента:
Проверка наличия:
В других ЯП это называют associative array:
https://en.wikipedia.org/wiki/Associative_array
Dictionary может хранить null:
Прекращайте преждевременные оптимизации. Они усложняют код и могут оказаться хуже самого тупого решения в будущем. Если вам нужно произвольные элементы массива удалять, и код на GDScript, лучше пользоваться Dictionary и не париться. Скорость у встроенного Dictionary чуть-чуть медленнее Array, но операции добавления и удаления в середине будут значительно дешевле. Аналог обычного Array:
>var array: Dictionary[int, Variant]
Добавление элемента:
>array[key] = data
Удаление элемента:
>array.erase(key)
Проверка наличия:
>if key in array: ...
>if key not in array: ...
В других ЯП это называют associative array:
https://en.wikipedia.org/wiki/Associative_array
Dictionary может хранить null:
>array[0] = "text"
>array[1] = null
>for key in 3:
>_ if key in array: print(array[key])
>_ else: print("Key ", key, " doesn't exist!")
>>9121
Я в силу глубины своей некомпетентности не понимаю, как покрывать тестами код) Эффект Даунинга-Крюгера))
Я в силу глубины своей некомпетентности не понимаю, как покрывать тестами код) Эффект Даунинга-Крюгера))
>>9089
Так. Ни хера себе. Это кто у нас такой охуенный клоун? Рядовой Шутник, а?
Так. Ни хера себе. Это кто у нас такой охуенный клоун? Рядовой Шутник, а?
>>9034 >>9113
Ты осознаёшь, что pick_random() здесь будет вызвана единожды перед вызовом fill(), а дальше fill() сделает заполнение массива единственным значением?
Если хочешь заполнить массив случайным мусором:
Правда, на тесты скорости это никак не повлияет.
>a.fill([...].pick_random())
Ты осознаёшь, что pick_random() здесь будет вызвана единожды перед вызовом fill(), а дальше fill() сделает заполнение массива единственным значением?
Если хочешь заполнить массив случайным мусором:
>a2 = a1.map(func(e): return [...].pick_random())
Правда, на тесты скорости это никак не повлияет.
Хочу попробовать GDExtension на C++. Подводные?
Не знаю C++, как лучше писать параллельный поток? Какими-то C++ классами или через Godot API? Хочу числодробилку параллельно Godot крутить, но чтоб излучала сигнал на сторону GDScript, когда закончит.
Не знаю C++, как лучше писать параллельный поток? Какими-то C++ классами или через Godot API? Хочу числодробилку параллельно Godot крутить, но чтоб излучала сигнал на сторону GDScript, когда закончит.
>>9127
Фух. Не обосрался. Ну не сильно. Обсер был, но в штанину не попало. Активно работает смена белья.
> Правда, на тесты скорости это никак не повлияет.
Фух. Не обосрался. Ну не сильно. Обсер был, но в штанину не попало. Активно работает смена белья.
>>9136
Будет крошиться на десктоп как скайрим с модами.
Так ты выучи си++ чтобы его знать ДО ТОГО как придёшь в геймдев.
> Подводные?
Будет крошиться на десктоп как скайрим с модами.
> Не знаю C++
> Не знаю как писать параллельный поток
Так ты выучи си++ чтобы его знать ДО ТОГО как придёшь в геймдев.
>>9158
https://github.com/orgs/godotengine/projects/61/views/5
когда пропадут release blcokers и по возможности very bad и bad
https://github.com/orgs/godotengine/projects/61/views/5
когда пропадут release blcokers и по возможности very bad и bad
Кто тут делал летающие острова?
Жаль тебя огорчать, анон, но такая игра уже скоро выйдет https://youtu.be/yG5vZqVVCn8?si=ZaXI1c8nYIbC2yXI
Жаль тебя огорчать, анон, но такая игра уже скоро выйдет https://youtu.be/yG5vZqVVCn8?si=ZaXI1c8nYIbC2yXI
>>9170
Ну вряд ли он будет заметен на фоне целой команды разработчиков, которые явно собираются поддерживать игру n лет. Тем более без четкой цели. Нужно менять концепцию и браться за что-то менее масштабное
Ну вряд ли он будет заметен на фоне целой команды разработчиков, которые явно собираются поддерживать игру n лет. Тем более без четкой цели. Нужно менять концепцию и браться за что-то менее масштабное
>>9184
Пчел этих игр про летающие острова вагон еще в нулевых был. Твой пойнт это пойнт уровня "в гта люди, всем перестать делать игры про людей".
Летающие острова самый обычный дженерик фентези сеттинг. Удобен для разработки и на этом все.
Пчел этих игр про летающие острова вагон еще в нулевых был. Твой пойнт это пойнт уровня "в гта люди, всем перестать делать игры про людей".
Летающие острова самый обычный дженерик фентези сеттинг. Удобен для разработки и на этом все.
В продолжение >>9188
Я думал делать редалерт1 лайк когда-то, поискал как там что было сделано - там танки отрисовывались в 3д на самом деле и были воксельными. Ну я сделал вьюпорт в котором 3д танк рендерился и передавался в 2д мир, написао конвертор координат 2д<>3д.
А ютуб такой на ка посмотри что нормальные люди делают https://www.youtube.com/watch?v=aNHMwEOJxoY
И как-то уже и не хочется
Я думал делать редалерт1 лайк когда-то, поискал как там что было сделано - там танки отрисовывались в 3д на самом деле и были воксельными. Ну я сделал вьюпорт в котором 3д танк рендерился и передавался в 2д мир, написао конвертор координат 2д<>3д.
А ютуб такой на ка посмотри что нормальные люди делают https://www.youtube.com/watch?v=aNHMwEOJxoY
И как-то уже и не хочется
>>9185
Там у них буквально полноценная постройка кораблей и полеты на них. Как раз то, что пробовал делать тот анон. В общем ему нужно допиливать концепцию и придумывать уникальные фишки.
Там у них буквально полноценная постройка кораблей и полеты на них. Как раз то, что пробовал делать тот анон. В общем ему нужно допиливать концепцию и придумывать уникальные фишки.
>>9189
Как ты - разработчик-одиночка (как понимаю) планировал высчитывать баланс хотя бы 2-3 фракций? Зачем вы беретесь за настолько сложные проекты со сложными механиками? У вас вообще есть горизонт планирования?
Как ты - разработчик-одиночка (как понимаю) планировал высчитывать баланс хотя бы 2-3 фракций? Зачем вы беретесь за настолько сложные проекты со сложными механиками? У вас вообще есть горизонт планирования?
>>9191
В редалерте баланс был на уровне у одних так с уроном 10 в других танк с уроном 10
В редалерте баланс был на уровне у одних так с уроном 10 в других танк с уроном 10
>>9190
Бля ты рофлишь если думаешь что это редкая идея
https://store.steampowered.com/app/2644050/Echoes_of_Elysium/
https://store.steampowered.com/app/1048950/Desert_Skies/
https://store.steampowered.com/app/1931180/Lost_Skies/
https://store.steampowered.com/app/1040070/Merchant_of_the_Skies/
https://store.steampowered.com/app/271920/Worlds_Adrift_Island_Creator/
https://store.steampowered.com/app/2097190/Astoaria/
https://store.steampowered.com/app/342560/Airships_Conquer_the_Skies/
https://store.steampowered.com/app/1641960/Forever_Skies/
https://store.steampowered.com/app/982290/Airborne_Kingdom/
https://store.steampowered.com/app/1660080/Aloft/
https://en.wikipedia.org/wiki/Project_Nomads
>полноценная постройка кораблей и полеты на них
Бля ты рофлишь если думаешь что это редкая идея
https://store.steampowered.com/app/2644050/Echoes_of_Elysium/
https://store.steampowered.com/app/1048950/Desert_Skies/
https://store.steampowered.com/app/1931180/Lost_Skies/
https://store.steampowered.com/app/1040070/Merchant_of_the_Skies/
https://store.steampowered.com/app/271920/Worlds_Adrift_Island_Creator/
https://store.steampowered.com/app/2097190/Astoaria/
https://store.steampowered.com/app/342560/Airships_Conquer_the_Skies/
https://store.steampowered.com/app/1641960/Forever_Skies/
https://store.steampowered.com/app/982290/Airborne_Kingdom/
https://store.steampowered.com/app/1660080/Aloft/
https://en.wikipedia.org/wiki/Project_Nomads
>>9206
Нет. Идеи стоят примерно нихуя, они копируются, воруются, вдохновляются, модифицируются, и в каждой голове их бесконечное количество. Трясусны за идеи - нюфаженьки, геймдева не нюхавшие.
Нет. Идеи стоят примерно нихуя, они копируются, воруются, вдохновляются, модифицируются, и в каждой голове их бесконечное количество. Трясусны за идеи - нюфаженьки, геймдева не нюхавшие.
>>9200
Зачем тебе индекс если у тебя задача добавлять удалять как в очереди (алгоритм). Если у тебя и то и то нужно, та надо уже матчасть учить.
Зачем тебе индекс если у тебя задача добавлять удалять как в очереди (алгоритм). Если у тебя и то и то нужно, та надо уже матчасть учить.
>>9150
Я могу читать и понимать исходники движка и могу смастерить хэллоу ворлд на C++, но я не знаю всех подводных камней C++. Знаю только что это очень костыльный язык, которому почти каждый год баги пытаются пофиксить в стандарте, но делают хуже; используется только ради скорости, скрипя зубами.
Так что использовать - Godot, OpenMP или что-то совершенно другое? Насколько я понял, в C++ нет многопоточности как таковой, её костылят васяны, поэтому просто взять и написать код не получится.
Кстати, почему так?.. Разве в Godot не используется exception handling? Или это снизило бы скорость для внешних модулей? По-моему, если в модуле что-то сломается, основная программа не должна падать, обрабатывая возникающие исключения на ходу.
>>9156
Что напишет? Код для OpenMP?
>выучи си++ чтобы его знать
Я могу читать и понимать исходники движка и могу смастерить хэллоу ворлд на C++, но я не знаю всех подводных камней C++. Знаю только что это очень костыльный язык, которому почти каждый год баги пытаются пофиксить в стандарте, но делают хуже; используется только ради скорости, скрипя зубами.
Так что использовать - Godot, OpenMP или что-то совершенно другое? Насколько я понял, в C++ нет многопоточности как таковой, её костылят васяны, поэтому просто взять и написать код не получится.
>Будет крошиться на десктоп
Кстати, почему так?.. Разве в Godot не используется exception handling? Или это снизило бы скорость для внешних модулей? По-моему, если в модуле что-то сломается, основная программа не должна падать, обрабатывая возникающие исключения на ходу.
>>9156
>Нейросеть напишет.
Что напишет? Код для OpenMP?
>>9256
По подводным надо самому походить, иначе твое знание нихуя не стоит. Разве что в срачах в интернетике козырнешь, а на пратике сразу же еблом в подводный камень да с разбегу угодишь.
Что ты имеешь ввиду? thread потерял?
>я не знаю всех подводных камней C++
По подводным надо самому походить, иначе твое знание нихуя не стоит. Разве что в срачах в интернетике козырнешь, а на пратике сразу же еблом в подводный камень да с разбегу угодишь.
>в C++ нет многопоточности как таковой
Что ты имеешь ввиду? thread потерял?
>>9258
Ааа, вон оно что.
<thread> вошёл в стандарт C++11.
А OpenMP рекомендовали в 2010.
Нейронка почему-то решила, что обсуждения на StackOverflow за 2010 год более авторитетные...
Спасибо за подсказку.
>thread потерял?
Ааа, вон оно что.
<thread> вошёл в стандарт C++11.
А OpenMP рекомендовали в 2010.
Нейронка почему-то решила, что обсуждения на StackOverflow за 2010 год более авторитетные...
Спасибо за подсказку.
>>9259
1 секунда гугла c++ threads и первая же ссылка. Я просто удивился твоим словам, типа как это так ваще, вот и загуглил. Нейронки пожрали твой мозг. Да и мой тоже, часто из-за льющегося от них говна так же туплю.
>Спасибо за подсказку.
1 секунда гугла c++ threads и первая же ссылка. Я просто удивился твоим словам, типа как это так ваще, вот и загуглил. Нейронки пожрали твой мозг. Да и мой тоже, часто из-за льющегося от них говна так же туплю.
>>9252
Иногда еще полезно бывает читать условие задачи. А там значится обьект типа массив, который обязан иметь функционал индекса, при чём не его o(n) суррогат, а нормальный вычесляемый индекс. И матчасть тут не поможет, потому что нет матчасти которая бы смогла к связному списку прикрутить индекс без прикручивания дополнительного массива для индексов элементов списка.
Иногда еще полезно бывает читать условие задачи. А там значится обьект типа массив, который обязан иметь функционал индекса, при чём не его o(n) суррогат, а нормальный вычесляемый индекс. И матчасть тут не поможет, потому что нет матчасти которая бы смогла к связному списку прикрутить индекс без прикручивания дополнительного массива для индексов элементов списка.
>>9252
>>9265
https://en.wikipedia.org/wiki/Associative_array
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
У Dictionary O(1) сложность доступа.
>Если у тебя и то и то нужно, та надо
>>9265
>массив, который обязан иметь индексы
https://en.wikipedia.org/wiki/Associative_array
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>при чём не его o(n) суррогат
У Dictionary O(1) сложность доступа.
>>9265
Ты хочешь и булку съесть и на годот сесть. Ты уже описываешь две задачи (рандомный доступ и очередь), так сова на глобус не налезет.
Чаще всего вообще бывает, что ты обосрался в предметной области и решаешь задачу, которая поставлена ошибочно, под все остальное всегда хватает стандартных алгоритмов.
Ты хочешь и булку съесть и на годот сесть. Ты уже описываешь две задачи (рандомный доступ и очередь), так сова на глобус не налезет.
Чаще всего вообще бывает, что ты обосрался в предметной области и решаешь задачу, которая поставлена ошибочно, под все остальное всегда хватает стандартных алгоритмов.
>>9267
Каким боком key value к связному списку? Тебе не кажется что сама задача "удалить элемент массива с конца" для такой вещи как словарь просто лишена смысла по той простой причине что словарь не имеет возможности укладывать элементы сообразно последовательности их добавления в словарь. У словарей нет индекса в его "массивном" понимании. А любые попытки его прикрутить значительно замедлят процесс добавления/удаления обьекта в словарь при этом не дав значительных преимуществ перед стандартными массивами.
>>9274
Лично я ничего не описываю, только отталкиваюсь от свойств требуемых обьектов, перечитай условие задачи еще раз. Вполне обоснованная задача, которая хоть и относительно редкая но всё же встречающаяся.
Каким боком key value к связному списку? Тебе не кажется что сама задача "удалить элемент массива с конца" для такой вещи как словарь просто лишена смысла по той простой причине что словарь не имеет возможности укладывать элементы сообразно последовательности их добавления в словарь. У словарей нет индекса в его "массивном" понимании. А любые попытки его прикрутить значительно замедлят процесс добавления/удаления обьекта в словарь при этом не дав значительных преимуществ перед стандартными массивами.
>>9274
>Ты хочешь и булку съесть и на годот сесть. Ты уже описываешь две задачи
Лично я ничего не описываю, только отталкиваюсь от свойств требуемых обьектов, перечитай условие задачи еще раз. Вполне обоснованная задача, которая хоть и относительно редкая но всё же встречающаяся.
>>9037
Не могу понять, где я облажался? Ресайз должен быть быстрее, но всё равно быстрее оказывается поп_бэк. Я уже на микросекунды перешёл, чтобы хоть какие-то данные увидеть.
Посмотри свежим взглядом, где неправ?
> Можешь тоже потестить и сравнить со своими бенчами.
Не могу понять, где я облажался? Ресайз должен быть быстрее, но всё равно быстрее оказывается поп_бэк. Я уже на микросекунды перешёл, чтобы хоть какие-то данные увидеть.
Посмотри свежим взглядом, где неправ?
>>9296
Вот кстати да. Полюбуйтесь.
> А любые попытки его прикрутить значительно замедлят процесс добавления/удаления обьекта в словарь при этом не дав значительных преимуществ перед стандартными массивами.
Вот кстати да. Полюбуйтесь.
>>9301
Возможно в глаза ебусь, но не вижу размеров твоих тестовых массивов. Сделай там 10к элементов и обрежь их до 5к каждым методом.
Возможно в глаза ебусь, но не вижу размеров твоих тестовых массивов. Сделай там 10к элементов и обрежь их до 5к каждым методом.
Для каких геймплейно-дизайнерских задач вам может понадобится обрезать массив на 10к элементов?
Игры дейлайте
Игры дейлайте
>>9308
Для истории ходов, например. Или даже для истории фреймов. Вместо постоянного дрочения на добавление-удоление обрезаешь раз в минуту.
Для истории ходов, например. Или даже для истории фреймов. Вместо постоянного дрочения на добавление-удоление обрезаешь раз в минуту.
>>9328
Уже тащемта рассказал, например.
Уже тащемта рассказал, например.
>>9310
Ты не пробовал делать как в го - слайсы делятся на чанки энного размера? Допустим у тебя кейс с историей ходов и по логике очевидно, что потребуется удалять из нее по 1к элементов за раз или близко к этому, значит делишь всю эту благодать сразу на 1к чанки либо на чанки кратные 1к, офк потребуется обертка в виде своего типа над этим говном, в любом случае ты в процессе либо рубишь на корню целыми чанками разом, либо один последний чанк хирургически, либо все вместе, но профит в том, что не ворочаешь свой массив с миллиардом элементов ради этого целиком на каждый чих. Впрочем гдскрипт массивы может внутри так и работают, это тоже глянь.
Ты не пробовал делать как в го - слайсы делятся на чанки энного размера? Допустим у тебя кейс с историей ходов и по логике очевидно, что потребуется удалять из нее по 1к элементов за раз или близко к этому, значит делишь всю эту благодать сразу на 1к чанки либо на чанки кратные 1к, офк потребуется обертка в виде своего типа над этим говном, в любом случае ты в процессе либо рубишь на корню целыми чанками разом, либо один последний чанк хирургически, либо все вместе, но профит в том, что не ворочаешь свой массив с миллиардом элементов ради этого целиком на каждый чих. Впрочем гдскрипт массивы может внутри так и работают, это тоже глянь.
>>9339
Да, идея хорошая. Я поленился ее делать. Подрезать массив раз в минуту проще. По таймингам фреймов там незначительный микро-пропук, который теряется на фоне активной игры.
Да, идея хорошая. Я поленился ее делать. Подрезать массив раз в минуту проще. По таймингам фреймов там незначительный микро-пропук, который теряется на фоне активной игры.
>>9296
Если очень нужно, то это просто сделать. Но зачем?
>>9308
Годотчую. Изобретают велосипед, экономят спички.
>>9310
Решение очень простое: не хранить историю ходов.
>>9360
А считать спички в велосипеде не поленился?
Он там всегда, даже на пустом проекте...
Если очень нужно, то это просто сделать. Но зачем?
>>9308
Годотчую. Изобретают велосипед, экономят спички.
>>9310
Решение очень простое: не хранить историю ходов.
>>9360
>Я поленился ее делать.
А считать спички в велосипеде не поленился?
>По таймингам фреймов
>незначительный микро-пропук
Он там всегда, даже на пустом проекте...
>>9357
Спасибо. Нашёл тупейшую ошибку копипастинга. Теперь всё заработало. И действительно, ресайз решает. Удаления по одному что в массиве, что в словаре примерно равны. Ну а pop_front() как и написано в документации - слоупок.
Спасибо. Нашёл тупейшую ошибку копипастинга. Теперь всё заработало. И действительно, ресайз решает. Удаления по одному что в массиве, что в словаре примерно равны. Ну а pop_front() как и написано в документации - слоупок.
>>9379
Нашёл ещё одну ошибку. Как-то не верилось, что словарь так быстр, и действительно, я наделел лишнего, из за чего удалялись те элементы, которые должны были остаться. После исправления всё встало на свои места.
Нашёл ещё одну ошибку. Как-то не верилось, что словарь так быстр, и действительно, я наделел лишнего, из за чего удалялись те элементы, которые должны были остаться. После исправления всё встало на свои места.
... А потом пришёл slice() и сделал всех как стоячих. Просто прикурили все.
>>9301
Как ты достал своими кодом. Иди матчасть по алгоритмам учи, это не твой ньюфаг бложик, хватит срать уже. всем насрать на твои юные исследования в программировании
Как ты достал своими кодом. Иди матчасть по алгоритмам учи, это не твой ньюфаг бложик, хватит срать уже. всем насрать на твои юные исследования в программировании
>>9301
Не слушай его. Мне не насрать. Потестируй ещё замену pop_at() на слайсы, раз уж у тебя готовый стенд напрограммирован.
Не слушай его. Мне не насрать. Потестируй ещё замену pop_at() на слайсы, раз уж у тебя готовый стенд напрограммирован.
>>9393
Дыши глубже. Все это напрямую касается годота и игр на нем. Полезные интересные посты. Я из похожих постов узнал что switch в гдскрипте медленнее чем портянки if-else
Дыши глубже. Все это напрямую касается годота и игр на нем. Полезные интересные посты. Я из похожих постов узнал что switch в гдскрипте медленнее чем портянки if-else
>>9395
Результаты неочень, есличесн, пришлось сильно уменьшить входной массив, и всё равно медленно. Слайс хорош когда выполняется один раз, а тут мы возвращаемся к циклам. Остальное хоть и быстрее слайсов-в-цикле, но тоже медленное.
Результаты неочень, есличесн, пришлось сильно уменьшить входной массив, и всё равно медленно. Слайс хорош когда выполняется один раз, а тут мы возвращаемся к циклам. Остальное хоть и быстрее слайсов-в-цикле, но тоже медленное.
>>9396
Надеюсь тебе напихают репортов за флуд.
Нужно к школе готовиться, а не операторы свитч замерять. Вниманиелять.
>Дыши глубже.
Надеюсь тебе напихают репортов за флуд.
Нужно к школе готовиться, а не операторы свитч замерять. Вниманиелять.
>>9400
Всё-таки Dictionary выгоднее, когда нужна, например, разреженная 3D сетка - с адресацией по (X, Y, Z) и добавлением-удалением элементов в произвольных местах этой сетки. На массивах такое делать - голову ломать над адресацией, забивать память нулями/null и даже сам доступ к ячейкам трёхмерного массива может на практике оказаться медленнее Dictionary из-за особенностей GDScript (здесь до сих пор отсутствует JIT/AOT-компиляция, которая могла бы сильно ускорить множество мелких операций, таких, как вычисление адреса в массиве).
Пример:
Пусть и не идеальное решение, но достаточно эффективное в рамках GDScript.
А ещё это решение, теоретически, масштабируется на любое количество измерений, потому что под капотом Vector вроде бы те же структуры, что и у Array, и поэтому Dictionary должен мочь принимать на вход массивы любого размера и любого содержимого:
Конечно, в данном случае вопрос не в скорости, а лишь бы оно вообще работало...
Всё-таки Dictionary выгоднее, когда нужна, например, разреженная 3D сетка - с адресацией по (X, Y, Z) и добавлением-удалением элементов в произвольных местах этой сетки. На массивах такое делать - голову ломать над адресацией, забивать память нулями/null и даже сам доступ к ячейкам трёхмерного массива может на практике оказаться медленнее Dictionary из-за особенностей GDScript (здесь до сих пор отсутствует JIT/AOT-компиляция, которая могла бы сильно ускорить множество мелких операций, таких, как вычисление адреса в массиве).
Пример:
>var grid: Dictionary[Vector3i, GridCell]
>grid[Vector3i(4, 5, 6)] = GridCell.new()
>grid[Vector3i(1, 50, -125)] = GridCell.new()
>grid[Vector3i(500, -250, 125)] = GridCell.new()
>if Vector3i(...) in grid: ...
>grid.erase(Vector3i(...))
Пусть и не идеальное решение, но достаточно эффективное в рамках GDScript.
А ещё это решение, теоретически, масштабируется на любое количество измерений, потому что под капотом Vector вроде бы те же структуры, что и у Array, и поэтому Dictionary должен мочь принимать на вход массивы любого размера и любого содержимого:
>var grid: Dictionary[Array, String]
>grid[[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, "A", "B", "C", "D", "E", "F"]] = "16-мерное пространство"
Конечно, в данном случае вопрос не в скорости, а лишь бы оно вообще работало...
>>9393
>>9402
Ты его поругал и тред умер на полдня. Доволен?
>>9184
Почему ты считаешь, что разработкой игр можно заниматься лишь ради заметности на фоне других? Большинство существующих игр никому не нужны, несмотря на уникальные концепции и хорошую реализацию. Даже от больших, дорогих студий. Они собирают ничтожные 10 тысяч отзывов и всё, пока условная Terraria побила миллион отзывов и растёт. Наиболее необычные игры вообще где-то на дне.
>>9402
Ты его поругал и тред умер на полдня. Доволен?
>>9184
>вряд ли он будет заметен на фоне целой команды
Почему ты считаешь, что разработкой игр можно заниматься лишь ради заметности на фоне других? Большинство существующих игр никому не нужны, несмотря на уникальные концепции и хорошую реализацию. Даже от больших, дорогих студий. Они собирают ничтожные 10 тысяч отзывов и всё, пока условная Terraria побила миллион отзывов и растёт. Наиболее необычные игры вообще где-то на дне.
...не смог установить конпелятор C++...
Щас буду биндить Ada к GDExtension...
Щас буду биндить Ada к GDExtension...
>>8979 (OP)
Кто нибудь делал мультиплеерные игры на годоте? Есть советы по архитектуре серверов?
Кто нибудь делал мультиплеерные игры на годоте? Есть советы по архитектуре серверов?
>>9508
Тут бывает какой-то фанатик, видимо делает что-то уровня киберкотлетской доты, аж пена изо рта идет на тему мультиплеера, особенно о том как сложно кнопки нажимать. Жди его, он занят тем, что делает синхронизации для синхронизаций. А я делал хуйни попроще только, что даже хуже, чем вообще ничего не делать.
Тут бывает какой-то фанатик, видимо делает что-то уровня киберкотлетской доты, аж пена изо рта идет на тему мультиплеера, особенно о том как сложно кнопки нажимать. Жди его, он занят тем, что делает синхронизации для синхронизаций. А я делал хуйни попроще только, что даже хуже, чем вообще ничего не делать.
>>9508 >>9509 >>9512
Семён, ты? Ты зачем флудишь?
Как у тебя
связано с
в твоём понимании?
Движок даёт тебе базовые инструменты, описанные здесь:
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
Остальное ты должен додумывать сам под требования своей игры.
Семён, ты? Ты зачем флудишь?
Как у тебя
>мультиплеерные игры на годоте
связано с
>советы по архитектуре серверов
в твоём понимании?
Движок даёт тебе базовые инструменты, описанные здесь:
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
Остальное ты должен додумывать сам под требования своей игры.
7 Кб, 372x74>>9517
Вообще я в годот тред залетел под какой-то истеричный срач о мультиплеере. Вот и запомнил шиза.
Вообще я в годот тред залетел под какой-то истеричный срач о мультиплеере. Вот и запомнил шиза.
24,2 Мб, mp4,1920x1080, 1:42
Чот напомнило.
>>9471
Я еще на него накляузничал (надеюсь не только я).
Чел тупо страдает фигней и вниманиелядствует в треде. Я конечно понимаю, весело вкатываться в разработку и транслировать свои изыскания, но есть для этого бложики и одноклассники.
Это хорошо, я сюда по делу и заходил, мы же не в /b чтобы тредами меряться.
>Ты его поругал
Я еще на него накляузничал (надеюсь не только я).
Чел тупо страдает фигней и вниманиелядствует в треде. Я конечно понимаю, весело вкатываться в разработку и транслировать свои изыскания, но есть для этого бложики и одноклассники.
>Ты его поругал и тред умер на полдня. Доволен?
Это хорошо, я сюда по делу и заходил, мы же не в /b чтобы тредами меряться.
>>9471
Значит концепция/реализация говно
>Большинство существующих игр никому не нужны, несмотря на уникальные концепции и хорошую реализацию
Значит концепция/реализация говно
>>9562
А я на тебя, и надеюсь не только я, потому что ты срешь в треде своим вечным недовольством на все вообще, и мешаешь обсуждать напрямую релейтед темы. Так и представляю этого старого душного пердячего деда-вахтера, которому даже обсуждение гдскрипта и его подводных камней неподходящая тема. Что дальше, нельзя чейнджлог годота обсуждать? Приходить к тебе за справочкой о каждой теме? Хртьфу.
Не, дед, судя по твоему поведению твое основное дело тут - вахтерство. Ну а мы не на работе, а ты нам не начальник.
А я на тебя, и надеюсь не только я, потому что ты срешь в треде своим вечным недовольством на все вообще, и мешаешь обсуждать напрямую релейтед темы. Так и представляю этого старого душного пердячего деда-вахтера, которому даже обсуждение гдскрипта и его подводных камней неподходящая тема. Что дальше, нельзя чейнджлог годота обсуждать? Приходить к тебе за справочкой о каждой теме? Хртьфу.
>я сюда по делу и заходил
Не, дед, судя по твоему поведению твое основное дело тут - вахтерство. Ну а мы не на работе, а ты нам не начальник.
4 Кб, 365x28Короче такой вопрос. Вот у меня есть этот шоу пиктуре. И там есть дефолтные вот эти вот 0, 0, 640, 520, true. И мне нужно только в конце передать не true, а false, а всё остальное по дефолту (0, 0, 640, 520). Я могу это как-то сделать не перечисляя вся остальное?
>>9580
В Питоне это делается с помощью named arguments, типа:
Объявление как:
func foo(a=640, b=520, c=true)
И вызов как:
foo(c=false)
Но гдскрипт в такое не умеет. Так что прописывай все.
В Питоне это делается с помощью named arguments, типа:
Объявление как:
func foo(a=640, b=520, c=true)
И вызов как:
foo(c=false)
Но гдскрипт в такое не умеет. Так что прописывай все.
>>9585
Ммм. Пиздося. Спасибо за инфу.
Ммм. Пиздося. Спасибо за инфу.
>>9580
Параметры по умолчанию.
func show_picture(a: bool, b: int = 0, c: int = 0) и так далее. Хотя точно не помню насколько хорошо гдскрипт в это умеет.
Передача дтошками.
class ShowPictureParams:
var a: bool
var b: int
var c: int
...
func show_picture(params: ShowPictureParams):
...
var params: ShowPictureParams.new()
params.a = true
show_picture(params)
Ну и методы-обертки.
func: show_picture_default(a: bool): show_picture(boo, 0, 0, 640, 520, false)
Параметры по умолчанию.
func show_picture(a: bool, b: int = 0, c: int = 0) и так далее. Хотя точно не помню насколько хорошо гдскрипт в это умеет.
Передача дтошками.
class ShowPictureParams:
var a: bool
var b: int
var c: int
...
func show_picture(params: ShowPictureParams):
...
var params: ShowPictureParams.new()
params.a = true
show_picture(params)
Ну и методы-обертки.
func: show_picture_default(a: bool): show_picture(boo, 0, 0, 640, 520, false)
>>9575
Я тут практически ридонли, так что кляузничай.
Это тематика, зачем флудить в тематике? Ну подыми отдельный тред со своими замерами свитчей (которые возможно разворачиваются в if...else во время интерпретации), скинь ссылку на движкосрач, собери компашку из хрюнити и возмущайтесь вместе.
Там же непочатый край, вызов функций не бесплатный, а если не указывать типы то ваще грустно. А потом окажется, что работа с полями объектов дороже работы с глобальными переменными.
Сколько же открытий ждет нас. а... нет... каникулы кончаются
>А я на тебя, и надеюсь не только я,
Я тут практически ридонли, так что кляузничай.
Это тематика, зачем флудить в тематике? Ну подыми отдельный тред со своими замерами свитчей (которые возможно разворачиваются в if...else во время интерпретации), скинь ссылку на движкосрач, собери компашку из хрюнити и возмущайтесь вместе.
Там же непочатый край, вызов функций не бесплатный, а если не указывать типы то ваще грустно. А потом окажется, что работа с полями объектов дороже работы с глобальными переменными.
Сколько же открытий ждет нас. а... нет... каникулы кончаются
>>9594
Репортнул тебя за превращение ИТТ в личный нытик-тред. И, надеюсь, не я один.
Репортнул тебя за превращение ИТТ в личный нытик-тред. И, надеюсь, не я один.
>>9580
Релейтед обсуждения на гитхабе:
https://github.com/godotengine/godot/issues/6866
https://github.com/godotengine/godot-proposals/issues/902
TL;DR: много технических сложностей, из-за которых данную фичу реализовывать не планируется. Если реализуют, то это ударит по производительности.
Заголовок функции ты не показал, зову экстрасенса:
Эти аргументы можно сжать так:
Можно пойти дальше:
Дальше тебе остаётся определить, какие параметры используются в среднем чаще других, и сортировать:
Либо можно пойти ещё дальше:
Но в таком случае подсказки в коде лишаешься.
По производительности костыль через Dictionary, естественно, должен быть немного медленнее, чем нормальный вызов с аргументами. Но этот костыль предназначен для твоего удобства, верно? Т.е. твоё удобство как разработчика компенсирует нехватку производительности. Зато в остальных местах всё работает быстрее, чем в каком-то там питоне.
Алсо, рекомендую не делать много аргументов в собственных функциях. Скорее всего тебе нужны свойства класса, а не аргументы функции, пример:
По этой причине, например, у CharacterBody теперь move_and_slide() вообще без аргументов - всё, что передавалось аргументами, настраивается теперь свойствами самого класса. Ибо так логичнее.
Релейтед обсуждения на гитхабе:
https://github.com/godotengine/godot/issues/6866
https://github.com/godotengine/godot-proposals/issues/902
TL;DR: много технических сложностей, из-за которых данную фичу реализовывать не планируется. Если реализуют, то это ударит по производительности.
Заголовок функции ты не показал, зову экстрасенса:
>func show_picture(p: ImageTexture, x: float, y: float, w: float, h: float, f: bool) -> void:
Эти аргументы можно сжать так:
>func show_picture(p: ImageTexture, at: Vector2, size: Vector2, f: bool) -> void:
Можно пойти дальше:
>func show_picture(p: ImageTexture, rect: Rect2, f: bool) -> void:
Дальше тебе остаётся определить, какие параметры используются в среднем чаще других, и сортировать:
>func show_picture(p: ImageTexture, f: bool = false, rect: Rect2 = Rect2(Vector2.ZERO, Vector2(640, 520))) -> void:
Либо можно пойти ещё дальше:
>func show_picture(p: ImageTexture, args := {}) -> void:
>_ var flag := args.get("flag", false)
>_ var rect := args.get("rect", Rect2(Vector2.ZERO, Vector2(640, 520)))
>_ # Или так:
>_ var at := args.get("at", Vector2.ZERO)
>_ var size := args.get("size", Vector2(640, 520))
Но в таком случае подсказки в коде лишаешься.
По производительности костыль через Dictionary, естественно, должен быть немного медленнее, чем нормальный вызов с аргументами. Но этот костыль предназначен для твоего удобства, верно? Т.е. твоё удобство как разработчика компенсирует нехватку производительности. Зато в остальных местах всё работает быстрее, чем в каком-то там питоне.
Алсо, рекомендую не делать много аргументов в собственных функциях. Скорее всего тебе нужны свойства класса, а не аргументы функции, пример:
>class_name InventoryItem extends Control
>@export var icon: ImageTexture
>@export var rect := Rect2(Vector2.ZERO, Vector2(640, 520))
>@export var flag := false
>func show_item() -> void: ...
По этой причине, например, у CharacterBody теперь move_and_slide() вообще без аргументов - всё, что передавалось аргументами, настраивается теперь свойствами самого класса. Ибо так логичнее.
>>9580
Релейтед обсуждения на гитхабе:
https://github.com/godotengine/godot/issues/6866
https://github.com/godotengine/godot-proposals/issues/902
TL;DR: много технических сложностей, из-за которых данную фичу реализовывать не планируется. Если реализуют, то это ударит по производительности.
Заголовок функции ты не показал, зову экстрасенса:
Эти аргументы можно сжать так:
Можно пойти дальше:
Дальше тебе остаётся определить, какие параметры используются в среднем чаще других, и сортировать:
Либо можно пойти ещё дальше:
Но в таком случае подсказки в коде лишаешься.
По производительности костыль через Dictionary, естественно, должен быть немного медленнее, чем нормальный вызов с аргументами. Но этот костыль предназначен для твоего удобства, верно? Т.е. твоё удобство как разработчика компенсирует нехватку производительности. Зато в остальных местах всё работает быстрее, чем в каком-то там питоне.
Алсо, рекомендую не делать много аргументов в собственных функциях. Скорее всего тебе нужны свойства класса, а не аргументы функции, пример:
По этой причине, например, у CharacterBody теперь move_and_slide() вообще без аргументов - всё, что передавалось аргументами, настраивается теперь свойствами самого класса. Ибо так логичнее.
Релейтед обсуждения на гитхабе:
https://github.com/godotengine/godot/issues/6866
https://github.com/godotengine/godot-proposals/issues/902
TL;DR: много технических сложностей, из-за которых данную фичу реализовывать не планируется. Если реализуют, то это ударит по производительности.
Заголовок функции ты не показал, зову экстрасенса:
>func show_picture(p: ImageTexture, x: float, y: float, w: float, h: float, f: bool) -> void:
Эти аргументы можно сжать так:
>func show_picture(p: ImageTexture, at: Vector2, size: Vector2, f: bool) -> void:
Можно пойти дальше:
>func show_picture(p: ImageTexture, rect: Rect2, f: bool) -> void:
Дальше тебе остаётся определить, какие параметры используются в среднем чаще других, и сортировать:
>func show_picture(p: ImageTexture, f: bool = false, rect: Rect2 = Rect2(Vector2.ZERO, Vector2(640, 520))) -> void:
Либо можно пойти ещё дальше:
>func show_picture(p: ImageTexture, args := {}) -> void:
>_ var flag := args.get("flag", false)
>_ var rect := args.get("rect", Rect2(Vector2.ZERO, Vector2(640, 520)))
>_ # Или так:
>_ var at := args.get("at", Vector2.ZERO)
>_ var size := args.get("size", Vector2(640, 520))
Но в таком случае подсказки в коде лишаешься.
По производительности костыль через Dictionary, естественно, должен быть немного медленнее, чем нормальный вызов с аргументами. Но этот костыль предназначен для твоего удобства, верно? Т.е. твоё удобство как разработчика компенсирует нехватку производительности. Зато в остальных местах всё работает быстрее, чем в каком-то там питоне.
Алсо, рекомендую не делать много аргументов в собственных функциях. Скорее всего тебе нужны свойства класса, а не аргументы функции, пример:
>class_name InventoryItem extends Control
>@export var icon: ImageTexture
>@export var rect := Rect2(Vector2.ZERO, Vector2(640, 520))
>@export var flag := false
>func show_item() -> void: ...
По этой причине, например, у CharacterBody теперь move_and_slide() вообще без аргументов - всё, что передавалось аргументами, настраивается теперь свойствами самого класса. Ибо так логичнее.
>>9602
>>9580
А, точно, можно создать вложенный класс, тогда сохраняются подсказки, правда, печатать дольше:
Обращение будет, правда, посложнее Dictionary:
Тот же пример через Dictionary:
Пример через свойства:
Выбирайте на свой вкус.
Очень жаль, что в GDScript нет оператора "with"...
>>9580
А, точно, можно создать вложенный класс, тогда сохраняются подсказки, правда, печатать дольше:
>class_name InventoryItem extends Control
>class SPArgs # подразумевается extends RefCounted
>_ var icon: ImageTexture = null
>_ var rect := Rect2(Vector2.ZERO, Vector2(640, 520))
>_ var flag := false
>_ func _init(i: ImageTexture) -> void:
>_ _ icon = i
>func show_picture(args := SPArgs.new()) -> void: ...
Обращение будет, правда, посложнее Dictionary:
>var args := InventoryItem.SPArgs.new(image)
>args.flag = true
>item.show_picture(args)
Тот же пример через Dictionary:
>item.show_picture(image, { flag = true })
Пример через свойства:
>item.icon = image
>item.flag = true
>item.show_item()
Выбирайте на свой вкус.
Очень жаль, что в GDScript нет оператора "with"...
>>9568
Нет, хорошие игры с интересной концепцией тоже опускаются на дно Стима, и там и остаются. Или, по крайней мере, эти игры ничем не хуже других, но не добрались до топа популярных.
Поэтому, если ищите мотивацию для разработки игр, можете сразу забыть о популярности игры. Если вы не популярный (видео)блоггер или нет бюджета на маркетинг, игра вряд ли станет популярной даже с достаточно большим бюджетом на разработку.
>>9562
А что такого-то, если это касается GDScript?
Раньше тут было больше узнаваемых анонов, но все, к сожалению, разбежались. Или это ты их репортил? Постите о разработке своих игр на Godot почаще, а то выглядит так, будто мы тут только код обсуждаем.
Тогда какое тебе дело до его постов?
>>9575
Ты его с кем-то путаешь, наверное. Это не он. Это я недоволен всеми, всем и всюду. А он кто-то другой.
>>9594
Не нужен отдельный тред. Он тут несколько тредов сидит уже, насколько я понимаю. Обычно постит интересные конструкции в коде на GDScript. Чем его производительность не устроила - не знаю, но сам вопрос оптимизации кода смысл для треда имеет.
>Значит концепция/реализация говно
Нет, хорошие игры с интересной концепцией тоже опускаются на дно Стима, и там и остаются. Или, по крайней мере, эти игры ничем не хуже других, но не добрались до топа популярных.
Поэтому, если ищите мотивацию для разработки игр, можете сразу забыть о популярности игры. Если вы не популярный (видео)блоггер или нет бюджета на маркетинг, игра вряд ли станет популярной даже с достаточно большим бюджетом на разработку.
>>9562
>Чел тупо страдает фигней
А что такого-то, если это касается GDScript?
>и вниманиелядствует в треде.
Раньше тут было больше узнаваемых анонов, но все, к сожалению, разбежались. Или это ты их репортил? Постите о разработке своих игр на Godot почаще, а то выглядит так, будто мы тут только код обсуждаем.
>я сюда по делу и заходил
Тогда какое тебе дело до его постов?
>>9575
>своим вечным недовольством на все вообще
Ты его с кем-то путаешь, наверное. Это не он. Это я недоволен всеми, всем и всюду. А он кто-то другой.
>>9594
>отдельный тред со своими замерами свитчей
Не нужен отдельный тред. Он тут несколько тредов сидит уже, насколько я понимаю. Обычно постит интересные конструкции в коде на GDScript. Чем его производительность не устроила - не знаю, но сам вопрос оптимизации кода смысл для треда имеет.
Где обсуждать скриптовый язык годота, если не в треде годота? Ща прибежит то чмо с репортами и скажет, что в /пр.
>>9635
Не раскачивай лодку.
Это тред любви и взаимопомощи.
>>9633
1. Интерактивный туториал по GDScript для нубов:
https://www.gdquest.com/learn-to-code-from-zero/
2. Официальная документация для продолжающих:
https://docs.godotengine.org/en/stable/tutorials/scripting/index.html
3. Некоторые крупные LLM могут ответить на многие программисткие вопросы более-менее хорошо, но конкретно в GDScript сильно заблуждаются. Лучше спрашивать теоретические вопросы, а не код. Дальше следуете в поисковик, далее Wikipedia, StackOverflow... Иногда что-то полезное бывает на Reddit, YouTube.
Главный практический навык кодера - умение искать необходимую информацию в интернете, желательно - на английском языке (всё основное именно на нём).
Я вот прокачал навык гуглинга за счёт кодинга...
Если планируешь публиковаться и просить деньги - желательно не использовать копирайченные ассеты. Используй цветные кубы/квадратики вместо них для прототипов, иначе в будущем забудешь удалить и ВНЕЗАПНО игру удалят по DMCA от кого-нибудь. Да и нарисовать стильный программер-арт не так сложно.
Про геймдизайн не забывай - он важнее кода и арта.
>Ща прибежит
Не раскачивай лодку.
Это тред любви и взаимопомощи.
>>9633
>Как вкатиться в кодинг?
1. Интерактивный туториал по GDScript для нубов:
https://www.gdquest.com/learn-to-code-from-zero/
2. Официальная документация для продолжающих:
https://docs.godotengine.org/en/stable/tutorials/scripting/index.html
3. Некоторые крупные LLM могут ответить на многие программисткие вопросы более-менее хорошо, но конкретно в GDScript сильно заблуждаются. Лучше спрашивать теоретические вопросы, а не код. Дальше следуете в поисковик, далее Wikipedia, StackOverflow... Иногда что-то полезное бывает на Reddit, YouTube.
Главный практический навык кодера - умение искать необходимую информацию в интернете, желательно - на английском языке (всё основное именно на нём).
Я вот прокачал навык гуглинга за счёт кодинга...
>Ассеты то и спиздить можно
Если планируешь публиковаться и просить деньги - желательно не использовать копирайченные ассеты. Используй цветные кубы/квадратики вместо них для прототипов, иначе в будущем забудешь удалить и ВНЕЗАПНО игру удалят по DMCA от кого-нибудь. Да и нарисовать стильный программер-арт не так сложно.
>как их работать заставить
Про геймдизайн не забывай - он важнее кода и арта.
>>9638
Респект.
Так а если чел сам пишет, что можно юзать в коммерческих проектах или это такая обманка хитрая?
Респект.
>Если планируешь публиковаться и просить деньги - желательно не использовать копирайченные ассеты. Используй цветные кубы/квадратики вместо них для прототипов, иначе в будущем забудешь удалить и ВНЕЗАПНО игру удалят по DMCA от кого-нибудь.
Так а если чел сам пишет, что можно юзать в коммерческих проектах или это такая обманка хитрая?
>>9639
Не обманка. Просто всегда надо смотреть лицензии ассетов. СС0 безопасно в любом виде в любом проекте, даже без указания авторства ассетов - сам под СС0 на итче выкладываю. СС-BY уже требует указания авторства, тут мутнее и хватает тонких моментов - ты авторство укажешь, а какой-нибудь мелкостример, играющий твою игру не укажет, и ему страйк прилетит от автоматизированной системы ютуба/твича, особенно это музыки касается.
Не обманка. Просто всегда надо смотреть лицензии ассетов. СС0 безопасно в любом виде в любом проекте, даже без указания авторства ассетов - сам под СС0 на итче выкладываю. СС-BY уже требует указания авторства, тут мутнее и хватает тонких моментов - ты авторство укажешь, а какой-нибудь мелкостример, играющий твою игру не укажет, и ему страйк прилетит от автоматизированной системы ютуба/твича, особенно это музыки касается.
>>9640
А, понял принял.
А, понял принял.
>>9639
Тогда у ассета свободная лицензия, чаще всего это вариант "CC". Скорее всего ты обязан в титрах игры обозначить, что используешь его ассет, добавить (не обязательно кликабельную) ссылку на его страницу. "Воровства" тут нет, "воровство" - это когда, скажем, извлекают ассет из одной игры, вставляя в другую, скачивают платные ассеты бесплатно с торрентов, нарушают условия лицензии на ассет и т.д.
Подробнее о самой популярной лицензии на ассеты:
https://en.wikipedia.org/wiki/Creative_Commons_license
Вряд ли. Большинство просто выкладывают своё творчество, надеясь стать популярнее, если их имя засветится в популярной игре. Но, в теории, можно провернуть манёвр, если удалить все упоминания свободной лицензии из интернета... Поэтому имеет смысл сохранять копию сайта автора в формате, который может иметь вес в суде (тут я не спец).
Главное не воруй у больших игроков (Sony, Nintendo, Rockstar, Hadbro и многие другие, кому не насрать). С рандомным Васяном из Нижнего Пердюйска скорее договоришься о компенсации без суда...
>>9640
Лол, не всё так просто. Не в каждой стране автору позволено выкладывать свой контент в публичное достояние до своей смерти + сколько-то лет.
Это только если музыка публиковалась каким-то музыкальным лейблом и зарегистрирована в этой автоматической системе. Нужно смотреть источник.
Ещё полезно почитать про "патентный троллинг" - в геймдеве некоторые игровые механики оч жёстко запатентованы. Стрелочку рисовать на экране стало разрешено всего несколько лет назад, например. И мини-игры на загрузочном экране делать нельзя по причине какого-то патента, а не из-за лени разрабов.
>чел сам пишет, что можно юзать в коммерческих
Тогда у ассета свободная лицензия, чаще всего это вариант "CC". Скорее всего ты обязан в титрах игры обозначить, что используешь его ассет, добавить (не обязательно кликабельную) ссылку на его страницу. "Воровства" тут нет, "воровство" - это когда, скажем, извлекают ассет из одной игры, вставляя в другую, скачивают платные ассеты бесплатно с торрентов, нарушают условия лицензии на ассет и т.д.
Подробнее о самой популярной лицензии на ассеты:
https://en.wikipedia.org/wiki/Creative_Commons_license
>или это такая обманка хитрая?
Вряд ли. Большинство просто выкладывают своё творчество, надеясь стать популярнее, если их имя засветится в популярной игре. Но, в теории, можно провернуть манёвр, если удалить все упоминания свободной лицензии из интернета... Поэтому имеет смысл сохранять копию сайта автора в формате, который может иметь вес в суде (тут я не спец).
Главное не воруй у больших игроков (Sony, Nintendo, Rockstar, Hadbro и многие другие, кому не насрать). С рандомным Васяном из Нижнего Пердюйска скорее договоришься о компенсации без суда...
>>9640
>СС0 безопасно в любом виде
Лол, не всё так просто. Не в каждой стране автору позволено выкладывать свой контент в публичное достояние до своей смерти + сколько-то лет.
>страйк прилетит от автоматизированной системы
Это только если музыка публиковалась каким-то музыкальным лейблом и зарегистрирована в этой автоматической системе. Нужно смотреть источник.
Ещё полезно почитать про "патентный троллинг" - в геймдеве некоторые игровые механики оч жёстко запатентованы. Стрелочку рисовать на экране стало разрешено всего несколько лет назад, например. И мини-игры на загрузочном экране делать нельзя по причине какого-то патента, а не из-за лени разрабов.
>>9642
А, тот патент в 2015 просрочился... Значит, можно.
Значит, это реально разработчики тупо ленятся.
Не ленитесь. Делайте игры на экран загрузки.
>мини-игры на загрузочном экране делать нельзя
А, тот патент в 2015 просрочился... Значит, можно.
Значит, это реально разработчики тупо ленятся.
Не ленитесь. Делайте игры на экран загрузки.
>>9642
Какой же это сюр нахуй. А мысли то еще запатентовали?
>игровые механики оч жёстко запатентованы
Какой же это сюр нахуй. А мысли то еще запатентовали?
>>9648
Мысли - нет. А вот бросать шарик для призыва себе боевого питомца - это сразу иск в суд от Nintendo... Использовать питомца как глайдер тоже нельзя.
>А мысли то еще не запатентовали?
Мысли - нет. А вот бросать шарик для призыва себе боевого питомца - это сразу иск в суд от Nintendo... Использовать питомца как глайдер тоже нельзя.
>>9656
1. Удалил броски шарика - теперь тупо спавн рядом.
2. Удалил петы-глайдеры - пет даёт бонус глайдеру.
Что им придётся удалить дальше - покажет время.
Если не веришь, сам гугли.
>И че сделал палворлд
1. Удалил броски шарика - теперь тупо спавн рядом.
2. Удалил петы-глайдеры - пет даёт бонус глайдеру.
Что им придётся удалить дальше - покажет время.
Если не веришь, сам гугли.
>>9657
Несколько месяцев назад играл. Не обратил внимание, что шарик не бросаю для призыва. А глайдер ваще не помню, летал на пале. Ну мб, просто действительно в глаза ебался, типа не важная мне деталь. А захват шариком они не патентовали выходит? И все остальное, что полностью спизжено с покемонов?
Несколько месяцев назад играл. Не обратил внимание, что шарик не бросаю для призыва. А глайдер ваще не помню, летал на пале. Ну мб, просто действительно в глаза ебался, типа не важная мне деталь. А захват шариком они не патентовали выходит? И все остальное, что полностью спизжено с покемонов?
Кто делает 3D игру с монитором >60 Гц, подскажите.
Вот есть Camera3D и RayCast3D. По идее, рейкаст обновляется с частотой физики, 60 Гц по умолчанию, однако, камеру предлагается вращать в _process() с частотой монитора. Как это по-хорошему решается? Необходимо плавное вращение и детект коллизий одновременно - с разными частотами обновлений.
>>9659
Там всё очень сложно. Изначально Nintendo вообще наехала без патентов, патенты зарегистрировали в процессе судебных разбирательств. Как это у них получается - непонятно, но Pocketpair им уступает.
Может, причина в том, что обе компании в Японии - кажется, это сильно упрощает судебный процесс. А Nintendo любит отжимать бабки у конкурентов...
Вот есть Camera3D и RayCast3D. По идее, рейкаст обновляется с частотой физики, 60 Гц по умолчанию, однако, камеру предлагается вращать в _process() с частотой монитора. Как это по-хорошему решается? Необходимо плавное вращение и детект коллизий одновременно - с разными частотами обновлений.
>>9659
Там всё очень сложно. Изначально Nintendo вообще наехала без патентов, патенты зарегистрировали в процессе судебных разбирательств. Как это у них получается - непонятно, но Pocketpair им уступает.
Может, причина в том, что обе компании в Японии - кажется, это сильно упрощает судебный процесс. А Nintendo любит отжимать бабки у конкурентов...
>>9662
Если я правильно понял, то тебе нужна интерполяция. Глянь вот этот видос
https://youtu.be/zfIuaRzNti4?si=UX141b_swfG3Be9w
Если я правильно понял, то тебе нужна интерполяция. Глянь вот этот видос
https://youtu.be/zfIuaRzNti4?si=UX141b_swfG3Be9w
Что такое CSRF check failed? Нет, я гуглил. Ничо не понял.
Я джва часа заполнял форму отправки ассета на ассетлиб, и вот наконец всё готово, нажимаю отправку и получаю сабж. Вся форма сбросилась, всё что я там вписывал.
Я джва часа заполнял форму отправки ассета на ассетлиб, и вот наконец всё готово, нажимаю отправку и получаю сабж. Вся форма сбросилась, всё что я там вписывал.
>>9669
Вероятно кто-то сильно накосячил в духе начала нулевых, когда делал форму. Или что там у них. Пиши заново.
Вероятно кто-то сильно накосячил в духе начала нулевых, когда делал форму. Или что там у них. Пиши заново.
>>9669
Это крч секьюрити, которую браузеры подкручивают в последние годы. Запрещает отдавать/запрашивать некоторые ресурсы между не-https доменами. Браузер на такое может ругаться даже если ты на локалхосте что-то хостишь, например верстаешь банальный index.html и подгружаешь в нем локальный ресурс.
Возможно ты тупил с отправкой слишком долго и csrf токен истек, или, скорее всего, бекенд успели рестартнуть.
Это крч секьюрити, которую браузеры подкручивают в последние годы. Запрещает отдавать/запрашивать некоторые ресурсы между не-https доменами. Браузер на такое может ругаться даже если ты на локалхосте что-то хостишь, например верстаешь банальный index.html и подгружаешь в нем локальный ресурс.
Возможно ты тупил с отправкой слишком долго и csrf токен истек, или, скорее всего, бекенд успели рестартнуть.
51 Кб, 1024x768>>9669
Проще говоря - ты слоупок.
>The "CSRF check failed" error usually occurs when a security token is missing or invalid during a form submission, often due to expired sessions or cookies. To resolve this, try clearing your browser's cookies or using an incognito window.
Проще говоря - ты слоупок.
1 Кб, 50x43>>9669
На каждую форму (открытие страницы) заводится токен. У токена есть время. Это как капча на двачах, у которой тоже есть время жизни.
На каждую форму (открытие страницы) заводится токен. У токена есть время. Это как капча на двачах, у которой тоже есть время жизни.
Ебать знали бы вы, как приятно иметь хотя бы минимально успешную игру и фанатов. Я сейчас узнал что в моей игре, сделанной на годоте, кто-то нашел осмысленный сюжет. А его там нет, вообще, лол.
>>9662
Если проблемы не случилось а я предполагаю, что её не случилось, то просто забей. У тебя не только рейкаст вращается с частотой в 60 кадров, у тебя и детект колизий происходит с этой частотой, т.е. если ты хочешь получить детект коллизий с частотой камеры либо вращай камеру в physics_process либо увеличивай частоту физики.
Если проблемы не случилось а я предполагаю, что её не случилось, то просто забей. У тебя не только рейкаст вращается с частотой в 60 кадров, у тебя и детект колизий происходит с этой частотой, т.е. если ты хочешь получить детект коллизий с частотой камеры либо вращай камеру в physics_process либо увеличивай частоту физики.
>>9682
Представляю. Мне ваще приятно, если любую мою работу ценят, но поскольку я хуйло криворукое обычно получаю ведро говна.
Представляю. Мне ваще приятно, если любую мою работу ценят, но поскольку я хуйло криворукое обычно получаю ведро говна.
>>9668
Чел создаёт проблему двигая физический объект (персонажа) в _process и решаёт её, гениально
Чел создаёт проблему двигая физический объект (персонажа) в _process и решаёт её, гениально
>>9668
Проверил - вроде бы работает... Но _process() теперь вообще нельзя, только _physics_process().
Странное решение. Если двигать камеру в _physics_process(), движок сам всё интерполирует.
>>9688
С чего ты взял? Это не из категории преждевременных оптимизаций.
В том-то и дело, что камера вращается быстрее - из-за этого проблемы.
Теперь камера вращается в _physic_process() и интерполируется.
>нужна интерполяция
Проверил - вроде бы работает... Но _process() теперь вообще нельзя, только _physics_process().
>Глянь вот этот видос
Странное решение. Если двигать камеру в _physics_process(), движок сам всё интерполирует.
>>9688
>я предполагаю, что её не случилось
С чего ты взял? Это не из категории преждевременных оптимизаций.
>У тебя не только рейкаст вращается с частотой в 60 кадров
В том-то и дело, что камера вращается быстрее - из-за этого проблемы.
Теперь камера вращается в _physic_process() и интерполируется.
>>9692
Значит у тебя какая то странность с игрой если тебе надо успеть рейкастом поймать что то в промежутке между двух вызовов физического процесса.
Вообще есть механизм рейкаста из камеры, у неё вроде метод есть такой, скорее всего закроет твою проблему, а нода скорее всего делает это же самое но каждый физический тик, но это надо в исходники смотреть
>С чего ты взял? Это не из категории преждевременных оптимизаций.
>
Значит у тебя какая то странность с игрой если тебе надо успеть рейкастом поймать что то в промежутке между двух вызовов физического процесса.
Вообще есть механизм рейкаста из камеры, у неё вроде метод есть такой, скорее всего закроет твою проблему, а нода скорее всего делает это же самое но каждый физический тик, но это надо в исходники смотреть
40 Кб, 500x740>>9694
1. Вращаешь камеру мышкой.
2. Повернув камеру, жмёшь левую кнопку мыши.
3. Рейкаст запаздывает и выбирает не то, на что смотрит камера.
4. ???
5. РРРРЯЯЯЯ, ДА КАК ТАК-ТО, Я ВЫБИРАЮ, А ОНО НЕ ВЫБИРАЕТСЯ!
Тру стори.
Почему-то не работало. Или мне было лень...
1. Вращаешь камеру мышкой.
2. Повернув камеру, жмёшь левую кнопку мыши.
3. Рейкаст запаздывает и выбирает не то, на что смотрит камера.
4. ???
5. РРРРЯЯЯЯ, ДА КАК ТАК-ТО, Я ВЫБИРАЮ, А ОНО НЕ ВЫБИРАЕТСЯ!
Тру стори.
>inb4 трансформируй рейкаст перед кликом
Почему-то не работало. Или мне было лень...
>>9692
Физический процесс работает с фикс частотой в 60 тиков/сек. А камера должна вращаться с частотой fps - т.е. process.
Или я что-то не вкуриваю?
>Странное решение. Если двигать камеру в _physics_process(), движок сам всё интерполирует.
Физический процесс работает с фикс частотой в 60 тиков/сек. А камера должна вращаться с частотой fps - т.е. process.
Или я что-то не вкуриваю?
26 Кб, 590x590Не появилась ли в новых версиях возможность "проксировать" свойства нод? То есть, у меня есть сцена нпс, внутри нее аудионода, и из общей сцены уровня я хочу отредачить одно свойство этой аудионоды - сейчас мне надо либо вручную геттер/сеттер на ноде нпс делать, либо ПКМ->Edit children чтобы достать до аудионоды. Было бы круто просто ставить галку рядом с любым свойством любой ноды - "передать это свойство в scene root".
>>9704
В некотором смысле появилось, опосредованно. Ты можешь унаследовать свой скрипт от SceneTree и указать его в свойствах проекта. С этого момента у тебя будет твой кастомный майнлуп, в котором ты можешь прописать свои свойства, которые хочешь юзать на топлевеле, а затем, когда аудионода загрузилась, она делает
Ну и естественно в любом другом месте, где тебе нужен доступ к аудионоде, ты делаешь
Но есть один нюанс... Ехехе... И не один.
В некотором смысле появилось, опосредованно. Ты можешь унаследовать свой скрипт от SceneTree и указать его в свойствах проекта. С этого момента у тебя будет твой кастомный майнлуп, в котором ты можешь прописать свои свойства, которые хочешь юзать на топлевеле, а затем, когда аудионода загрузилась, она делает
> if get_tree() is MyZaLoop: get_tree().my_bga = self
Ну и естественно в любом другом месте, где тебе нужен доступ к аудионоде, ты делаешь
> if get_tree() is MyZaLoop and get_tree().my_bga is not null: get_tree().my_bga.volume += 5
Но есть один нюанс... Ехехе... И не один.
>>9697
Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
>>9709 >>9712
Задавай вопросы нормально: что ты пытаешься там реализовать и зачем, и что у тебя там не получается? Например, что за "типмиксинг" такой? Зачем нужен?
>>9704
Другого выбора нет. Главная нода сцены - это как бы интерфейс класса ООП, т.е. то, что взаимодействует с окружающими объектами. Ноды под главной нодой - скрытые детали имплементации класса, от которых существенно зависит работа объекта. Если ты жмёшь "editable children", ты нарушаешь инкапсуляцию в ООП. Создавая геттеры и сеттеры ты создаёшь интерфейс, независящий от имплементации класса - даже удалив конкретные ноды внутри сцены, интерфейс никак не изменяется, и, соответственно, сцена будет работать.
Если ты хочешь настраивать большое количество однотипных нод из одного места, то рекомендую воспользоваться ресурсами: если не делать их явно уникальными, они будут иметь одни параметры вне зависимости от того, где используются. Пример:
Сохраняешь 1 экземпляр audio_settings.tres где-то в файловой системе и вставляешь его в каждую ноду, требующую AudioSettings. Тогда изменения в файле отобразятся во всех нодах, использующих его. Даже в рантайме, если ты не использовал .dublicate().
Ещё можно использовать статические поля класса.
>>9713
Ты просто переизобрёл синглтон. Зачем? Если у тебя потребуется изменить что-то в синглтоне (например, расширить функциональность игры), то потребуется изменять все места, где у тебя к нему обращение...
С ресурсами получается более гибкий подход.
>камера должна вращаться с частотой fps
Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
>>9709 >>9712
Задавай вопросы нормально: что ты пытаешься там реализовать и зачем, и что у тебя там не получается? Например, что за "типмиксинг" такой? Зачем нужен?
>>9704
>либо вручную геттер/сеттер на ноде нпс делать, либо ПКМ->Edit children чтобы достать до аудионоды
Другого выбора нет. Главная нода сцены - это как бы интерфейс класса ООП, т.е. то, что взаимодействует с окружающими объектами. Ноды под главной нодой - скрытые детали имплементации класса, от которых существенно зависит работа объекта. Если ты жмёшь "editable children", ты нарушаешь инкапсуляцию в ООП. Создавая геттеры и сеттеры ты создаёшь интерфейс, независящий от имплементации класса - даже удалив конкретные ноды внутри сцены, интерфейс никак не изменяется, и, соответственно, сцена будет работать.
Если ты хочешь настраивать большое количество однотипных нод из одного места, то рекомендую воспользоваться ресурсами: если не делать их явно уникальными, они будут иметь одни параметры вне зависимости от того, где используются. Пример:
>@export var audio_settings: AudioSettings
>class_name AudioSettings extends Resource
>@export var volume: float
Сохраняешь 1 экземпляр audio_settings.tres где-то в файловой системе и вставляешь его в каждую ноду, требующую AudioSettings. Тогда изменения в файле отобразятся во всех нодах, использующих его. Даже в рантайме, если ты не использовал .dublicate().
Ещё можно использовать статические поля класса.
>>9713
Ты просто переизобрёл синглтон. Зачем? Если у тебя потребуется изменить что-то в синглтоне (например, расширить функциональность игры), то потребуется изменять все места, где у тебя к нему обращение...
С ресурсами получается более гибкий подход.
>>9697
Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
>>9709 >>9712
Задавай вопросы нормально: что ты пытаешься там реализовать и зачем, и что у тебя там не получается? Например, что за "типмиксинг" такой? Зачем нужен?
>>9704
Другого выбора нет. Главная нода сцены - это как бы интерфейс класса ООП, т.е. то, что взаимодействует с окружающими объектами. Ноды под главной нодой - скрытые детали имплементации класса, от которых существенно зависит работа объекта. Если ты жмёшь "editable children", ты нарушаешь инкапсуляцию в ООП. Создавая геттеры и сеттеры ты создаёшь интерфейс, независящий от имплементации класса - даже удалив конкретные ноды внутри сцены, интерфейс никак не изменяется, и, соответственно, сцена будет работать.
Если ты хочешь настраивать большое количество однотипных нод из одного места, то рекомендую воспользоваться ресурсами: если не делать их явно уникальными, они будут иметь одни параметры вне зависимости от того, где используются. Пример:
Сохраняешь 1 экземпляр audio_settings.tres где-то в файловой системе и вставляешь его в каждую ноду, требующую AudioSettings. Тогда изменения в файле отобразятся во всех нодах, использующих его. Даже в рантайме, если ты не использовал .dublicate().
Ещё можно использовать статические поля класса.
>>9713
Ты просто переизобрёл синглтон. Зачем? Если у тебя потребуется изменить что-то в синглтоне (например, расширить функциональность игры), то потребуется изменять все места, где у тебя к нему обращение...
С ресурсами получается более гибкий подход.
>камера должна вращаться с частотой fps
Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
>>9709 >>9712
Задавай вопросы нормально: что ты пытаешься там реализовать и зачем, и что у тебя там не получается? Например, что за "типмиксинг" такой? Зачем нужен?
>>9704
>либо вручную геттер/сеттер на ноде нпс делать, либо ПКМ->Edit children чтобы достать до аудионоды
Другого выбора нет. Главная нода сцены - это как бы интерфейс класса ООП, т.е. то, что взаимодействует с окружающими объектами. Ноды под главной нодой - скрытые детали имплементации класса, от которых существенно зависит работа объекта. Если ты жмёшь "editable children", ты нарушаешь инкапсуляцию в ООП. Создавая геттеры и сеттеры ты создаёшь интерфейс, независящий от имплементации класса - даже удалив конкретные ноды внутри сцены, интерфейс никак не изменяется, и, соответственно, сцена будет работать.
Если ты хочешь настраивать большое количество однотипных нод из одного места, то рекомендую воспользоваться ресурсами: если не делать их явно уникальными, они будут иметь одни параметры вне зависимости от того, где используются. Пример:
>@export var audio_settings: AudioSettings
>class_name AudioSettings extends Resource
>@export var volume: float
Сохраняешь 1 экземпляр audio_settings.tres где-то в файловой системе и вставляешь его в каждую ноду, требующую AudioSettings. Тогда изменения в файле отобразятся во всех нодах, использующих его. Даже в рантайме, если ты не использовал .dublicate().
Ещё можно использовать статические поля класса.
>>9713
Ты просто переизобрёл синглтон. Зачем? Если у тебя потребуется изменить что-то в синглтоне (например, расширить функциональность игры), то потребуется изменять все места, где у тебя к нему обращение...
С ресурсами получается более гибкий подход.
>>9722
Я честно говоря не очень понял. И вообще не врубаюсь зачем в движках сделано так, чтобы это все можно было по разному настроить. По моему единственная рабочая схема такая:
1) Камера двигается плавно в зависимости от FPS
2) Физический тикрейт работает 1/60
3) Как-то все работает и вместе и хорошо куда нажать, чтобы так было
И почему везде не настроено так по умолчанию? Кому блять может понадобится по другому и зачем?
>Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
Я честно говоря не очень понял. И вообще не врубаюсь зачем в движках сделано так, чтобы это все можно было по разному настроить. По моему единственная рабочая схема такая:
1) Камера двигается плавно в зависимости от FPS
2) Физический тикрейт работает 1/60
3) Как-то все работает и вместе и хорошо куда нажать, чтобы так было
И почему везде не настроено так по умолчанию? Кому блять может понадобится по другому и зачем?
>>9724
Здесь всё подробно описано:
https://docs.godotengine.org/en/stable/tutorials/physics/interpolation/index.html
Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц? И наоборот, у некоторых игр физика >200 Гц. В Godot по умолчанию установлено 60 Гц просто потому что это наиболее популярная частота обновления монитора.
С мониторами тоже не всё так просто. Давно уже существуют мониторы >120 Гц, но разница на глаз ощущается даже между 60 и 75 Гц, а 75 Гц уже очень древний стандарт в мониторах. Если у тебя физика зафиксирована на 60 Гц без интерполяции, на всех мониторах >60 Гц физ. объекты будут дёргаться.
Алсо, совет: если ты где-то в коде на мышь хочешь реагировать, накапливай смещение мыши в input и сбрасывай накопленное в process/physics_process. Поскольку у геймерских проводных мышей >2000 Гц обновление, даже у офисных беспроводных >125 Гц - ошибки с плавающей точкой и лишние вычисления...
Избавляет от лишней головной боли.
Здесь всё подробно описано:
https://docs.godotengine.org/en/stable/tutorials/physics/interpolation/index.html
>Физический тикрейт работает 1/60
>может понадобится по другому и зачем?
Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц? И наоборот, у некоторых игр физика >200 Гц. В Godot по умолчанию установлено 60 Гц просто потому что это наиболее популярная частота обновления монитора.
С мониторами тоже не всё так просто. Давно уже существуют мониторы >120 Гц, но разница на глаз ощущается даже между 60 и 75 Гц, а 75 Гц уже очень древний стандарт в мониторах. Если у тебя физика зафиксирована на 60 Гц без интерполяции, на всех мониторах >60 Гц физ. объекты будут дёргаться.
Алсо, совет: если ты где-то в коде на мышь хочешь реагировать, накапливай смещение мыши в input и сбрасывай накопленное в process/physics_process. Поскольку у геймерских проводных мышей >2000 Гц обновление, даже у офисных беспроводных >125 Гц - ошибки с плавающей точкой и лишние вычисления...
>var mouse_movement: Vector2
>func _input(...): # вызывается 2000 раз в секунду
>_ if event is Mouse...:
>_ _ mouse_movement += event.relative
>func _process(...): # вызывается 60 раз в секунду
>_ react_on(mouse_movement)
>_ mouse_movement = Vector2.ZERO
Избавляет от лишней головной боли.
>>9725
Вот это годно с мышкой. Не знал.
Вот это годно с мышкой. Не знал.
>>9725
А, в движке есть вроде как аккумулятор событий (?):
https://docs.godotengine.org/en/stable/classes/class_inputevent.html#class-inputevent-method-accumulate
Правда, я его пока не использовал. Новая фича?..
>mouse_movement += event.relative
А, в движке есть вроде как аккумулятор событий (?):
https://docs.godotengine.org/en/stable/classes/class_inputevent.html#class-inputevent-method-accumulate
Правда, я его пока не использовал. Новая фича?..
>>9713
Мне не нравится твой смех, поэтому этим путем я не пойду.
Мне не нравится твой смех, поэтому этим путем я не пойду.
>>9725
Я правильно понимаю, что нужно:
1) Оставить физику на 60 Гц
2) Включить (?) интерполяцию
3) Вызывать все движения физ объектов в т.ч. камеры в physics_process
И все будет тип-топ и при 30 FPS, и при 60 FPS, и при 120 FPS?
Типа для производительности?
>Если у тебя физика зафиксирована на 60 Гц без интерполяции, на всех мониторах >60 Гц физ. объекты будут дёргаться.
Я правильно понимаю, что нужно:
1) Оставить физику на 60 Гц
2) Включить (?) интерполяцию
3) Вызывать все движения физ объектов в т.ч. камеры в physics_process
И все будет тип-топ и при 30 FPS, и при 60 FPS, и при 120 FPS?
>Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц?
Типа для производительности?
>>9725
Ну тип это не объясняет, почему интерполяция не включена по умолчанию. Тип, какая разница какой тик пер секонд у физики. Камера то все равно должна двигаться нормально
>Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц? И наоборот, у некоторых игр физика >200 Гц. В Godot по умолчанию установлено 60 Гц просто потому что это наиболее популярная частота обновления монитора.
Ну тип это не объясняет, почему интерполяция не включена по умолчанию. Тип, какая разница какой тик пер секонд у физики. Камера то все равно должна двигаться нормально
>>9731
Если ты меняешь позицию камеры без привязки к какому-либо физическому объекту, то тебе не нужна интерполяция, просто обновляй позицию камеры внутри _process и она отрендерится на следующем же визуальном фрейме. Но если ты например хочешь следить камерой за каким-то юнитом, то камера очевидно будет двигаться только при обновлении позиции этого юнита, т.е только при обновлении физики. И если у тебя физика обновляется раз в 1/60 секунды, то и камера будет залочена в 60 FPS, вот тут и нужна интерполяция.
Если ты меняешь позицию камеры без привязки к какому-либо физическому объекту, то тебе не нужна интерполяция, просто обновляй позицию камеры внутри _process и она отрендерится на следующем же визуальном фрейме. Но если ты например хочешь следить камерой за каким-то юнитом, то камера очевидно будет двигаться только при обновлении позиции этого юнита, т.е только при обновлении физики. И если у тебя физика обновляется раз в 1/60 секунды, то и камера будет залочена в 60 FPS, вот тут и нужна интерполяция.
>>9662
Детект коллизий чего с чем? Если твоей камеры с условными стенами, то ты получается хочешь сделать саму камеру физическим объектом и обновляться она будет только с частотой физики. Соответственно передвигаешь камеру внутри _physics_process и на каждом визуальном фрейме интерполируешь ее позицию чтобы визуально не лочить движение в 60 FPS, в чем проблема-то?
>Необходимо плавное вращение и детект коллизий одновременно - с разными частотами обновлений.
Детект коллизий чего с чем? Если твоей камеры с условными стенами, то ты получается хочешь сделать саму камеру физическим объектом и обновляться она будет только с частотой физики. Соответственно передвигаешь камеру внутри _physics_process и на каждом визуальном фрейме интерполируешь ее позицию чтобы визуально не лочить движение в 60 FPS, в чем проблема-то?
>>9733
Ну т.е. интерполяция имитирует обычное движение камеры, как внутри _process, но для камеры, которая внутри _physics_process. Т.е. по сути ее можно включать по умолчанию для всех проектов
Ну т.е. интерполяция имитирует обычное движение камеры, как внутри _process, но для камеры, которая внутри _physics_process. Т.е. по сути ее можно включать по умолчанию для всех проектов
>>9737
Интерполяция движения камеры нужна только в проектах, где сама камера - физический объект. Если как в моем примере, у тебя камера просто следует за каким-то физическим объектом, то там нужно интерполировать движение этого объекта, а не камеры.
Интерполяция движения камеры нужна только в проектах, где сама камера - физический объект. Если как в моем примере, у тебя камера просто следует за каким-то физическим объектом, то там нужно интерполировать движение этого объекта, а не камеры.
>>9738
Если камеры следует за каким-то физ объектом, а не просто перемещается по воздуху (хотя тут тоже вопросы к, например, мыши, как писал анон выше), то она двигается в зависимости от движения этого объекта. Все равно что камеру повесить на голову игрока в игре от первого лица. Не?
Если камеры следует за каким-то физ объектом, а не просто перемещается по воздуху (хотя тут тоже вопросы к, например, мыши, как писал анон выше), то она двигается в зависимости от движения этого объекта. Все равно что камеру повесить на голову игрока в игре от первого лица. Не?
>>9739
Ну, а объект без интерполяции его движения будет двигаться только при обновлении физики, т.е в 60 FPS по умолчанию.
>то она двигается в зависимости от движения этого объекта
Ну, а объект без интерполяции его движения будет двигаться только при обновлении физики, т.е в 60 FPS по умолчанию.
>>9729
Нужно смотреть, что нужно твоей игре. Как правило, слишком редкая симуляция пропускает коллизии; слишком частая симуляция впустую нагружает ЦПУ. Количество объектов и скорости движений влияют. Тримешам нужна точность выше, чем примитивам.
Да, по идее, но в некоторых случаях нужно какое-то собственное решение, например, в мультиплеере, в хардкорных играх на высокую реакцию игрока и т.п.
Да, разумеется. Это примерно как v-sync - чтобы не занимать компьютер лишними вычислениями.
>>9731
>>9737
Потому что:
1. Не всем подходит, добавляет инпут лаг.
2. Если у тебя 60 FPS + 60 TPS, то разницы нет.
3. Godot следит за тем, чтоб ты ничего не трогал вне _physics_process (warning отключается в настройках). Потому что тогда интерполяция просто ломается.
4. Телепортация объектов слегка усложняется.
Я ещё не полностью прочитал документацию...
>>9733
>>9738
Во-первых, в 99% игр камера следует за каким-либо физическим объектом плюс сама имеет коллизию, предотвращающую клипинг камеры "в текстуры". Исключением будут только некоторые стратегии, фиксированная камера, простые головоломки...
Во-вторых, Godot предупреждает (warning) обо всех трансформах в проекте; скажем, MultiMeshInstance необходимо обновлять в _physics_process, если вы включили интерполяцию физики в проекте, хотя в MultiMeshInstance в принципе отсутствует физика. Достаточно странно, но, наверное, причина есть...
>Оставить физику на 60 Гц
Нужно смотреть, что нужно твоей игре. Как правило, слишком редкая симуляция пропускает коллизии; слишком частая симуляция впустую нагружает ЦПУ. Количество объектов и скорости движений влияют. Тримешам нужна точность выше, чем примитивам.
>И все будет тип-топ
Да, по идее, но в некоторых случаях нужно какое-то собственное решение, например, в мультиплеере, в хардкорных играх на высокую реакцию игрока и т.п.
>для производительности?
Да, разумеется. Это примерно как v-sync - чтобы не занимать компьютер лишними вычислениями.
>>9731
>почему интерполяция не включена по умолчанию
>>9737
>включать по умолчанию для всех проектов
Потому что:
1. Не всем подходит, добавляет инпут лаг.
2. Если у тебя 60 FPS + 60 TPS, то разницы нет.
3. Godot следит за тем, чтоб ты ничего не трогал вне _physics_process (warning отключается в настройках). Потому что тогда интерполяция просто ломается.
4. Телепортация объектов слегка усложняется.
Я ещё не полностью прочитал документацию...
>>9733
>Но если ты например хочешь следить камерой
>>9738
>проектах, где сама камера - физический объект
Во-первых, в 99% игр камера следует за каким-либо физическим объектом плюс сама имеет коллизию, предотвращающую клипинг камеры "в текстуры". Исключением будут только некоторые стратегии, фиксированная камера, простые головоломки...
Во-вторых, Godot предупреждает (warning) обо всех трансформах в проекте; скажем, MultiMeshInstance необходимо обновлять в _physics_process, если вы включили интерполяцию физики в проекте, хотя в MultiMeshInstance в принципе отсутствует физика. Достаточно странно, но, наверное, причина есть...
>>9754
3d игра от первого лица. Так что 60 тиков вроде как раз
Понял, спасибо
Он там минимальный, вроде
Ну ща игры редко лочат на макс 60 fps.
В смысле телепортация? Там же просто меняется global_position
>Нужно смотреть, что нужно твоей игре. Как правило, слишком редкая симуляция пропускает коллизии; слишком частая симуляция впустую нагружает ЦПУ.
3d игра от первого лица. Так что 60 тиков вроде как раз
>Да, по идее
Понял, спасибо
> Не всем подходит, добавляет инпут лаг.
Он там минимальный, вроде
>Если у тебя 60 FPS + 60 TPS, то разницы нет.
Ну ща игры редко лочат на макс 60 fps.
>Телепортация объектов слегка усложняется
В смысле телепортация? Там же просто меняется global_position
>>9763
Есть разные "3д игры от первого лица": можно сделать спокойную бродилку с минимумом взаимодействий, а можно сделать скоростной паркур с кучей падающих обломков окружения... Вот второй игре рационально завысить тикрейт физики, а первой можно и снизить.
В самом прямом: когда движение отсутствует.
А движок пытается это изменение автоматически интерполировать, создавая видимое движение от предыдущей позиции к новой, которого нам здесь совершенно не нужно, т.к. мы телепортируемся.
Ты вообще ссылку выше по треду не открывал?
https://docs.godotengine.org/en/stable/tutorials/physics/interpolation/physics_interpolation_quick_start_guide.html
Конечно, это всего 1 вызов, но придётся держать постоянно в уме, когда что-то куда-то двигаешь.
>>9727
Вспомнил, где я его видел - в классе Input:
https://docs.godotengine.org/en/stable/classes/class_input.html#class-input-property-use-accumulated-input
Но странно, что
А я точно помню, что на 3.x у меня процессор сильно напрягался из-за движений мышки. Изменили что ли?
Хм... Судя по документации:
Input.use_accumulated_input существует с Godot 3.5.
InputEvent.accumulate() существует с Godot 3.1.
Значит, у меня проблемы были в 3.2-3.4...
>3d игра от первого лица
Есть разные "3д игры от первого лица": можно сделать спокойную бродилку с минимумом взаимодействий, а можно сделать скоростной паркур с кучей падающих обломков окружения... Вот второй игре рационально завысить тикрейт физики, а первой можно и снизить.
>В смысле телепортация?
В самом прямом: когда движение отсутствует.
>Там же просто меняется global_position
А движок пытается это изменение автоматически интерполировать, создавая видимое движение от предыдущей позиции к новой, которого нам здесь совершенно не нужно, т.к. мы телепортируемся.
Ты вообще ссылку выше по треду не открывал?
https://docs.godotengine.org/en/stable/tutorials/physics/interpolation/physics_interpolation_quick_start_guide.html
>Be sure to call Node.reset_physics_interpolation on nodes after you first position or teleport them, to prevent "streaking".
Конечно, это всего 1 вызов, но придётся держать постоянно в уме, когда что-то куда-то двигаешь.
>>9727
>вроде как аккумулятор событий
Вспомнил, где я его видел - в классе Input:
https://docs.godotengine.org/en/stable/classes/class_input.html#class-input-property-use-accumulated-input
Но странно, что
>Note: Input accumulation is enabled by default.
А я точно помню, что на 3.x у меня процессор сильно напрягался из-за движений мышки. Изменили что ли?
Хм... Судя по документации:
Input.use_accumulated_input существует с Godot 3.5.
InputEvent.accumulate() существует с Godot 3.1.
Значит, у меня проблемы были в 3.2-3.4...
>>9789
Речь идет именно про телепорт? Т.е. обычное перемещение, какой-нибудь apply impulse и т.п. не считается?
Открывал, но я не усваиваю гумозный язык документаций. Мне бы на пальцах объяснения...
>Конечно, это всего 1 вызов, но придётся держать постоянно в уме, когда что-то куда-то двигаешь.
Речь идет именно про телепорт? Т.е. обычное перемещение, какой-нибудь apply impulse и т.п. не считается?
>Ты вообще ссылку выше по треду не открывал?
Открывал, но я не усваиваю гумозный язык документаций. Мне бы на пальцах объяснения...
9 Кб, 784x592>>9791
>>9792
Ещё раз. Что такое интерполяция?
https://ru.wikipedia.org/wiki/Интерполяция
Вот у тебя, допустим, 60 фпс и 30 тпс:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2)
Как видишь, тут кадры 2 и 4 повторяют кадры 1 и 3 - поскольку физика работает в 2 раза медленнее. Мы увидим скачкообразное движение. Как исправить?
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1.5)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2.5)
Мы вычислили промежуточные значения 1.5 и 2.5 - получилось более плавное движение. Физические вычисления происходят в 1 и 3, но выходит плавное движение между этими кадрами, будто их больше.
Теперь представим, что мы телепортируемся:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 100)
Интерполяция найдёт промежуточное значение:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 50)
3 - 2 - vector2(1, 100)
Но нам это не нужно. Нам нужна точка 100, а не 50.
Поэтому при телепортации нужно сообщать движку: "интерполяция здесь не нужна, не интерполируй".
Так понятно?
У Godot одна из лучших документаций в айти.
>apply impulse и т.п. не считается?
>>9792
>после move_and_slide нужно вызывать
Ещё раз. Что такое интерполяция?
https://ru.wikipedia.org/wiki/Интерполяция
Вот у тебя, допустим, 60 фпс и 30 тпс:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2)
Как видишь, тут кадры 2 и 4 повторяют кадры 1 и 3 - поскольку физика работает в 2 раза медленнее. Мы увидим скачкообразное движение. Как исправить?
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1.5)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2.5)
Мы вычислили промежуточные значения 1.5 и 2.5 - получилось более плавное движение. Физические вычисления происходят в 1 и 3, но выходит плавное движение между этими кадрами, будто их больше.
Теперь представим, что мы телепортируемся:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 100)
Интерполяция найдёт промежуточное значение:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 50)
3 - 2 - vector2(1, 100)
Но нам это не нужно. Нам нужна точка 100, а не 50.
Поэтому при телепортации нужно сообщать движку: "интерполяция здесь не нужна, не интерполируй".
Так понятно?
>не усваиваю язык документаций
У Godot одна из лучших документаций в айти.
9 Кб, 784x592>>9791
>>9792
Ещё раз. Что такое интерполяция?
https://ru.wikipedia.org/wiki/Интерполяция
Вот у тебя, допустим, 60 фпс и 30 тпс:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2)
Как видишь, тут кадры 2 и 4 повторяют кадры 1 и 3 - поскольку физика работает в 2 раза медленнее. Мы увидим скачкообразное движение. Как исправить?
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1.5)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2.5)
Мы вычислили промежуточные значения 1.5 и 2.5 - получилось более плавное движение. Физические вычисления происходят в 1 и 3, но выходит плавное движение между этими кадрами, будто их больше.
Теперь представим, что мы телепортируемся:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 100)
Интерполяция найдёт промежуточное значение:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 50)
3 - 2 - vector2(1, 100)
Но нам это не нужно. Нам нужна точка 100, а не 50.
Поэтому при телепортации нужно сообщать движку: "интерполяция здесь не нужна, не интерполируй".
Так понятно?
У Godot одна из лучших документаций в айти.
>apply impulse и т.п. не считается?
>>9792
>после move_and_slide нужно вызывать
Ещё раз. Что такое интерполяция?
https://ru.wikipedia.org/wiki/Интерполяция
Вот у тебя, допустим, 60 фпс и 30 тпс:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2)
Как видишь, тут кадры 2 и 4 повторяют кадры 1 и 3 - поскольку физика работает в 2 раза медленнее. Мы увидим скачкообразное движение. Как исправить?
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1.5)
3 - 2 - vector2(1, 2)
4 - 2 - vector2(1, 2.5)
Мы вычислили промежуточные значения 1.5 и 2.5 - получилось более плавное движение. Физические вычисления происходят в 1 и 3, но выходит плавное движение между этими кадрами, будто их больше.
Теперь представим, что мы телепортируемся:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 1)
3 - 2 - vector2(1, 100)
Интерполяция найдёт промежуточное значение:
1 - 1 - vector2(1, 1)
2 - 1 - vector2(1, 50)
3 - 2 - vector2(1, 100)
Но нам это не нужно. Нам нужна точка 100, а не 50.
Поэтому при телепортации нужно сообщать движку: "интерполяция здесь не нужна, не интерполируй".
Так понятно?
>не усваиваю язык документаций
У Godot одна из лучших документаций в айти.
>>9722
А у меня встречный вопрос, зачем ты пишешь "типмиксинг"? Никто так не пишет, принято говорить либо "тайп миксин" либо "смешивание типов".
Код - лучшая документация ©
> Например, что за "типмиксинг" такой?
А у меня встречный вопрос, зачем ты пишешь "типмиксинг"? Никто так не пишет, принято говорить либо "тайп миксин" либо "смешивание типов".
> Зачем нужен?
Код - лучшая документация ©
10 Кб, 417x152Годот в такое умеет? Это новое требование гугл плея. У них есть инструкции только для Юнити и Анрила.
1,5 Мб, 1440x800Литературно
>>9832
1) Там один и тот же текст и для анрыла и для юнити
2) Это зависит не от самих движков, а от СДК андроида
3) Начиная с андроид АПИ версии 35 это будет по умолчанию
4) Для более ранних версий просто флаг компиляции, в Годот или добавят или напишут в статье как сделать, это в любом случае будет касаться в первую очередь шаблона экспорта, а не игры из редактора
1) Там один и тот же текст и для анрыла и для юнити
2) Это зависит не от самих движков, а от СДК андроида
3) Начиная с андроид АПИ версии 35 это будет по умолчанию
4) Для более ранних версий просто флаг компиляции, в Годот или добавят или напишут в статье как сделать, это в любом случае будет касаться в первую очередь шаблона экспорта, а не игры из редактора
45 Кб, 867x123>>9864
Я текбе больше скажу, ещё в мае в разрабатываемую 4.5 её добавили https://github.com/godotengine/godot/pull/106358
И в блог посте 4.5.бета1 писали https://godotengine.org/article/dev-snapshot-godot-4-5-beta-1/
Я текбе больше скажу, ещё в мае в разрабатываемую 4.5 её добавили https://github.com/godotengine/godot/pull/106358
И в блог посте 4.5.бета1 писали https://godotengine.org/article/dev-snapshot-godot-4-5-beta-1/