Шапка: https://hipolink.me/godothread
Предыдущий: >>1040245 (OP)
Архивный: >>1030839 (OP)
Что надо сделать, чтобы увековечиться в шапке тредю?
1. Быть интересным.
2. Напомнить о себе под бамплимит.
Ну или угнать тред, да.
Старый треллей, как-то уныло. Неужели нечем рисануться?
На случай важных переговоров с издателем вашей игры, если вдруг спросят, а как вы будете удалять элементы из головы массива? Отвечайте, что быстрее будет реверснуть и удалять с хвоста.
О, я после похожих тестов пришел к такому решению. У меня там обычно массив 10к, который я шринкаю до 1к раз в минуту, потом снова отращиваю его до 10к и снова шринкаю. Можешь тоже потестить и сравнить со своими бенчами.
a1 = a1.slice(a1.size() - items_to_stay, a1.size());
Но подозреваю что тест наврал по времени и-за кеширования.
>На случай важных переговоров с издателем вашей игры, если вдруг спросят, а как вы будете удалять элементы из головы массива?
>Отвечайте, что быстрее будет реверснуть и удалять с хвоста.
Неправильно.
Нужно отвечать "А тебя это ебать не должно"
Ты не поверил тому, что в документации написано?
Это проблема 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().
Задача Б: рефакторить архитектуру приложения.
a1.reverse()
a1.resize(items_to_stay)
a1.reverse()
>>1049061
А что, с помощью реверсов, ресайзов и слайсов сможем ли мы сделать быструю замену pop_at()?
>сделать быструю замену pop_at()
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>>1049067
>>1049061
>>1049039
>>1049034
Вы не шарите, надо делать так:
Минимальные требования
ОС: 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
> надо делать так:
Чтобы получить школоассетфлип, который запускается только на топовых печах, не обладая при этом графоном? Ну, допустим.
Не, тут только ситууационно что-то придумать можно, например тебе нужно из огромного массива размером N удалить много элементов например N/2.
Тогда можно вместо удаления делать их null, потом пробежаться по массиву двумя "курсорами" делая swap для null и не null значений, а когда один курсор дойдёт до конца массива сделать resize до позиции другого курсора.
Неплохо, реально неплохо. Потом реализую. А вот если мне в массиве нулль нужен, чем его заменить? Скажем, для указания на пустое место под удаление использовать класс-пустышку?
Он не это имел ввиду.
Я кстати без понятия что писать в системках, если когда-нибудь настанет день релиза. Возможно просто напишу конфиг моего компа. Похуй что он игру может хоть в 100 окон запустить.
Если вы бездомный - просто купите дом. Если вы бесхлебный - кушайте пирожные.
>А вот если мне в массиве нулль нужен, чем его заменить?
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
(не проверял, но смысл чтобы собрать новый массив из кусков старого, за счёт памяти)
Прекращайте преждевременные оптимизации. Они усложняют код и могут оказаться хуже самого тупого решения в будущем. Если вам нужно произвольные элементы массива удалять, и код на 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!")
> Прекращайте преждевременные оптимизации.
Игры делать штоле? Штоооа?
У тебя шарики за ролики? Ты чекаешь ссылки, что они ссылки и ведут себя как ссылки?
Я в силу глубины своей некомпетентности не понимаю, как покрывать тестами код) Эффект Даунинга-Крюгера))
Так. Ни хера себе. Это кто у нас такой охуенный клоун? Рядовой Шутник, а?
>a.fill([...].pick_random())
Ты осознаёшь, что pick_random() здесь будет вызвана единожды перед вызовом fill(), а дальше fill() сделает заполнение массива единственным значением?
Если хочешь заполнить массив случайным мусором:
>a2 = a1.map(func(e): return [...].pick_random())
Правда, на тесты скорости это никак не повлияет.
Не знаю C++, как лучше писать параллельный поток? Какими-то C++ классами или через Godot API? Хочу числодробилку параллельно Godot крутить, но чтоб излучала сигнал на сторону GDScript, когда закончит.
> Правда, на тесты скорости это никак не повлияет.
Фух. Не обосрался. Ну не сильно. Обсер был, но в штанину не попало. Активно работает смена белья.
> Подводные?
Будет крошиться на десктоп как скайрим с модами.
> Не знаю C++
> Не знаю как писать параллельный поток
Так ты выучи си++ чтобы его знать ДО ТОГО как придёшь в геймдев.
https://github.com/orgs/godotengine/projects/61/views/5
когда пропадут release blcokers и по возможности very bad и bad
Жаль тебя огорчать, анон, но такая игра уже скоро выйдет https://youtu.be/yG5vZqVVCn8?si=ZaXI1c8nYIbC2yXI
Ну вряд ли он будет заметен на фоне целой команды разработчиков, которые явно собираются поддерживать игру n лет. Тем более без четкой цели. Нужно менять концепцию и браться за что-то менее масштабное
Пчел этих игр про летающие острова вагон еще в нулевых был. Твой пойнт это пойнт уровня "в гта люди, всем перестать делать игры про людей".
Летающие острова самый обычный дженерик фентези сеттинг. Удобен для разработки и на этом все.
Я думал делать редалерт1 лайк когда-то, поискал как там что было сделано - там танки отрисовывались в 3д на самом деле и были воксельными. Ну я сделал вьюпорт в котором 3д танк рендерился и передавался в 2д мир, написао конвертор координат 2д<>3д.
А ютуб такой на ка посмотри что нормальные люди делают https://www.youtube.com/watch?v=aNHMwEOJxoY
И как-то уже и не хочется
Там у них буквально полноценная постройка кораблей и полеты на них. Как раз то, что пробовал делать тот анон. В общем ему нужно допиливать концепцию и придумывать уникальные фишки.
Как ты - разработчик-одиночка (как понимаю) планировал высчитывать баланс хотя бы 2-3 фракций? Зачем вы беретесь за настолько сложные проекты со сложными механиками? У вас вообще есть горизонт планирования?
В редалерте баланс был на уровне у одних так с уроном 10 в других танк с уроном 10
>полноценная постройка кораблей и полеты на них
Бля ты рофлишь если думаешь что это редкая идея
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
Нет. Идеи стоят примерно нихуя, они копируются, воруются, вдохновляются, модифицируются, и в каждой голове их бесконечное количество. Трясусны за идеи - нюфаженьки, геймдева не нюхавшие.
Зачем тебе индекс если у тебя задача добавлять удалять как в очереди (алгоритм). Если у тебя и то и то нужно, та надо уже матчасть учить.
>выучи си++ чтобы его знать
Я могу читать и понимать исходники движка и могу смастерить хэллоу ворлд на C++, но я не знаю всех подводных камней C++. Знаю только что это очень костыльный язык, которому почти каждый год баги пытаются пофиксить в стандарте, но делают хуже; используется только ради скорости, скрипя зубами.
Так что использовать - Godot, OpenMP или что-то совершенно другое? Насколько я понял, в C++ нет многопоточности как таковой, её костылят васяны, поэтому просто взять и написать код не получится.
>Будет крошиться на десктоп
Кстати, почему так?.. Разве в Godot не используется exception handling? Или это снизило бы скорость для внешних модулей? По-моему, если в модуле что-то сломается, основная программа не должна падать, обрабатывая возникающие исключения на ходу.
>>1049156
>Нейросеть напишет.
Что напишет? Код для OpenMP?
>я не знаю всех подводных камней C++
По подводным надо самому походить, иначе твое знание нихуя не стоит. Разве что в срачах в интернетике козырнешь, а на пратике сразу же еблом в подводный камень да с разбегу угодишь.
>в C++ нет многопоточности как таковой
Что ты имеешь ввиду? thread потерял?
>thread потерял?
Ааа, вон оно что.
<thread> вошёл в стандарт C++11.
А OpenMP рекомендовали в 2010.
Нейронка почему-то решила, что обсуждения на StackOverflow за 2010 год более авторитетные...
Спасибо за подсказку.
>Спасибо за подсказку.
1 секунда гугла c++ threads и первая же ссылка. Я просто удивился твоим словам, типа как это так ваще, вот и загуглил. Нейронки пожрали твой мозг. Да и мой тоже, часто из-за льющегося от них говна так же туплю.
Иногда еще полезно бывает читать условие задачи. А там значится обьект типа массив, который обязан иметь функционал индекса, при чём не его o(n) суррогат, а нормальный вычесляемый индекс. И матчасть тут не поможет, потому что нет матчасти которая бы смогла к связному списку прикрутить индекс без прикручивания дополнительного массива для индексов элементов списка.
>Если у тебя и то и то нужно, та надо
>>1049265
>массив, который обязан иметь индексы
https://en.wikipedia.org/wiki/Associative_array
https://docs.godotengine.org/en/stable/classes/class_dictionary.html
>при чём не его o(n) суррогат
У Dictionary O(1) сложность доступа.
Ты хочешь и булку съесть и на годот сесть. Ты уже описываешь две задачи (рандомный доступ и очередь), так сова на глобус не налезет.
Чаще всего вообще бывает, что ты обосрался в предметной области и решаешь задачу, которая поставлена ошибочно, под все остальное всегда хватает стандартных алгоритмов.
Каким боком key value к связному списку? Тебе не кажется что сама задача "удалить элемент массива с конца" для такой вещи как словарь просто лишена смысла по той простой причине что словарь не имеет возможности укладывать элементы сообразно последовательности их добавления в словарь. У словарей нет индекса в его "массивном" понимании. А любые попытки его прикрутить значительно замедлят процесс добавления/удаления обьекта в словарь при этом не дав значительных преимуществ перед стандартными массивами.
>>1049274
>Ты хочешь и булку съесть и на годот сесть. Ты уже описываешь две задачи
Лично я ничего не описываю, только отталкиваюсь от свойств требуемых обьектов, перечитай условие задачи еще раз. Вполне обоснованная задача, которая хоть и относительно редкая но всё же встречающаяся.
> Можешь тоже потестить и сравнить со своими бенчами.
Не могу понять, где я облажался? Ресайз должен быть быстрее, но всё равно быстрее оказывается поп_бэк. Я уже на микросекунды перешёл, чтобы хоть какие-то данные увидеть.
Посмотри свежим взглядом, где неправ?
> А любые попытки его прикрутить значительно замедлят процесс добавления/удаления обьекта в словарь при этом не дав значительных преимуществ перед стандартными массивами.
Вот кстати да. Полюбуйтесь.
>быстрее оказывается поп_бэк.
у тебя массив пустой и длины 0
Возможно в глаза ебусь, но не вижу размеров твоих тестовых массивов. Сделай там 10к элементов и обрежь их до 5к каждым методом.
Не пустой.
>>1049305
> Сделай там 10к элементов и обрежь их до 5к каждым методом.
Щас погодите. Всё это время (с предыдущего поста) выполняется кейс_1. Хочу дождаться конца.
Игры дейлайте
Для истории ходов, например. Или даже для истории фреймов. Вместо постоянного дрочения на добавление-удоление обрезаешь раз в минуту.
Ты не пробовал делать как в го - слайсы делятся на чанки энного размера? Допустим у тебя кейс с историей ходов и по логике очевидно, что потребуется удалять из нее по 1к элементов за раз или близко к этому, значит делишь всю эту благодать сразу на 1к чанки либо на чанки кратные 1к, офк потребуется обертка в виде своего типа над этим говном, в любом случае ты в процессе либо рубишь на корню целыми чанками разом, либо один последний чанк хирургически, либо все вместе, но профит в том, что не ворочаешь свой массив с миллиардом элементов ради этого целиком на каждый чих. Впрочем гдскрипт массивы может внутри так и работают, это тоже глянь.
>Не пустой.
На пик2
> var arr: Array
> ...
> ..
> arr.reverse()
>...
>>Не пустой.
Да, идея хорошая. Я поленился ее делать. Подрезать массив раз в минуту проще. По таймингам фреймов там незначительный микро-пропук, который теряется на фоне активной игры.
Если очень нужно, то это просто сделать. Но зачем?
>>1049308
Годотчую. Изобретают велосипед, экономят спички.
>>1049310
Решение очень простое: не хранить историю ходов.
>>1049360
>Я поленился ее делать.
А считать спички в велосипеде не поленился?
>По таймингам фреймов
>незначительный микро-пропук
Он там всегда, даже на пустом проекте...
Спасибо. Нашёл тупейшую ошибку копипастинга. Теперь всё заработало. И действительно, ресайз решает. Удаления по одному что в массиве, что в словаре примерно равны. Ну а pop_front() как и написано в документации - слоупок.
Нашёл ещё одну ошибку. Как-то не верилось, что словарь так быстр, и действительно, я наделел лишнего, из за чего удалялись те элементы, которые должны были остаться. После исправления всё встало на свои места.
Увеличь arr_size на порядок ещё
>>1049384
Не совсем честно замерять копирование одного и того же куска в никуда. делай дубликат потом отрезай.
> в никуда
В оперативку.
> делай дубликат потом отрезай
Слайс уже возвращает дубликат.
> Увеличь arr_size на порядок ещё
Готово! Ещё вопросы?
Как ты достал своими кодом. Иди матчасть по алгоритмам учи, это не твой ньюфаг бложик, хватит срать уже. всем насрать на твои юные исследования в программировании
Не слушай его. Мне не насрать. Потестируй ещё замену pop_at() на слайсы, раз уж у тебя готовый стенд напрограммирован.
Дыши глубже. Все это напрямую касается годота и игр на нем. Полезные интересные посты. Я из похожих постов узнал что switch в гдскрипте медленнее чем портянки if-else
Результаты неочень, есличесн, пришлось сильно уменьшить входной массив, и всё равно медленно. Слайс хорош когда выполняется один раз, а тут мы возвращаемся к циклам. Остальное хоть и быстрее слайсов-в-цикле, но тоже медленное.
>Дыши глубже.
Надеюсь тебе напихают репортов за флуд.
Нужно к школе готовиться, а не операторы свитч замерять. Вниманиелять.
Всё-таки 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-мерное пространство"
Конечно, в данном случае вопрос не в скорости, а лишь бы оно вообще работало...
>>1049402
Ты его поругал и тред умер на полдня. Доволен?
>>1049184
>вряд ли он будет заметен на фоне целой команды
Почему ты считаешь, что разработкой игр можно заниматься лишь ради заметности на фоне других? Большинство существующих игр никому не нужны, несмотря на уникальные концепции и хорошую реализацию. Даже от больших, дорогих студий. Они собирают ничтожные 10 тысяч отзывов и всё, пока условная Terraria побила миллион отзывов и растёт. Наиболее необычные игры вообще где-то на дне.
>Доволен?
Конечно доволен, это же сренькальщик залетный.
Делайте игры и обсуждайте делание игр.
Щас буду биндить Ada к GDExtension...
Кто нибудь делал мультиплеерные игры на годоте? Есть советы по архитектуре серверов?
Я не делал. Зато я делал синглплеерный пиксельный платформер.
Тут бывает какой-то фанатик, видимо делает что-то уровня киберкотлетской доты, аж пена изо рта идет на тему мультиплеера, особенно о том как сложно кнопки нажимать. Жди его, он занят тем, что делает синхронизации для синхронизаций. А я делал хуйни попроще только, что даже хуже, чем вообще ничего не делать.
Семён, ты? Ты зачем флудишь?
Как у тебя
>мультиплеерные игры на годоте
связано с
>советы по архитектуре серверов
в твоём понимании?
Движок даёт тебе базовые инструменты, описанные здесь:
https://docs.godotengine.org/en/stable/tutorials/networking/index.html
Остальное ты должен додумывать сам под требования своей игры.
Вообще я в годот тред залетел под какой-то истеричный срач о мультиплеере. Вот и запомнил шиза.
Любой может написать 3 поста с 3 разных браузеров и сделать 3 таких же скриншота.
Но только семён попытается доказать, что он не семён, запостив 3 скриншота подряд.
>>1049531
>Ок, подожду.
Я тебе уже ответил. Ты ничего о своей игре не сказал - какого совета ты ждёшь?
>Ты его поругал
Я еще на него накляузничал (надеюсь не только я).
Чел тупо страдает фигней и вниманиелядствует в треде. Я конечно понимаю, весело вкатываться в разработку и транслировать свои изыскания, но есть для этого бложики и одноклассники.
>Ты его поругал и тред умер на полдня. Доволен?
Это хорошо, я сюда по делу и заходил, мы же не в /b чтобы тредами меряться.
>Большинство существующих игр никому не нужны, несмотря на уникальные концепции и хорошую реализацию
Значит концепция/реализация говно
А я на тебя, и надеюсь не только я, потому что ты срешь в треде своим вечным недовольством на все вообще, и мешаешь обсуждать напрямую релейтед темы. Так и представляю этого старого душного пердячего деда-вахтера, которому даже обсуждение гдскрипта и его подводных камней неподходящая тема. Что дальше, нельзя чейнджлог годота обсуждать? Приходить к тебе за справочкой о каждой теме? Хртьфу.
>я сюда по делу и заходил
Не, дед, судя по твоему поведению твое основное дело тут - вахтерство. Ну а мы не на работе, а ты нам не начальник.
В Питоне это делается с помощью named arguments, типа:
Объявление как:
func foo(a=640, b=520, c=true)
И вызов как:
foo(c=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)
>А я на тебя, и надеюсь не только я,
Я тут практически ридонли, так что кляузничай.
Это тематика, зачем флудить в тематике? Ну подыми отдельный тред со своими замерами свитчей (которые возможно разворачиваются в if...else во время интерпретации), скинь ссылку на движкосрач, собери компашку из хрюнити и возмущайтесь вместе.
Там же непочатый край, вызов функций не бесплатный, а если не указывать типы то ваще грустно. А потом окажется, что работа с полями объектов дороже работы с глобальными переменными.
Сколько же открытий ждет нас. а... нет... каникулы кончаются
Репортнул тебя за превращение ИТТ в личный нытик-тред. И, надеюсь, не я один.
Релейтед обсуждения на гитхабе:
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() вообще без аргументов - всё, что передавалось аргументами, настраивается теперь свойствами самого класса. Ибо так логичнее.
>>1049580
А, точно, можно создать вложенный класс, тогда сохраняются подсказки, правда, печатать дольше:
>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"...
>Значит концепция/реализация говно
Нет, хорошие игры с интересной концепцией тоже опускаются на дно Стима, и там и остаются. Или, по крайней мере, эти игры ничем не хуже других, но не добрались до топа популярных.
Поэтому, если ищите мотивацию для разработки игр, можете сразу забыть о популярности игры. Если вы не популярный (видео)блоггер или нет бюджета на маркетинг, игра вряд ли станет популярной даже с достаточно большим бюджетом на разработку.
>>1049562
>Чел тупо страдает фигней
А что такого-то, если это касается GDScript?
>и вниманиелядствует в треде.
Раньше тут было больше узнаваемых анонов, но все, к сожалению, разбежались. Или это ты их репортил? Постите о разработке своих игр на Godot почаще, а то выглядит так, будто мы тут только код обсуждаем.
>я сюда по делу и заходил
Тогда какое тебе дело до его постов?
>>1049575
>своим вечным недовольством на все вообще
Ты его с кем-то путаешь, наверное. Это не он. Это я недоволен всеми, всем и всюду. А он кто-то другой.
>>1049594
>отдельный тред со своими замерами свитчей
Не нужен отдельный тред. Он тут несколько тредов сидит уже, насколько я понимаю. Обычно постит интересные конструкции в коде на GDScript. Чем его производительность не устроила - не знаю, но сам вопрос оптимизации кода смысл для треда имеет.
>Ща прибежит
Не раскачивай лодку.
Это тред любви и взаимопомощи.
>>1049633
>Как вкатиться в кодинг?
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 от кого-нибудь. Да и нарисовать стильный программер-арт не так сложно.
>как их работать заставить
Про геймдизайн не забывай - он важнее кода и арта.
Респект.
>Если планируешь публиковаться и просить деньги - желательно не использовать копирайченные ассеты. Используй цветные кубы/квадратики вместо них для прототипов, иначе в будущем забудешь удалить и ВНЕЗАПНО игру удалят по DMCA от кого-нибудь.
Так а если чел сам пишет, что можно юзать в коммерческих проектах или это такая обманка хитрая?
Не обманка. Просто всегда надо смотреть лицензии ассетов. СС0 безопасно в любом виде в любом проекте, даже без указания авторства ассетов - сам под СС0 на итче выкладываю. СС-BY уже требует указания авторства, тут мутнее и хватает тонких моментов - ты авторство укажешь, а какой-нибудь мелкостример, играющий твою игру не укажет, и ему страйк прилетит от автоматизированной системы ютуба/твича, особенно это музыки касается.
>чел сам пишет, что можно юзать в коммерческих
Тогда у ассета свободная лицензия, чаще всего это вариант "CC". Скорее всего ты обязан в титрах игры обозначить, что используешь его ассет, добавить (не обязательно кликабельную) ссылку на его страницу. "Воровства" тут нет, "воровство" - это когда, скажем, извлекают ассет из одной игры, вставляя в другую, скачивают платные ассеты бесплатно с торрентов, нарушают условия лицензии на ассет и т.д.
Подробнее о самой популярной лицензии на ассеты:
https://en.wikipedia.org/wiki/Creative_Commons_license
>или это такая обманка хитрая?
Вряд ли. Большинство просто выкладывают своё творчество, надеясь стать популярнее, если их имя засветится в популярной игре. Но, в теории, можно провернуть манёвр, если удалить все упоминания свободной лицензии из интернета... Поэтому имеет смысл сохранять копию сайта автора в формате, который может иметь вес в суде (тут я не спец).
Главное не воруй у больших игроков (Sony, Nintendo, Rockstar, Hadbro и многие другие, кому не насрать). С рандомным Васяном из Нижнего Пердюйска скорее договоришься о компенсации без суда...
>>1049640
>СС0 безопасно в любом виде
Лол, не всё так просто. Не в каждой стране автору позволено выкладывать свой контент в публичное достояние до своей смерти + сколько-то лет.
>страйк прилетит от автоматизированной системы
Это только если музыка публиковалась каким-то музыкальным лейблом и зарегистрирована в этой автоматической системе. Нужно смотреть источник.
Ещё полезно почитать про "патентный троллинг" - в геймдеве некоторые игровые механики оч жёстко запатентованы. Стрелочку рисовать на экране стало разрешено всего несколько лет назад, например. И мини-игры на загрузочном экране делать нельзя по причине какого-то патента, а не из-за лени разрабов.
>мини-игры на загрузочном экране делать нельзя
А, тот патент в 2015 просрочился... Значит, можно.
Значит, это реально разработчики тупо ленятся.
Не ленитесь. Делайте игры на экран загрузки.
>игровые механики оч жёстко запатентованы
Какой же это сюр нахуй. А мысли то еще запатентовали?
>А мысли то еще не запатентовали?
Мысли - нет. А вот бросать шарик для призыва себе боевого питомца - это сразу иск в суд от Nintendo... Использовать питомца как глайдер тоже нельзя.
>И че сделал палворлд
1. Удалил броски шарика - теперь тупо спавн рядом.
2. Удалил петы-глайдеры - пет даёт бонус глайдеру.
Что им придётся удалить дальше - покажет время.
Если не веришь, сам гугли.
Несколько месяцев назад играл. Не обратил внимание, что шарик не бросаю для призыва. А глайдер ваще не помню, летал на пале. Ну мб, просто действительно в глаза ебался, типа не важная мне деталь. А захват шариком они не патентовали выходит? И все остальное, что полностью спизжено с покемонов?
Вот есть Camera3D и RayCast3D. По идее, рейкаст обновляется с частотой физики, 60 Гц по умолчанию, однако, камеру предлагается вращать в _process() с частотой монитора. Как это по-хорошему решается? Необходимо плавное вращение и детект коллизий одновременно - с разными частотами обновлений.
>>1049659
Там всё очень сложно. Изначально Nintendo вообще наехала без патентов, патенты зарегистрировали в процессе судебных разбирательств. Как это у них получается - непонятно, но Pocketpair им уступает.
Может, причина в том, что обе компании в Японии - кажется, это сильно упрощает судебный процесс. А Nintendo любит отжимать бабки у конкурентов...
Если я правильно понял, то тебе нужна интерполяция. Глянь вот этот видос
https://youtu.be/zfIuaRzNti4?si=UX141b_swfG3Be9w
Я джва часа заполнял форму отправки ассета на ассетлиб, и вот наконец всё готово, нажимаю отправку и получаю сабж. Вся форма сбросилась, всё что я там вписывал.
Вероятно кто-то сильно накосячил в духе начала нулевых, когда делал форму. Или что там у них. Пиши заново.
Это крч секьюрити, которую браузеры подкручивают в последние годы. Запрещает отдавать/запрашивать некоторые ресурсы между не-https доменами. Браузер на такое может ругаться даже если ты на локалхосте что-то хостишь, например верстаешь банальный index.html и подгружаешь в нем локальный ресурс.
Возможно ты тупил с отправкой слишком долго и csrf токен истек, или, скорее всего, бекенд успели рестартнуть.
>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.
Проще говоря - ты слоупок.
На каждую форму (открытие страницы) заводится токен. У токена есть время. Это как капча на двачах, у которой тоже есть время жизни.
Если проблемы не случилось а я предполагаю, что её не случилось, то просто забей. У тебя не только рейкаст вращается с частотой в 60 кадров, у тебя и детект колизий происходит с этой частотой, т.е. если ты хочешь получить детект коллизий с частотой камеры либо вращай камеру в physics_process либо увеличивай частоту физики.
Представляю. Мне ваще приятно, если любую мою работу ценят, но поскольку я хуйло криворукое обычно получаю ведро говна.
Чел создаёт проблему двигая физический объект (персонажа) в _process и решаёт её, гениально
>нужна интерполяция
Проверил - вроде бы работает... Но _process() теперь вообще нельзя, только _physics_process().
>Глянь вот этот видос
Странное решение. Если двигать камеру в _physics_process(), движок сам всё интерполирует.
>>1049688
>я предполагаю, что её не случилось
С чего ты взял? Это не из категории преждевременных оптимизаций.
>У тебя не только рейкаст вращается с частотой в 60 кадров
В том-то и дело, что камера вращается быстрее - из-за этого проблемы.
Теперь камера вращается в _physic_process() и интерполируется.
>С чего ты взял? Это не из категории преждевременных оптимизаций.
>
Значит у тебя какая то странность с игрой если тебе надо успеть рейкастом поймать что то в промежутке между двух вызовов физического процесса.
Вообще есть механизм рейкаста из камеры, у неё вроде метод есть такой, скорее всего закроет твою проблему, а нода скорее всего делает это же самое но каждый физический тик, но это надо в исходники смотреть
1. Вращаешь камеру мышкой.
2. Повернув камеру, жмёшь левую кнопку мыши.
3. Рейкаст запаздывает и выбирает не то, на что смотрит камера.
4. ???
5. РРРРЯЯЯЯ, ДА КАК ТАК-ТО, Я ВЫБИРАЮ, А ОНО НЕ ВЫБИРАЕТСЯ!
Тру стори.
>inb4 трансформируй рейкаст перед кликом
Почему-то не работало. Или мне было лень...
>Странное решение. Если двигать камеру в _physics_process(), движок сам всё интерполирует.
Физический процесс работает с фикс частотой в 60 тиков/сек. А камера должна вращаться с частотой fps - т.е. process.
Или я что-то не вкуриваю?
>>1049676
>>1049674
>>1049672
Спасибо, человеки, со второго раза запостилось. Алсо, мои данные запомнились в автоподстановке. СПАСИ ВАС БОГ! 🙏❣❤ ХРАНИ ГОСПОДЬ АССЕТЛИБ! 💌💦
А чо там ассет стор? Туда публиковываешь?
https://store-beta.godotengine.org
Отбой! Отбой! Смотрим на быстрофикс. Думоем.
В некотором смысле появилось, опосредованно. Ты можешь унаследовать свой скрипт от 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
Но есть один нюанс... Ехехе... И не один.
>камера должна вращаться с частотой fps
Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
>>1049709 >>1049712
Задавай вопросы нормально: что ты пытаешься там реализовать и зачем, и что у тебя там не получается? Например, что за "типмиксинг" такой? Зачем нужен?
>>1049704
>либо вручную геттер/сеттер на ноде нпс делать, либо ПКМ->Edit children чтобы достать до аудионоды
Другого выбора нет. Главная нода сцены - это как бы интерфейс класса ООП, т.е. то, что взаимодействует с окружающими объектами. Ноды под главной нодой - скрытые детали имплементации класса, от которых существенно зависит работа объекта. Если ты жмёшь "editable children", ты нарушаешь инкапсуляцию в ООП. Создавая геттеры и сеттеры ты создаёшь интерфейс, независящий от имплементации класса - даже удалив конкретные ноды внутри сцены, интерфейс никак не изменяется, и, соответственно, сцена будет работать.
Если ты хочешь настраивать большое количество однотипных нод из одного места, то рекомендую воспользоваться ресурсами: если не делать их явно уникальными, они будут иметь одни параметры вне зависимости от того, где используются. Пример:
>@export var audio_settings: AudioSettings
>class_name AudioSettings extends Resource
>@export var volume: float
Сохраняешь 1 экземпляр audio_settings.tres где-то в файловой системе и вставляешь его в каждую ноду, требующую AudioSettings. Тогда изменения в файле отобразятся во всех нодах, использующих его. Даже в рантайме, если ты не использовал .dublicate().
Ещё можно использовать статические поля класса.
>>1049713
Ты просто переизобрёл синглтон. Зачем? Если у тебя потребуется изменить что-то в синглтоне (например, расширить функциональность игры), то потребуется изменять все места, где у тебя к нему обращение...
С ресурсами получается более гибкий подход.
>Да. Но если ты включаешь в настройках проекта "физическую интерполяцию", все transform у Node3D интерполируются на каждый кадр, даже если ты их изменяешь очень редко. Единственный подвох - эта интерполяция линейная, т.е. если у тебя тикрейт 10, вращение камеры будет в виде "многоугольника"...
Я честно говоря не очень понял. И вообще не врубаюсь зачем в движках сделано так, чтобы это все можно было по разному настроить. По моему единственная рабочая схема такая:
1) Камера двигается плавно в зависимости от FPS
2) Физический тикрейт работает 1/60
3) Как-то все работает и вместе и хорошо куда нажать, чтобы так было
И почему везде не настроено так по умолчанию? Кому блять может понадобится по другому и зачем?
Здесь всё подробно описано:
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
Избавляет от лишней головной боли.
>mouse_movement += event.relative
А, в движке есть вроде как аккумулятор событий (?):
https://docs.godotengine.org/en/stable/classes/class_inputevent.html#class-inputevent-method-accumulate
Правда, я его пока не использовал. Новая фича?..
Мне не нравится твой смех, поэтому этим путем я не пойду.
>Если у тебя физика зафиксирована на 60 Гц без интерполяции, на всех мониторах >60 Гц физ. объекты будут дёргаться.
Я правильно понимаю, что нужно:
1) Оставить физику на 60 Гц
2) Включить (?) интерполяцию
3) Вызывать все движения физ объектов в т.ч. камеры в physics_process
И все будет тип-топ и при 30 FPS, и при 60 FPS, и при 120 FPS?
>Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц?
Типа для производительности?
>Ты знал, что у многих игр физика 30 Гц, а то и 15 Гц? И наоборот, у некоторых игр физика >200 Гц. В Godot по умолчанию установлено 60 Гц просто потому что это наиболее популярная частота обновления монитора.
Ну тип это не объясняет, почему интерполяция не включена по умолчанию. Тип, какая разница какой тик пер секонд у физики. Камера то все равно должна двигаться нормально
Если ты меняешь позицию камеры без привязки к какому-либо физическому объекту, то тебе не нужна интерполяция, просто обновляй позицию камеры внутри _process и она отрендерится на следующем же визуальном фрейме. Но если ты например хочешь следить камерой за каким-то юнитом, то камера очевидно будет двигаться только при обновлении позиции этого юнита, т.е только при обновлении физики. И если у тебя физика обновляется раз в 1/60 секунды, то и камера будет залочена в 60 FPS, вот тут и нужна интерполяция.
>Необходимо плавное вращение и детект коллизий одновременно - с разными частотами обновлений.
Детект коллизий чего с чем? Если твоей камеры с условными стенами, то ты получается хочешь сделать саму камеру физическим объектом и обновляться она будет только с частотой физики. Соответственно передвигаешь камеру внутри _physics_process и на каждом визуальном фрейме интерполируешь ее позицию чтобы визуально не лочить движение в 60 FPS, в чем проблема-то?
Ну т.е. интерполяция имитирует обычное движение камеры, как внутри _process, но для камеры, которая внутри _physics_process. Т.е. по сути ее можно включать по умолчанию для всех проектов
Интерполяция движения камеры нужна только в проектах, где сама камера - физический объект. Если как в моем примере, у тебя камера просто следует за каким-то физическим объектом, то там нужно интерполировать движение этого объекта, а не камеры.
Если камеры следует за каким-то физ объектом, а не просто перемещается по воздуху (хотя тут тоже вопросы к, например, мыши, как писал анон выше), то она двигается в зависимости от движения этого объекта. Все равно что камеру повесить на голову игрока в игре от первого лица. Не?
>то она двигается в зависимости от движения этого объекта
Ну, а объект без интерполяции его движения будет двигаться только при обновлении физики, т.е в 60 FPS по умолчанию.
>Оставить физику на 60 Гц
Нужно смотреть, что нужно твоей игре. Как правило, слишком редкая симуляция пропускает коллизии; слишком частая симуляция впустую нагружает ЦПУ. Количество объектов и скорости движений влияют. Тримешам нужна точность выше, чем примитивам.
>И все будет тип-топ
Да, по идее, но в некоторых случаях нужно какое-то собственное решение, например, в мультиплеере, в хардкорных играх на высокую реакцию игрока и т.п.
>для производительности?
Да, разумеется. Это примерно как v-sync - чтобы не занимать компьютер лишними вычислениями.
>>1049731
>почему интерполяция не включена по умолчанию
>>1049737
>включать по умолчанию для всех проектов
Потому что:
1. Не всем подходит, добавляет инпут лаг.
2. Если у тебя 60 FPS + 60 TPS, то разницы нет.
3. Godot следит за тем, чтоб ты ничего не трогал вне _physics_process (warning отключается в настройках). Потому что тогда интерполяция просто ломается.
4. Телепортация объектов слегка усложняется.
Я ещё не полностью прочитал документацию...
>>1049733
>Но если ты например хочешь следить камерой
>>1049738
>проектах, где сама камера - физический объект
Во-первых, в 99% игр камера следует за каким-либо физическим объектом плюс сама имеет коллизию, предотвращающую клипинг камеры "в текстуры". Исключением будут только некоторые стратегии, фиксированная камера, простые головоломки...
Во-вторых, Godot предупреждает (warning) обо всех трансформах в проекте; скажем, MultiMeshInstance необходимо обновлять в _physics_process, если вы включили интерполяцию физики в проекте, хотя в MultiMeshInstance в принципе отсутствует физика. Достаточно странно, но, наверное, причина есть...
>Нужно смотреть, что нужно твоей игре. Как правило, слишком редкая симуляция пропускает коллизии; слишком частая симуляция впустую нагружает ЦПУ.
3d игра от первого лица. Так что 60 тиков вроде как раз
>Да, по идее
Понял, спасибо
> Не всем подходит, добавляет инпут лаг.
Он там минимальный, вроде
>Если у тебя 60 FPS + 60 TPS, то разницы нет.
Ну ща игры редко лочат на макс 60 fps.
>Телепортация объектов слегка усложняется
В смысле телепортация? Там же просто меняется global_position