Спасибо чуваку напомнившему про камеру. Все получилось. Нормально вычисляю через трансформы положение элементов.
Я вообще нерекомендую CanvasLayer, странный он какой то. Да я знаю что в новичковой документации его рекомендуют для гуя, но то ли это легаси, то ли он для простых игр, типа в платформере очки показывать - для более сложных взаимодействий с гуем он требует напильника.
Хмм. А что использовать? Просто контрол ноды в главную сцену вставлять?
В прошлом треде писал как у меня
ВьюпортКонтейнер - Вьюпорт нужного размера - инстанс сцены с уровнем, камерой и игроком
После него все гуи ноды какие нужны.
Вроде все просто, быстро и удобно. Единственное что надо понастраивать ресайз окна, если планируется.
Чот сложна.
> Вот я хочу, перемещать камеру по экрану, но GUI оставался на месте. Поместил интерфейс в узел CanvasLayer, который специально для этого, но теперь я не могу кликать сквозь этот CanvasLayer. А как?
Сорян за поздний ответ. У тебя в канваслеере по умолчанию первая контрол-нода разворачивается на всю доступную площадь (Макет -> Полный прямоугольник). И! И перехватывает события мыши на себя.
> CanvasLayer, странный он какой то
Проблем не в нём, а в вышеописанном. У меня были поначалу проблемы с этим. Я их пофиксил делая первую контрол-ноду в слое размером в пиксель (Макет -> Слева сверху (для лево-верхнего виджета, например)
> у CanvasLayer нет галочки с инпутом
Разумеется нет. Потому что она есть у потомков контрол-ноды, которые ты там помещаешь.
> Могу предложить не пользоваться канвас лейром.
А я предлагаю разобраться в вопросе...
...а не городить велосипед с вьюпортом, который вообще не для этого.
> в канваслеере по умолчанию первая контрол-нода разворачивается на всю доступную площадь
Да, ты прав, я не разбирался и нагугли похожие нерешенные проблемы.
Видимо если ставить первый контрол на весь экран и ставить ему mouse filter = ignore то будет работать и гуй, и клики в игровую сцену.
Но с тем что вьюпорт не для этого - не согласен. Я им многие фичи уже запиливал, с ним все прозрачно. Например рисование шлейфа за планетами, всякие трюки с прозрачностью по z глубине, обводки выделенных объектов, рендер анимаций в 3д текстуры и так далее, так что это мощный инструмент который стоит изучить.
Еба
Аноны, как начать строить комьюнити для своей игры?
Ну ты конечно ночью с козырей зашел.
Игра то какая хоть? Интеллектуальная или аркадная?
Интеллектуальная под Андроид.
Ссылочку тут оставлю на браузер, если у тебя хром, погамаешь.
https://gotm.io/2ch-studio/hbt
Комьюнити нужно исключительно чтобы находить неудобства, к которым у меня глаз замылен. Ну и мб когда куплю подписку девелопера в гуглсторе иметь пару скачавших.
А на итчио залил?
Не, на итч не заливал. Какие там правила для залива? Если полотенце на пол бросят, подбирать?
Ну ты колорист конечно
У меня Моник старый половину цветов не передаёт. Это сарказм такой?
Ну сарказм да
>Изумительный Годот
Зачем давать левый необновляемый форк-репо, если есть оффициальный обновляемый оригинал https://github.com/godotengine/awesome-godot
Ты не мог бы сказать точнее что там не так? Потому что я явно не понимаю. Вроде ж норм.
Хз зачем, но перекачусь!
Так и не сделал гребанное меню в игре(
Так и не сделал гребанное меню в игре(
АААйййййййййй
Да это ж годус на минималках
У при запуске начинается цепочка вычислений, обмена сигналами между узлами и синглтонами. Например, расчитывается что-то в синглтоне в _ready, отправляется сигнал, затем в скрипте какого-то узла по сигналу еще что-то расчитвается, отправляется другой сигнал, в другом скрипте расчитывается по этому сигналу расчитывается из другого синглтона. Иногда yield(get_tree(), "idle_frame") помогало, но что-то больше не помогает. Почему так и как избегать всего этого? Пробовал
>yield(get_tree().root, "ready")
но у меня все сломалось от такого.
А как дождаться что все, что есть загрузилось?
>yield(get_tree().root, "ready")
но у меня все сломалось от такого.
А как дождаться что все, что есть загрузилось?
Здесь анон обещал запустить серию туторов на ру в 3D и с С# скриптом. Как там успехи?
Принимаю возражения. Постил сгоряча. Извиняюсь. Изучу матчасть по вьюпортам.
> А как дождаться что все, что есть загрузилось?
Опрос дерева построен так, что дерево опрашивается рекурсивно, при этом в первую очередь выполняются потомки, затем предки. То есть, если рассматривать выполнение колбэка ready, он сначала выполнится для всех листьев, затем для всех ветвей, затем для ствола, и наконец для корня. То есть, если у тебя выполнилось ready для корневого узла, ты можешь быть уверен, что все остальные узлы уже ready выполнили.
Yeld может ждать выполнения функции. Если ты конечно не с сигналами работаешь. Если с сигналами, тогда знаю только про ожидание сигнала.
Путаница какая-то. Вот поэтому и рекомендуется предпродакшен и диздок с как можно более точным и полным описанием, что откуда и куда. Без этого получится как у при запуске.
Где то недельку надо еще на планирование и подготовку, увы
Можешь пока предлагать темы - я думаю начать с чего нибудь киперказуального либо простенькой РТС.
А в чем проблема? По твоему описанию, когда что-то рассчиталось, оно отправляет сигнал - это запускает вычисления, когда они закончатся - отправляется другой сигнал, и так далее, у тебя получается цепочка, значит тебе достаточно подписаться на самый последний сигнал после самого последнего вычисления.
Если же у тебя задача узнать когда закончатся несколько параллельных вычислений, то заведи массив или словарик и отмечай там каждый принятый сигнал, и когда совпадет с требуемым - значит все загрузилось.
Например:
var required = { "signalA": true, "signalB": true }
func onSignalA(): required.erase("signalA"); checkAll()
func onSignalB(): required.erase("signalB"); checkAll()
func checkAll(): if required.size() == 0: emit_signal("all_loaded")
Если же все это непонятно, то вместо yield(get_tree(), "idle_frame"), который ждет всего 1 кадр, можно просто завести таймер на 5 секунд с фейковым экраном загрузки, я так делал :3
>Если же все это непонятно, то вместо yield(get_tree(), "idle_frame"), который ждет всего 1 кадр, можно просто завести таймер на 5 секунд с фейковым экраном загрузки, я так делал :3
Пиздец :D
Предлагаю любую популярную 2д игру в 3д.
Начать с аркадных гоночек вид сверху.
Потом если не надоест платформер.
Затем РПГ
Стратегии не советую, сложно для понимания, да и сам жанр умирает, но если начнёшь ты будешь первым на ютубе среди ру и анг кто пилит тутор по РТС.
геймплейно 2д и 3д абсолютно разные
да
геймплейно 2д и 3д сильно отличаются, любой кто переходил из 3д в 2д или наоборот это знает
но никто не мешает делать 2д игры в 3д, только не надо себе врать!!!
почему у меня функция, которая вызывается по сигналу, срабатывает раньше, чем реади в том же скрипте, что и функция?
Как такое возможо, пацаны?
>да и сам жанр умирает
Э
Мощно. Это вулкан?
Назови пару стратегий РТС за прошлый гол, кроме Тоталов, рефоржа вара и ремастера СинСи.
Чего ты айкаешь? Мне и так грустно.
Зачем мне следовать за тобой, если у меня уже есть концепт своей игры? Он куда проще, и профита даст больше. Только сука как же я ненавижу программирование. Гребаный ад где все следует по правилам, которые ты никогда не поймешь!
Ебал я в рот ебучие движки, с ебучими языками!
Ты только что поговорил с копипастой спам-бота.
А по теме, программирование намного проще освоить, чем рисование, моделирование и музыку. Тебе не нужно надрачивать скилл годами тяжёлого труда, ты просто читаешь правила в книжке со списком правил (ака мануал) и затем используешь эти правила для составления программы. Не нужно даже наизусть помнить, достаточно знать где можно найти забытое.
Если очень трудно освоить общие принципы программирования, поиграй в игры для маленьких детей, в которых нужно с помощью кнопок задать программу виртуальному роботу, чтобы он решил головоломку.
Чел, это же бот.
>Ты только что поговорил с копипастой спам-бота.
Да насрать, я просто хотел выговорится.
>А по теме, программирование намного проще освоить, чем рисование, моделирование и музыку.
Нихера чел! В рисовании ты когда делаешь, сразу видишь что у тебя выходит. Даже если ты совершил ошибку, тебе не вылезет окно в программе "ОШИБКА ОШИБКА, ИСПРАВТЕ ТО ЧТО ВЫ СДЕЛАЛИ!"
>Если очень трудно освоить общие принципы программирования, поиграй в игры для маленьких детей, в которых нужно с помощью кнопок задать программу виртуальному роботу, чтобы он решил головоломку.
Да и само программирование скучная херня, которая отбирает больше сил и нервов, чем принесения удовольствия.
>Не нужно даже наизусть помнить, достаточно знать где можно найти забытое.
Это можно отнести к чему угодно в наши дни, к рисованию в частности.
> да и сам жанр умирает
Я бы не сказал, что жанр умирает. Скорее кризис идей. Ведь на рынке сейчас ни одной нормальной популярной пошаговой стратегии. А вот те же парадоксовские игры, типа стеллариса - вполне себе стратегии, и вполне себе популярные. Даже индюшатина, типа northgard, нашла свою аудиторию, причём немалую. Но игра нормально играется в первые часов 10. Потом надоедает, потому что ничего нового не привнесли.
Та же история, что с wow и hs. Они не были основоположниками мморпг и ccg, но привнесли что-то, что заставило прочих равняться на близзов и популяризировало соответствующие жанры. А сейчас близзы стагнируют в боязни, ка бы чего не случилось, и не хотят рисковать в попытках выпустить новый мир и геймплей, а переключились на ремастеры.
Вот и с rts и tbs, мне кажется. Выпусти новую, или, даже правильней сказать, старую механику с взглядом с нового ракурса - и будет успех. Не все могут бесконечно играть в ск, стронгхолд, homm3 и дисайплсов. И вот этот перетекающий народ и есть шанс заново запустить жанр to the moon.
Подозреваю, что реди срабатывает при инстанцировании/загрузке объекта, куда прицеплен скрипт, либо если скрипт грузится в проект. Но это не точно. Я не годот эксперт и в треде сам на правах вопрошающего.
>В рисовании ты когда делаешь, сразу видишь что у тебя выходит.
Ага. И выходит обычно говно. И ты понимаешь, что это говно. Но совершенно не понимаешь, почему конкретно говно, и как переделать говно в конфетку. А ведь говнографика не выполняет свою главную задачу - вызывать какие-то эмоции, которые задумывались рисователем. Страшные сцены будут выглядеть смешно, серьёзные сцены будут выглядеть нелепо, милые сцены будут выглядеть отвратно, смешные сцены будут выглядеть постыдно и так далее. А говнокод, пусть и говно, но свою главную задачу решает. И пользователь никогда не узнает, что его любимая программа состоит из говна, потому что он её код никогда не увидит, а если даже увидит, то не сможет понять, почему он говно. Да и ты сам, когда учишься кодить, не знаешь, говнокод это или не говнокод, поэтому не можешь себя критиковать, а в рисовании ты прекрасно знаешь как выглядит говно, и критикуешь себя за рисование говна. Короче кодинг проще.
>Даже если ты совершил ошибку, тебе не вылезет окно в программе
Вот именно! Компилятор тебе по-дружески укажет на ошибку в коде, даст направление, в котором нужно искать, практически ссылку на страничку в руководстве. И ты её исправляешь, потому что ты либо уже знаешь как это исправить, либо загуглишь и по первой ссылке найдёшь решение. А в рисовании ты можешь нарисовать что угодно и программа тебе ничем не поможет, ей вообще без разницы что у тебя получится, она не может сказать тебе, где ты ошибся, почему ошибся и как это исправить. И никто не скажет точно, каждый скажет свою вкусовщину и не сможет ясно и чётко ответить. Это кошмар какой-то, ты рисуешь говно и понимаешь что это говно, но никто не может тебе помочь исправить ошибки. А компилятор иногда тебе прямым текстом говорит: вот здесь замени А на Б и всё заработает, компилятор умный и добрый.
С другой стороны, если у тебя куча EAV (ошибка доступа к памяти), тогда просто не лезь писать код, пока не продумал структуру программы и всю работу с данными. Если ошибка со стороны библиотеки - обращайся к руководству библиотеки, и т.д. Если ошибка логическая (программа работает, но ответ неправильный) - опять же думай головой, решение где-то близко. А в рисовании сколько ни думай, внутренний критик говорит только "это говно". Даже прочитав теорию, всё равно не помогает...
>Да и само программирование скучная херня, которая отбирает больше сил и нервов, чем принесения удовольствия.
Скорее всего ты просто берёшься за непосильные задачи, которые намного выше уровня твоего навыка. Либо это просто личное. Мне нравится видеть, как из ничего появляется и развивается рабочая программа, способная самостоятельно выполнять то, что без неё тебе пришлось бы делать вручную, долго и трудно. Это как рождение живого существа, которое постепенно взрослеет и учится новым навыкам, а потом помогает тебе, отвечает заботой в ответ на заботу. А картинка - ну вот ты её нарисовал, положил в папку и всё, будет лежать и занимать место или пылиться на полке, толку от неё никакого, одни страдания, стыд и самобичевание.
>Либо это просто личное
p.s. Пишу в начале, потому что концовка зачетная. Мне нравится рисование своей простотой, а...
"Да и само программирование скучная херня, которая отбирает больше сил и нервов, чем принесения удовольствия."
>И ты понимаешь, что это говно. Но совершенно не понимаешь, почему конкретно говно, и как переделать говно в конфетку.
Как раз наоборот, с помощью анализа ты можешь спокойно понять где и что нужно поправить.
>А говнокод, пусть и говно, но свою главную задачу решает.
Я в ремпае пока каждой строчке отступы не сделал, оно мне игру не запускало!
В годод же я скопировал код из инета, решив вставить его в свой проект, но нихуя не работает! Я его написал не туда куда нужно, а как делать по другому я не знаю. И все, иду нахуй тут же, посмотрев на весь проект целиком я могу только закрыть и пойти спрашивать программиста почему у моего перса спец атаки не работают! Он же тоже НЕ БУДЕТ ЕБАТЬ ПОЧЕМУ, он на другом языке работает, а на годот ему похуй!
>Короче кодинг проще.
Его проще забросить, и не вспоминать никогда! Тут согласен на все сто!
>Вот именно! Компилятор тебе по-дружески укажет на ошибку в коде, даст направление, в котором нужно искать, практически ссылку на страничку в руководстве.
Я скопировал чужой код, так же для спец приема, вставил. Ничего не работает! Почему? Я мне пк не говорит! Молчит в тряпочку! Видит код, а про себя думает "Вот я его вижу, но ничего не сделаю. Пусть он помочиться, перепишит все там нахуй!" Ахуеть в крысу он тебе не поможет. А за точку которую ты случайно поставил, осудит и обоссыт!
>А в рисовании ты можешь нарисовать что угодно и программа тебе ничем не поможет, ей вообще без разницы что у тебя получится, она не может сказать тебе, где ты ошибся, почему ошибся и как это исправить. И никто не скажет точно, каждый скажет свою вкусовщину и не сможет ясно и чётко ответить. Это кошмар какой-то, ты рисуешь говно и понимаешь что это говно, но никто не может тебе помочь исправить ошибки. А компилятор иногда тебе прямым текстом говорит: вот здесь замени А на Б и всё заработает, компилятор умный и добрый.
Если тебя палками не бьют, по твоему это похуизм?! Программе не важно кто и что ты за человек, и по этому она тебя не осуждает! И если ты будешь общаться не с ясельной группой, нормальные худы скажут "Вкусовщины собой нету, и даже в абстракционизме есть правила, которыми пользуются и ОСТАЛЬНЫЕ ХУДОЖНИКИ!" Та же самая композиция, по твоему если её сделать плохо - это будет вкусно?
>Даже прочитав теорию, всё равно не помогает...
Я бывал на уроках информатики, и читал тамошние учебники, выполнял от туда задания. Что такое переменная?! Я не знаю что такое переменная! А построение примерные пропорции лица я запомню на все оставшуюся жизнь. Потому что я чужие лица смотрю каждый день.
>Скорее всего ты просто берёшься за непосильные задачи, которые намного выше уровня твоего навыка.
Да я готов и три в ряд сделать, только чтобы там были вн вставки.
>Мне нравится видеть, как из ничего появляется и развивается рабочая программа, способная самостоятельно выполнять то, что без неё тебе пришлось бы делать вручную, долго и трудно. Это как рождение живого существа, которое постепенно взрослеет и учится новым навыкам, а потом помогает тебе, отвечает заботой в ответ на заботу.
Ага, гомункул гребаный который будет тормозить и пускать слюни из рта. Я таких стараюсь в подвале старом харде держать, морить голодом пока они сами не вымрут. Но они пожирают друг друга, регенерируя оторванные конечности.
>А картинка - ну вот ты её нарисовал, положил в папку и всё, будет лежать и занимать место или пылиться на полке, толку от неё никакого, одни страдания, стыд и самобичевание.
Картина попадает в сеть из твоего пера, собирая толпу людей которых зацепили твои взмахи кисточкой! Грациозное палатное которое получает большое внимание, разносясь по разным соцсетям с ссылкой на автора оригинала. Зрители кормят художника деньгами и овациями! А конкуренты и коллеги репектуют, ожидая твой следующий шаг к вершине мастерства!
p.s. Пишу в начале, потому что концовка зачетная. Мне нравится рисование своей простотой, а...
"Да и само программирование скучная херня, которая отбирает больше сил и нервов, чем принесения удовольствия."
>И ты понимаешь, что это говно. Но совершенно не понимаешь, почему конкретно говно, и как переделать говно в конфетку.
Как раз наоборот, с помощью анализа ты можешь спокойно понять где и что нужно поправить.
>А говнокод, пусть и говно, но свою главную задачу решает.
Я в ремпае пока каждой строчке отступы не сделал, оно мне игру не запускало!
В годод же я скопировал код из инета, решив вставить его в свой проект, но нихуя не работает! Я его написал не туда куда нужно, а как делать по другому я не знаю. И все, иду нахуй тут же, посмотрев на весь проект целиком я могу только закрыть и пойти спрашивать программиста почему у моего перса спец атаки не работают! Он же тоже НЕ БУДЕТ ЕБАТЬ ПОЧЕМУ, он на другом языке работает, а на годот ему похуй!
>Короче кодинг проще.
Его проще забросить, и не вспоминать никогда! Тут согласен на все сто!
>Вот именно! Компилятор тебе по-дружески укажет на ошибку в коде, даст направление, в котором нужно искать, практически ссылку на страничку в руководстве.
Я скопировал чужой код, так же для спец приема, вставил. Ничего не работает! Почему? Я мне пк не говорит! Молчит в тряпочку! Видит код, а про себя думает "Вот я его вижу, но ничего не сделаю. Пусть он помочиться, перепишит все там нахуй!" Ахуеть в крысу он тебе не поможет. А за точку которую ты случайно поставил, осудит и обоссыт!
>А в рисовании ты можешь нарисовать что угодно и программа тебе ничем не поможет, ей вообще без разницы что у тебя получится, она не может сказать тебе, где ты ошибся, почему ошибся и как это исправить. И никто не скажет точно, каждый скажет свою вкусовщину и не сможет ясно и чётко ответить. Это кошмар какой-то, ты рисуешь говно и понимаешь что это говно, но никто не может тебе помочь исправить ошибки. А компилятор иногда тебе прямым текстом говорит: вот здесь замени А на Б и всё заработает, компилятор умный и добрый.
Если тебя палками не бьют, по твоему это похуизм?! Программе не важно кто и что ты за человек, и по этому она тебя не осуждает! И если ты будешь общаться не с ясельной группой, нормальные худы скажут "Вкусовщины собой нету, и даже в абстракционизме есть правила, которыми пользуются и ОСТАЛЬНЫЕ ХУДОЖНИКИ!" Та же самая композиция, по твоему если её сделать плохо - это будет вкусно?
>Даже прочитав теорию, всё равно не помогает...
Я бывал на уроках информатики, и читал тамошние учебники, выполнял от туда задания. Что такое переменная?! Я не знаю что такое переменная! А построение примерные пропорции лица я запомню на все оставшуюся жизнь. Потому что я чужие лица смотрю каждый день.
>Скорее всего ты просто берёшься за непосильные задачи, которые намного выше уровня твоего навыка.
Да я готов и три в ряд сделать, только чтобы там были вн вставки.
>Мне нравится видеть, как из ничего появляется и развивается рабочая программа, способная самостоятельно выполнять то, что без неё тебе пришлось бы делать вручную, долго и трудно. Это как рождение живого существа, которое постепенно взрослеет и учится новым навыкам, а потом помогает тебе, отвечает заботой в ответ на заботу.
Ага, гомункул гребаный который будет тормозить и пускать слюни из рта. Я таких стараюсь в подвале старом харде держать, морить голодом пока они сами не вымрут. Но они пожирают друг друга, регенерируя оторванные конечности.
>А картинка - ну вот ты её нарисовал, положил в папку и всё, будет лежать и занимать место или пылиться на полке, толку от неё никакого, одни страдания, стыд и самобичевание.
Картина попадает в сеть из твоего пера, собирая толпу людей которых зацепили твои взмахи кисточкой! Грациозное палатное которое получает большое внимание, разносясь по разным соцсетям с ссылкой на автора оригинала. Зрители кормят художника деньгами и овациями! А конкуренты и коллеги репектуют, ожидая твой следующий шаг к вершине мастерства!
Художникам проще рисовать, логикам программировать, никакого открытия тут нет.
Программирование не скучная херня, а интересное и веселое занятие, примерно как решать головоломки, или строить из лего.
А вот мне лично рисовать скучно - я не умею и это такое мучение, когда надо выдавить из себя N единиц контента, текстур, спрайтов
В программировании есть такая фишка, как диаграммы. Трюк заключается в том, что если тебе сложно, нет нужды держать все в голове. Ты можешь нарисовать схему где опишешь кто кому посылает сигнал и когда, к примеру.
В 20 веке когда я изучал погроммирование по книжкам, там описывали какие то страшные аналогии что такое переменная. Например это ящик в картотеке. А если я блджад никогда не видел картотек и их боюсь?
Но в 21 веке в окружении техники и интернета сложно не знать что такое переменная. Это любое поле, которое имеет постоянное название, но разное содержание. Вот ты когда платишь картой, у тебя списывают со счета. А сам счет не меняется. Значит, сумма на счете - переменная. Ты вводишь пароль когда заходишь в почту. Пароль ты меняешь, а само поле так и называется пароль. И так далее.
Годот пишет всегда, когда возникает проблема. Ну или рассказывай какой код использовал, поможем
Привет, годотчикам! Я балуюсь и делаю рогалик для себя и хочу накатить тайлы https://opengameart.org/content/dungeon-crawl-32x32-tiles-supplemental там они предоставляются в виде отсортированных по папочкам, и в виде одного большого изображения. Проблема в том, чтобы всё это загнать в один тайлсет: либо я добавляю по одному спрайту и получаю огромную кучу, в которой нужно сразу записывать в какую нибудь глобальную переменную айдишники, чтобы не забыть, либо выделять на одном огромном изображении нужные мне атласы и автотайлы. Не то чтобы я был против, но я не понимаю как сделать атлас на нескольких строчках с разрывами как на пике. Делать несколько атласов для одного тематического набора тайлов кажется сомнительным решением и костылём, который аукнется в будущем. Посоветуйте выход из ситуации, пожалуйста!
Перенарежь саму картинку, можно склеивая из "отсортированных по папочкам"
Инструмент для этого не посоветуешь? А то я пробовал гуглить - какие-то все не очень варианты были
так так вот это интересно
попробуй ASU
alferd spritesheet unpacker
Тут не код.
Из последнего я скопировал стены, которые не позволяют моему персонажу падать в пустоту сквозь поле, и сетку я сделал таким же образом. Но, открыв файл через несколько недель решил сделать тоже самое во круг поле, скопировав блок стоящий на сетке. Но итогу правая стенка не пропускает игрока, левая и задняя пропускают. Что не так? Только всевышний знает!
Окей.
>Художникам проще рисовать, логикам программировать, никакого открытия тут нет.
Ты это тому скажи.
>Ты можешь нарисовать схему где опишешь кто кому посылает сигнал и когда, к примеру.
Мне эти схемы не о чем не говорят. Я в них могу видеть только ответвление по вн, или же семейное древо.
Извини я такое в консольке imagemagick делаю
https://stackoverflow.com/questions/20737061/merge-images-side-by-sidehorizontally
Спасибо, выглядит полезно
Скрипты к стенкам приклеены? Попробуй развернуть их на 180 градусов для прикола
Пробывал, тоже самое. Если проблема со скриптами, почему правая стенка работает как надо?
За столкновения отвечает физический коллайдер.
Вот на скрине я его немного сдвинул для наглядности.
Если ты включишь вот эту галочку, то будешь видеть их даже в игре, даже если сам объект сделаешь невидимым.
Просто могло получиться так, что ты скопировал только визуал, а физику не скопировал, или поменял размер физического коллайдера, а они поменялись все вместе. Чтобы такого не происходило, после копирования надо нажать в свойствах коллайдера кнопочку "Make unique"
Понятно, спасибо что написал об этом. Но сейчас уже нет желания открывать и править все это.
>с помощью анализа ты можешь спокойно понять где и что нужно поправить.
Не помогает оно, и так двигаешь, и эдак, а оно всё равно не то. Как в меме с унитазом, из стороны в сторону двигаешь и всё не то.
>Я в ремпае пока каждой строчке отступы не сделал, оно мне игру не запускало!
Есть такое выражение: RTFM! То есть читай грёбаный мануал! Наверняка не читал вообще или невнимательно.
>В годод же я скопировал код из инета, решив вставить его в свой проект, но нихуя не работает
Ну вот представь что ты скачал чужие фотки памятников, склеил в пейнте и удивляешься почему у тебя не получилось аниме в стиле 90-х с озвучкой и мерчендайзом. Действительно, почему? Да потому что так дела не делаются. Ты должен разумно подходить к разработке, а не бессознательно копипастить рандомные фрагменты чужих проектов. Тем более в GDScript важны отступы, на один отступ ошибёшься и код уже что-то другое делает, при этом он может запускаться и работать, но результат будет неправильным (но это не во всех языках так). Короче нужно учиться, учиться, и ещё раз учиться, а потом сознательно писать свой собственный код своими руками.
>он на другом языке работает,
Большинство ЯП очень похожи друг на друга из-за того, что парадигма одна - императивная. Программист, владеющий одним императивным языком, без труда поймёт код на другом императивном языке, и даже может найти некоторые ошибки. Но да, в контексте движка всё сложнее, ошибка может не касаться кода, ты мог что-то другое неправильно сделать.
>Я скопировал чужой код, так же для спец приема, вставил. Ничего не работает! Почему?
Потому что ты:
>скопировал чужой код
>скопировал
>СКОПИРОВАЛ
Вот почему.
>Вкусовщины собой нету
Ну да, конечно. Аниме-хейтеры назовут любую картинку в стиле аниме говном. А мне, например, наоборот, от классической живописи, современного реализма и западных мультиков блевать хочется, а вот аниме - это хорошо, это качественно. Твои "нормальные худы" любую кляксу готовы за миллион баксов с аукциона купить, или пытаются эту кляксу за миллион баксов продать. Но мне вот не нравятся их "высокохудожественные" кляксы, мне нужно аниме, но даже зная все формальные правила получается какое-то говно. Даже если пытаюсь рисовать в векторной программе, которая опирается на строгую математику, в отличие от растрового хаоса.
>и даже в абстракционизме есть правила
Ну вот ты выполняешь все эти формальные правила, а получается говно. Почему? В рисовании правила выполнять недостаточно, нужно что-то ещё. В программировании достаточно выполнять правила и всё будет работать как задумано.
>Что такое переменная?!
Это коробочка с надписью, в которой ты можешь хранить какие-нибудь данные, например, числа. И обращаешься к коробочке ласково, по имени.
>построение примерные пропорции лица я запомню на все оставшуюся жизнь
Это никак не помогает. Я тоже знаю, где у человека глаза, нос, рот, уши. Знаю пропорции головы. Но всё равно получаются уродцы, не похожие на хомо сапиенс даже. Если бы можно было программно эту задачу решить, я бы уже давно не мучился, но программно слишком долго все ракурсы и вариации описывать.
>Картина попадает в сеть из твоего пера, собирая толпу людей которых зацепили твои взмахи кисточкой!
Во-первых, никуда она не попадёт, потому что говно.
Во-вторых, никого не соберёт, потому что ты никому не известное говно.
В-третьих, тебя и твою картинку обосрут и потопят в говне, потому что она говно.
А программа полезна лично для тебя, а не для толпы быдланов.
Сколько тебе лет вообще? Говоришь как старик, по какой-то причине решивший освоить геймдев на старости лет. Или как ребёнок, привыкший к тому что всё делают за него и не желающий работать своими руками, но для ребёнка ты слишком много знаешь. Возможно, это не твоё. Продолжай рисовать картины и собирать толпы людей в сети) Ну или закажи разработку игры на фрилансе, если не хочешь учиться программированию.
Не парься, на такой стадии проще с начала сделать.
Я вообще не стесняюсь сцены выкидывать и делать 2-3 варианта.
Это же разработка + обучение, а не экзамен.
Как обновить элемент в массиве?
Есть dictionary, где хранимое значение - массивы. Положим
array = [0, 1, 0, 0]
Нужно проапдейтить только определённый элемент массива, например, второй (заменить 1 на 4).
Как это сделать? Вариант, как для массива array[1] = 4 не катит, потому что dictionary["arrayZ"][1] = 4 выдаст ошибку.
Из придуманного - перекладывать весь массив по новой по типу пикрил, но это какой-то сизифов труд.
Есть какой-то метод нормальный для этого?
Есть dictionary, где хранимое значение - массивы. Положим
array = [0, 1, 0, 0]
Нужно проапдейтить только определённый элемент массива, например, второй (заменить 1 на 4).
Как это сделать? Вариант, как для массива array[1] = 4 не катит, потому что dictionary["arrayZ"][1] = 4 выдаст ошибку.
Из придуманного - перекладывать весь массив по новой по типу пикрил, но это какой-то сизифов труд.
Есть какой-то метод нормальный для этого?
Есть, конечно, вариант ещё пикрил, но тоже кажется тупым.
Какую ошибку выдаёт? dictionary["arrayZ"][1] = 4 по идее должно работать
Да я не парюсь, просто много сил жрет ковыряется в этом. А удовольствие победы несоизмеримо с выносом мозга на таких затупах.
>программирование намного проще освоить
>Есть такое выражение: RTFM! То есть читай грёбаный мануал Наверняка не читал вообще или невнимательно.
>Действительно, почему? Да потому что так дела не делаются. Ты должен разумно подходить к разработке.
>Аниме-хейтеры назовут любую картинку в стиле аниме говном.
>Твои "нормальные худы"
>Но мне вот не нравятся их "высокохудожественные" кляксы, мне нужно аниме, но даже зная все формальные правила получается какое-то говно.
Бля я просто угораю! Приплел с нихуя аудиторию аукционов, не поняв что под нормальными худами я имел ввиду пик ниже. Если ты не знал, вся стилизация основана на реализме. Если ты захочешь нарисовать человека, ты "умный программист" будешь рисовать ему две ноги, два глаза, две руки, и два полужопия. Знаешь почему? Потому что человек априори выглядит так а не иначе. Если у тебя получается говно, значит ты рисуешь не аниме тян, а того же гомункула, у которого шея с пальчик, растет на затылке.
>Это никак не помогает. Я тоже знаю, где у человека глаза, нос, рот, уши.
А слепой ничего не увидит.
>Сколько тебе лет вообще?
Больше 18, меньше пенсионного возраста.
>Возможно, это не твоё. Продолжай рисовать картины и собирать толпы людей в сети) Ну или закажи разработку игры на фрилансе, если не хочешь учиться программированию.
Я в прошлом треде написал что я буду делать, при неудачи. То бишь найму программиста/реализую задумку в виде маленького комикса.
Я очень хочу разобрать всю твою писанину, но впаду от понимания того, что ты опять ответишь в такой же развернутой манере! А говорить я не особо люблю. Ведь я творец, а не клоун. Занавес.
Блин, действительно работает. Немного не то юзал в качестве ключа - ошибся с переменной, содержащей ключ.
На второй картинке рекомендуется вместо get_parent использовать PackedScene?
>реализую задумку в виде маленького комикса
Если ты умеешь рисовать, почему бы сначала не нарисовать комикс? Или параллельно с игрой, если есть время. Так можно заранее привлечь аудиторию и точнее определиться с персонажами для игры, если она вообще нужна. Или, если аудитория уже есть, комикс будет проще для восприятия - его не нужно скачивать, запускать и проходить, просто читаешь на странице любимого художника и не паришь мозги. Т.е. в теории у комикса шире охват сообщества, чем у игры.
>стилизация основана на реализме
Знаю. Но мне не нравится большое количество лишних деталей, таких как выпуклые мышцы, какие-то пятна на коже и т.д. Но речь не про то шла. Вот ты нарисуешь стикмана и я нарисую стикмана: палочки, кружочки, всё по линеечке если нужно. Вот только твой стикман моих глазах будет неплох, я буду даже завидовать, а мой стикман в моих глазах будет выглядеть как говно, и чем больше я буду пытаться его исправить, тем больше буду портить. С формальной точки зрения стикманы одинаковые - все размеры, пропорции, толщина линий, цвет чернил и т.д. равны, но мой всё равно намного хуже. Чего-то мне не хватает, и без этого даже пытаться рисовать бесполезно. А вот код - чтобы он работал и решал задачи, его не нужно сравнивать с чужим кодом, он хорош сам по себе.
Ладно, к чёрту стикманов, вот я точку поставлю и ты точку поставишь. И твоя точка хороша, а моя - говно. И я её десять раз обведу и заново переделаю, но всё равно моя точка будет хуже. Она всегда хуже. Я не понимаю, почему. Знаю, это моя заниженная самооценка виновата. Но всё равно я только говно делаю.
>будешь рисовать ему две ноги, два глаза, две руки, и два полужопия
Вот это, кстати, одна из ошибок новичков, её часто дети допускают. Рисовать нужно не "две ноги, две руки, два глаза", рисовать нужно то, что видишь перед собой (или мог бы видеть, будь оно перед тобой). А перед тобой не обязательно полный комплект частей тела - часть из них могут быть прикрыты чем-нибудь, находиться за границами кадра, отсутствовать у модели и т.д. Аналогично с тем, как выглядит часть тела: рука под определённым ракурсом может вообще не иметь отличительных черт типичной руки, но рисовать нужно то что видишь, а не то что по твоему мнению должно быть на руке. То есть рисование сложнее загнать в рамки формальных правил, правила зачастую только мешают: ты знаешь, что у человека пять пальцев на руке, и пытаешься их все на эту руку прикрепить, а на самом деле в конкретной позе и ракурсе видно только один палец или два. В программировании такого не бывает, если нужно написать программу для решения задачи - ты пишешь программу для решения задачи, а не какое-то непонятное пятно в форме задачи.
Вообще я изначально пытался помочь с принятием программирования, а ты продолжаешь бодаться. Ради чего? Просто перестань буянить, когда встречаешь какие-то сложности, трезво оцени ситуацию и читать самоучители, выполняя все упражнения из них. Тебе не нужно написать десять тысяч программ, это только художнику нужно десять тысяч рисунков сделать, а тебе достаточно научиться писать программы. Это просто, если контролировать себя и не психовать.
> моя заниженная самооценка
Ещё перфекционизм на вышеописанную проблему работает нехило.
>Ещё перфекционизм
Вот-вот, именно так. Но код с перфекционизмом всё же проще писать: мой перфекционизм зачастую удовлетворяется ровными отступами, правильными заглавными буквами, правильным числом пробелов, пустыми строками между блоками кода, длинными понятными именами и т.д., т.е. главное чтобы выглядело опрятно и красиво. А с рисунками так не получается, на один пиксель ошибёшься - уже совсем другой результат, а пикселей миллионы. С 3D-моделями ещё хуже, пытаюсь до миллиметров всё вычислить и всё равно говно получается. А код пишешь себе и пишешь, практически как на родном языке говоришь.
да, меня бомбит с "кодит сложна, рисувать лигко"
Я это ты, бро. Бомблю с того же самого, когда люди, которым по жизни легко, не понимают как такое может быть, что кому-то по жизни сложно? "Да вы просто не стараетесь" говорят они. Пиздец.
> С 3D-моделями ещё хуже, пытаюсь до миллиметров всё вычислить и всё равно говно получается.
А ещё квады. Маниакально трясусь над моделькой, чтоб недайбох нигде многоугольника не образовалось, иначе пиздец. В то время, как васян уже сдаёт готовую модельку, ему перезванивают, а мне нет.
>Т.е. в теории у комикса шире охват сообщества, чем у игры.
1. Нихуя. Играют охотнее, чем читают.
2. Если я сделаю игру, смогу расширить пул площадок для продвижения себя любимого как минимум на два. itch.io и тд
3. Я хочу сделать для игрока челлендж, при котором он борется за получение желаемого арта.
>Если ты умеешь рисовать, почему бы сначала не нарисовать комикс?
Потому что это блять идея не для комикса, а для игры. Идеи для комикса у меня есть, и они придуманы с заточкой под это.
>Вот ты нарисуешь стикмана и я нарисую стикмана: палочки, кружочки, всё по линеечке если нужно. Вот только твой стикман моих глазах будет неплох, я буду даже завидовать, а мой стикман в моих глазах будет выглядеть как говно, и чем больше я буду пытаться его исправить, тем больше буду портить. С формальной точки зрения стикманы одинаковые - все размеры, пропорции, толщина линий, цвет чернил и т.д. равны, но мой всё равно намного хуже.
В реальности же ты сделаешь ему длинную шею, разные размеры рук, и просрешь ещё много пропорций которые важны в построении человека. Это уже не смотря на то, что крутан будет все это делать в векторе, а ты в растре мышкой рисовать. xD Считай шутка среди cg худов.
>Ладно, к чёрту стикманов, вот я точку поставлю и ты точку поставишь. И твоя точка хороша, а моя - говно. И я её десять раз обведу и заново переделаю, но всё равно моя точка будет хуже. Она всегда хуже. Я не понимаю, почему. Знаю, это моя заниженная самооценка виновата. Но всё равно я только говно делаю.
У меня тоже заниженная самооценка. Не мое мнение, а людей со стороны. Мне это не мешат если получилось говно, изменить ошибку, а потом в дальнейшем попытаться её не допустить.
>Вот это, кстати, одна из ошибок новичков, её часто дети допускают. Рисовать нужно не "две ноги, две руки, два глаза", рисовать нужно то, что видишь перед собой (или мог бы видеть, будь оно перед тобой). А перед тобой не обязательно полный комплект частей тела - часть из них могут быть прикрыты чем-нибудь, находиться за границами кадра, отсутствовать у модели и т.д. Аналогично с тем, как выглядит часть тела: рука под определённым ракурсом может вообще не иметь отличительных черт типичной руки, но рисовать нужно то что видишь, а не то что по твоему мнению должно быть на руке. То есть рисование сложнее загнать в рамки формальных правил, правила зачастую только мешают: ты знаешь, что у человека пять пальцев на руке, и пытаешься их все на эту руку прикрепить, а на самом деле в конкретной позе и ракурсе видно только один палец или два. В программировании такого не бывает, если нужно написать программу для решения задачи - ты пишешь программу для решения задачи, а не какое-то непонятное пятно в форме задачи.
Ты должен видеть на сквозь. Этому и учат почти все учения по художественному ремеслу.
>Вообще я изначально пытался помочь с принятием программирования
Это не возможно принять, боль и страдания от тильда только в пучины депрессии вгоняют. Чем дольше сидишь, тем больше не понимаешь.
>Тебе не нужно написать десять тысяч программ, это только художнику нужно десять тысяч рисунков сделать, а тебе достаточно научиться писать программы.
Тебе нужно много знать чтобы написать одну программу, а мне чтобы нарисовать один рунок достаточно посмотреть на свою ногу.
>да, меня бомбит с "кодит сложна, рисувать лигко"
>которым по жизни легко, не понимают как такое может быть
Я если сравнивать с другими худами, даже на средний уровень ещё не вышел. Но даже с таким бэкграундом рисование легче, чем программирование.
>как васян уже сдаёт готовую модельку, ему перезванивают, а мне нет.
Вася потратит на эту подельку в лучшем случае две рабочих недели, из которых спать и есть будет 7 часов. Остальное выдрачивание.
Отклеилось. 2 пик там не актуален, посчитал что этот аргумент можно спокойно списать.
Есть ли в godot реализация Breadth-first search?
AStar знаю и использую для поиска пути. Но для реализации разведки карты это не подходит, BFS выглядит более адекватным, но не могу найти такой функции.
AStar знаю и использую для поиска пути. Но для реализации разведки карты это не подходит, BFS выглядит более адекватным, но не могу найти такой функции.
Нет, дружище, в движке нет, если тебе надо я конвертнул первый попавшийся питоновский код
https://pastebin.com/33BVNLRJ
Спасибо.
Если я делаю так:
>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.
>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:
Потому что нельзя сравнивать разные типы, а я объявил строковую константу и сравниваю с цветом.
Мне всегда нравилась фраза "какой тут физический смысл"? И я всем советую пользоваться этим приемом.
Какой смысл ты вкладываешь в этот код?
Вот draw_lines вызывается, скажем, раз в кадр. В ней ты запускаешь цикл, скажем, на 10 линий.
И внутри каждой линии ты просишь движок - отсрочь каждую линию на 1 кадр.
WUT? Каждый кадр ты просишь отложить 10 кадров.
А что такое Color(..., 2)? Прозрачность выражается в числах 0.0 .. 1.0. Как и остальные части которые ты умножаешь на 2.
Нет, не будет. Только что проверил, перепечатав твой код.
Не совсем так, как мне надо, но сделал по твоему подобию, даже йылды оказались не нужны, все заработало, как надо. Тысячи благодарностей.
А вот так
var line_2d : Line2D = get_child(i).get_line_2d()
всегда рекомендуется делать?
Эээээээххх!
Я просто хотел заставить одну функцию дожидаться завершения другой, чтобы другая не слала null.
желтый с фиолетовым плохо сочетается. Погугли, какие цвета хорошо сочетаются и поставь их, а то от этих глаза болят.
мимо
> всегда рекомендуется делать?
Вообще говоря, вкусовщина. Твой вариант опрашивает дерево строковым запросом. Диды неодобряе такой подход, но мне как-то в стрингосраче убедительно на миллисекундах показали, что современные строки работают на исчезающе малую величину медленнее, чем числа, и этим можно пренебречь. Мой вариант опрашивает потомка ноды в её массиве потомков, индексы которого инт, то есть везде работа с числами, но не строками. Но на этапе оптимизации вспомни этот момент и сможешь оптимизировать пару лишних фреймов.
Вот примерно то, о чём я говорю: https://pastebin.com/gjfLrUpV
>Но на этапе оптимизации
Хо-хо!
На самом деле такое может случиться, когда фпс начнёт падать меньше 30. Помнится мне, у меня комп обосрался, когда я на годоте сделал реализацию http://stuffin.space/
Жалко, что код при обновлении пекарни не сохранил. Или нет. В следующий раз нормально напишу.
Проверяем галку ОПа. Были траблы.
Дак вот восстановленные из бекапа и проверял.
Как можно заставить узлы Label сталкиваться друг с другом, а не перекрывать?
У меня несколько персонажей, у каждого Лэйбл над головой, хочу, чтобы Лэйблы не накладывались друг на друга
Добавить их под какой нибудь контейнер, например HBoxContainer, GridContainer...
А, такое. Тут сходу не придумаешь. 2д/3д игра? Могут ли надписи двигаться вверх или только по горизонтали? Что будет если три игрока рядом, насколько далеко надпись может быть оттолкнута? Что должно произойти с надписью когда персонаж пройдет мимо другого слева направо?
Одна из идей пришла такая - сделать отдельный физический слой с прямоугольниками и "таскать" их по невидимому полу.
Или курить алгоритмы расстановки меток на карте.
2д, надписи могут двигаться вверх и по-горизонтали. Если три игрока рядом, каждая надпись должна занять ближайшее к своему игроку место.
Я попробовал сделать каждому персонажу дочерний узел RigidBody, а его дочерний узел Label. И все надписи поместил на один Collision-слой. Сначала они сталкиваются, но потом сталкиваются как-то слабо.
Скорее вообще не сталкиваются
Сделай втупую, сделай в лоб, как я зимой делал: лейбл сидит в ригидбоди, ригидбоди прикручено джойнтом к боде персонажа, когда персы сближаются, все их лейбл-блоки будут отталкиваться физическим движком и занимать удобное для себя положение.
аааааа джоинты точно
А помнишь, антуан, как ты помогал кодить платформер?
Я тебе ещё спрайтов нарисую.
Ты только заходи...
хоть иногда...
Я тебе ещё спрайтов нарисую.
Ты только заходи...
хоть иногда...
Я ХЗ, ещё как минимум до конца июня ваще никак. Дел не в проворот. Ты пока спрайты рисуй, рисуй.
Рад, что ты жив, цел и орёл
Я сейчас немного другую пиксельную хуйню делаю, туда хоть кодить не надо, но как освободишься, хайдде тоже время найдётся.
Че там кодить то бля?
Буквально всё. Я с кодом не очень дружу.
> Че там кодить то бля?
Подскажи, как сделать в двадэ выглядящее симпатчно и удобно-играбельное вскарабкивание по вертикальным поверхностям. Это одна из фишек Хайди. Делать двадэ-клон Хайди без реализации её фирменной фичи, это будет хуйня какая-то. Очередной митбой.
Я пока что рассматриваю вариант с физикой: По бокам от капсулы персонажа расположены два физических тела в форме квадрата, которые двигаются вверх-вниз и немножко подворачиваются внизу к центру, что на тестовых сценах выглядит весьма няшно.
мимо тот самый кодер
убегаю, чмоке фсем в чати
Делаю сейвы по гайду https://docs.godotengine.org/en/stable/tutorials/io/saving_games.html.
Получается не очень. Можно сохранять данные в словарях, но не сгенерированную заранее по известным значения карту, потому что инстанцируется всё рантайм из кода.
Вот как это инстанцирование сохранять? Вручную все-все-все параметры вытаскивать и сохранять? Или как-то можно всё дерево сохранить?
Получается не очень. Можно сохранять данные в словарях, но не сгенерированную заранее по известным значения карту, потому что инстанцируется всё рантайм из кода.
Вот как это инстанцирование сохранять? Вручную все-все-все параметры вытаскивать и сохранять? Или как-то можно всё дерево сохранить?
upd.
Нашёл другой способ и реализую сейчас его. Это вообще валидно, или костыль какой?
https://godotengine.org/qa/903/how-to-save-a-scene-at-run-time
У меня 2D персонаж приходит в последнюю точку NavigationPath2D и начинает трястись. Точнее он может прямо в нее прийти, почему-то, поэтому трясется. Как это лучше пофиксить? Двигается с помощью velocity = move_and_slide(velocity )
>Точнее он не может прямо в нее прийти
Пальцем в небо: у него длина "шага" больше расстояния до точки, вот он её и перешагивает. Надо если расстояние меньше определённой величины - телепортировать
>если расстояние меньше определённой величины - телепортировать
Двачую. Везде где вещественные числа - только так. Можно сравнить с гольфом - ты бьешь в сторону лунки, шар перелетает, приходится бить обратно, и так бесконечно.
Ага
А есть ли какой-то пример как загружать прямо dll-ку? Не gdnative. Ну или возможно через обертку gdnative. Если я не хочу ни собирать модулем в составе движка, ни вставлять в нее всякие годот-хидерс, а только дергать ее c++ функции.
Противники дерутся и в какой-то момент один из них погибает через queue_free. Почему-то проверки "if enemy:" не работают, хотя в отладчике вижу, что var enemy = null, ставлю везде проверку на "is_instance_valid(enemy)". Во дела.
Написано же в доках - переменные, ссылающиеся на объект, за тобой оно чистить не будет. Второй абзац.
Ааааааааааааа
Надо юзать референс. Референсы чистит автоматом.
Надо просто самому следить, где у тебя что хранится и что живое и что активное. Я считаю все эти queue_free, idle_frame, call_deferred костылями, да, нужными костылями на границе между скриптовым языком и c++ кишочками, чтобы программа не падала, но не надо их делать основными рабочими инструментами.
В данном случае - когда вызываешь queue_free, зануляй и переменную.
Если из-за архитектуры сложно добраться до этой переменной - удаляй не через queue_free, а свою функцию, в ней делай queue_free и посылай свой сигнал, а саму переменную подписывай на него примерно так
my_variable.connect("before_destroyed", self, "set", ["my_variable", null])
> когда вызываешь queue_free, зануляй и переменную
А ещё лучше, как диды, сделать себе утилитарную функцию free_and_nil (у дидов в стандартных либах было, нам же придётся где-нибудь в утилитарном синглтоне объявить)
> func free_and_null(obj : Object, queue : bool = true):
> > if queue:
> > > obj.queue_free()
> > else:
> > > obj.free()
> >obj = null
> Если я не хочу
На нет и суда нет. Всё тобой вышеупомянутое сделано не просто так. Движок не просто так зовётся движком. У движка архитектура. Благодаря архитектуре ты встраиваешь в готовый продукт (в нашем случае игру) сторонние компоненты не абы как, а в строго определённые места и строго определёнными способами. Если бы ты мог просто импортнуть длл-ки, то какой же это движок? Так, голое ИДЕ.
Через шарп можно.
Лень сейчас думать, жара. Просто у меня сейчас работает передача данных через сокеты. Чувствую что это излишне, ведь на обоих концах программы на c++ и они могли бы просто передавать указатель и заполнять переданный буфер. Кроме того я сейчас понял что та dll-ка грузит 6 других, я еще и там могу обломаться.
С шарпом кстати неплохой вариант, тоже потом попробую.
у
Сделал с оберткой gdnative. Как ни странно, все заработало с полтычка.
Основная DLL собрана своей билдсистемой без знаний о годоте
GDNative собран сконсом по оф документации под конкретную версию движка
В native-плагине делаем тупо #include <windows.h> LoadLibrary(path); (myFnPtr)GetProcAddress("fun_name"); скопипащеное со стековерфлоу
LoadLibrary автоматом загрузила все остальные DLL зависимости основной DLL, найдя их рядом с exe-шником
Native-плагин создает char buffer[1024], дергает fnPtr(buffer) DLLки и получает буффер заполненный правильными данными.
Завтра только многопоток потестирую, но вроде проблем быть не должно, если точка вызова одна.
Основная DLL собрана своей билдсистемой без знаний о годоте
GDNative собран сконсом по оф документации под конкретную версию движка
В native-плагине делаем тупо #include <windows.h> LoadLibrary(path); (myFnPtr)GetProcAddress("fun_name"); скопипащеное со стековерфлоу
LoadLibrary автоматом загрузила все остальные DLL зависимости основной DLL, найдя их рядом с exe-шником
Native-плагин создает char buffer[1024], дергает fnPtr(buffer) DLLки и получает буффер заполненный правильными данными.
Завтра только многопоток потестирую, но вроде проблем быть не должно, если точка вызова одна.
Ну вот, видишь. Всё не так страшно. Но зато у тебя уже есть готовый адаптер (твой натив-плагин), который может распарсить полученные данные и распихать их по нодам годота.
Отлаживать это, конечно, мама дорогая.
Но std::cout из самой DLL пишет в терминал, который с редактором годота запускается.
Да стандартный вывод он и в африке стандартный. Было бы удивительно, если бы он не заработал.
Идея адаптера ( https://ru.wikipedia.org/wiki/Адаптер_(шаблон_проектирования) ) же в том, что твоя сторонняя либа ничего не знает о годоте. Годот ничего не знает о либе. А вот натив-плагин (адаптер) знает обоих и может через интерфейс годота обмениваться данными с годотом, а через интерфейс сторонней либы - с ней.
Как заставить Control-узел расширяться при расширении размеров его детей? У меня узел Panel, в нем HBoxContainer, в нем TetureRect и Label. Размер Panel не меняется, текст в Label выходит за рамку.
И как уменьшить, если текст стал короче?
Там надо какое-то уведомление посылать вроде было
https://github.com/godotengine/godot/issues/20623#issuecomment-654605616
Справа от 959 и 620 по сигналу появляются стрелочка и число. Хоть и ХБоксКонтейнер, а похуй, накладывается, зато панель, на которой это все находится, расширится, ну что за хуйня бляха!
Ай, я там использовал Панель, а надо было ПанельКонтейнер
А почему вот это не работает?
if child extends Container :
Ошибка:
Parse Error: ':' expected at end of line.
if child extends Container :
Ошибка:
Parse Error: ':' expected at end of line.
А, надо
if child is Container :
Почему в классе Control есть функция rect_size(), а в ее дочернем PanelContainer ее нет?
Двущ, за тайлмап поясни.
Хочу взять нод, запихнуть тайлмап, отчертить комнату.
И сделать таких комнат штук 5-6, чтобы потом склеивать ноды в разном порядке, чтобы строить уже уровни.
Говно идея? Может есть что по лучше из вариантов?
Хочу взять нод, запихнуть тайлмап, отчертить комнату.
И сделать таких комнат штук 5-6, чтобы потом склеивать ноды в разном порядке, чтобы строить уже уровни.
Говно идея? Может есть что по лучше из вариантов?
По мне лучше комнаты закодировать в текстовом виде, и на основе этого текста отрисовывать без лишней мороки с гуём.
Я когда-то в csv файлах хранил заготовленные комнаты.
Для рогалика збс, пара файлов - пара слоёв(пол\стены\враги\предметы), но чот для годота это хуета как по мне.
Или я может долбаёб и не разобрался ещё до конца.
Прячет.
>Очень часто потребность в сокрытии методов получения и установки значений возникает в связи с разработкой более богатого интерфейса, предоставляющего дополнительное поведение.
https://refactoring.guru/ru/hide-method
> я может долбаёб и не разобрался ещё до конца
Ставлю бочку нефти на это.
В нескольких прошлых тредах я неоднократно убеждал анонов, что данные игрового мира должны быть платформонезависимы, в случае с годотом платформой является сам годот, его иерархия классов и его дерево сцены. Ты должен хранить данные уровней без привязки ко внутренним потрохам годота. То есть, ни о каком тайлмапе описательный язык твоего файла данных знать не должен.
Почему, когда PanelContainer раздувает в стороны при изменении в Remote любого значения margin контейнер ужимается до размера содержимого, а при изменении в коде не ужимается?
Потому что ему сигнал об изменении размеров не приходит. Пришли ему вручную этот сигнал.
Да вроде приходит. Послал вручную, не помогло.
Пускал сигнал в _процессе - тоже не помогает.
Если законнектить и в _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 и ничего больше не дергается. И даже процесс не нужен. Во дела.
Мужики, здарова. Смотрите, у ноды Button два сигнала: button_down() и mouse_exited().
Mouse_exited() сам по себе хорошо отрабатывает, когда курсор покидает кнопку,
но при зажатой кнопке (когда прошёл сигнал button_down()), mouse_exited() не срабатывает когда курсор выходит за пределы кнопки.
Точнее сработает спустя какое-то время, когда отпустишь кнопку на мышке за пределами Button.
Это можно как-то порправить?
Mouse_exited() сам по себе хорошо отрабатывает, когда курсор покидает кнопку,
но при зажатой кнопке (когда прошёл сигнал button_down()), mouse_exited() не срабатывает когда курсор выходит за пределы кнопки.
Точнее сработает спустя какое-то время, когда отпустишь кнопку на мышке за пределами Button.
Это можно как-то порправить?
У меня камера2д, а точнее ее позишн, выходит за правый и нижний предел и если дошел до правой стороны экрана и хочу передвинуть экран влево, мне приходится ждать, пока позишн вернется. А если он уедет слишком далеко вправо или вниз или вправо-вниз, то вообще непонятно где камера и куда нажимать, чтобы она вернулась. Короче очень уродливо это все получается.
для камеры существуют лимиты
Лимиты установлены. Позиция камеры спокойно уходит за правый и нижний лимит.
Если совсем невмоготу и не фиксится, попробуй закостылить.
Когда камера обнаруживает какую-то деталь на правом нижнем лимите, включается скрипт "если позиция камеры > максимальный лимит, то позиция камеры = максимальный лимит"
Меня бы за такое половина кодеров выебла с особой жестокостью, а ЯнДев бы одобрил.
мимокрокодил
Хм, думаю что настройками не поправить, только написать свою проверку по типу такой https://github.com/godotengine/godot/issues/20881#issuecomment-839388929
Я так понимаю, объясняют это тем, что если бы mouse_exited срабатывал то тут же начинали бы нажиматься соседние кнопки, при том что первую ты еще не отпустил.
Есть какой-то способ сжать использование видеокарты текстурой, кроме как сжать под видеокарту или изменить масштаб?
Если у тебя building_color просто меняет цвет домикам, то ты можешь выкинуть эти обе текстуры, перекрашивая шейдером какой-то заданный цвет.
Если у тебя вокруг домиков много пустого места, как на пике, то можно как-то компактнее их хранить
Посмотрел на твою картинку в соседней теме и вообще думаю - а не дешевли ли будет просто создавать на каждый вид постройки свою сцену, и выводить ее на нужных координатах тайлмапа.
Например видно что деревья у тебя одни и те же.
(Все еще считаю что такое еще легковеснее было бы в лоуполи с одноцветными текстурами)
Каким образом шейдер узнает является ли это на рисунке домиком первого или второго игрока? Это только если здания выделять как указывает автор ниже.
Для видеокарты - да, возможно дешевле. Для упрощения кодовой базы и вычислений - хуже. Грузить каждое изображение гораздо дороже, чем тайлмап.
Ведь как то раньше делали огромные тайлсеты под юнитов в героях 3. С кучей картинок и анимаций. И ничего, не лагало.
Эм, как ты видишь, видеокарта жрет на каждый пиксель 1 байт. Ей пофиг лоуполи там или нет. Она никак не оптимизирует изображение.
Я имел в виду 3д. Текстуры бы там не весили почти ничего, модельки из нескольких вершин - тоже не больше килобайт.
Ну, у меня не 3д. И вряд ли будет 3д.
>Каким образом шейдер узнает является ли это на рисунке домиком первого или второго игрока?
Для этого шейдеру передается параметр через varying, по сути это переменная в шейдере. Выставлять ее можно из скрипта, который знает в каком тайле какой игрок, так что тут все тривиально. Сейчас накидаю пример
Это бы очень помогло. Я пытался писать такой шейдер, но тайлмапе было грустно от таких попыток.
Правда есть нюанс. Передние объекты могут цветом залезть на заднюю ячейку, где другой цвет игрока. Я могу как-то взяв ячейку с текстуры ее перекрасить?
У меня самого пока не получилось, возьму таймаут подумать.
Давай, удачи
Да похоже сами разработчики так рекомендуют делать
https://github.com/godotengine/godot-proposals/issues/685#issuecomment-611671983
В общем, я покопался и нашел самый дешевый способ. Через вижуал сервер делать канвас итемы, которые будут брать из дикта RECT'ы для обрисования тайла. После этого к ним прикрепляется один из шейдеров замены цвета у игрока. После этого канвас итемы можно перемещать и делать с ним что угодно.
Выигрыш:
- 150 мб видеокарты минимум
- Оперативка не заспамлена бесполезными параметрами объектов
-Все работает очень быстро, т.к. ты идешь напрямую в вижуал сервер.
Минусы:
- Если понадобится анимация, то работа с нодами будет проще чем канвасы.
- Распределять и перерисовывать в файлике все минимум сутки.
- Канвас итемы жрут ноды. После 4.2х тысяч нод годот превращается в тыкву (в билдах 3.2 тестил, сейчас хз). Можно рисовать на обычном канвасе, но на сколько понял, придется его перерисовывать, если объект надо нарисовать сзади.
О, немного горжусь собой.
Доступ к размеру размеру видимой игровой области это get_viewport().size.
А если я зуммировался, то как размер видимой области получить?
А если я зуммировался, то как размер видимой области получить?
>А если я зуммировался
get_porrige()
Я четыре дня делал камеру
Пацаны я зуммировался ((((((((((
>get_porrige(porrige)
Пофиксил тебя. Хотя я всё равно не согласен, что для пориджа отдельная функция, уж лучше get_meal(porrige) если конкретный порридж, или get_meal(GLOBAL.MEALSARRAY.PORRIGE) если в принципе
porridge
> зуммировался
> порридж
> порридж
> порридж
> порридж
Оооо зумера порвалооооооооооо
Как запускать редактор в фулскрине по-умолчанию?
Пытаюсь заставить спрайты отображаться поверх других таких же спрайтов при наведении на спрайт мышкой. При наведении на красный спрайт почему-то выскакивает зеленый раньше красного. В одной точке есть и красный, и зеленый спрайты. Может мне кто-нибудь объяснить почему так выходит?
https://pastebin.com/eT6XRcYi
https://pastebin.com/eT6XRcYi
А в самой игре срабатывает только когда курсор на границе прямоугольника CollisionShape
У меня Ареа2Д имеет детей-Контрол ноды. Поставил им всем майус фильтр Игноре, заработало.
В свойствах ярлыка, не?
Не. Я про shift+11.
Это чушь, о чем сказал Хуан здесь 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) не пашет. Хотя если скрипт добавлять вручную, а не кодом, то всё нормально.
Я из одного скрипта добавляю скрипт к другой ноде.
Первый скрипт:
> 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. Я вот думаю, не сильная ли будет нагрузка. По сути достаточно чтобы скрипт работал только у пяти спрайтов в определённый момент времени. Вот и хочу добавлять, убирать скрипты ненужным в данный момент спрайтам.
Вводишь марку is_active и все
Ну вы чего, в Node же есть штатный set_process_input(true/false)
Что это?
Спасибо! То что надо.
Был бы ты тёлочкой, я бы тебя поцеловал.
Поцелуй его пабрацке ногомо.
Нельзя его юзать. Тебе может понадобиться менять визуал у ноды. И этот код смены визуала ты явно будешь хранить в скрипте. А ты его вырубил.
>Я так понимаю, объясняют это тем, что если бы mouse_exited срабатывал то тут же начинали бы нажиматься соседние кнопки, при том что первую ты еще не отпустил.
Это кстати работает не только для кнопок: к TextureRect приконнектить два сигнала mouse_entered() и mouse_exited(), и они перестают работать, если зажать кнопку мыши, когда курсор находится над TextureRect.
Для себя пока нашёл такое решение: отказался от кнопок, вместо них использую спрайты, на которые вешаю этот скрипт https://pastebin.com/yztZazat
>И этот код смены визуала ты явно будешь хранить в скрипте. А ты его вырубил.
Хранить этот код в скрипте, который не будешь вырубать. Не?
Я был не прав
Как можно зарендерить 3D меш поверх UI?
Вьюпортом. В UI-контролах даже есть такой. Во вьюпорте стало быть, рендеришь требуемый меш. Вьюпорт показывается поверх предыдущих нод и позади следующих.
Я так понимаю через таймлайн AnimationPlayer'а к синглтоновскому-сеттеру/параметру доступ не получить, да?
Через скрипт все работает, а через интерфейс не нашел как добавить.
Наверное можно еще прямо в блокноте tscn отредактировать.
> через интерфейс не нашел как добавить
Через интерфейс плеера анимаций можно вписать абсолютный путь к синглтону. Только есть один нюанс. У меня на 3.3.2. Ключи не добавляет, пишет, что требуется 3 параметра, а добавление вызывается с двумя. поэтому, если прям сильно надо, то сначала настрой анимацию на прокси-ноде того же типа, что и твой синглтон, затем замени путь. Пик рилейтед.
Да, получилось, спасибо.
А, не догадался что можно вписать в поле свойства путь к другой ноде, не той что уже указана. Какой же годот гибкий.
На твоём месте, если бы мне понадобился анимированный синглтон, я бы добавил анимационный плеер прямо в него, а ещё лучше - сразу связку из плеера и анимационной стейтмашины, всё настроил бы в редакторе, а в игре мой код бы просто делал что-то типа такого:
> Singleton.transit_to("new_state")
Благодарю за пояснение
Да, это какое-то очень странное говно, ставлю абсолютный путь, пытаюсь добавить метод/параметр из синглтона, пишет неправильный путь, но если использовать сначала ноду из сцены, добавить метод/параметр и потом переименовать все под синглтон - работает без проблем. Никогда бы не догадался до такого обхода.
Что нового?
Кто-то пилит пакетный менеджер для аддонов, думаю заюзать.
https://godotengine.org/asset-library/asset/962
Никто не знает как сделать кастомный анимейшн плеер?
Интересненько...
Ну что тут сказать? Это хак. В его классическом смысле (как лайфхак, только коде-хак). Что-то не задумывавшееся разработчиками. И что интересно, хак этот я придумал читая твой вопрос. Читаю пост, и такой себе думаю, я ж там клацал и открывался текстбокс с вводом пути вручную, а что если туда ебануть абсолютный путь до синглтона? И такой открыл, и такой ебанул, а он такой ключи не добавляет. А я такой путь вернул, ключ добавил, путь переписал, запустил - работает. И я такой - ОооООоо, чеэсвэээ!
> Что нового?
Говорят, Хуан в четвёрке все попапы сделает в отдельных окнах. Или не все? Поясните, посаны. Это какая-то хуйня, если он так сделает. Мне например внутриоконные псевдоокна, которые есть сейчас, больше подходят.
> Мне например внутриоконные псевдоокна, которые есть сейчас, больше подходят.
К хорошему быстро привыкаешь.
Тики для вызова функций на определенном тике.
Но ведь это уже есть. Или что ты имеешь ввиду?
Вот же, не?
Третья пикча не та:
У меня все нарисовано через визуал сервер. Я столкнулся с проблемой апдейта ридов и подсчета тика без таймера через сохранение инты предыдущего тика времени ос.
Крч у меня 2 проблемы.
1. Я хз как обновлять рисунок сделанный через VisualServer.canvas_item_create()
2. Я хз как по времени OS сделать нормальную обработку анимаций через redraw
По первому пункту ящитаю (с дивана) что редактор так же делает, например, когда в запускаемом проекте ты выставил галочку "показывать коллизии". Он эти коллизии рисует напрямую через АПИ вижуалсервера (осторожно, диван!) поэтому я бы глянул исходники редакторной части движка, чтобы подглядеть, как это реализовано там.
По второму пункту примерно то же, только непонятно зачем тебе время ОС, один хуй там те же тайминги, что приходят в мейнлуп (тоже диванное предположение, требуется проверка, но впадлу).
Разобрался. Вызов VisualServer'a идет отдельным потоком в движке, и годот прост не успевал почему-то получить новые параметры для перерисовки.
По второму пункту ещё не пробовал. Мне хочется, чтобы object'ы которые висят в памяти и не имеют нод спокойно себя рисовали и анимировали сами, либо через такую же обертку не несущую оверхеда
Может вопрос и глупый, но должен был задать
Вижу, что на оф. сайте можно скачать отдельную версию с поддержкой Mono. Вопрос такой: в стим версии есть вообще поддержка Mono?
Вижу, что на оф. сайте можно скачать отдельную версию с поддержкой Mono. Вопрос такой: в стим версии есть вообще поддержка Mono?
В чем профит стим версии перед нормальной?
Тоже не понимаю. Может Хуан изначально местный ассетстор планировал через стим воркшип организовать, хз.
Как получить дубликат объекта в годоте?
Как сравнить кастомные классы?
Как сравнить кастомные классы?
>Как получить дубликат объекта в годоте?
var second = first.duplicate()
>Как сравнить кастомные классы?
Наверное написать свою функцию сравнения.
у object нет метода duplicate.
И правда, ну тогда три варианта
1. Наследоваться от Node, Ну это ты можешь посчитать оверхедом.
2. Написать свой duplicate. В питонячьих языках это обычно легко, смотри функцию get_property_list() которая возвращает массив всех полей объекта (в формате словарь name: type)
3. Перейти на C#, там вроде есть MemberwiseClone()
Но я не могу получить класс кастомного объекта. Я его не создам, не прописав заранее класс в код. А значит не смогу сделать обертку для object на века.
Значит, не надо пользоваться object, пользуйся Node или Resource как базой, у них duplicate есть.
Вот бы кто нибудь сделал игруху на годоте
Чтобы тащить гарбадж коллектор за собой? Увольте.
Вот как товарищ погромизд освободится, так может и продолжим делать.
а ты сам кто?
Пытающийся в графен. Пиксели содомирую, короче.
Чот тайлмапы не оч понял.
Делаю одиночные плитки, могу кодом выставлять через set_cell, делаю атлас и могу только первую картинку юзать из атласа.
Типо кодом только одиночными плитками можно пользоваться и автотайлами?
Делаю одиночные плитки, могу кодом выставлять через set_cell, делаю атлас и могу только первую картинку юзать из атласа.
Типо кодом только одиночными плитками можно пользоваться и автотайлами?
Последний параметр опциональный задает координаты тайла с атласа.
Тьфу блядь, ещё раз прочитал доку и увидел, спасибо.
Как сделать, чтобы окно вело себя так, как на видео? Чтобы игра и объекты всегда были в центре и не меняли расположение, как на втором видео.
anchor или привязки
Есть разные способы
В одной игре делал так
1. Настройки Project->settings->window->stretch
mode=viewport
aspect=ignore
2. В _ready подписан на событие screen_resized
get_tree().connect("screen_resized", self, "_screen_resized")
3. пик
Спасибо, анонче!
У кого-нибудь случайно шейдеров не завалялось, которые бы определенный цвет зеркалили?
Почему шецдера со screen_texture не работают? Что за лажа?
В глес 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()
Впервые попробовал live editing, господи как это прекрасно.
И константы, положения на лету меняю, и скрипты.
И константы, положения на лету меняю, и скрипты.
Бамп вопросу.
BackBufferCopy почему-то не работает. Я без понятия как его использовать.
Бамп вопросу.
Бля, анон, я не знаю ответа на этот вопрос. Прости!
Мне даже в чате годота не отвечают. Это очень странно
Я не понимаю что происходит. Я взял шейдер из оф демки, поместил на спрайт и получаю ошибки
В оф демо работает, кстати. И пока я хуй знает почему.
Так, было в какой-то настройке дело. Теперь правда все равно нихуя не работает. Но это хотя бы не очень раздражает.
Шейдер если видит что угодно кроме цвета заднего фона, красит воду в бело-красный (чтобы виднее при тесте) цвет. В зависимости от угла наклона камеры, шейдер либо работает, либо нет. Что блять странно и уродливо. Кто-то с этим сталкивался?
Шейдеры - штука капризная, если ты конкретно не знаешь, что именно ты делаешь - шейдеры тебя выебут. И они тебя судя по постам уже ебут, ибо ты копипастишь. Что посоветовать тут? Совет может быть один: пиши свой шейдер с нуля.
Я и пишу свой шейдер с нуля. Есть что по делу сказать? Почему шейдер у которого логика "вода наехала на что угодно фоном != цвета фона сделай белым" - не работает на весь экран?
> Есть что по делу сказать?
Есть.
> Почему шейдер не работает
Потому что ты не разобрался в вопросе и не знаешь, что ты делаешь.
Это не троллинг.
Это мой личный опыт, в геймдеве, в годоте и вообще в айти.
Предлагаю тебе пикрелейтед.
>В зависимости от угла наклона камеры
Что ты имеешь в виду? Разве у тебя не 2д спрайты?
У меня канвасы которые нарисованы через visual server поверх node2d. Чтобы их выстраивать попорядку, я использую z index, но что-то мне подсказывает, что у годота есть на z-index оптимизон, отрубающий получение скрин текстуры? потому что шейдеры работающие непосредственно с текстурой канваса - в порядке.
Угол наклона камеры, эт я конечно шизофразно спиздел. В общем в зависимости от положения камеры шейдеры либо включаются, либо отключаются, хотя канвасы ещё в камере (но видимо годот думает, что уже нет).
Естественно я не разобрался в вопросе. Потому что я нахуй не понимаю, что происходит. Я делаю шейдер, на тестовом полигоне он работает как надо. Сую в мейн сцену, а игра думает, что моя камера не смотрит на объект и вырубает работу шейдера нахуй. Покажи мне пожалуйста документацию, где описано такое поведение, чтобы я разобрался.
> Покажи мне пожалуйста
Мне лень. Я лучше пивка ещё ёбну за твои успехи. Давай, успехов там тебе! И хорошего настроения!
Ага, спасибо.
Отбой. Мысль про z-index не верная. Все равно нихуя не пашет
4.0 всё еще не вышел?
Waiting 4 4
Зачем он? По сути в 3.3 есть все что нужно для разработки игр.
Нет предела совершенству.
Ох какую красивую опечатку словил
Вроде бы в C# тут ошибка, а в C++ варнинг
Вроде бы в C# тут ошибка, а в C++ варнинг
Кто-то сталкивался с 15 screen_texture шейдерами под андроид? У меня жуткие лаги от них.
Судя по всему:
- backbuffercopy уникален на каждый рид, тем самым превращая устройство андроид, где больше 10+ шейдеров с SCREEN_TEXTURE в лагающее говно.
- Каждый текст до сих пор вызывает draw call, будь то label или что-то иное, вроде draw_text().
- Канвас итем если состоит из нескольких текстур - вызывает 3 дравкола. Да, движку не интересно склеить все текстуры в одно внутри канвас итема и реюзать.
Вопрос в следующем, когда оптимизон от движкопись?
У меня до сих пор бомбит, что на рисование 30 символов выделяется 20 мб оперативы.
> когда оптимизон от движкопись?
Форкай и делай сам. Не жди Хуана.
Как только ты напишешь "зачем мне форкать, у меня есть юнити/уеч/гамак/итп" - на тебя моментально от меня летит репорт за движкосрач со всей любовью, побрацке, ногомо.
Годотеры, когда альфа 4 версии будет?
Кочай бетку прямо сейчас https://downloads.tuxfamily.org/godotengine/testing/ не будь лохом! Не жди альфу.
Кубы содомируются на Вулкане.
Бле, я так то на годоте игру хотел доделать без форков. А то я сейчас форкану, починю эту залупу или хотя бы методы себе в годот выведу, а за это время движкописи новой версией починят другие баги, на которые я натолкнусь завтра.
Может есть кто знает фишку/костыль чтобы это обойти или имеет влияние в кругах движкопись,чтобы они в работу взяли?
Нужно быть кабанчиком. Если ты кабанчик, ты подскочишь, порешаешь вопросики, Хуан и Акиен мигом твои пулл реквесты одобрят.
Не помню чтобы проскакивало в новостях, это что порталы завезли?
В 3.4 немного поломали треды (что ломает пару аддонов), я пока баг репорт не отправлял, воркэраунд простой - добавить третий аргумент thread.start(self, "func_name", [])
Спасибо за совет. Это важно.
Так они были всегда.
А что в 3.4 будет? Никак не могу найти заявленных фич
>Так они были всегда.
Нет, был кастомный модуль lportal, теперь его автор другую лучшую реалищацию в сам движок впилил
https://github.com/godotengine/godot/commit/eb6f98ec559b3df1d1346d88ae4f94323db2d383
Для spatial:
rotate_object_local ( Vector3 axis, float angle ) - вращение в координатах самого объекта (object space)
global_rotate ( Vector3 axis, float angle ) - вращение в координатах world space
rotate ( Vector3 axis, float angle ) - это вращение в координатах родительского объекта (parent space), правильно?
rotate_object_local ( Vector3 axis, float angle ) - вращение в координатах самого объекта (object space)
global_rotate ( Vector3 axis, float angle ) - вращение в координатах world space
rotate ( Vector3 axis, float angle ) - это вращение в координатах родительского объекта (parent space), правильно?
Спасибо.
Хвала Cinemachine. Аой...
Тут есть ребята которые умеют красивые шейдеры писать желающие помочь-проконсультировать?
Я не умею, братюнь, сорян. Попробуй видосики на ютубе.
Я от туда могу только копировать. А я хочу понять.
Чтобы понять, следует читать матчасть. На твоём месте я бы загуглил GLSL и там уже по ссылочкам читал джва месяца.
Задавай сразу конкретные вопросы, если знают - ответят.
Есть атлас 900х900.
Есть выбранная картинка 300 на 300.
Как шейдером разделить картинку на 8 равных частей?
Как перевернуть изображение через шейдер?
Вот есть у меня VBoxContainer нулевого размера.
Потом я добавляю в него Label-ы через код, по идее его margin-ы и размер должны измениться же?
Потому что все показывается нормально, но в коде эти переменные не обновляются после добавления Label-ов.
Как в связи с этим получить актуальные размеры контейнера?
Потом я добавляю в него Label-ы через код, по идее его margin-ы и размер должны измениться же?
Потому что все показывается нормально, но в коде эти переменные не обновляются после добавления Label-ов.
Как в связи с этим получить актуальные размеры контейнера?
В шейдере действуют координаты от 0.0 0.0 до 1.0 1.0
Также там подается что-то на вход, и что-то на выход.
Пик 1 - самый простой вариант это вручную задавать цвет.
Пик 2 - это читать цвет из текстуры по координатам UV и возможно как то его преобразовывать.
Пик 3 -Это значит что читать можно по любым координатам, например вот тут я перевернул по вертикали полоску второй четверти.
Пик 4 - насколько я понимаю, if в шейдерах плохо, а математика на параллельных ядрах хорошо. Поэтому есть такая функция как step(a,b), она возвращает 1.0 если a > b, в остальных случаях 0.0
Надеюсь тебе это поможет сориентироваться.
Ну и чтобы управлять этим всем, надо завести переменную, например, вектор. Переменная в шейдерах называется uniform, и выставлять ее можно через скрипт.
UV атлас текстуры работает не так. Он разделит всю текстуру на 8 частей, а не выделенную часть.
Ну я не спорю, я в твою задачу особо не вникал.
Если тебе надо вырезать кусок с текстуры, то умножение и сдвиг UV координат и вперед.
Может быть есть более штатные способы какие-то специально для атласов, хз.
Нет, атлас текстура уже порезала мне на 9 элементов 300 на 300.
Я беру по случайному куску 300х300 UV и получаю UV по всей текстуре, а не по этому куску. И соответсвенно этот кусок не могу поделить штатными методами.
То есть ты имеешь в виду что атлас все равно передает всю текстуру 900 в шейдер целиком.
Если у тебя отдельные объекты, спрайты, то ты можешь передавать в шейдер через униформ, какой именно кусок. Если тайлмап, то я способов не придумал.
Тайлмап. И атлас. И не передаёт в шейдер, а один раз на видюхе закешил и берет от туда регионы. По крайней мере так должен делать нормальный движок.
Чел деление на регионы делается на проце, какой нахуй шейдер, кеш и ещё какая залупа. Просто, если нужно отрисовать несколько регионов этой тайлмапы, создаётся батч и эта текстура уходит на отрисовку, где каждый регион указывает свой прямоугольник. Всё. Никакой хуйни. Так работает любой тайлмап под капотом в любом движке, фреймворке, библиотеке.
Блэт треды перепутал. Ну да похуй.
В тайлмапе зеркаливание реализовано. Завязывай с оверинжинирингом.
Каким овериндженерингом? Я шейдер пишу под тайлмапу.
А тем временем, в бункере Петюни:
https://www.youtube.com/watch?v=hQ1j5R5IG6g
https://www.youtube.com/watch?v=hQ1j5R5IG6g
Прикольно смотреть на то как они оправдывают удаление GLES2 при том что он работает лучше чем GLES3 и поддерживает больше устройств https://godotengine.org/article/about-godot4-vulkan-gles3-and-gles2
лутший движок для игр
Рано или поздно от этого старья придется отказываться. Сейчас лучше сосредоточиться на Vulkan.
> оправдывают удаление GLES2
Но ведь удаляют глес 3. Пруф пик:
> поддерживает больше устройств
На момент выхода 4-ки это будет уже не большинство.
>GLES2 работает лучше
Если только в примитивных играх. Ну например террейна под него нет. Некоторых спецэффектов тоже.
Блдь а как сглаживать line2d, polygon2d и тд?
> line2d.antialiased = true
Да, но не меняется ничего же
Кто-нибудь использует этот движок для производства игр на андроид, иос? Хочу вкатиться в движок, прочитал, что есть возможность такая, если я правильно понял
Появляются тут такие аноны, но редко, на быструю помощь не рассчитывай. Рикаминдую ютуб. Сканера знаешь? Он делал подробный туториал по сборке на андроид.
Выключи HDR или жди мержа.
https://godotengine.org/qa/53982/noticed-that-antialiased-setting-polygons-doesnt-anything
Хбт сделано под андроид на годоте. Под айос года полтора назад были баги в 3.1. Возможно поправили.
Благодарю
Пробовал, шейдеры дохнут(
годоти, поясните сложный прикол. почему созданный встроенный меш всегда повернут на 90 градусов? это "фича"?
почему ось X направлена ВЛЕВО?
можно ли как-то перезагрузить ВСЮ игру? Закрыть и сразу же открыть.
get_tree().reload_current_scene()
Спасибо конечно, но я же специально выделил слово ВСЮ. Грубо говоря так же, если бы я закрыл и открыл игру.
get_tree().change_scene("res://my_launch_scene.tscn")
> если бы я закрыл и открыл игру
OS.execute("path/to/game")
get_tree().quit()
Круто, очень близко к тому что я хотел. Я пытался сделать настройки, которые включаются только при перезапуске игры. В итоге сделал временно костыльный недоспособ, но пока хватит.
Передаю текст в скрипт и делаю reload();
Если ошибка отсутствует, все норм. Если присутствует - все крашится к хуям. Не хочу, чтобы крашилось.
Как сделать так, чтобы это говно начало мне возвращать ошибку?
Если ошибка отсутствует, все норм. Если присутствует - все крашится к хуям. Не хочу, чтобы крашилось.
Как сделать так, чтобы это говно начало мне возвращать ошибку?
Вот тут не возвращается ошибка, что меня раздражает. Он просто роняет игру и все.
пытаюсь вкатиться, ебался с движением по склону часов пять. Ничего нормального нагуглить не смог
Тоже. Эта хуйня всегда возвращает 0. Ей норм. А потом берет и роняет игру с ошибкой. Сука, ебаный хуан.
А что должно, по твоему происходить, проверка гдскрипта на синтаксис?
все уже просмотрено, про прыжки нигде не говорят, а у меня именно они косо работают, впрочем похуй, решил своей головой думать и переписать с нуля.
Конечно, и возврат ошибки о ней. Но хуан на столько жесток, что РОНЯЕТ НАХУЙ ВСЕ при проверке на парсинг, и возвращает ошибку только если при компиляции срабатывает какая-то переменная can run. Я в шоке. Кто-нибудь знает как поправить код и перекомпилить годотю? А то я на С++ на винде заебусь пакеты качать.
Если кто-то знает как из годота достучаться до:
GDScriptParser - буду благодарен.
Да вроде бы сам годот себя ведет точно так же, он просто остановится на ошибочном скрипте, не проверяя заранее.
Не факт что он вообще попадает в экспорт. Шаблоничики-то собираются с tools=no. Может быть кто-то gdnative модуль делал где просто копипастнул туда весь парсер.
Я хочу сам написать этот код на гдскрипте и вкинуть куда-нибудь в консоль или в текстовую ноду.
Как пользоваться нативскриптом так и не разобрался. Если есть норм примеры, дай плз. Тогда я тупо попробую скопировать парсер и анализатор.
Я в такое вписываться сейчас не готов.
Видел на гитхабе пару-тройку парсеров гдскрипта на питоне, может быть как костыль запускать их как внешнюю прогу и смотреть успешно ли распарсилось?
Я гдскриптом буду запускать питонопарсер, чтобы понять запустился ли гдскрипт?
Ну, я вижу твою цель так -
1. загрузить скрипт (тут годот не сингализирует об ошибках в самом скрипте, а только о факте загрузки файла),
2. ??? (проверка на ошибки в скрипте)
3. запустить, но если есть ошибки, то годот падает
На п.2 ты хочешь достать с++ код из движка, я предложил альтернативу.
Можно еще, вроде бы, запускать сам годот чтобы он выполнял скрипт, хз как это работает, пикрил
Вообще, я все равно вижу проблему в подходе. Ок, ты проверишь на ошбики. Но пользователь все равно может написать что-то вроде
var x = null
x.some_func()
это все равно упадет же, не? Способа игнорировать ошибки для какой-то ноды я не нашел.
Я попробовал через ос экзекют, он орет с незнакомого символа юникода. Если у тебя есть работающий пример - будет хорошо.
Я бы хотел попробовать сделать прототип, где каждый игрок пишет скрипт своему персонажу, чтобы проходить уровни. Я могу запустить нормальный скрипт, но не могу отловить ошибку чтобы показать, что скрипт кривой. А так же не могу отловить ошибку, чтобы откатить выполнение скрипта, чтобы игрок мог продолжить исправлять скрипт.
Последнее что я хочу - это писать свой лексер и парсер)
Вообще, как только кто-то накостылит плагин/ещё что-то позволяющее пользакам адекватно встраивать скрипты в твою игру, это позволит расширить аудиторию годота, хотящих побырому наверстать такого рода игры. Возможен даже асинхронный опенвлрлд, где каждый пишет свой объект и грузит скрипт на сервер, чтобы другие игроки их выкачали.
Я видел какие то игры, где можно писать скрипты, но там упрощенный язык созданный для игры.
Может быть взять C#? Под него есть парсеры, и по крайней мере там можно взять в try catch
Это устанавливать студию и мучится с прикреплением ее к годоту. Поэтому проще тогда уж на юнити.
В общем, тяжёлый пакет говна и то и другое. В гдскрипте прелесть в том, что он весит мало и запускается на любом калькуляторе.
Я нашел ту игрулю, автор пишет как он обрабатывает свой язык построчно
https://www.reddit.com/r/godot/comments/msodaw/finally_got_the_basics_of_my_ingame_scripting_done
гдскрипт все равно упадет если игрок напишет
move(0/0)
Напиши свой мини-язык, в котором будут только нужные функции, типа move(x, y), shoot, raycast, может быть циклы, условия, переменные. За пару дней реально.
Ну да, только как писать токены на кондишены и на for() я пока не знаю.
Выглядит здорово!
Давно не занимался языками, там будет что-то типа
IF cond_expr : cod_block
FOR var_name IN array : code_block
Ну на псевдоязыке такие паттерны я тоже могу к чему угодно написать) А вот как дело до областей видимости дойдет, там не все так просто.
Если ты для твг делаешь то нафиг надо области видимости.
За область видимости же не лексер все равно отвечает. Ну а там парсер посмотрит, что это имя уже есть в списке используемых и выдаст ошибку.
Не для твг. Твг я уже не успею.
Обожаю все что связано с геймдевом в C#
\.nuget\packages\godot.net.sdk\3.3.0\Sdk\Sdk.props(29,3): Не удается найти пакет SDK для .NET. Убедитесь, что пакет установлен и версия, указанная в файле global.json (если он имеется), соответствует установленной.
\.nuget\packages\godot.net.sdk\3.3.0\Sdk\Sdk.props(29,3): Не удается найти пакет SDK для .NET. Убедитесь, что пакет установлен и версия, указанная в файле global.json (если он имеется), соответствует установленной.
Короче т.к. папочка была ещё на 86х, хуанокод не мог залезть в 64х. Я в шоке.
В глубинных интернетах наткнулся на фичу, но не понял ее назначение.
На вложенной сцене ставим галочку Load as Placeholder, и хопа, она больше не загружается при старте сцены.
Зато ее можно загрузить ручками ($Player as InstancePlaceholder).replace_by_instance()
Плюс: можно сделать отложенную загрузку, при этом не надо писать имена файлов из res://
Минус: сигналы не загрузятся, надо подключать руками после загрузки
На вложенной сцене ставим галочку Load as Placeholder, и хопа, она больше не загружается при старте сцены.
Зато ее можно загрузить ручками ($Player as InstancePlaceholder).replace_by_instance()
Плюс: можно сделать отложенную загрузку, при этом не надо писать имена файлов из res://
Минус: сигналы не загрузятся, надо подключать руками после загрузки
Сто раз говорил себе - теперь писать буду только на C#.
Ну и чо, очередную игру дописываю на гдскрипте.
Удобно, быстро, просто, мать его.
Ну и чо, очередную игру дописываю на гдскрипте.
Удобно, быстро, просто, мать его.
Почти дописал свой парсер языка на с#.
Сделал математические, логические и операции сравнения. Установку/получение переменных. Вызов дефолтных функций с любым количеством параметров (без возврата/с возвратов значения). Ифы.
Остались циклы, объявление функций и вызов функци игрока. Потом полировка и все, можно писать игры на программирование.
Сделал математические, логические и операции сравнения. Установку/получение переменных. Вызов дефолтных функций с любым количеством параметров (без возврата/с возвратов значения). Ифы.
Остались циклы, объявление функций и вызов функци игрока. Потом полировка и все, можно писать игры на программирование.
> Почти дописал свой парсер языка
> Я бы хотел попробовать сделать прототип, где каждый игрок пишет скрипт своему персонажу, чтобы проходить уровни.
В шапке описан вариант, как такое сделать без танцев с бубном. Правда из-за полного доступа к скриптингу, такой проект будет беззащитен против крыс.
> - Для приверженцев опенсорца существует возможность распространять проекты в незапакованном формате. Просто скачай темплейт с оф.сайта и положи экзешник/эльфешник в папку с проектом, этого достаточно. Имя файлу можно задать любое. Дополнительно можешь вшить свою иконку в экзешник. После этого, запустившийся файл темплейта обнаружит рядом с собой файл project.godot и начнет грузить проект из него и из файлов, лежащих в распакованном виде в той же директории. Для запущенного таким образом проекта папка res:// становится доступна для записи (если это не ограничено правами доступа в системе).
Данный метод прямо позволяет не ебаться с подгрузкой скриптов в рантайме, а просто модифицировать весь проект на лету (в том числе редактором, и даже лучше редактором), а потом перезапускать "game.exe" в корневой папке проекта.
Чувак... Он делает игру, где игрок пишет скрипт во время игры, а не пакует зипы и перезапускает экзешник.
Чувак... Я ни слова не сказал о паковании зипов.
Ты про аддон диалоговой системы который работает на экспрешенах?
Короче уже не важно. У меня работает нода for, нода while.
Осталось функции запилить и отлаживать. Возможно, будет работать в разы быстрее чем гдскрипт, лол.
Осталось функции запилить и отлаживать. Возможно, будет работать в разы быстрее чем гдскрипт, лол.
Так, вызов пользовательских функций и скопы сделал. Осталось потестить пару дней и можно в релиз, писать игру вокруг всего этого.
Я про шаблон экспорта, который по сути является запускным файлом игры. Когда ты делаешь "экспорт", редактор пакует все файлы проекта в PCK кладёт его в указанную тобой папку и рядом кладёт "шаблон экспорта", который по сути является запускным файлом игры. Однако, как написано в ОП-посте, если просто положить в папку с проектом шаблон экспорта, и кликнуть по нему, он запустит игру прямо из проекта.
Таким образом, внутри игры не нужно делать загрузку скриптов, а достаточно только открывать, изменять и записывать файлы GD, после чего перезапускать связанные с ними сцены. Тоже внутри игры. Первоначальную отладку сделать в редакторе, а дальше хуярить внитриигровыми инструментами. При этом моддерам твоей игры весь редактор годота станет доступен как редактор игры. Что в некотором роде небезопасно.
Это уже будет не моддинг, а чистое комьюнити-редактирование игры целиком. Тут уж впору организовывать контроль версий и апрувить пуллреквесты.
Я как бы могу скрипты и из годота релоадить. Твои шаблоны экспорта ошибки позволяют отлавливать в коде?
> Твои шаблоны экспорта
> Твои
> Твои
Мопед не мой. Я просто разместил объяву.
Порекомендуйте плагин для Google Play In-App Review, которым пользуетесь.
Порекомендуй свой, Бардинов, хуле скромничаешь?
Телепаты в отпуске. Я позвонил им, они говорят
> пусть пакет нацеливания переустановит
> пусть восстановит удалённые сборки
> пусть перезапустит годот
>Порекомендуй свой, Бардинов, хуле скромничаешь?
Чиво блять?
Таво, блять. Не отпирайся. Запостил свой вопрос с правильно написанным 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);
}"
Крч такой код обрабатывает.
Собачки в коде нахуя? Обоснование есть?
Очевидно, он так детектит переменные, упрощая парсер, и не вводя ключевые слова var, let
Вначале была явная инициализация, через вар. Но потом мне показалось это скучным и лишь мешающим пользователю. Плюс переменные с собачками явно видно.
В общем ищу программиста, который бы продолжил делать мой проект с написанием кода для игрока. Я не могу сейчас его делать, т.к. два проекта не потяну. Пишите свои тгшчки. У меня гениальная геймдизайнерская задумка.
> упрощая парсер
Каким образом он упрощает парсер? Вместо case else (в который попадают переменные в парсерах здорового человека, когда все ключевые слова обработаны, а значит остались только объявляения переменных) у него дополнительный case @.
> скучным и лишь мешающим пользователю
Очередной аутист, блять.
Жаль что ты неуч ебаный, который ни одного парсера в глаза не видел и выдумывает как оно работает.
Разве это говно может быть красивее, чем предыдущее с собаками?
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);
}
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);
}
>Каким образом он упрощает парсер?
Когда читаешь токен, сразу знаешь, что если он начинается с @ то это имя переменной.
> ты неуч ебаный, который ни одного парсера в глаза не видел
Смешные заявления от неуча, видевшего ОДИН парсер-...
..-.токенизатор
Смешно читать заявления от неуча, который экстрополирует свою проблему на других.
> ты неуч, яскозал
Аргументация - моё почтение.
У меня нет проблем с парсерами, такшта мне нечего экстраполировать на залётного тролика, демагогящего редукцией к невежеству.
Ты поздно с детского сада приходишь. Троллики у него, нет ты дурак. Просто пиздец.
Бамп проблемой. не помогло.
Нужно удалить в програм файлсе 86 папку с net залупой, если она присутствует в х64. + скачать говно именно той версии, которую поддерживает годот.
Не помогло. Снёс нахуй, короче.
Опять годот виноват в том, что залётный движкосрачер вкатился в опенсорц на инвалидной коляске, свалился на первой же кочке и был выебан древним, отточенным механизмом опенсорца на потеху всех УМВР-пасанов.
в 4вермии будет прорыв?
а что еще?
Да это уже много, до этого годот был непригоден просто к 3д, а сейчас сразу считай твердочёткий прорыв. Рывок со дна поносного до альфа центавры. Вопрос по производительности остаётся. Осталось заменить гдскрипт на сишарпу. Хотя надо узнать, они же там что-то переделывали, производительность может увеличилась?
подскажите как настроечки сделать, допустим я хочу подрубить msaa внутри игры. Я нагуглить не могу, разучился
Берешь в поиск убиваешь msaa и ставишь галочку.
Блять, за что мне это? Хуан, за чтоооо??? Нахуй ты поп-апы поломал? Неужели нельзя было оставить псевдооконные классы в зелёных нодах, как сейчас в трёшке, и выводить их в отдельное окно через встраивание в выделенный класс на скриншоте? Вот уёбок, прости господи.
Пацаны, годот ставит мне залупу 6.5 версии, а она не работает на 18 жаве. Как мне поднять её до 7.1?
Бля, прошел 9 кругов ада, но все же все запустилась. Но при добавлении адмоба в модули андроида проект фаталит. Кто знает почему?
Я думал надо выбирать версию под размер челена.
Можно ли как-то без viewport в качестве фона сделать текстуру или градиент? На переднем плане 3D модель.
У меня сейчас в настройках Environment: Background - Color+Sky. Могу менять цвет фона, но хотелось бы туда присобачить текстуру.
У меня сейчас в настройках Environment: Background - Color+Sky. Могу менять цвет фона, но хотелось бы туда присобачить текстуру.
Написано делать так
Environment: Background - canvas
Canvas Layer с глубиной -1
И уже на него кидать свой задник
Про Sky там ничего не написано? а то мне без него никак.
Может тебе просто билбоард поставить?
Да и во вьюпортах нет ничего страшного.
Спасибо, это мне подходит. Сейчас буду учиться растягивать его на весь экран.
>во вьюпортах нет ничего страшного
Они мне фпс просаживают.
Хочу рендерить много-много квадратиков разных размеров, некоторые в будущем могут иметь текстуру и коллизии. Я знаю про компонент TileMap2D, но для него нужно создавать тайлсет, а это создаёт лишние трудности. Короче, хочу рисовать вручную, как на пикриле (я уже делал более сложный код, этот для примера).
Вопросы:
1. Чё как с оптимизацией? Я читал про то, что _draw() выполняется один раз (обновить можно только вызовом update()) и результат кэшируется, но что на счёт видимости на экране - кулинг есть?
2. Как прикручивать физику? Создавать отдельные ноды статикбоди с кучей коллижншейп под каждую зону? Тайлмап ведь именно так делает, только скрытно от юзера?
3. Стоит ли вообще смотреть в сторону тайлмап, если мне не нужна сортировка по Y, разворачиваю тайлы я через код (я пробовал автотайлы, там нужно много лишнего рисовать, не умеет он использовать один тайл в 4 ракурсах сразу, очень жаль), а необходимость делать все тайлы заранее и одного размера меня сильно ограничивает? Заполнение и настройка тайлмапы выглядит как лишние телодвижения, если я могу просто спамить draw_rect().
4. Я правильно понял, что если какой-то тайл имеет полупрозрачность, нужно создавать отдельную тайлмап, на которой будет фоновый тайл? Что-то я не нашёл переключения слоёв, как, например, в Tiled. Полупрозрачность нужна для совмещения разных типов тайлов, но без нескольких слоёв ничего совместить не получится. Довольно странно создавать отдельный тайлмап, при том что вручную я мог бы нарисовать гораздо быстрее (в один проход).
Вопросы:
1. Чё как с оптимизацией? Я читал про то, что _draw() выполняется один раз (обновить можно только вызовом update()) и результат кэшируется, но что на счёт видимости на экране - кулинг есть?
2. Как прикручивать физику? Создавать отдельные ноды статикбоди с кучей коллижншейп под каждую зону? Тайлмап ведь именно так делает, только скрытно от юзера?
3. Стоит ли вообще смотреть в сторону тайлмап, если мне не нужна сортировка по Y, разворачиваю тайлы я через код (я пробовал автотайлы, там нужно много лишнего рисовать, не умеет он использовать один тайл в 4 ракурсах сразу, очень жаль), а необходимость делать все тайлы заранее и одного размера меня сильно ограничивает? Заполнение и настройка тайлмапы выглядит как лишние телодвижения, если я могу просто спамить draw_rect().
4. Я правильно понял, что если какой-то тайл имеет полупрозрачность, нужно создавать отдельную тайлмап, на которой будет фоновый тайл? Что-то я не нашёл переключения слоёв, как, например, в Tiled. Полупрозрачность нужна для совмещения разных типов тайлов, но без нескольких слоёв ничего совместить не получится. Довольно странно создавать отдельный тайлмап, при том что вручную я мог бы нарисовать гораздо быстрее (в один проход).
Фпс просаживает не вьюпорт, а рендер всей сцены его камерой.
Т.е. если у тебя обычная сцена (все равно тратит 1 корневой вьюпорт) + еще один вьюпорт, например для зеркала или камеры наблюдения, то это будет 2 рендера сцены. А если ты основную сцену перенесешь во вьюпорт, отрендеришь в текстуру и выведешь поверх спрайта, то вроде ничего серьезного просаживать не должно.
>основную сцену перенесешь во вьюпорт, отрендеришь в текстуру и выведешь поверх спрайта
Кстати, это возможно как-то сделать без мерцания экрана? Я пробовал сделать рендер мира в контрол на экране, но если просто перенести сцену во второй вьюпорт, вьюпорт ничего не рендерит до следующего кадра (чёрная картинка на выходе). Если использовать 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() для очистки рендерера, т.к. пусть даже его не видно в основном вьюпорте, он всё равно рендерится во втором.
Какой?
А можно как-то дождаться выполнения update() или _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, странный какой-то механизм, тяжело представить себе его работу.
У меня такая система получилась:
- в сцене есть второй вьюпорт
- в нём камера и 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, странный какой-то механизм, тяжело представить себе его работу.
UE5
Ладно, я уже сам разобрался.
>ВНЕЗАПНО происходит две отрисовки текстуры подряд
Это я сам виноват. У меня отрисовка текстуры происходит по проверке одной переменной, значение которой менялось после 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/getting_started/scripting/gdscript/gdscript_basics.html#coroutines-with-yield
Calling yield() will immediately return from the current function, with the current frozen state of the same function as the return value
Ну да, я читал этот фрагмент, но не так понял.
Я вспомнил, что меня запутало:
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
?
= Vector2(0, 0)
или
.x = 0
.y = 0
?
Таблетки
Нет ты.
Очевидно через абстрактную фабрику обнуления векторов.
а если на фабрике забастовка? как занулять?
Годогвардейцев пошли, пусть отпиздит шатателей киберлодки.
Двач, а как компьютер выводит цвет на экран? Ну вот, допустим, пилю я веб страницу и в css указываю три байта rgb цвета. Как выстроена цепочка событий внутри компьютера, чтобы отобразить указаный мной цвет?
Какой то вопрос уровня собеседования в гугол. В деталях не знаю, сначала браузер собирает все в слои, css от слова каскадные, т.е. цвет берется от предка к наследнику, наворачиваются всякие полутени, прозрачности, потом это все отправляется в либу (в хроме это skia) которая, вроде бы, по строчкам все сканирует и собирает команду paint, эта команда улетает в gpu сервер в песочнице, дальше преобразуется в opengl команду, думаю тут собирается в текстуры разбитые по атласам (чтобы весь экран не перерисовывать когда у тебя только один элемент поменялся), тут опционально если бекэнд ANGLE то конвертируется в команду для vulkan, ну и собственно отправляется в драйвер (тут где-то участвует композитинг операционки, опять же для всяких прозрачных окошек, плюс цветокоррекция, ночные зеленые темы, яркость контрастность в панели нвидия, вот это все), не знаю, участвуют ли тут шейдеры, но шейдеры это просто по сути обработать параллельными ядрами видяхи все вершины и все пиксели текстуры по заданным алгоритмам. Физику мониторов вообще не знаю, это какой то бутерброд из нескольких слоев, где-то там куча почти прозрачных транзисторов, которым выборочно по строкам/столбцам включают прозрачность током, и в которые с торцов светят из трубочных ламп.
> Как лучше обнулять вектора:
1. Выбираешь несколько способов, предложенных выше.
2. Оборачиваешь каждый способ в функцию.
3. Запускаешь каждую функцию в цикле 999999 раз, подсчитывая время выполнения.
4. Выбираешь ту, которая выполнялась быстрее всего.
https://github.com/Shfty/qodot-plugin
Ну и кто вы после этого?
Ну и кто вы после этого?
Прости анончик-рокетджамповый-попрыгунчик. Было 10 тредов назад. Никого не заинтересовало (меня тоже). Добавить в шапку?
А что? Это же тупиковый путь. "импортить .map кваки, чтобы не учить блендер". Бе.
Scatter https://github.com/HungryProton/scatter/
- мощная штука. Вообще-то она для рассадки травы и деревьев, но заборчик в примерах натолкнул меня на мысль, и действительно, оказалось, что оно отлично подходит для рисования дорог из куска прямоугольника.
Для этого я добавил модификатор Along the path (even) с галочкой Align to Path, модификатор Project on Floor с галочкой Align with floor normal.
Точки ставятся Ctrl+ЛКМ, двигаются ЛКМ, удаляются ПКМ, хэндлы для кривых двигаются Shift+ЛКМ
- мощная штука. Вообще-то она для рассадки травы и деревьев, но заборчик в примерах натолкнул меня на мысль, и действительно, оказалось, что оно отлично подходит для рисования дорог из куска прямоугольника.
Для этого я добавил модификатор Along the path (even) с галочкой Align to Path, модификатор Project on Floor с галочкой Align with floor normal.
Точки ставятся Ctrl+ЛКМ, двигаются ЛКМ, удаляются ПКМ, хэндлы для кривых двигаются Shift+ЛКМ
А в годоте есть 2.5д тайлы? Типо как обычные, но которые могут разделяться на слои и перекрывать друг-друга. Если есть, то поставлю годот, gameMaker залупа гойская.
Вопрос - я тайлмапу могу натянуть на PlaneMesh, чтобы использовать в качестве террейна?
Есть
Есть 3д тайлмапа.
Я знаю про гридмапу, мне плоское нужно.
Есть 2.5 демка, https://godotengine.org/asset-library/asset/583
Также есть видос как работают искоробочные изометрические тайлы
https://www.youtube.com/watch?v=SteMRdOYrds
Сразу скажу что от встроенного редактора тайлов в годоте жопа горит у многих, так что возможно ты захочешь что-то типа Tiled + импортер https://godotengine.org/asset-library/asset/158
Если визуал то можно через вьюпорт сделать
Но ты же наверное коллизии потом захочешь, но для этого можно невидимый гридмап использовать наверное.
Вообще в таких случаях за пару часов можно написать конвертор, который берет графон и коллижны с тайлмапа и генерит по ним гридмапу
> Вообще в таких случаях за пару часов можно написать конвертор, который берет графон и коллижны с тайлмапа и генерит по ним гридмапу
А есть готовые расширения?
Вряд ли.
Ну там правда все несложно - просто пройтись по одному массиву и скопировать в другой массив.
https://www.youtube.com/watch?v=yWfttGYyeSU
С коллижнами чуть посложнее, но там надо просто сделать новый 3д объект, например через CSGPolygon которому задать нужную высоту (через depth) и точки скопировать с 2д полигона тайла. Буду посвободней, могу скинуть код.
Не надо, я гипотетически спрашивал. В принципе, наверное, даже коллижнов не надо, раз все плоское будет, я их могу отдельно поверху нарисовать.
> от встроенного редактора тайлов в годоте жопа горит у многих
Горела во времена 3.0. Нынче он стал поюзабельней. И главное - сторонние редакторы, увы, не обеспечат никогда полной поддержки фич.
Конечно, поддержку фич можно обеспечить скриптом импорта-экспорта.
Ну ка покажи мне, как в стороннем редакторе создаются настроенные и функциональные автотайлы. С коллизиями и окклюзиями где надо.
Я как-то показывал LDtk от автора Dead Cells. Но в нем нет изометрии.
Автотайлы там крышесносные. Посмотри тут с 15 минуты.
https://youtu.be/ck8ohhC0XdM?t=902
Да и в Tiled вроде автотайлы были.
Коллизии мне не понравилось рисовать в годоте полигонами. Мне нужен более точный контроль, так что я генерил их из скрипта сам все равно. Я 2д играми не занимаюсь, но если бы делал, то все равно рисовал бы отдельный слой в ldtk под коллизии. Мне все равно не хватает когда коллайдеры привязаны к визуалу. Бывает нужен визуал без коллайдеров (например когда анимация постройки здания), бывает коллайдер без визуала (когда что-то стало прозрачным или потолки скрыты)
Есть примеры на годоте хорошие имитаций древних софтварных псевдо и ранних 3д рендеров, без фильтрации текстур, с пиксельными тенями и прочим?
Не знаю. Не интересуюсь древностью, не испытываю ностальгии. С удовольствием играю в ремастеры денди-игор, без уёбищных пикселов. Ненавижу уёбищное лоуполи плойка-стайл. Извини, не могу тебе помочь.
Тем временем близится время, то самое время, время перекатывать штрендовс. Давайте припомним, кто что хотел в шапочку вшить?
Нахуй ты отвечаешь тогда, говна кусок? Всем глубоко насрать, что ты там не испытываешь и во что ты там с удовольствием не интересуешься, человек конкретный вопрос задал, если тебе нечего по теме ответить - молчи в тряпочку.
> Нахуй ты отвечаешь тогда, говна кусок?
Чтоб добить до бамплимита, очевидно же!
ПЕРЕКАТ
Он тебе ответил, чтобы ты не чувствовал себя одиноко.
Тоже, кстати, да. А он ругаться сразу. Злые анончики.
Краткий гайд по вкату в движок:
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
Предыдущий:
Архивный: https://arhivach.net/thread/664976/