Краткий гайд по вкату в движок:
1. Читать документацию.
2. Качать примеры.
3. ПРОФИТ!
Ссылки
Новости движка: https://godotengine.org/news/
Скачать движок: https://godotengine.org/download/ или http://store.steampowered.com/app/404790/Godot_Engine/
Теперь прямо онлайн - можно и с дивана: https://godotengine.org/online/godot.tools.html
FAQ: https://docs.godotengine.org/ru/latest/about/faq.html
Документация: https://docs.godotengine.org/ru/latest/ https://docs.godotengine.org/en/stable/
Примеры качаются прямо в движке через свой магазин в отдельной вкладке AssetLib. Там есть всё - от платформера до чата.
Игры, созданные глобальными кириллами: https://steamcommunity.com/app/404790/discussions/0/412448792354265655/
Изумительный Годот: https://github.com/Calinou/awesome-godot - подборка дополнений, модулей и минишоукейс от одного из авторов.
Аддон для диалоговой системы: https://github.com/coppolaemilio/dialogic
Для любителей пощекотать конпеляцию
Бинды LUA: https://github.com/perbone/luascript
Бинды JS: https://github.com/GodotExplorer/ECMAScript
Годнота от анона
- Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе).
- В версии 3.2 появилась возможность прикреплять pck к бинарнику. Не появилась, а вернулась - 2.х умел. Бриллиант для любителей однофайлового продукта!
- Редактор персонажей на основе makehuman: https://github.com/Lexpartizan/Go_MakeHuman_dot
- Тест-бенчмарк:
- - Веб-версия - https://govdot.herokuapp.com
- - Вишмастер для винды - https://govdot.herokuapp.com/4Anon.rar
Предыдущий: >>734420 (OP)
Архивный: https://arhivach.net/thread/664976/
Хмм. А что использовать? Просто контрол ноды в главную сцену вставлять?
Чот сложна.
>>745023 →
> Вот я хочу, перемещать камеру по экрану, но GUI оставался на месте. Поместил интерфейс в узел CanvasLayer, который специально для этого, но теперь я не могу кликать сквозь этот CanvasLayer. А как?
Сорян за поздний ответ. У тебя в канваслеере по умолчанию первая контрол-нода разворачивается на всю доступную площадь (Макет -> Полный прямоугольник). И! И перехватывает события мыши на себя.
>>747311
> CanvasLayer, странный он какой то
Проблем не в нём, а в вышеописанном. У меня были поначалу проблемы с этим. Я их пофиксил делая первую контрол-ноду в слое размером в пиксель (Макет -> Слева сверху (для лево-верхнего виджета, например)
>>745075 →
> у CanvasLayer нет галочки с инпутом
Разумеется нет. Потому что она есть у потомков контрол-ноды, которые ты там помещаешь.
> Могу предложить не пользоваться канвас лейром.
А я предлагаю разобраться в вопросе...
>>747318
...а не городить велосипед с вьюпортом, который вообще не для этого.
Интеллектуальная под Андроид.
Ссылочку тут оставлю на браузер, если у тебя хром, погамаешь.
https://gotm.io/2ch-studio/hbt
Комьюнити нужно исключительно чтобы находить неудобства, к которым у меня глаз замылен. Ну и мб когда куплю подписку девелопера в гуглсторе иметь пару скачавших.
Не, на итч не заливал. Какие там правила для залива? Если полотенце на пол бросят, подбирать?
У меня Моник старый половину цветов не передаёт. Это сарказм такой?
>Изумительный Годот
Зачем давать левый необновляемый форк-репо, если есть оффициальный обновляемый оригинал https://github.com/godotengine/awesome-godot
Ты не мог бы сказать точнее что там не так? Потому что я явно не понимаю. Вроде ж норм.
Так и не сделал гребанное меню в игре(
>yield(get_tree().root, "ready")
но у меня все сломалось от такого.
А как дождаться что все, что есть загрузилось?
Принимаю возражения. Постил сгоряча. Извиняюсь. Изучу матчасть по вьюпортам.
> А как дождаться что все, что есть загрузилось?
Опрос дерева построен так, что дерево опрашивается рекурсивно, при этом в первую очередь выполняются потомки, затем предки. То есть, если рассматривать выполнение колбэка ready, он сначала выполнится для всех листьев, затем для всех ветвей, затем для ствола, и наконец для корня. То есть, если у тебя выполнилось ready для корневого узла, ты можешь быть уверен, что все остальные узлы уже ready выполнили.
Yeld может ждать выполнения функции. Если ты конечно не с сигналами работаешь. Если с сигналами, тогда знаю только про ожидание сигнала.
Путаница какая-то. Вот поэтому и рекомендуется предпродакшен и диздок с как можно более точным и полным описанием, что откуда и куда. Без этого получится как у при запуске.
>Если же все это непонятно, то вместо yield(get_tree(), "idle_frame"), который ждет всего 1 кадр, можно просто завести таймер на 5 секунд с фейковым экраном загрузки, я так делал :3
Пиздец :D
Предлагаю любую популярную 2д игру в 3д.
Начать с аркадных гоночек вид сверху.
Потом если не надоест платформер.
Затем РПГ
Стратегии не советую, сложно для понимания, да и сам жанр умирает, но если начнёшь ты будешь первым на ютубе среди ру и анг кто пилит тутор по РТС.
да
геймплейно 2д и 3д сильно отличаются, любой кто переходил из 3д в 2д или наоборот это знает
но никто не мешает делать 2д игры в 3д, только не надо себе врать!!!
Назови пару стратегий РТС за прошлый гол, кроме Тоталов, рефоржа вара и ремастера СинСи.
Чего ты айкаешь? Мне и так грустно.
>>747986
Зачем мне следовать за тобой, если у меня уже есть концепт своей игры? Он куда проще, и профита даст больше. Только сука как же я ненавижу программирование. Гребаный ад где все следует по правилам, которые ты никогда не поймешь!
Ебал я в рот ебучие движки, с ебучими языками!
Ты только что поговорил с копипастой спам-бота.
А по теме, программирование намного проще освоить, чем рисование, моделирование и музыку. Тебе не нужно надрачивать скилл годами тяжёлого труда, ты просто читаешь правила в книжке со списком правил (ака мануал) и затем используешь эти правила для составления программы. Не нужно даже наизусть помнить, достаточно знать где можно найти забытое.
Если очень трудно освоить общие принципы программирования, поиграй в игры для маленьких детей, в которых нужно с помощью кнопок задать программу виртуальному роботу, чтобы он решил головоломку.
>Ты только что поговорил с копипастой спам-бота.
Да насрать, я просто хотел выговорится.
>А по теме, программирование намного проще освоить, чем рисование, моделирование и музыку.
Нихера чел! В рисовании ты когда делаешь, сразу видишь что у тебя выходит. Даже если ты совершил ошибку, тебе не вылезет окно в программе "ОШИБКА ОШИБКА, ИСПРАВТЕ ТО ЧТО ВЫ СДЕЛАЛИ!"
>Если очень трудно освоить общие принципы программирования, поиграй в игры для маленьких детей, в которых нужно с помощью кнопок задать программу виртуальному роботу, чтобы он решил головоломку.
Да и само программирование скучная херня, которая отбирает больше сил и нервов, чем принесения удовольствия.
>Не нужно даже наизусть помнить, достаточно знать где можно найти забытое.
Это можно отнести к чему угодно в наши дни, к рисованию в частности.
> да и сам жанр умирает
Я бы не сказал, что жанр умирает. Скорее кризис идей. Ведь на рынке сейчас ни одной нормальной популярной пошаговой стратегии. А вот те же парадоксовские игры, типа стеллариса - вполне себе стратегии, и вполне себе популярные. Даже индюшатина, типа northgard, нашла свою аудиторию, причём немалую. Но игра нормально играется в первые часов 10. Потом надоедает, потому что ничего нового не привнесли.
Та же история, что с wow и hs. Они не были основоположниками мморпг и ccg, но привнесли что-то, что заставило прочих равняться на близзов и популяризировало соответствующие жанры. А сейчас близзы стагнируют в боязни, ка бы чего не случилось, и не хотят рисковать в попытках выпустить новый мир и геймплей, а переключились на ремастеры.
Вот и с rts и tbs, мне кажется. Выпусти новую, или, даже правильней сказать, старую механику с взглядом с нового ракурса - и будет успех. Не все могут бесконечно играть в ск, стронгхолд, homm3 и дисайплсов. И вот этот перетекающий народ и есть шанс заново запустить жанр to the moon.
Подозреваю, что реди срабатывает при инстанцировании/загрузке объекта, куда прицеплен скрипт, либо если скрипт грузится в проект. Но это не точно. Я не годот эксперт и в треде сам на правах вопрошающего.
>В рисовании ты когда делаешь, сразу видишь что у тебя выходит.
Ага. И выходит обычно говно. И ты понимаешь, что это говно. Но совершенно не понимаешь, почему конкретно говно, и как переделать говно в конфетку. А ведь говнографика не выполняет свою главную задачу - вызывать какие-то эмоции, которые задумывались рисователем. Страшные сцены будут выглядеть смешно, серьёзные сцены будут выглядеть нелепо, милые сцены будут выглядеть отвратно, смешные сцены будут выглядеть постыдно и так далее. А говнокод, пусть и говно, но свою главную задачу решает. И пользователь никогда не узнает, что его любимая программа состоит из говна, потому что он её код никогда не увидит, а если даже увидит, то не сможет понять, почему он говно. Да и ты сам, когда учишься кодить, не знаешь, говнокод это или не говнокод, поэтому не можешь себя критиковать, а в рисовании ты прекрасно знаешь как выглядит говно, и критикуешь себя за рисование говна. Короче кодинг проще.
>Даже если ты совершил ошибку, тебе не вылезет окно в программе
Вот именно! Компилятор тебе по-дружески укажет на ошибку в коде, даст направление, в котором нужно искать, практически ссылку на страничку в руководстве. И ты её исправляешь, потому что ты либо уже знаешь как это исправить, либо загуглишь и по первой ссылке найдёшь решение. А в рисовании ты можешь нарисовать что угодно и программа тебе ничем не поможет, ей вообще без разницы что у тебя получится, она не может сказать тебе, где ты ошибся, почему ошибся и как это исправить. И никто не скажет точно, каждый скажет свою вкусовщину и не сможет ясно и чётко ответить. Это кошмар какой-то, ты рисуешь говно и понимаешь что это говно, но никто не может тебе помочь исправить ошибки. А компилятор иногда тебе прямым текстом говорит: вот здесь замени А на Б и всё заработает, компилятор умный и добрый.
С другой стороны, если у тебя куча EAV (ошибка доступа к памяти), тогда просто не лезь писать код, пока не продумал структуру программы и всю работу с данными. Если ошибка со стороны библиотеки - обращайся к руководству библиотеки, и т.д. Если ошибка логическая (программа работает, но ответ неправильный) - опять же думай головой, решение где-то близко. А в рисовании сколько ни думай, внутренний критик говорит только "это говно". Даже прочитав теорию, всё равно не помогает...
>Да и само программирование скучная херня, которая отбирает больше сил и нервов, чем принесения удовольствия.
Скорее всего ты просто берёшься за непосильные задачи, которые намного выше уровня твоего навыка. Либо это просто личное. Мне нравится видеть, как из ничего появляется и развивается рабочая программа, способная самостоятельно выполнять то, что без неё тебе пришлось бы делать вручную, долго и трудно. Это как рождение живого существа, которое постепенно взрослеет и учится новым навыкам, а потом помогает тебе, отвечает заботой в ответ на заботу. А картинка - ну вот ты её нарисовал, положил в папку и всё, будет лежать и занимать место или пылиться на полке, толку от неё никакого, одни страдания, стыд и самобичевание.
p.s. Пишу в начале, потому что концовка зачетная. Мне нравится рисование своей простотой, а...
"Да и само программирование скучная херня, которая отбирает больше сил и нервов, чем принесения удовольствия."
>>748070
>И ты понимаешь, что это говно. Но совершенно не понимаешь, почему конкретно говно, и как переделать говно в конфетку.
Как раз наоборот, с помощью анализа ты можешь спокойно понять где и что нужно поправить.
>А говнокод, пусть и говно, но свою главную задачу решает.
Я в ремпае пока каждой строчке отступы не сделал, оно мне игру не запускало!
В годод же я скопировал код из инета, решив вставить его в свой проект, но нихуя не работает! Я его написал не туда куда нужно, а как делать по другому я не знаю. И все, иду нахуй тут же, посмотрев на весь проект целиком я могу только закрыть и пойти спрашивать программиста почему у моего перса спец атаки не работают! Он же тоже НЕ БУДЕТ ЕБАТЬ ПОЧЕМУ, он на другом языке работает, а на годот ему похуй!
>Короче кодинг проще.
Его проще забросить, и не вспоминать никогда! Тут согласен на все сто!
>Вот именно! Компилятор тебе по-дружески укажет на ошибку в коде, даст направление, в котором нужно искать, практически ссылку на страничку в руководстве.
Я скопировал чужой код, так же для спец приема, вставил. Ничего не работает! Почему? Я мне пк не говорит! Молчит в тряпочку! Видит код, а про себя думает "Вот я его вижу, но ничего не сделаю. Пусть он помочиться, перепишит все там нахуй!" Ахуеть в крысу он тебе не поможет. А за точку которую ты случайно поставил, осудит и обоссыт!
>А в рисовании ты можешь нарисовать что угодно и программа тебе ничем не поможет, ей вообще без разницы что у тебя получится, она не может сказать тебе, где ты ошибся, почему ошибся и как это исправить. И никто не скажет точно, каждый скажет свою вкусовщину и не сможет ясно и чётко ответить. Это кошмар какой-то, ты рисуешь говно и понимаешь что это говно, но никто не может тебе помочь исправить ошибки. А компилятор иногда тебе прямым текстом говорит: вот здесь замени А на Б и всё заработает, компилятор умный и добрый.
Если тебя палками не бьют, по твоему это похуизм?! Программе не важно кто и что ты за человек, и по этому она тебя не осуждает! И если ты будешь общаться не с ясельной группой, нормальные худы скажут "Вкусовщины собой нету, и даже в абстракционизме есть правила, которыми пользуются и ОСТАЛЬНЫЕ ХУДОЖНИКИ!" Та же самая композиция, по твоему если её сделать плохо - это будет вкусно?
>Даже прочитав теорию, всё равно не помогает...
Я бывал на уроках информатики, и читал тамошние учебники, выполнял от туда задания. Что такое переменная?! Я не знаю что такое переменная! А построение примерные пропорции лица я запомню на все оставшуюся жизнь. Потому что я чужие лица смотрю каждый день.
>Скорее всего ты просто берёшься за непосильные задачи, которые намного выше уровня твоего навыка.
Да я готов и три в ряд сделать, только чтобы там были вн вставки.
>Мне нравится видеть, как из ничего появляется и развивается рабочая программа, способная самостоятельно выполнять то, что без неё тебе пришлось бы делать вручную, долго и трудно. Это как рождение живого существа, которое постепенно взрослеет и учится новым навыкам, а потом помогает тебе, отвечает заботой в ответ на заботу.
Ага, гомункул гребаный который будет тормозить и пускать слюни из рта. Я таких стараюсь в подвале старом харде держать, морить голодом пока они сами не вымрут. Но они пожирают друг друга, регенерируя оторванные конечности.
>А картинка - ну вот ты её нарисовал, положил в папку и всё, будет лежать и занимать место или пылиться на полке, толку от неё никакого, одни страдания, стыд и самобичевание.
Картина попадает в сеть из твоего пера, собирая толпу людей которых зацепили твои взмахи кисточкой! Грациозное палатное которое получает большое внимание, разносясь по разным соцсетям с ссылкой на автора оригинала. Зрители кормят художника деньгами и овациями! А конкуренты и коллеги репектуют, ожидая твой следующий шаг к вершине мастерства!
Годот пишет всегда, когда возникает проблема. Ну или рассказывай какой код использовал, поможем
Инструмент для этого не посоветуешь? А то я пробовал гуглить - какие-то все не очень варианты были
Тут не код.
Из последнего я скопировал стены, которые не позволяют моему персонажу падать в пустоту сквозь поле, и сетку я сделал таким же образом. Но, открыв файл через несколько недель решил сделать тоже самое во круг поле, скопировав блок стоящий на сетке. Но итогу правая стенка не пропускает игрока, левая и задняя пропускают. Что не так? Только всевышний знает!
>>748080
Окей.
>>748077
>Художникам проще рисовать, логикам программировать, никакого открытия тут нет.
Ты это тому скажи.
>Ты можешь нарисовать схему где опишешь кто кому посылает сигнал и когда, к примеру.
Мне эти схемы не о чем не говорят. Я в них могу видеть только ответвление по вн, или же семейное древо.
Скрипты к стенкам приклеены? Попробуй развернуть их на 180 градусов для прикола
Пробывал, тоже самое. Если проблема со скриптами, почему правая стенка работает как надо?
Понятно, спасибо что написал об этом. Но сейчас уже нет желания открывать и править все это.
>с помощью анализа ты можешь спокойно понять где и что нужно поправить.
Не помогает оно, и так двигаешь, и эдак, а оно всё равно не то. Как в меме с унитазом, из стороны в сторону двигаешь и всё не то.
>Я в ремпае пока каждой строчке отступы не сделал, оно мне игру не запускало!
Есть такое выражение: RTFM! То есть читай грёбаный мануал! Наверняка не читал вообще или невнимательно.
>В годод же я скопировал код из инета, решив вставить его в свой проект, но нихуя не работает
Ну вот представь что ты скачал чужие фотки памятников, склеил в пейнте и удивляешься почему у тебя не получилось аниме в стиле 90-х с озвучкой и мерчендайзом. Действительно, почему? Да потому что так дела не делаются. Ты должен разумно подходить к разработке, а не бессознательно копипастить рандомные фрагменты чужих проектов. Тем более в GDScript важны отступы, на один отступ ошибёшься и код уже что-то другое делает, при этом он может запускаться и работать, но результат будет неправильным (но это не во всех языках так). Короче нужно учиться, учиться, и ещё раз учиться, а потом сознательно писать свой собственный код своими руками.
>он на другом языке работает,
Большинство ЯП очень похожи друг на друга из-за того, что парадигма одна - императивная. Программист, владеющий одним императивным языком, без труда поймёт код на другом императивном языке, и даже может найти некоторые ошибки. Но да, в контексте движка всё сложнее, ошибка может не касаться кода, ты мог что-то другое неправильно сделать.
>Я скопировал чужой код, так же для спец приема, вставил. Ничего не работает! Почему?
Потому что ты:
>скопировал чужой код
>скопировал
>СКОПИРОВАЛ
Вот почему.
>Вкусовщины собой нету
Ну да, конечно. Аниме-хейтеры назовут любую картинку в стиле аниме говном. А мне, например, наоборот, от классической живописи, современного реализма и западных мультиков блевать хочется, а вот аниме - это хорошо, это качественно. Твои "нормальные худы" любую кляксу готовы за миллион баксов с аукциона купить, или пытаются эту кляксу за миллион баксов продать. Но мне вот не нравятся их "высокохудожественные" кляксы, мне нужно аниме, но даже зная все формальные правила получается какое-то говно. Даже если пытаюсь рисовать в векторной программе, которая опирается на строгую математику, в отличие от растрового хаоса.
>и даже в абстракционизме есть правила
Ну вот ты выполняешь все эти формальные правила, а получается говно. Почему? В рисовании правила выполнять недостаточно, нужно что-то ещё. В программировании достаточно выполнять правила и всё будет работать как задумано.
>Что такое переменная?!
Это коробочка с надписью, в которой ты можешь хранить какие-нибудь данные, например, числа. И обращаешься к коробочке ласково, по имени.
>построение примерные пропорции лица я запомню на все оставшуюся жизнь
Это никак не помогает. Я тоже знаю, где у человека глаза, нос, рот, уши. Знаю пропорции головы. Но всё равно получаются уродцы, не похожие на хомо сапиенс даже. Если бы можно было программно эту задачу решить, я бы уже давно не мучился, но программно слишком долго все ракурсы и вариации описывать.
>Картина попадает в сеть из твоего пера, собирая толпу людей которых зацепили твои взмахи кисточкой!
Во-первых, никуда она не попадёт, потому что говно.
Во-вторых, никого не соберёт, потому что ты никому не известное говно.
В-третьих, тебя и твою картинку обосрут и потопят в говне, потому что она говно.
А программа полезна лично для тебя, а не для толпы быдланов.
Сколько тебе лет вообще? Говоришь как старик, по какой-то причине решивший освоить геймдев на старости лет. Или как ребёнок, привыкший к тому что всё делают за него и не желающий работать своими руками, но для ребёнка ты слишком много знаешь. Возможно, это не твоё. Продолжай рисовать картины и собирать толпы людей в сети) Ну или закажи разработку игры на фрилансе, если не хочешь учиться программированию.
Есть dictionary, где хранимое значение - массивы. Положим
array = [0, 1, 0, 0]
Нужно проапдейтить только определённый элемент массива, например, второй (заменить 1 на 4).
Как это сделать? Вариант, как для массива array[1] = 4 не катит, потому что dictionary["arrayZ"][1] = 4 выдаст ошибку.
Из придуманного - перекладывать весь массив по новой по типу пикрил, но это какой-то сизифов труд.
Есть какой-то метод нормальный для этого?
Какую ошибку выдаёт? dictionary["arrayZ"][1] = 4 по идее должно работать
Да я не парюсь, просто много сил жрет ковыряется в этом. А удовольствие победы несоизмеримо с выносом мозга на таких затупах.
>>748111
>программирование намного проще освоить
>Есть такое выражение: RTFM! То есть читай грёбаный мануал Наверняка не читал вообще или невнимательно.
>Действительно, почему? Да потому что так дела не делаются. Ты должен разумно подходить к разработке.
>Аниме-хейтеры назовут любую картинку в стиле аниме говном.
>Твои "нормальные худы"
>Но мне вот не нравятся их "высокохудожественные" кляксы, мне нужно аниме, но даже зная все формальные правила получается какое-то говно.
Бля я просто угораю! Приплел с нихуя аудиторию аукционов, не поняв что под нормальными худами я имел ввиду пик ниже. Если ты не знал, вся стилизация основана на реализме. Если ты захочешь нарисовать человека, ты "умный программист" будешь рисовать ему две ноги, два глаза, две руки, и два полужопия. Знаешь почему? Потому что человек априори выглядит так а не иначе. Если у тебя получается говно, значит ты рисуешь не аниме тян, а того же гомункула, у которого шея с пальчик, растет на затылке.
>Это никак не помогает. Я тоже знаю, где у человека глаза, нос, рот, уши.
А слепой ничего не увидит.
>Сколько тебе лет вообще?
Больше 18, меньше пенсионного возраста.
>Возможно, это не твоё. Продолжай рисовать картины и собирать толпы людей в сети) Ну или закажи разработку игры на фрилансе, если не хочешь учиться программированию.
Я в прошлом треде написал что я буду делать, при неудачи. То бишь найму программиста/реализую задумку в виде маленького комикса.
Я очень хочу разобрать всю твою писанину, но впаду от понимания того, что ты опять ответишь в такой же развернутой манере! А говорить я не особо люблю. Ведь я творец, а не клоун. Занавес.
Блин, действительно работает. Немного не то юзал в качестве ключа - ошибся с переменной, содержащей ключ.
На второй картинке рекомендуется вместо get_parent использовать PackedScene?
>реализую задумку в виде маленького комикса
Если ты умеешь рисовать, почему бы сначала не нарисовать комикс? Или параллельно с игрой, если есть время. Так можно заранее привлечь аудиторию и точнее определиться с персонажами для игры, если она вообще нужна. Или, если аудитория уже есть, комикс будет проще для восприятия - его не нужно скачивать, запускать и проходить, просто читаешь на странице любимого художника и не паришь мозги. Т.е. в теории у комикса шире охват сообщества, чем у игры.
>стилизация основана на реализме
Знаю. Но мне не нравится большое количество лишних деталей, таких как выпуклые мышцы, какие-то пятна на коже и т.д. Но речь не про то шла. Вот ты нарисуешь стикмана и я нарисую стикмана: палочки, кружочки, всё по линеечке если нужно. Вот только твой стикман моих глазах будет неплох, я буду даже завидовать, а мой стикман в моих глазах будет выглядеть как говно, и чем больше я буду пытаться его исправить, тем больше буду портить. С формальной точки зрения стикманы одинаковые - все размеры, пропорции, толщина линий, цвет чернил и т.д. равны, но мой всё равно намного хуже. Чего-то мне не хватает, и без этого даже пытаться рисовать бесполезно. А вот код - чтобы он работал и решал задачи, его не нужно сравнивать с чужим кодом, он хорош сам по себе.
Ладно, к чёрту стикманов, вот я точку поставлю и ты точку поставишь. И твоя точка хороша, а моя - говно. И я её десять раз обведу и заново переделаю, но всё равно моя точка будет хуже. Она всегда хуже. Я не понимаю, почему. Знаю, это моя заниженная самооценка виновата. Но всё равно я только говно делаю.
>будешь рисовать ему две ноги, два глаза, две руки, и два полужопия
Вот это, кстати, одна из ошибок новичков, её часто дети допускают. Рисовать нужно не "две ноги, две руки, два глаза", рисовать нужно то, что видишь перед собой (или мог бы видеть, будь оно перед тобой). А перед тобой не обязательно полный комплект частей тела - часть из них могут быть прикрыты чем-нибудь, находиться за границами кадра, отсутствовать у модели и т.д. Аналогично с тем, как выглядит часть тела: рука под определённым ракурсом может вообще не иметь отличительных черт типичной руки, но рисовать нужно то что видишь, а не то что по твоему мнению должно быть на руке. То есть рисование сложнее загнать в рамки формальных правил, правила зачастую только мешают: ты знаешь, что у человека пять пальцев на руке, и пытаешься их все на эту руку прикрепить, а на самом деле в конкретной позе и ракурсе видно только один палец или два. В программировании такого не бывает, если нужно написать программу для решения задачи - ты пишешь программу для решения задачи, а не какое-то непонятное пятно в форме задачи.
Вообще я изначально пытался помочь с принятием программирования, а ты продолжаешь бодаться. Ради чего? Просто перестань буянить, когда встречаешь какие-то сложности, трезво оцени ситуацию и читать самоучители, выполняя все упражнения из них. Тебе не нужно написать десять тысяч программ, это только художнику нужно десять тысяч рисунков сделать, а тебе достаточно научиться писать программы. Это просто, если контролировать себя и не психовать.
> моя заниженная самооценка
Ещё перфекционизм на вышеописанную проблему работает нехило.
>Ещё перфекционизм
Вот-вот, именно так. Но код с перфекционизмом всё же проще писать: мой перфекционизм зачастую удовлетворяется ровными отступами, правильными заглавными буквами, правильным числом пробелов, пустыми строками между блоками кода, длинными понятными именами и т.д., т.е. главное чтобы выглядело опрятно и красиво. А с рисунками так не получается, на один пиксель ошибёшься - уже совсем другой результат, а пикселей миллионы. С 3D-моделями ещё хуже, пытаюсь до миллиметров всё вычислить и всё равно говно получается. А код пишешь себе и пишешь, практически как на родном языке говоришь.
да, меня бомбит с "кодит сложна, рисувать лигко"
Я это ты, бро. Бомблю с того же самого, когда люди, которым по жизни легко, не понимают как такое может быть, что кому-то по жизни сложно? "Да вы просто не стараетесь" говорят они. Пиздец.
> С 3D-моделями ещё хуже, пытаюсь до миллиметров всё вычислить и всё равно говно получается.
А ещё квады. Маниакально трясусь над моделькой, чтоб недайбох нигде многоугольника не образовалось, иначе пиздец. В то время, как васян уже сдаёт готовую модельку, ему перезванивают, а мне нет.
>Т.е. в теории у комикса шире охват сообщества, чем у игры.
1. Нихуя. Играют охотнее, чем читают.
2. Если я сделаю игру, смогу расширить пул площадок для продвижения себя любимого как минимум на два. itch.io и тд
3. Я хочу сделать для игрока челлендж, при котором он борется за получение желаемого арта.
>Если ты умеешь рисовать, почему бы сначала не нарисовать комикс?
Потому что это блять идея не для комикса, а для игры. Идеи для комикса у меня есть, и они придуманы с заточкой под это.
>Вот ты нарисуешь стикмана и я нарисую стикмана: палочки, кружочки, всё по линеечке если нужно. Вот только твой стикман моих глазах будет неплох, я буду даже завидовать, а мой стикман в моих глазах будет выглядеть как говно, и чем больше я буду пытаться его исправить, тем больше буду портить. С формальной точки зрения стикманы одинаковые - все размеры, пропорции, толщина линий, цвет чернил и т.д. равны, но мой всё равно намного хуже.
В реальности же ты сделаешь ему длинную шею, разные размеры рук, и просрешь ещё много пропорций которые важны в построении человека. Это уже не смотря на то, что крутан будет все это делать в векторе, а ты в растре мышкой рисовать. xD Считай шутка среди cg худов.
>Ладно, к чёрту стикманов, вот я точку поставлю и ты точку поставишь. И твоя точка хороша, а моя - говно. И я её десять раз обведу и заново переделаю, но всё равно моя точка будет хуже. Она всегда хуже. Я не понимаю, почему. Знаю, это моя заниженная самооценка виновата. Но всё равно я только говно делаю.
У меня тоже заниженная самооценка. Не мое мнение, а людей со стороны. Мне это не мешат если получилось говно, изменить ошибку, а потом в дальнейшем попытаться её не допустить.
>Вот это, кстати, одна из ошибок новичков, её часто дети допускают. Рисовать нужно не "две ноги, две руки, два глаза", рисовать нужно то, что видишь перед собой (или мог бы видеть, будь оно перед тобой). А перед тобой не обязательно полный комплект частей тела - часть из них могут быть прикрыты чем-нибудь, находиться за границами кадра, отсутствовать у модели и т.д. Аналогично с тем, как выглядит часть тела: рука под определённым ракурсом может вообще не иметь отличительных черт типичной руки, но рисовать нужно то что видишь, а не то что по твоему мнению должно быть на руке. То есть рисование сложнее загнать в рамки формальных правил, правила зачастую только мешают: ты знаешь, что у человека пять пальцев на руке, и пытаешься их все на эту руку прикрепить, а на самом деле в конкретной позе и ракурсе видно только один палец или два. В программировании такого не бывает, если нужно написать программу для решения задачи - ты пишешь программу для решения задачи, а не какое-то непонятное пятно в форме задачи.
Ты должен видеть на сквозь. Этому и учат почти все учения по художественному ремеслу.
>Вообще я изначально пытался помочь с принятием программирования
Это не возможно принять, боль и страдания от тильда только в пучины депрессии вгоняют. Чем дольше сидишь, тем больше не понимаешь.
>Тебе не нужно написать десять тысяч программ, это только художнику нужно десять тысяч рисунков сделать, а тебе достаточно научиться писать программы.
Тебе нужно много знать чтобы написать одну программу, а мне чтобы нарисовать один рунок достаточно посмотреть на свою ногу.
>>748160
>>748161
>да, меня бомбит с "кодит сложна, рисувать лигко"
>которым по жизни легко, не понимают как такое может быть
Я если сравнивать с другими худами, даже на средний уровень ещё не вышел. Но даже с таким бэкграундом рисование легче, чем программирование.
>как васян уже сдаёт готовую модельку, ему перезванивают, а мне нет.
Вася потратит на эту подельку в лучшем случае две рабочих недели, из которых спать и есть будет 7 часов. Остальное выдрачивание.
Отклеилось. 2 пик там не актуален, посчитал что этот аргумент можно спокойно списать.
AStar знаю и использую для поиска пути. Но для реализации разведки карты это не подходит, BFS выглядит более адекватным, но не могу найти такой функции.
>func draw_lines():
>>for i in get_children().size():
>>>var colour = generate_colour(i)
>>>var line_2d : Line2D = get_child(i).get_node("Line2D")
>>>yield(generate_colour(i), "completed")
>>>line_2d.set_modulate(colour)
>
>func generate_colour(number : int):
># yield(get_tree(), "idle_frame")
>>var colR := randf() 2
>>var colG := randf() 2
>>var colB := randf() 2
>>var colour = Color(colR, colG, colB, 2)
>>return colour
то будет ошибка
>First argument of yield() not of type object.
А если сделаю так (раскоменчу yield в generate_colour):
>func draw_lines():
>>for i in get_children().size():
>>>var colour = generate_colour(i)
>>>var line_2d : Line2D = get_child(i).get_node("Line2D")
>>>yield(generate_colour(i), "completed")
>>>line_2d.set_modulate(colour)
>
>func generate_colour(number : int):
>>yield(get_tree(), "idle_frame")
>>var colR := randf() 2
>>var colG := randf() 2
>>var colB := randf() 2
>>var colour = Color(colR, colG, colB, 2)
>>return colour
То будет ошибка
>Invalid type in function 'set_modulate' in base 'Line2D'. Cannot convert argument 1 from Object to Color.
А если не ставить yield нигде, то будет ошибка
>Invalid type in function 'set_modulate' in base 'Line2D'. Cannot convert argument 1 from Nil to Color.
Как так получается, что спустя 1 кадр меняется класс с Color на Object?
Смотри как распидорасило твой код, а ты при этом ещё и корпел над ним, угловыми скобачками отступы симулировал, а про знаки * забыл. Юзай пастебин, Люк!
Значит, смотри сюда, когда ты юзаешь yield, то метод, в котором он вызван, перестаёт возвращать любые значения, кроме корутинного объекта https://docs.godotengine.org/ru/stable/classes/class_gdscriptfunctionstate.html который управляет состоянием функции. Соответственно, до твоего return colour дело не доходит. Если хочешь ебаться таким образом, то делай так: https://pastebin.com/iHN3EcC3
Обосрался таки с советом. Замени в строке 8:
>if typeof(ref.color) == TYPE_COLOR:
Потому что нельзя сравнивать разные типы, а я объявил строковую константу и сравниваю с цветом.
>>748353
Ну и наконец, барабанная дробь, финальный вариант: https://pastebin.com/1rjs5XDE
Не совсем так, как мне надо, но сделал по твоему подобию, даже йылды оказались не нужны, все заработало, как надо. Тысячи благодарностей.
А вот так
var line_2d : Line2D = get_child(i).get_line_2d()
всегда рекомендуется делать?
Я просто хотел заставить одну функцию дожидаться завершения другой, чтобы другая не слала null.
желтый с фиолетовым плохо сочетается. Погугли, какие цвета хорошо сочетаются и поставь их, а то от этих глаза болят.
мимо
> всегда рекомендуется делать?
Вообще говоря, вкусовщина. Твой вариант опрашивает дерево строковым запросом. Диды неодобряе такой подход, но мне как-то в стрингосраче убедительно на миллисекундах показали, что современные строки работают на исчезающе малую величину медленнее, чем числа, и этим можно пренебречь. Мой вариант опрашивает потомка ноды в её массиве потомков, индексы которого инт, то есть везде работа с числами, но не строками. Но на этапе оптимизации вспомни этот момент и сможешь оптимизировать пару лишних фреймов.
Вот примерно то, о чём я говорю: https://pastebin.com/gjfLrUpV
На самом деле такое может случиться, когда фпс начнёт падать меньше 30. Помнится мне, у меня комп обосрался, когда я на годоте сделал реализацию http://stuffin.space/
Жалко, что код при обновлении пекарни не сохранил. Или нет. В следующий раз нормально напишу.
У меня несколько персонажей, у каждого Лэйбл над головой, хочу, чтобы Лэйблы не накладывались друг на друга
2д, надписи могут двигаться вверх и по-горизонтали. Если три игрока рядом, каждая надпись должна занять ближайшее к своему игроку место.
Я попробовал сделать каждому персонажу дочерний узел RigidBody, а его дочерний узел Label. И все надписи поместил на один Collision-слой. Сначала они сталкиваются, но потом сталкиваются как-то слабо.
Сделай втупую, сделай в лоб, как я зимой делал: лейбл сидит в ригидбоди, ригидбоди прикручено джойнтом к боде персонажа, когда персы сближаются, все их лейбл-блоки будут отталкиваться физическим движком и занимать удобное для себя положение.
Я тебе ещё спрайтов нарисую.
Ты только заходи...
хоть иногда...
Я ХЗ, ещё как минимум до конца июня ваще никак. Дел не в проворот. Ты пока спрайты рисуй, рисуй.
Рад, что ты жив, цел и орёл
Я сейчас немного другую пиксельную хуйню делаю, туда хоть кодить не надо, но как освободишься, хайдде тоже время найдётся.
> Че там кодить то бля?
Подскажи, как сделать в двадэ выглядящее симпатчно и удобно-играбельное вскарабкивание по вертикальным поверхностям. Это одна из фишек Хайди. Делать двадэ-клон Хайди без реализации её фирменной фичи, это будет хуйня какая-то. Очередной митбой.
Я пока что рассматриваю вариант с физикой: По бокам от капсулы персонажа расположены два физических тела в форме квадрата, которые двигаются вверх-вниз и немножко подворачиваются внизу к центру, что на тестовых сценах выглядит весьма няшно.
мимо тот самый кодер
убегаю, чмоке фсем в чати
Получается не очень. Можно сохранять данные в словарях, но не сгенерированную заранее по известным значения карту, потому что инстанцируется всё рантайм из кода.
Вот как это инстанцирование сохранять? Вручную все-все-все параметры вытаскивать и сохранять? Или как-то можно всё дерево сохранить?
upd.
Нашёл другой способ и реализую сейчас его. Это вообще валидно, или костыль какой?
https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
Пальцем в небо: у него длина "шага" больше расстояния до точки, вот он её и перешагивает. Надо если расстояние меньше определённой величины - телепортировать
> когда вызываешь queue_free, зануляй и переменную
А ещё лучше, как диды, сделать себе утилитарную функцию free_and_nil (у дидов в стандартных либах было, нам же придётся где-нибудь в утилитарном синглтоне объявить)
> func free_and_null(obj : Object, queue : bool = true):
> > if queue:
> > > obj.queue_free()
> > else:
> > > obj.free()
> >obj = null
> Если я не хочу
На нет и суда нет. Всё тобой вышеупомянутое сделано не просто так. Движок не просто так зовётся движком. У движка архитектура. Благодаря архитектуре ты встраиваешь в готовый продукт (в нашем случае игру) сторонние компоненты не абы как, а в строго определённые места и строго определёнными способами. Если бы ты мог просто импортнуть длл-ки, то какой же это движок? Так, голое ИДЕ.
Через шарп можно.
Может кто пояснить что за изменения будут?
Ну вот, видишь. Всё не так страшно. Но зато у тебя уже есть готовый адаптер (твой натив-плагин), который может распарсить полученные данные и распихать их по нодам годота.
Да стандартный вывод он и в африке стандартный. Было бы удивительно, если бы он не заработал.
Идея адаптера ( https://ru.wikipedia.org/wiki/Адаптер_(шаблон_проектирования) ) же в том, что твоя сторонняя либа ничего не знает о годоте. Годот ничего не знает о либе. А вот натив-плагин (адаптер) знает обоих и может через интерфейс годота обмениваться данными с годотом, а через интерфейс сторонней либы - с ней.
Ай, я там использовал Панель, а надо было ПанельКонтейнер
if child extends Container :
Ошибка:
Parse Error: ':' expected at end of line.
Хочу взять нод, запихнуть тайлмап, отчертить комнату.
И сделать таких комнат штук 5-6, чтобы потом склеивать ноды в разном порядке, чтобы строить уже уровни.
Говно идея? Может есть что по лучше из вариантов?
По мне лучше комнаты закодировать в текстовом виде, и на основе этого текста отрисовывать без лишней мороки с гуём.
Я когда-то в csv файлах хранил заготовленные комнаты.
Для рогалика збс, пара файлов - пара слоёв(пол\стены\враги\предметы), но чот для годота это хуета как по мне.
Или я может долбаёб и не разобрался ещё до конца.
Прячет.
>Очень часто потребность в сокрытии методов получения и установки значений возникает в связи с разработкой более богатого интерфейса, предоставляющего дополнительное поведение.
https://refactoring.guru/ru/hide-method
> я может долбаёб и не разобрался ещё до конца
Ставлю бочку нефти на это.
В нескольких прошлых тредах я неоднократно убеждал анонов, что данные игрового мира должны быть платформонезависимы, в случае с годотом платформой является сам годот, его иерархия классов и его дерево сцены. Ты должен хранить данные уровней без привязки ко внутренним потрохам годота. То есть, ни о каком тайлмапе описательный язык твоего файла данных знать не должен.
Потому что ему сигнал об изменении размеров не приходит. Пришли ему вручную этот сигнал.
Да вроде приходит. Послал вручную, не помогло.
Пускал сигнал в _процессе - тоже не помогает.
Если законнектить и в _on_resized() изменять марджин, случается Stack Overflow (Stack Size: 1024).
Как сделать-то
Короче, если сделать вот так
>func _process(delta):
>>emit_signal("resized")
>>margin_right -= 1
>>margin_right += 1
то сжимается, но это происходит не моментально, вижу сперва большую рамку, а потом тут же она становится маленькой.
Даже вот так достаточно
>func _process(delta):
>>margin_right -= 1
>>margin_right += 1
Происходило не моментально, потому что я удалял старые лэйблы через queue_free. Поставил просто free и ничего больше не дергается. И даже процесс не нужен. Во дела.
Mouse_exited() сам по себе хорошо отрабатывает, когда курсор покидает кнопку,
но при зажатой кнопке (когда прошёл сигнал button_down()), mouse_exited() не срабатывает когда курсор выходит за пределы кнопки.
Точнее сработает спустя какое-то время, когда отпустишь кнопку на мышке за пределами Button.
Это можно как-то порправить?
Лимиты установлены. Позиция камеры спокойно уходит за правый и нижний лимит.
Если совсем невмоготу и не фиксится, попробуй закостылить.
Когда камера обнаруживает какую-то деталь на правом нижнем лимите, включается скрипт "если позиция камеры > максимальный лимит, то позиция камеры = максимальный лимит"
Меня бы за такое половина кодеров выебла с особой жестокостью, а ЯнДев бы одобрил.
мимокрокодил
Каким образом шейдер узнает является ли это на рисунке домиком первого или второго игрока? Это только если здания выделять как указывает автор ниже.
>>750836
Для видеокарты - да, возможно дешевле. Для упрощения кодовой базы и вычислений - хуже. Грузить каждое изображение гораздо дороже, чем тайлмап.
Ведь как то раньше делали огромные тайлсеты под юнитов в героях 3. С кучей картинок и анимаций. И ничего, не лагало.
Эм, как ты видишь, видеокарта жрет на каждый пиксель 1 байт. Ей пофиг лоуполи там или нет. Она никак не оптимизирует изображение.
Это бы очень помогло. Я пытался писать такой шейдер, но тайлмапе было грустно от таких попыток.
Правда есть нюанс. Передние объекты могут цветом залезть на заднюю ячейку, где другой цвет игрока. Я могу как-то взяв ячейку с текстуры ее перекрасить?
Да похоже сами разработчики так рекомендуют делать
https://github.com/godotengine/godot-proposals/issues/685#issuecomment-611671983
В общем, я покопался и нашел самый дешевый способ. Через вижуал сервер делать канвас итемы, которые будут брать из дикта RECT'ы для обрисования тайла. После этого к ним прикрепляется один из шейдеров замены цвета у игрока. После этого канвас итемы можно перемещать и делать с ним что угодно.
Выигрыш:
- 150 мб видеокарты минимум
- Оперативка не заспамлена бесполезными параметрами объектов
-Все работает очень быстро, т.к. ты идешь напрямую в вижуал сервер.
Минусы:
- Если понадобится анимация, то работа с нодами будет проще чем канвасы.
- Распределять и перерисовывать в файлике все минимум сутки.
- Канвас итемы жрут ноды. После 4.2х тысяч нод годот превращается в тыкву (в билдах 3.2 тестил, сейчас хз). Можно рисовать на обычном канвасе, но на сколько понял, придется его перерисовывать, если объект надо нарисовать сзади.
А если я зуммировался, то как размер видимой области получить?
>get_porrige(porrige)
Пофиксил тебя. Хотя я всё равно не согласен, что для пориджа отдельная функция, уж лучше get_meal(porrige) если конкретный порридж, или get_meal(GLOBAL.MEALSARRAY.PORRIGE) если в принципе
> порридж
> порридж
https://pastebin.com/eT6XRcYi
А в самой игре срабатывает только когда курсор на границе прямоугольника CollisionShape
У меня Ареа2Д имеет детей-Контрол ноды. Поставил им всем майус фильтр Игноре, заработало.
Посмотри этот урок. Там малеха попроще
https://www.youtube.com/watch?v=L5QjuFe5Gys
Это чушь, о чем сказал Хуан здесь https://github.com/godotengine/godot/issues/1218
Не нервируй меня, движкосрачер, блядь! Зарепорчу!
Ты всерьёз считаешь это проблемой? И неприменимостью туториала?
Я из одного скрипта добавляю скрипт к другой ноде.
Первый скрипт:
> extends Node
> func _ready():
> > $"/root/Node/Sprite".set_script(load("res://Sprite.gd"))
Скрипт, который приаттачиваю:
> extends Sprite
> func _init():
> > print("Yop")
> func _input(event):
> > if event is InputEventMouseButton:
> > > print("Yep")
Функция _init() печатает Yop, что как бы говорит, что скрипт добавлен. А _input(event) не пашет. Хотя если скрипт добавлять вручную, а не кодом, то всё нормально.
У меня работает...Скинь скриншот сцены полностью, что ли.
Я рекомендую не использовать load для загрузки скриптов в ноды, если ты в точности не уверен, что хочешь именно загружать скрипты в ноды.
Лично для меня, после того, как Хуан ввёл именование классов, этот функционал стал deprecated. Load пусть грузит ресурсы (в том числе packed-сцены), а объекты я теперь создаю через языковые механизмы:
> class_name MySprite extends Sprite
и
> $"/root/Node".add_child(MySprite.new())
Однако, у тебя скорее всего Спрайт - это отдельно загруженная упакованная сцена без скриптов, к которой ты хочешь грузить разные скрипты. Тут надо крепко задуматься, всё ли ты правильно делаешь? ИМХО, загрузка скриптов в ноды - это утилитарный функционал движка и даже скорее редактора. В игре тебе надо всё иначе организовать. Заготовить скрипт с параметрами в сохранённой сцене. Инициализировать сцену параметрами после загрузки. Я бы так делал.
Задумка у меня простая. На сцене сотня спрайтов, и у каждого скрипт с _input(event) в которой проверяется mouse movement. Я вот думаю, не сильная ли будет нагрузка. По сути достаточно чтобы скрипт работал только у пяти спрайтов в определённый момент времени. Вот и хочу добавлять, убирать скрипты ненужным в данный момент спрайтам.
Нельзя его юзать. Тебе может понадобиться менять визуал у ноды. И этот код смены визуала ты явно будешь хранить в скрипте. А ты его вырубил.
>Я так понимаю, объясняют это тем, что если бы mouse_exited срабатывал то тут же начинали бы нажиматься соседние кнопки, при том что первую ты еще не отпустил.
Это кстати работает не только для кнопок: к TextureRect приконнектить два сигнала mouse_entered() и mouse_exited(), и они перестают работать, если зажать кнопку мыши, когда курсор находится над TextureRect.
Для себя пока нашёл такое решение: отказался от кнопок, вместо них использую спрайты, на которые вешаю этот скрипт https://pastebin.com/yztZazat
>И этот код смены визуала ты явно будешь хранить в скрипте. А ты его вырубил.
Хранить этот код в скрипте, который не будешь вырубать. Не?
>вешаю этот скрипт https://pastebin.com/yztZazat
UPD небольшая правка https://pastebin.com/BwS0wk6s
Вьюпортом. В UI-контролах даже есть такой. Во вьюпорте стало быть, рендеришь требуемый меш. Вьюпорт показывается поверх предыдущих нод и позади следующих.
> через интерфейс не нашел как добавить
Через интерфейс плеера анимаций можно вписать абсолютный путь к синглтону. Только есть один нюанс. У меня на 3.3.2. Ключи не добавляет, пишет, что требуется 3 параметра, а добавление вызывается с двумя. поэтому, если прям сильно надо, то сначала настрой анимацию на прокси-ноде того же типа, что и твой синглтон, затем замени путь. Пик рилейтед.
На твоём месте, если бы мне понадобился анимированный синглтон, я бы добавил анимационный плеер прямо в него, а ещё лучше - сразу связку из плеера и анимационной стейтмашины, всё настроил бы в редакторе, а в игре мой код бы просто делал что-то типа такого:
> Singleton.transit_to("new_state")
Да, это какое-то очень странное говно, ставлю абсолютный путь, пытаюсь добавить метод/параметр из синглтона, пишет неправильный путь, но если использовать сначала ноду из сцены, добавить метод/параметр и потом переименовать все под синглтон - работает без проблем. Никогда бы не догадался до такого обхода.
Ну что тут сказать? Это хак. В его классическом смысле (как лайфхак, только коде-хак). Что-то не задумывавшееся разработчиками. И что интересно, хак этот я придумал читая твой вопрос. Читаю пост, и такой себе думаю, я ж там клацал и открывался текстбокс с вводом пути вручную, а что если туда ебануть абсолютный путь до синглтона? И такой открыл, и такой ебанул, а он такой ключи не добавляет. А я такой путь вернул, ключ добавил, путь переписал, запустил - работает. И я такой - ОооООоо, чеэсвэээ!
>>751791
> Что нового?
Говорят, Хуан в четвёрке все попапы сделает в отдельных окнах. Или не все? Поясните, посаны. Это какая-то хуйня, если он так сделает. Мне например внутриоконные псевдоокна, которые есть сейчас, больше подходят.
> Мне например внутриоконные псевдоокна, которые есть сейчас, больше подходят.
К хорошему быстро привыкаешь.
Вот же, не?
У меня все нарисовано через визуал сервер. Я столкнулся с проблемой апдейта ридов и подсчета тика без таймера через сохранение инты предыдущего тика времени ос.
Крч у меня 2 проблемы.
1. Я хз как обновлять рисунок сделанный через VisualServer.canvas_item_create()
2. Я хз как по времени OS сделать нормальную обработку анимаций через redraw
По первому пункту ящитаю (с дивана) что редактор так же делает, например, когда в запускаемом проекте ты выставил галочку "показывать коллизии". Он эти коллизии рисует напрямую через АПИ вижуалсервера (осторожно, диван!) поэтому я бы глянул исходники редакторной части движка, чтобы подглядеть, как это реализовано там.
По второму пункту примерно то же, только непонятно зачем тебе время ОС, один хуй там те же тайминги, что приходят в мейнлуп (тоже диванное предположение, требуется проверка, но впадлу).
Разобрался. Вызов VisualServer'a идет отдельным потоком в движке, и годот прост не успевал почему-то получить новые параметры для перерисовки.
По второму пункту ещё не пробовал. Мне хочется, чтобы object'ы которые висят в памяти и не имеют нод спокойно себя рисовали и анимировали сами, либо через такую же обертку не несущую оверхеда
Вижу, что на оф. сайте можно скачать отдельную версию с поддержкой Mono. Вопрос такой: в стим версии есть вообще поддержка Mono?
Тоже не понимаю. Может Хуан изначально местный ассетстор планировал через стим воркшип организовать, хз.
Как сравнить кастомные классы?
Но я не могу получить класс кастомного объекта. Я его не создам, не прописав заранее класс в код. А значит не смогу сделать обертку для object на века.
Вот игра на годоте.
https://2ch.hk/gd/res/747551.html
Вот как товарищ погромизд освободится, так может и продолжим делать.
Делаю одиночные плитки, могу кодом выставлять через set_cell, делаю атлас и могу только первую картинку юзать из атласа.
Типо кодом только одиночными плитками можно пользоваться и автотайлами?
В глес 3 жалуется мне на какой то буфер, блеать. В редакторе работает, в игре нет. Мб я какую настройку в проекте не включил, хз
Вот такую муйню получаю.
E 0:03:52.159 copytexscreen: Can't use screen texture copying in a render target configured without copy buffers.
<C++ Error> Condition "storage->frame.currentrt->effects.mipmaps[0].sizes.size() == 0" is true.
<C++ Source> drivers/gles3/rasterizercanvasgles3.cpp:1259 @ copytexscreen()
BackBufferCopy почему-то не работает. Я без понятия как его использовать.
Я не понимаю что происходит. Я взял шейдер из оф демки, поместил на спрайт и получаю ошибки
Шейдеры - штука капризная, если ты конкретно не знаешь, что именно ты делаешь - шейдеры тебя выебут. И они тебя судя по постам уже ебут, ибо ты копипастишь. Что посоветовать тут? Совет может быть один: пиши свой шейдер с нуля.
Я и пишу свой шейдер с нуля. Есть что по делу сказать? Почему шейдер у которого логика "вода наехала на что угодно фоном != цвета фона сделай белым" - не работает на весь экран?
> Есть что по делу сказать?
Есть.
> Почему шейдер не работает
Потому что ты не разобрался в вопросе и не знаешь, что ты делаешь.
Это не троллинг.
Это мой личный опыт, в геймдеве, в годоте и вообще в айти.
Предлагаю тебе пикрелейтед.
У меня канвасы которые нарисованы через visual server поверх node2d. Чтобы их выстраивать попорядку, я использую z index, но что-то мне подсказывает, что у годота есть на z-index оптимизон, отрубающий получение скрин текстуры? потому что шейдеры работающие непосредственно с текстурой канваса - в порядке.
Угол наклона камеры, эт я конечно шизофразно спиздел. В общем в зависимости от положения камеры шейдеры либо включаются, либо отключаются, хотя канвасы ещё в камере (но видимо годот думает, что уже нет).
>>753105
Естественно я не разобрался в вопросе. Потому что я нахуй не понимаю, что происходит. Я делаю шейдер, на тестовом полигоне он работает как надо. Сую в мейн сцену, а игра думает, что моя камера не смотрит на объект и вырубает работу шейдера нахуй. Покажи мне пожалуйста документацию, где описано такое поведение, чтобы я разобрался.
> Покажи мне пожалуйста
Мне лень. Я лучше пивка ещё ёбну за твои успехи. Давай, успехов там тебе! И хорошего настроения!
Отбой. Мысль про z-index не верная. Все равно нихуя не пашет
Зачем он? По сути в 3.3 есть все что нужно для разработки игр.
Судя по всему:
- backbuffercopy уникален на каждый рид, тем самым превращая устройство андроид, где больше 10+ шейдеров с SCREEN_TEXTURE в лагающее говно.
- Каждый текст до сих пор вызывает draw call, будь то label или что-то иное, вроде draw_text().
- Канвас итем если состоит из нескольких текстур - вызывает 3 дравкола. Да, движку не интересно склеить все текстуры в одно внутри канвас итема и реюзать.
Вопрос в следующем, когда оптимизон от движкопись?
У меня до сих пор бомбит, что на рисование 30 символов выделяется 20 мб оперативы.
> когда оптимизон от движкопись?
Форкай и делай сам. Не жди Хуана.
Как только ты напишешь "зачем мне форкать, у меня есть юнити/уеч/гамак/итп" - на тебя моментально от меня летит репорт за движкосрач со всей любовью, побрацке, ногомо.
Кочай бетку прямо сейчас https://downloads.tuxfamily.org/godotengine/testing/ не будь лохом! Не жди альфу.
Кубы содомируются на Вулкане.
Бле, я так то на годоте игру хотел доделать без форков. А то я сейчас форкану, починю эту залупу или хотя бы методы себе в годот выведу, а за это время движкописи новой версией починят другие баги, на которые я натолкнусь завтра.
Может есть кто знает фишку/костыль чтобы это обойти или имеет влияние в кругах движкопись,чтобы они в работу взяли?
Нужно быть кабанчиком. Если ты кабанчик, ты подскочишь, порешаешь вопросики, Хуан и Акиен мигом твои пулл реквесты одобрят.
Так они были всегда.
А что в 3.4 будет? Никак не могу найти заявленных фич
rotate_object_local ( Vector3 axis, float angle ) - вращение в координатах самого объекта (object space)
global_rotate ( Vector3 axis, float angle ) - вращение в координатах world space
rotate ( Vector3 axis, float angle ) - это вращение в координатах родительского объекта (parent space), правильно?
Чтобы понять, следует читать матчасть. На твоём месте я бы загуглил GLSL и там уже по ссылочкам читал джва месяца.
Есть атлас 900х900.
Есть выбранная картинка 300 на 300.
Как шейдером разделить картинку на 8 равных частей?
Как перевернуть изображение через шейдер?
Потом я добавляю в него Label-ы через код, по идее его margin-ы и размер должны измениться же?
Потому что все показывается нормально, но в коде эти переменные не обновляются после добавления Label-ов.
Как в связи с этим получить актуальные размеры контейнера?
UV атлас текстуры работает не так. Он разделит всю текстуру на 8 частей, а не выделенную часть.
Нет, атлас текстура уже порезала мне на 9 элементов 300 на 300.
Я беру по случайному куску 300х300 UV и получаю UV по всей текстуре, а не по этому куску. И соответсвенно этот кусок не могу поделить штатными методами.
Тайлмап. И атлас. И не передаёт в шейдер, а один раз на видюхе закешил и берет от туда регионы. По крайней мере так должен делать нормальный движок.
Чел деление на регионы делается на проце, какой нахуй шейдер, кеш и ещё какая залупа. Просто, если нужно отрисовать несколько регионов этой тайлмапы, создаётся батч и эта текстура уходит на отрисовку, где каждый регион указывает свой прямоугольник. Всё. Никакой хуйни. Так работает любой тайлмап под капотом в любом движке, фреймворке, библиотеке.
https://www.youtube.com/watch?v=hQ1j5R5IG6g
Рано или поздно от этого старья придется отказываться. Сейчас лучше сосредоточиться на Vulkan.
> оправдывают удаление GLES2
Но ведь удаляют глес 3. Пруф пик:
Появляются тут такие аноны, но редко, на быструю помощь не рассчитывай. Рикаминдую ютуб. Сканера знаешь? Он делал подробный туториал по сборке на андроид.
Выключи HDR или жди мержа.
https://godotengine.org/qa/53982/noticed-that-antialiased-setting-polygons-doesnt-anything
Хбт сделано под андроид на годоте. Под айос года полтора назад были баги в 3.1. Возможно поправили.
Спасибо конечно, но я же специально выделил слово ВСЮ. Грубо говоря так же, если бы я закрыл и открыл игру.
> если бы я закрыл и открыл игру
OS.execute("path/to/game")
get_tree().quit()
Круто, очень близко к тому что я хотел. Я пытался сделать настройки, которые включаются только при перезапуске игры. В итоге сделал временно костыльный недоспособ, но пока хватит.
Если ошибка отсутствует, все норм. Если присутствует - все крашится к хуям. Не хочу, чтобы крашилось.
Как сделать так, чтобы это говно начало мне возвращать ошибку?
Вот тут не возвращается ошибка, что меня раздражает. Он просто роняет игру и все.
Тоже. Эта хуйня всегда возвращает 0. Ей норм. А потом берет и роняет игру с ошибкой. Сука, ебаный хуан.
все уже просмотрено, про прыжки нигде не говорят, а у меня именно они косо работают, впрочем похуй, решил своей головой думать и переписать с нуля.
Конечно, и возврат ошибки о ней. Но хуан на столько жесток, что РОНЯЕТ НАХУЙ ВСЕ при проверке на парсинг, и возвращает ошибку только если при компиляции срабатывает какая-то переменная can run. Я в шоке. Кто-нибудь знает как поправить код и перекомпилить годотю? А то я на С++ на винде заебусь пакеты качать.
Если кто-то знает как из годота достучаться до:
GDScriptParser - буду благодарен.
Я хочу сам написать этот код на гдскрипте и вкинуть куда-нибудь в консоль или в текстовую ноду.
Как пользоваться нативскриптом так и не разобрался. Если есть норм примеры, дай плз. Тогда я тупо попробую скопировать парсер и анализатор.
Я гдскриптом буду запускать питонопарсер, чтобы понять запустился ли гдскрипт?
Я попробовал через ос экзекют, он орет с незнакомого символа юникода. Если у тебя есть работающий пример - будет хорошо.
Я бы хотел попробовать сделать прототип, где каждый игрок пишет скрипт своему персонажу, чтобы проходить уровни. Я могу запустить нормальный скрипт, но не могу отловить ошибку чтобы показать, что скрипт кривой. А так же не могу отловить ошибку, чтобы откатить выполнение скрипта, чтобы игрок мог продолжить исправлять скрипт.
Последнее что я хочу - это писать свой лексер и парсер)
Вообще, как только кто-то накостылит плагин/ещё что-то позволяющее пользакам адекватно встраивать скрипты в твою игру, это позволит расширить аудиторию годота, хотящих побырому наверстать такого рода игры. Возможен даже асинхронный опенвлрлд, где каждый пишет свой объект и грузит скрипт на сервер, чтобы другие игроки их выкачали.
Это устанавливать студию и мучится с прикреплением ее к годоту. Поэтому проще тогда уж на юнити.
В общем, тяжёлый пакет говна и то и другое. В гдскрипте прелесть в том, что он весит мало и запускается на любом калькуляторе.
Ну да, только как писать токены на кондишены и на for() я пока не знаю.
>>757675
Выглядит здорово!
Ну на псевдоязыке такие паттерны я тоже могу к чему угодно написать) А вот как дело до областей видимости дойдет, там не все так просто.
\.nuget\packages\godot.net.sdk\3.3.0\Sdk\Sdk.props(29,3): Не удается найти пакет SDK для .NET. Убедитесь, что пакет установлен и версия, указанная в файле global.json (если он имеется), соответствует установленной.
Короче т.к. папочка была ещё на 86х, хуанокод не мог залезть в 64х. Я в шоке.
Сделал математические, логические и операции сравнения. Установку/получение переменных. Вызов дефолтных функций с любым количеством параметров (без возврата/с возвратов значения). Ифы.
Остались циклы, объявление функций и вызов функци игрока. Потом полировка и все, можно писать игры на программирование.
> Почти дописал свой парсер языка
>>757669
> Я бы хотел попробовать сделать прототип, где каждый игрок пишет скрипт своему персонажу, чтобы проходить уровни.
В шапке описан вариант, как такое сделать без танцев с бубном. Правда из-за полного доступа к скриптингу, такой проект будет беззащитен против крыс.
>>747202 (OP)
> - Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе).
Данный метод прямо позволяет не ебаться с подгрузкой скриптов в рантайме, а просто модифицировать весь проект на лету (в том числе редактором, и даже лучше редактором), а потом перезапускать "game.exe" в корневой папке проекта.
Ты про аддон диалоговой системы который работает на экспрешенах?
Осталось функции запилить и отлаживать. Возможно, будет работать в разы быстрее чем гдскрипт, лол.
Так, вызов пользовательских функций и скопы сделал. Осталось потестить пару дней и можно в релиз, писать игру вокруг всего этого.
Я про шаблон экспорта, который по сути является запускным файлом игры. Когда ты делаешь "экспорт", редактор пакует все файлы проекта в PCK кладёт его в указанную тобой папку и рядом кладёт "шаблон экспорта", который по сути является запускным файлом игры. Однако, как написано в ОП-посте, если просто положить в папку с проектом шаблон экспорта, и кликнуть по нему, он запустит игру прямо из проекта.
Таким образом, внутри игры не нужно делать загрузку скриптов, а достаточно только открывать, изменять и записывать файлы GD, после чего перезапускать связанные с ними сцены. Тоже внутри игры. Первоначальную отладку сделать в редакторе, а дальше хуярить внитриигровыми инструментами. При этом моддерам твоей игры весь редактор годота станет доступен как редактор игры. Что в некотором роде небезопасно.
Это уже будет не моддинг, а чистое комьюнити-редактирование игры целиком. Тут уж впору организовывать контроль версий и апрувить пуллреквесты.
Я как бы могу скрипты и из годота релоадить. Твои шаблоны экспорта ошибки позволяют отлавливать в коде?
> Твои шаблоны экспорта
> Твои
> Твои
Мопед не мой. Я просто разместил объяву.
Порекомендуй свой, Бардинов, хуле скромничаешь?
>>758693
Телепаты в отпуске. Я позвонил им, они говорят
> пусть пакет нацеливания переустановит
> пусть восстановит удалённые сборки
> пусть перезапустит годот
>Порекомендуй свой, Бардинов, хуле скромничаешь?
Чиво блять?
Таво, блять. Не отпирайся. Запостил свой вопрос с правильно написанным Google Play In-App Review по которому в гугле первым постом вылезает годот-плагин на гитхабе за авторством некоего И. Бардинова. Рекламируешь свой плагин? Распиши его плюсы и минусы ИТТ.
Шизоид, что ты несёшь. https://developer.android.com/guide/playcore/in-app-review
Зачем обзываешься, Бардинов?
Странный человек, сам какой плугин используешь?
>Последнее что я хочу - это писать свой лексер и парсер)
Попробуй сделать имплементацию Forth. Вся машина пишется примерно за день-два.
>не могу отловить ошибку чтобы показать, что скрипт кривой
У Форт-машины очень мало ошибок, которые легко отловить:
- стек пуст (попытались снять число с пустого стека)
- стек переполнен (практически неактуально на современных ПК)
- слово не найдено (обратились к слову, которого нет в словаре)
Такие вещи как деление на ноль обрабатываются самими словами, а не Форт-машиной. В твоём случае обработка подобных ошибок будет на GDScript, что-то вроде "вызвали слово деления, но второе от вершины слово - ноль, значит нужно кинуть ошибку деления на ноль". Хотя можно сделать и на самом Форте (собственно Форт пишется на Форте, не считая самых примитивных слов)...
Плюс Форта для игры - не нужно никакого GUI и подсветки синтаксиса, достаточно имитации консольки. Правила языка настолько просты, что разберётся любой человек, особенно если он ничего про программирование не слышал.
Далее, ты можешь описать базовые игровые слова, например: идти поворот толкнуть открыть проверить закрасить и т.д. Каждое слово может использовать некоторое количество чисел со стека, например, слово идти берёт со стека число клеток, на которое нужно передвинуть фигурку персонажа в направлении его взгляда, а слово поворот берёт направление поворота (0/1 или 0-3). Игрок может мгновенно взаимодействовать с персонажем вот так:
>10 идти 0 поворот толкнуть 5 идти
Получается "пройти 10 клеток, повернуть налево, толкнуть препятствие, попытаться пройти ещё 5 клеток вперёд", при этом игровой персонаж выполнит эту программу после нажатия enter. Далее можно использовать подпрограммы - слова:
>: пройти-по-кругу ( диаметр -- ) dup идти 0 поворот dup идти 0 поворот dup идти 0 поворот идти ;
>2 пройти-по-кругу 5 пройти-по-кругу 10 пройти-по-кругу
Здесь мы объявляем слово пройти-по-кругу, которое возьмёт одно число со стека и ничего на стек не положит (см. комментарий в круглых скобках, общепринятый формат "берёт -- отдаёт"), в процессе оно дублирует (dup) число на вершине стека для своей работы, но это уже детали реализации. А дальше самое интересное - ходим кругами (квадрат тоже круг, только квадрат) с диаметрами 2, 5 и 10, или ещё сколько угодно. Можем использовать это слово в другом слове. А можем переписать этот код так:
>: влево ( -- 0 ) 0 ;
>: идти-и-повернуть ( направление расстояние -- направление расстояние ) dup идти swap dup поворот swap ;
>: пройти-по-кругу ( диаметр -- ) влево swap идти-и-повернуть идти-и-повернуть идти-и-повернуть идти drop ;
Кстати, повторное объявление пройти-по-кругу перезапишет предыдущее, и в результате в последующем коде мы будем обращаться к самому свежему объявлению этого слова, а на весь предыдущий код это переопределение никак не влияет, что очень удобно в некоторых случаях.
Данный код, во-первых, стал читабельнее, во-вторых, теперь можно будет использовать слово идти-и-повернуть в других словах, например, в хождении зигзагом:
>: вправо ( -- 1 ) 1 ;
>: зигзаг ( длина-шага шаги -- ) 0 do влево swap идти-и-повернуть drop вправо swap идти-и-повернуть drop loop ;
>5 10 зигзаг
Тут использован цикл со счётчиком, который позволяет выполнить код указанное число раз. Всё просто и понятно, если предварительно ознакомиться со стандартными словами и порядком аргументов.
Короче, Форт очень хорошо подошёл бы для программерской игрушки любого уровня сложности. Вместо набора слов можно использовать визуальные фишки, которые размещаются мышкой в последовательность (те же условия и циклы можно заменить крупными фишками с "окошками" под фишки), в общем, есть простор для упрощений. А главное что Форт-машина легко пишется на любом ЯП и по сравнению с современными языками крайне быстрая и экономная, в идеале даже быстрее компилируемых ЯП высокого уровня (если сама Форт-машина на ассемблере, но это не наш случай), а компиляция выполняется по отдельным словам в момент их написания (это не так страшно, как звучит). В качестве базовых слов можешь использовать что угодно, ты не обязан следовать стандарту Форта, у тебя свой язык под свою задачу.
мимо джва+ года мечтаю о такой игре с Фортом
Так и знал, что ошибусь в коде, вот исправленная версия:
>: зигзаг ( длина-шага шаги -- ) 0 do влево swap идти-и-повернуть swap drop вправо swap идти-и-повернуть swap drop loop drop ;
По-русски:
- изначально вершина стека выглядит так: ... длина-шага шаги
- первое число с вершины (шаги) вместе с 0 "съест" do как начало цикла (аналог for)
- потом кладём на вершину "влево" (0), и обмениваем местами (swap) с "длина-шага"
- выполняем слово "идти-и-повернуть", которое сохранит вершину стека нетронутой
- однако "влево" нам больше не нужно, поэтому сбрасываем его (swap drop)
- и теперь кладём на вершину "вправо", снова крутим (swap)
- выполняем второе "идти-и-повернуть", снова сбрасываем направление (swap drop)
- повторяем цикл (loop) пока не досчитаем до "шаги"
- сбрасываем оставшееся "длина-шага" (drop)
Кажется что слишком сложно, но на самом деле всё просто, ощущение сложности создаёт количество операций со стеком и обратная польская запись, но ко всему привыкаешь и принимаешь это как единственно возможное решение любых задач)
Это очень интересный комментарий, потому что я уже написал свой компилируемый парсер для годота который умеет в базовые конструкции люого языка. Почему твой комментарий интересный? Потому что он интерпретатор. Но уже не охото переделывать.
>он интерпретатор
Что интересного в простом интерпретаторе? Правда, Форт-машина - не простой интерпретатор, от интерпретатора в ней только интерактивный режим (как в консоли питона или консоли JS), а все новые слова компилируются в шитый код по мере их поступления (из консоли или из файла). В интерактивном режиме Форта невозможно делать некоторые вещи, например, нельзя напрямую использовать ветвление и циклы (только в составе вызываемых слов). Но для простого управления персонажем этого должно быть достаточно, а для чего-то большего описываешь слова и они моментально компилируются.
А что ты сделал? Как так "умеет в конструкции любого языка"? Некоторые языки очень сильно отличаются друг от друга.
У меня есть:
- создание кастомный функций пользователем
- вызов этих самых функций
- вызов подкапотных функций написанных мной
- обязательность функции Мейн откуда пойдет начало скрипта
- циклы форич, вайл
- ифы
- области видимости
- переменные интового и булевого типа
- математические формулы (плюс, минус, умножить)
- логические операторы - энд, ор, нот
- операторы сравнения - равно, не равно, больше, меньше, больше или равно, меньше или равно
Ну дальше надо дотестить и мб массивы добавить для удобства.
func main(){
@b = 5;
@g = 1;
for @tile_num in tiles(){
@b = @b+@tile_num;
}
g(@b, @g);
}
func g(@a, @g){
if (@g == 1){
print(@g);
}
print(@a);
}"
Вначале была явная инициализация, через вар. Но потом мне показалось это скучным и лишь мешающим пользователю. Плюс переменные с собачками явно видно.
> упрощая парсер
Каким образом он упрощает парсер? Вместо case else (в который попадают переменные в парсерах здорового человека, когда все ключевые слова обработаны, а значит остались только объявляения переменных) у него дополнительный case @.
>>759039
> скучным и лишь мешающим пользователю
Очередной аутист, блять.
Жаль что ты неуч ебаный, который ни одного парсера в глаза не видел и выдумывает как оно работает.
func main(){
b = 5;
g = 1;
for tile_num in tiles(){
b = b+tile_num;
}
g(b, g);
}
func g(a, g){
if (g == 1){
print(g);
}
print(a);
}
> ты неуч ебаный, который ни одного парсера в глаза не видел
Смешные заявления от неуча, видевшего ОДИН парсер-...
>>759100
..-.токенизатор
Смешно читать заявления от неуча, который экстрополирует свою проблему на других.
> ты неуч, яскозал
Аргументация - моё почтение.
У меня нет проблем с парсерами, такшта мне нечего экстраполировать на залётного тролика, демагогящего редукцией к невежеству.
Ты поздно с детского сада приходишь. Троллики у него, нет ты дурак. Просто пиздец.
Нужно удалить в програм файлсе 86 папку с net залупой, если она присутствует в х64. + скачать говно именно той версии, которую поддерживает годот.
Опять годот виноват в том, что залётный движкосрачер вкатился в опенсорц на инвалидной коляске, свалился на первой же кочке и был выебан древним, отточенным механизмом опенсорца на потеху всех УМВР-пасанов.
Да это уже много, до этого годот был непригоден просто к 3д, а сейчас сразу считай твердочёткий прорыв. Рывок со дна поносного до альфа центавры. Вопрос по производительности остаётся. Осталось заменить гдскрипт на сишарпу. Хотя надо узнать, они же там что-то переделывали, производительность может увеличилась?
У меня сейчас в настройках Environment: Background - Color+Sky. Могу менять цвет фона, но хотелось бы туда присобачить текстуру.
Спасибо, это мне подходит. Сейчас буду учиться растягивать его на весь экран.
>во вьюпортах нет ничего страшного
Они мне фпс просаживают.
Вопросы:
1. Чё как с оптимизацией? Я читал про то, что _draw() выполняется один раз (обновить можно только вызовом update()) и результат кэшируется, но что на счёт видимости на экране - кулинг есть?
2. Как прикручивать физику? Создавать отдельные ноды статикбоди с кучей коллижншейп под каждую зону? Тайлмап ведь именно так делает, только скрытно от юзера?
3. Стоит ли вообще смотреть в сторону тайлмап, если мне не нужна сортировка по Y, разворачиваю тайлы я через код (я пробовал автотайлы, там нужно много лишнего рисовать, не умеет он использовать один тайл в 4 ракурсах сразу, очень жаль), а необходимость делать все тайлы заранее и одного размера меня сильно ограничивает? Заполнение и настройка тайлмапы выглядит как лишние телодвижения, если я могу просто спамить draw_rect().
4. Я правильно понял, что если какой-то тайл имеет полупрозрачность, нужно создавать отдельную тайлмап, на которой будет фоновый тайл? Что-то я не нашёл переключения слоёв, как, например, в Tiled. Полупрозрачность нужна для совмещения разных типов тайлов, но без нескольких слоёв ничего совместить не получится. Довольно странно создавать отдельный тайлмап, при том что вручную я мог бы нарисовать гораздо быстрее (в один проход).
>основную сцену перенесешь во вьюпорт, отрендеришь в текстуру и выведешь поверх спрайта
Кстати, это возможно как-то сделать без мерцания экрана? Я пробовал сделать рендер мира в контрол на экране, но если просто перенести сцену во второй вьюпорт, вьюпорт ничего не рендерит до следующего кадра (чёрная картинка на выходе). Если использовать yield (ожидание следующего кадра), то на экране видно мерцание из-за того, что основной вьюпорт рендерит пустую сцену один кадр, пока сцена не вернётся из второго. Так и не понял, как от этого избавиться, и просто нарисовал весь мир простыми формами на картинке, но всё равно интересно, как это правильно делать, чтобы ничего не мигало.
другой анон
>Если использовать yield, то на экране видно мерцание
В том числе и из-за этого тоже отказался от вьюпорта, это даже хуже чем снижение fps.
тот самый анон
Ещё про фпс: почему-то на линуксе и в html5 drawcalls в два раза больше, чем на андроиде для одной и той же игры.
>Я читал про то, что _draw() выполняется один раз (обновить можно только вызовом update()) и результат кэшируется, но что на счёт видимости на экране - кулинг есть?
Ээээ, короче, я потестил. Кэширование и кулинг действительно присутствуют, но есть и нюанс...
1. В "кэш отрисовки" судя по всему, загоняются вызовы функций, а не текстура. То есть если 64 квадрата полностью закрывают большую площадь - норм, если квадратов 4096 на той же площади - у меня просадка до 16 фпс. Я ожидал кэширование в виде текстур...
2. Если ни одного кусочка нарисованного на экране нет, то оно и не рисуется, фпс на 75. Как только на экране появляется хотя бы один пиксель, все эти 4096 вызовов вступают в бой и просаживают фпс. То есть кулинг идёт по целой ноде, а не тому, что нарисовано. Тут я ничего хорошего не ожидал, т.к. ожидал кэширование текстурой.
Из этого следует вопрос, как превратить нарисованное в текстуру, не извращаясь с вьюпортами? Мне бы функцию типа get_texture() или convert_to_texture(), но я не нашёл. Когда ищу "how to draw to texture" поисковик выдаёт обсуждения на тему "как рисовать во вьюпорт", но мне не нужен вьюпорт, мне нужно кэшировать рисунок в текстуру.
Кстати, на SDL2 это делалось очень легко, быстро сделал чанковую отрисовку с кэшированием через текстуры, фпс был очень хорошим. А здесь что-то непонятное...
>мне не нужен вьюпорт, мне нужно кэшировать рисунок в текстуру
Ладно, не важно, я уже сделал через вьюпорт. Похоже, вьюпорт - единственный способ рендерить в текстуру. Правда, потом приходится повторно вызывать _draw() для очистки рендерера, т.к. пусть даже его не видно в основном вьюпорте, он всё равно рендерится во втором.
У меня такая система получилась:
- в сцене есть второй вьюпорт
- в нём камера и node2d
- нода содержит скрипт рендеринга в текстуру
- чтобы отрендерить что-то:
1. передаём ноде информацию о том, что рендерить
2. вызываем у ноды update() и делаем yield(VisualServer...)
3. в _draw() происходит отрисовка
4. там же делается yield(VisualServer...)
5. текстура из вьюпорта сохраняется в last_texture ноды
6. нода переключает себя в режим очистки
7. снова вызывается update() и yield(VisualServer...)
8. в _draw() ничего не рисуется (очистка кэша)
9. возврат к п.2, переносим текстуру из last_texture в спрайт
Что я ожидаю:
1. Тот, кто запрашивает рендер, ждёт текстуру.
2. Нода-рендерер делает текстуру и возвращает её.
3. Запрашивавший текстуру получает её и довольно урчит.
4. Нода-рендерер чистит свою _draw(), не трогая текстуру.
Что получается: текстура рендерится, но запрашивающий получает неактуальную текстуру, а предыдущую. Если запрашивающий делает два yield(VisualServer...) подряд, то ВНЕЗАПНО происходит две отрисовки текстуры подряд, что в 2 раза затратнее, чем могло бы быть, но текстура приходит верная. Если запрашивающий не делает yield(VisualServer...) совсем, текстура вообще не приходит или приходит какая-то не та, возможно предпредыдущая, сложно понять.
Как это решить? Мне нужно чтобы _draw() вызывался только два раза, а не четыре, но при этом нужно получить текстуру вот прям сразу, а не в следующий раз. Я пытался делать yield(update(), "complete"), но судя по ошибкам в консоли, update() не является функцией (лолшто).
Вообще читал про yield, странный какой-то механизм, тяжело представить себе его работу.
Ладно, я уже сам разобрался.
>ВНЕЗАПНО происходит две отрисовки текстуры подряд
Это я сам виноват. У меня отрисовка текстуры происходит по проверке одной переменной, значение которой менялось после yield, в итоге всё это срабатывало дважды. Перенёс одну строчку и теперь всё один раз выполняется, как задумано.
>запрашивающий получает неактуальную текстуру, а предыдущую
А вот это связано с очень странным поведением yield: если вложенная процедура останавливается ждать чего-то, выполнение вызывающей её процедуры продолжается так, будто процедура уже завершилась. Пример:
func f1():
_ f2()
_ print("1")
func f2():
_ yield(VisualServer, "frame_post_draw")
_ print("2")
Вопрос: что будет выведено? 21 или 12? Логично предположить, что должно быть 21, т.к. f2 по идее остановлена и вместе с ней остановлена f1. А нет, на самом деле yield ставит метку "вернись сюда, когда %сигнал%" и всё, дальше программа выполняется как если бы f2 уже завершилась, и ответ будет 12.
Я обнаружил это только после того, как обмазался print() и начал беспорядочно тыкать yield во все места. Потом догадался создать дополнительный signal, чтобы приостановить вышестоящую процедуру (в примере это f1) и всё заработало. Как-то так:
func f1():
_ f2()
_ yield(self, "f2_done")
_ print("1")
func f2():
_ yield(VisualServer, "frame_post_draw")
_ print("2")
_ emit_signal("f2_done")
Мне кажется, что это жуткий костыль, но по-другому будет только костыльнее. Имхо, о таком должны в мануале большими буквами писать, а то даже если это где-то и написано, я не нашёл. Уж точно во встроенной справке ничего об этом нет...
Я вспомнил, что меня запутало:
https://docs.godotengine.org/en/stable/tutorials/viewports/viewports.html
>But if you use this in _ready() or from the first frame of the Viewport's initialization, you will get an empty texture because there is nothing to get as texture. You can deal with it using (for example):
># Wait until the frame has finished before getting the texture.
>yield(VisualServer, "frame_post_draw")
># You can get the image after this.
Я зацепился за это "wait" и думал, что весь мой код останавливается, или по крайней мере весь код из одного скрипта. А если выполнение продолжается как после return, то это никакое не "wait", не знаю, как это правильно назвать. Могли хоть предупредить, что "ждёт" только одна конкретная функция...
Ты чего так расстроился-то?
Ну не успели и не успели, да и хрен с ним! Ещё доделаем.
= Vector2(0, 0)
или
.x = 0
.y = 0
?
Годогвардейцев пошли, пусть отпиздит шатателей киберлодки.
> Как лучше обнулять вектора:
1. Выбираешь несколько способов, предложенных выше.
2. Оборачиваешь каждый способ в функцию.
3. Запускаешь каждую функцию в цикле 999999 раз, подсчитывая время выполнения.
4. Выбираешь ту, которая выполнялась быстрее всего.
Ну и кто вы после этого?
Прости анончик-рокетджамповый-попрыгунчик. Было 10 тредов назад. Никого не заинтересовало (меня тоже). Добавить в шапку?
> Вообще в таких случаях за пару часов можно написать конвертор, который берет графон и коллижны с тайлмапа и генерит по ним гридмапу
А есть готовые расширения?
Не надо, я гипотетически спрашивал. В принципе, наверное, даже коллижнов не надо, раз все плоское будет, я их могу отдельно поверху нарисовать.
> от встроенного редактора тайлов в годоте жопа горит у многих
Горела во времена 3.0. Нынче он стал поюзабельней. И главное - сторонние редакторы, увы, не обеспечат никогда полной поддержки фич.
Ну ка покажи мне, как в стороннем редакторе создаются настроенные и функциональные автотайлы. С коллизиями и окклюзиями где надо.
Не знаю. Не интересуюсь древностью, не испытываю ностальгии. С удовольствием играю в ремастеры денди-игор, без уёбищных пикселов. Ненавижу уёбищное лоуполи плойка-стайл. Извини, не могу тебе помочь.
Тем временем близится время, то самое время, время перекатывать штрендовс. Давайте припомним, кто что хотел в шапочку вшить?
Нахуй ты отвечаешь тогда, говна кусок? Всем глубоко насрать, что ты там не испытываешь и во что ты там с удовольствием не интересуешься, человек конкретный вопрос задал, если тебе нечего по теме ответить - молчи в тряпочку.
> Нахуй ты отвечаешь тогда, говна кусок?
Чтоб добить до бамплимита, очевидно же!
ПЕРЕКАТ
>>766120 (OP)
>>766120 (OP)
>>766120 (OP)