Шапка: https://hipolink.me/godothread
Предыдущий 83: >>1104969 (OP)
---
Все статьи, читать: https://godotengine.org/blog/
Все версии, скачать: https://github.com/godotengine/godot-builds/releases
Я тут читаю учебник по Zig (в прошлом треде анон заинтересовал) и знаете что? Это же системный вариант гдскрипта! Тот самый, о котором мы мечтали не менее 40 тредов - вот же он!
Вы только поглядите на синтаксис. Мы же именно эти изменения.
Ну не знаю, кто куда, а я на зиг перекатываюсь. Вода замёрзла. Перебьёмся. Остаёмся.
Да, там автор написал какую-то построчную компиляцию, в итоге получается кодгенерить налету. В общем, системный язык но ведет себя как интерпретация динамикоязыков.
У этого есть минусы (и плюсы, конечно). Но в любом случае надо писать тесты на любых языках.
Надо еще понимать что это не язык для попила хайпа. И что это все еще односторонний интероп над сями.
Тот же пакетный менеджер ньюфагов точно отпугнет. Или ручная инъекция памяти/io. Да и не всем хочется обрабатывать out of memory при каждом добавление в динамический список.
В общем, если держать в голове что это "новый" си, то системный бойлерплейт терпим. Но тем кто кроме гдскрипта ничего не нюхал - будет сложно.
Еще им, вроде, удалось сделать асинхронный код без покраса. Но я еще не вникал, но звучит круто.
Zig очень хорош как язык, даже есть биндинги godot-zig, перекатывайся, я там был пару лет назад.
Вот это уже интересно. Изучаю дальше.
>>1108528
> кроме гдскрипта ничего не нюхал
Я нюхал от Паскаля с бейсиком до си, джавы, шарпа, питона, раста. Мне норм.
>>1108535
Мне нравится такой подход: на системном языке следует писать ядро игровой логики, со всеми менеджерами, фабриками, моделями, контроллерами. А на гдскрипте нужно писать логику подключения к этому ядру и настройки параметров.
В качестве системного я сначала рассматривал шарп, но оказалось, что он тащи за собой дотнет и нет простого способа сделать нативный билд. Потом я попробовал присмотреться к расту, но там меня разочаровала абстракция владения, которая должна была дать людям абсолютно непотопляемый код, надёжный как швейцарские часы, но люди не поняли и кодят на ансейфе. Кроме того ref<ref<ref<ref>>> окончательно добило интерес.
И тут такая Зига нарисовалась! Все нравится. Дошел до аллокаторов. Нравятся. Выглядят логично, понятно.
>Вот это уже интересно. Изучаю дальше.
Только учти что переписали они i/0 в каком-то последнем патче. Книги будут отставать.
>Вы только поглядите на синтаксис. Мы же именно эти изменения.
Какие "эти"?.. Загуглил хэлло ворлд, вы только посмотрите на это:
>const std = @import("std");
>pub fn main() void {
>_ std.log.info("Hello, World!", .{});
>}
Это же просто... просто... буээээ... простите... Это же C без ++!
Зачем все эти извращения? Чтобы что? Быть "не таким как все"?
Просто берите то, что удобнее - т.е. GDScript.
А для кранча больших циферок берите C/C++.
Что тут ещё можно выбирать 40+ тредов?
Алсо, завязывайте со скриптосрачем.
Это сорта прокрастинации у них. Ищут причины чтобы нихуя не делать, как всегда. Дай им супер-производительный годот-зиг-хуиг прямо в мейнлайне движка - найдут другую причину хуи пинать.
А реальность, напомню, на пике. И доля гдскрипта выросла относительно 2025 года.
Придётся более серьёзно изучить разные защиты проекта.
Забавно, но график больше показывает сколько вкатунцов любителей, залетевшие на хайпе и реальный разработчиков.
На гдскрипте не практично писать либы и любые системы/сервисы/менеджеры итд. Ну мы же не тетрисы делаем.
Ты думаешь, все прокрастинируют как ты, раз пишут в тред. Но ты не думал что реальность другая?
Ты еще не видел новый хелловорд с новым i/o.
И все равно это приятнее чем сишный макросный ад.
Получается, что автор столкнулся с прагматичной реальностью и отступил от своего принципа, чтобы не было "скрытой" логики, выполняющейся под капотом. Ну и ладно, так хотя бы реальные программы станет можно писать. Может, и ООП когда-то решится добавить.
>>1108633
У C/C++ есть некоторые родовые травмы именно в синтаксисе. Такие штуки как не всегда однозначный парсинг https://en.wikipedia.org/wiki/Most_vexing_parse который приводит к ошибкам программиста, или к долгой компиляции. Не просто так многие современные языки делают вот этот синтаксис где до объявления пишешь ключевое слово func, а после объявления и спец символа -> возвращаемый тип.
>Еще им, вроде, удалось сделать асинхронный код без покраса.
Насколько я понял, как раз не удалось, там был какой-то неявный автовывод компилятором, который был слишком запутанным, и переписывание IO как раз привело к отказу от этого.
>Получается, что автор столкнулся с прагматичной реальностью и отступил от своего принципа, чтобы не было "скрытой" логики, выполняющейся под капотом.
Речь и проблему скрытой/неявной аллокации и ошибок. Любой метод это абстракция.
Например можно написать базу с гарантированной работой (чел, который пропагандировал раньше раст и написал LSP для раста)
https://www.youtube.com/watch?v=NAOOGB1q6uQ
>Может, и ООП когда-то решится добавить.
ООП в системной разработки зло
Лезть в зиг или плюсы нужно только если ты собираешься свой движок собирать. Годотеру шарпов за глаза. Ты выиграешь 5-10% но будешь сидеть и побеждать системный язык. А если у тебя скрипт из чистых API лучше написать на гдскрипте.
>не всегда однозначный парсинг
Вообще не понимаю, нахрена в C-подобных языках указывается тип переменой и тип возврата функции задолго до самой переменной/функции? Мне вот на практике сначала известно имя того, что я планирую описать, а уже потом я думаю над тем, какой именно использовать тип/класс для хранения/возврата. Эта необходимость сначала указать некий тип для того несуществующего чего-то, что ещё не придумано, выбивает меня из потока. Как люди справляются с подобным неудобством в большинстве языков?
>современные языки
C - 1972, Pascal - 1970, ALGOL - 1960, Fortran - 1957. Современные языки просто вернулись к БАЗЕ, поняв косячность бредовой C-подобной фигни. Ещё бы все бесполезные скобки выкинули и писали нормально, литературным текстом, без лишних спецсимволов (машинный код, а не промпт галлюционирующему генератору псевдослучайных токенов в тексте).
В C# нет этих проблем. Это просто тупость автора языка, вроде указания переменных на стеке (Foo foo(10); ), которая создает эти проблемы.
> и писали нормально, литературным текстом
БЫТИЕ ОПРЕДЕЛЯЕТ СОЗНАНИЕ
Это написано литературным текстом. Теперь давай, распарсь, кто здесь кого определяет?
В C# всё то же самое - сначала тип, потом имя.
>>1108818
У тебя некорректный пример.
Вот более корректные сравнения:
ВАСЯ ЯВЛЯЕТСЯ ГЕЙМДЕВЫЧЕМ
МАША ЯВЛЯЕТСЯ ШКОЛЬНИЦЕЙ
ШКОЛА ИМЕЕТ МНОГО ШКОЛОТЫ
ФАЛЬКО ПРОИЗВОДИТ СЛОПЧИК
РОКСТАР ПРОИЗВОДИТ ГТАШКИ
Сравни это с:
ОТ ГЕЙМДЕВЫЧА ПРОИСХОДИТ ВАСЯ
ОТ ШКОЛЬНИЦА ПРОИСХОДИТ МАША
ШКОЛОТА МНОГО ИМЕЕТСЯ В ШКОЛА
СЛОПЧИК ПРОИЗВОДИТСЯ ФАЛЬКО
ГТАШКИ ПРОИЗВОДИТСЯ РОКСТАР
Вот вроде понятно, а звучит неудобно - запутывает.
В C# нет проблем с парсингом из-за этого, только вкусовщина (мне нравится)
>C-подобных языках указывается тип переменой и тип возврата функции задолго до самой переменной/функции?
Потому что матерые программисты в коде "думают типами", а ньюфаги думают "названиями переменных", а уже потом им редактор подсказывает тип - то есть, ньюфаги вообще не контролируют ситуацию.
Тоже самое с функциями, ты сначала думаешь какой результат получить, а уже потом что закинуть в коробку.
У тебя синдром утёнка, выучил паскаль в детстве и сидишь скобочек пугаешься.
Люди пытались сделать из языка программирования - естественный язык, но всегда получалась какая-то жопа.
Почему передвинули тип? Да потому что парсер удобнее писать, не от хорошей жизни, средний специалист тупеет, забытые технологии древних
Ты думаешь эти люди смогут написать ядро шарпов?
https://2ch.su/pr/res/3735926.html#3736033
>"думают типами", а ньюфаги думают "названиями переменных"
Тип данных может поменяться вместе с задачей, а название переменной меняется не так часто. Скажем, у тебя есть счётчик денег, который ты создал сначала как float, обосрался от ошибок с округлением и резко переделал на int, но потом узнал, что в твоём языке поддерживаются числа с фиксированной точкой, и снова переделал. То есть тип поменялся два раза, а название переменной осталось без изменений. Или ты сначала сделал индексы в форме строковых констант, обосрался от того, как долго происходит сравнение, переписал на int, потом подумал-подумал и переписал на enum, а потом обнаружил StringName и снова переписал на строки, но теперь без замедления. Опять - имя не поменялось, а тип поменялся 2-3 раза. Потому что задача строится как "что нам нужно", а не "через что это имплементировать" - нам нужны "деньги" или "индексы", а через какие типы данных эти вещи будут реализовываться - дело десятое. Ты не можешь контраргументировать в стиле "олдфаг не будет ошибаться" - во-первых, это лишь означает, что он подорвался на этом в прошлом, во-вторых, не допускает ошибок только тот, кто ничего не делает. Лучше пусть точная машина следит за ошибками, чем человек грузит своё wetware лишними самопроверками.
>сначала думаешь какой результат получить, а уже потом что закинуть в коробку
Сначала ты думаешь "что требуется сделать" - это глагол-название действия, который звучит наподобие "переварить"; потом ты думаешь "с чем это требуется сделать" - это объекты, над которыми действие производится, типа "еда", потом ты выбираешь тип этих объектов - "еда" (в данном случае совпадает, но может быть нам нужен только "фастфуд" или "здоровая пища"?), а только потом определяешь, что твоё действие в оставит после себя - "говно", или "обёртку", или "ничего", если у тебя 100% КПД пищеварения, способное переварить всё, включая обёртку. Было бы странно начинать описание своего действия с того, что тебе "нужен производитель говна", или "нужен производитель пустых обёрток", или "ничего не нужно, просто пустота", и только потом давать имя этому действию. Нет, соглашусь, что иногда тебе и правда необходим абстрактный "производитель говна", а не действие с объектами, но это специфичный случай.
>>1108831
>скобочек пугаешься
Они выглядят некрасиво и их труднее отличить от других видов скобок со слабым зрением и высоким PPI. На моём текущем мониторе я даже в очках пимпочки на "{}" не вижу, они выглядят как нечто среднее между "[]" и "()", поэтому с первого взгляда даже не понять, что там на самом деле. А "begin end" или отступы от края экрана видно сразу, даже без очков, даже при мелком шрифте с высоким PPI...
>Люди пытались сделать естественный язык, но всегда получалась какая-то жопа
Не знаю, о какой "жопе" ты говоришь, но подумай сам, что лучше:
>for Child in GetChildren do Child.Work; // Pascal
>for child in get_children(): child.work() # GDScript
>foreach (Node child in GetChildren()) { child.Work(); } // C#
>for (Node child: getChildren()) { child->work() } // C++
И т.д. Абсолютное превосходство Pascal очевидно - тебе не нужны ни "{}", ни "()", ни даже ":", и весь твой код читается как проза: "для каждого ребёнка из полученного списка детей приказать ребёнку сделать работу". Твой взгляд не "спотыкается" об избыточные спецсимволы и указатели типов. Просто и изящно.
>потому что парсер удобнее писать
Тогда почему не FORTH? Минимальная FORTH-машина умещается в 340 байт и это полноценный язык, способный с легкостью конкурировать с C/C++ по производительности и работать на любом железе без операционной системы. Его можно даже в древние чипы BIOS засунуть, целиком... ещё когда в них не запихивали аж десятки мегабайт под обновления. А если писать ОС, то FORTH-машина умещается в загрузочный сектор дискеты (512 байт) - и это всё, что тебе нужно, дальше только читать код ОС.
>Ты думаешь эти люди смогут написать ядро шарпов?
Пффф, обыкновенные "носочки программиста". Ты что, не надеваешь такие, когда код пишешь? А вдруг простудишься? У программиста комп мощный, сосёт как пылесос - и ветер прям по ногам дует. Тут без носочков не попрограммируешь никак. В полосочку или однотонные - это уже дело вкуса, не придирайся. Борода и длинные волосы - это тоже для теплоизоляции и терморегуляции головы. А в юбке мошонка не сдавливается и не перегревается... Не понимаю, почему у нас какие-то предрассудки против юбок - вот по какой такой причине бабам с пустой промежностью можно юбку, а мужики вынуждены сдавливать себе всё самое нежное и чувствительное, что природа специально вынесла наружу для охлаждения? У тебя никогда яичко не перекручивалось из-за того, что ногой в грубых штанах неудачно двинул? Это супер-больно. А в одних трусах не попрограммируешь по той же причине, по которой нельзя программировать без носков. Нормальные, здоровые, счастливые программисты в своей классической рабочей одежде.
И вот такие зашоренные шовинисты критикуют GDScript? То им отступы мешают, то носочки...
>Тип данных может поменяться вместе с задачей
Ну если ты ньюфажа ты буквально перебираешь возможности языка. А если ты PRO то ты обычно думаешь сигнатурами методов.
Пик, база баз, ты не должен знать кишки. Тебе нужна только сигнатура.
Единственное это когда вообще не знаешь что делать и делаешь "налету" (прототипируешь). И тогда тебе правда нужны только действие и именно поэтому js идеально подходит для быстрого прототипирования (помню школота даже не поняла о чем я говорил, опять трансформатор жужжит).
>Они выглядят некрасиво и их труднее отличить
Тебе не нужно их отличать, они нужны для форматирования - одна кнопка и все отступы раставлены.
В общем, синдром утёнка - развивайся.
>Не знаю, о какой "жопе" ты говоришь,
Смотри COBOL и прочую чепуху 1960-2000х (а может раньше)
Все что выжило - это продукт проб и ошибок - лучшее из худших.
>И вот такие зашоренные шовинисты критикуют GDScript? То им отступы мешают, то носочки...
Ни разу не говорил про синтаксис, я за всю жизнь на чем только не писал. В срачнике я даже сказал что синтаксис неплох, плоха техническая реализация - сдвиг миллионного массива в 45 раз дешевле чем оптимизированный свап-алгоритм на гдскрипте - это безумие (ты видел цифры на шарпе, какая должна быть разница). И самое страшное им насрать
За жизнь у вас будет только 1-2 языка в которых вы сможете сверх-шустро ориентироваться и комфортно писать. Поэтому стоит определиться.
При этом в инфраструктуре языка есть все нужные оптимизации, даже unsafe на арифметике указателей.
PS Кто не понял
>пик1
Проход по массиву без проверки выхода за границу на каждой итерации.
Но только надо проверять, потому что JIT делает больше чем вы думаете.
> У тебя некорректный пример.
Для иллюстрации неоднозначности натурального языка - вполне корректный. А у тебя наоборот иллюстрация корректных фраз.
> X ЯВЛЯЕТСЯ Y
Где "является" - это усовремененная форма словосочетания "являет ся", "являет себя", след древних словесных форм, существовавших в старорусском. И в этом смысле любое -ся определяет предыдущего. Вася являет себя как геймдевыч, но не геймдевыч являет себя как Вася.
Далее ты добавляешь еще больше частиц, всё дальше уходя от сути.
А суть в том, что если бытие определяет ся, то бытие первично, иначе сознание определяет ся. Эта фраза уже легко переводится на логичные языки программирования.
Но учтите, что если вы возьмете тройку и моно под веб/ios - моно интерпретатор будет убивать вашу игру на постоянной основе из-за вагона багов внутри самого моно, надо брать только четверку и фиксироваться на конкретных платформах, либо принять волевое решение и переехать на C++ godot 4, отличная работа в вебе, санитайзеры закроют проблемы по памяти, кодогенерация позволяет не писать руками тело bind_methods или описывать геттеры сеттеры а так же - ей же закрывается вопрос о рефлексии (clangast+своя реализация appdomain с хранилищем типов как в c#/il2cpp), std 20 модули для избавления от инклудов и шарпофикации импорта зависимостей, но - нужна нормальная тачка под компиляцию и сила воли это схавать
Не надо брать тройку, у него сломанный шедоумап и вагон багов с более низкой относительно четверки производительностью
>у него сломанный шедоумап
В чем это проявляется?
>вагон багов
Там наистабильнейшая 3.6.3 maintenance. Супротив 4-ки в которой еще не все даже существовавшее допортировали (хотя, конечно, добавили много новых фич)
>более низкой производительностью
Бенчмарки покаж. У меня другой опыт. Что на твг с десктопной на вулкане, что в вебе.
>В чем это проявляется?
В дырявых тенях на лоуполи геометрии у динамических обьедков, впринципе реализация directional освещения дерьмовая в тройке, в четверке щас нормально все и с тенями и с перфомансом
>Там наистабильнейшая 3.6.3 maintenance
Не на многопотоке, в отличие от четверки, где потоки в вебе могут сильно зарешать по перфомансу, в тройке апи многопоточное только в справке, а по факту - любые freeable операции делай только в главном иначе движок крякнет
>Бенчмарки покаж. У меня другой опыт. Что на твг с десктопной на вулкане, что в вебе.
Тогда придется игру показывать, а мне сильно неохота. Работаю щас с 4.7.2, буст по перфомансу куда заметнее против тройки, хошь верь хошь нет, но у меня основа глес, вулкан я не трогал так как веб целевая платформа
>еще не все даже существовавшее допортировали (хотя, конечно, добавили много новых фич)
А каких тебе фичей из тройки не хватает собственно? Просто интересно, не увидел ни одной такой которой в 4 не было бы против тройки.
Пойду потестирую потом, может что-то в новых версиях подкрутили. Но думаю размер билда все равно будет расти. На многопоток в вебе мне пофиг, там все равно дно устройства, максимум загрузку в фоне какую-то делаю.
Дыры в динамических объектах - ну хз опять же нишево. Проверь может у тебя баг при их создании какой-то, там легко напутать со всеми этими поверхностями, индексами. Может просто вывернулась нормаль наизнанку.
Не помню, периодически натыкаюсь на вопрос, собираюсь ответить что для этого же есть встроенный метод - а его не довезли. Да дело не в этом, многое заново переписали, поэтому нет доверия что там уже баги вылизали.
Ну размер билда да, немаленький, только васм плюсовый пакетик игровой логики у меня в оптимизированном состоянии весит почти 9мб, да плюс рантайм движка, где мне нечего резать, так что 15-20мб как минимум точно нарисуется. Но мне вес важен мало, игра может себе позволить забить хуй на вес клиента в разумных пределах, так как я сильно выделяюсь на фоне прочих браузерок
>На многопоток в вебе мне пофиг, там все равно дно устройства
Как раз на донных устройствах и надо выскребать всё из ядер, все что есть. Щас какой говнопроц не возьми - везде есть 4 ядра как минимум, надо поглощать.
>Дыры в динамических объектах - ну хз опять же нишево. Проверь может у тебя баг при их создании какой-то, там легко напутать со всеми этими поверхностями, индексами. Может просто вывернулась нормаль наизнанку
Ну может быть, но помимо этого еще и тени стали гораздо лучше в 4 сами по себе, практически без урона по производительности.
>>умный дядя еще не понял что они не хотят ничего писать
Не ну кто-то хочет, но под призмой максимализма лезет в плюсы или си (который по сути почти ассемблер).
Из-за веба лезть в плюсы - великолепный план.
Так по факту. Хочешь выбить предельную производительность? Добро пожаловать в клуб gdextension-данжен мастеров.
Если под вебом подразумевают свой сайт (не я.игры), то я бы вообще не брал ни один движок.
Есть подозрение что там колоссальное число оберток (на любом движке).
>И самое страшное им насрать
А почему должно быть не насрать?
Мы говорим в контексте выбора альтернативы гдскрипту
-если есть потребность написать сложные алгоритмы/системы,
-или если ты не хочешь за базовые операции платить микросекундами (вместо наносекунд, то есть в 1000-10.000 раз больше)
-и если ты раньше не писал на плюсах (лаба1.cpp не считается).
Вопрос в том куда ты хочешь инвестировать свое временя. Не все понимают реальную сложность С++. А если ты не хочешь учиться и вообще вайбкодя, то просто уйди в свои нейронки и загон /ai, не ровняйся с теми кто хочет учиться, твое мнение не важно в рамках инвестиции времени и сил
>А почему должно быть не насрать?
Ну тут вопрос что ты выберешь - практичность или удобство? Возможно ты как и я выберешь практичность выше удобства, поэтому тебе и мне было бы не насрать. Но если ты выбираешь удобство в ущерб практичности, у тебя даже цели не будет что-то изменить.
Вся надежда что годот обрастет сообществом и те продавят "практичность" (я кидал ссылки, такие потуги уже есть, люди пытаются, людям это важно. ).
>>1108390 →
>>1108391 →
Я бы не отказался от GDLang поставляющегося с отдельным компилятором и компилирующиегося в консольные утилиты, а к нему отдельно подключается редактор Godot и использует GDLang наравне с GDScript.
Я бы хотел, чтобы отличия от скрипта были минимальны, только в заголовочной части было бы import Godot. И был бы компилируемый язык с охуенным годотовым синтаксисом, который я обожаю. После гдскрипта питон кажется омерзительной поебенью. Всё что я вижу в нём похожего это только блоки отступами, в остальном ничего похожего. И при этом питон всё равно не компилируемый.
Самый ближайший к небесному годоязыку из существующих - это пока что Zig, посмотрите на пикчу от нашего железного друга. Это же буквально то, о чём мы мечтали долгими зимними ночами.
Тру стори. У меня в пайплайне даже используется несколько раз в год. Скрипт, который меняет иконку игры в релиз темплейте.
>Godot --no-window -s scripts/HelloCli.gd
Несколько лет знаю об этой фиче, но как-то не нашёл применения для неё. Если мне нужно что-то "автоматизировать", я либо .bat-скрипт напишу, либо AutoIt3-скрипт... Я могу понять, почему Python и похожие на него языки имеют "интерактивный режим" в консольке - ведь это "языки математиков", а математикам часто нужно какие-то матановские формулы считать, вот они этим и занимаются. А нам зачем? У нас матана никакого нет, то есть есть, но он такой, что в эксель-табличке проще посчитать, чем писать какой-то мудрёный скрипт...
>>1109054
>меняет иконку игры в релиз темплейте
Разве Godot не меняет иконку сам? Для Godot 3 нужно rcedit.exe скачать, а в Godot 4 вроде из коробки работает.
>>1109066
>генератор материалов по палитре
По-моему, это самый плохой подход к материалам. Ты должен делать наоборот: уменьшать число материалов, соединяя текстуры в атласы и/или используя текстуру-палитру с UV координатами, или какие-то ухищрения с Vertex Color делать. Как минимум если таргетишь OpenGL/мобилки; с Vulkan/DX вроде это уже не так важно. Также лучше использовать "instance uniforms" вместо создания отдельной копии материала для модификации каких-то параметров шейдера - это будет эффективнее, но, вроде, поддерживается только в Forward+.
А rcedit глючный. Дак в этом и фишка, зачем лишняя прога, когда есть скрипт на гдскрипте.
>Вася являет себя как геймдевыч, но не геймдевыч являет себя как Вася.
Правильно. Поэтому в нормальных языках ты пишешь так:
>class Vasya extends Gamedevich:
>_ func eat_and_shit(what: Food) -> Shit: ...
А в дебильных языках, описывающих всё через жопу - так:
>Gamedevich class public protected unsafe private anus-derned rejected heart-breaked Vasya {
>Shit public unsafe private anus-produced prolapsed method eat_and_shit(Food: what_the_fuck) { ... } }
По-моему, очевидно, что "литературный" подход для восприятия человеком лучше вывернутого наизнанку.
А уж что там приходится создателям компилятора/интерпретатора делать, чтоб это всё развернуть - нас не касается.
>>1108878
>синдром утёнка
>>1108880
>За жизнь у вас будет только 1-2 языка
Всё так: ты выучил этот C# и больше ничего не понимаешь, потому что тебя научили такому >>1108881 безобразию.
>>1108985
>что ты выберешь - практичность или удобство?
Значения русских слов забыл? http://ru.wiktionary.org/wiki/практичный
>выгодный, удобный по каким-либо своим свойствам, хорошо подходящий для решения каких-либо задач ценой сравнительно небольших затрат
То есть GDScript практичен, потому что удобен, а удобен потому, что позволяет решать многие задачи ценой сравнительно небольших затрат. А C# непрактичен, потому что заставляет перепрыгнуть через кучу различных совершенно не нужных ограничений ради абстрактной "скорости", которую и в GDScript тоже можно в перспективе завести, если поднапрячься (и вроде бы уже есть транспиляторы GDScript -> C/C++, так что можно не напрягаться), но в большинстве ситуаций современный компьютер решает задачи мгновенно даже на GDScript. Единственная ситуация, требующая более быстрый язык - это когда тебе позарез нужно тысячи единиц чего-то каждый кадр обрабатывать, но подобное в видеоиграх встречается относительно редко и чаще всего - уже полностью решено в ядре движка.
>нет доверия что там уже баги вылизали
Godot 4 начали делать более 4 лет назад, и уже более 3 лет он считается stable - на нём куча проектов и в разработке, и в релизе, в том числе в Steam. Если какие-то баги и остались, то это что-то очень специфическое, а значит, не критичное. У тебя какая-то фобия увеличения мажорной версии? На юнити и многих других закрытых движках владельцы движка крутят мажорную версию как и когда захотят, а с Godot ты даже сам можешь посмотреть исходники и решить для себя, много там критичных для тебя багов или нет...
>>1108925
>Супротив 4-ки в которой еще не все даже существовавшее допортировали
То, что есть в 3, но "не портировали" в 4, портировать уже не будут, потому что это не считается нужным для проектов на 4-ке. Лично мне вспоминается, что под конец 3-ки подвезли метод/ноду для "склеивания мешей", которая помогает решить вопрос с избыточным количеством дроуколлов в OpenGL. Но Godot 4 рассчитан на Vulkan/DX и дроуколлы экономит автоматически, поэтому возиться со склейкой мешей не нужно, если ты не пытаешься делать в режиме Compatibility. Но даже если тебе всё-таки нужна эта склейка мешей на 4-ке, ты можешь её легко реализовать даже на GDScript, потому что это тривиальная задача. В 3-ку эту фичу запилили только ради школоло-художников, которые не способны по массиву пройтись своими руками... А вообще, есть же Blender...
...вот эта нода: https://docs.godotengine.org/en/3.6/classes/class_mergegroup.html
Если есть что-то ещё, то мотивация там та же самая - в Forward+ не нужно, а Compatibility никто не обещал держать на уровне тройки.
>Это же буквально то, о чём мы мечтали долгими зимними ночами.
Ехал pub через pub, сунул pub свой var в fn, а там const .{.ц=ап} pub за var...
>>1109008
>Odin
Скочал, а потом посмотрел как оно в Godot вкручивается и думаю удолить.
> Поэтому в нормальных языках ты пишешь так:
Шаришь, бро! Вот за это гдскрипт и любим.
>>1109079
> Ехал pub через pub, сунул pub свой var в fn, а там const .{.ц=ап} pub за var...
Ну хотя бы паб разреши?
>>1109075
> >class Vasya extends Gamedevich:
> >_ pub func eat_and_shit(what: Food) -> Shit: ...
А хотя, я уже после того как пост отправил, нашёл гдскрипт-вэй решение. Все "паб" - это интерфейс, в его классическом смысле, а не в том, которым нагадили в современных языках. То есть, нам в листинге скрипта вообще не нужно никакие приставки методам прикручивать, все они по умолчанию должны быть приватными. А вот чтобы вынести то или иное наружу, его нужно объявить в интерфейсе (в заголовке). Примерно так:
> class Vasya extends Gamedevich:
> public:
> _ func eat_and_shit(what: Food) -> Shit
> _ var foo : String : get # объявили get-only свойство
>
> func eat_and_shit(what: Food) -> Shit:
> _ pass
>
> var foo : String = "" :
> _ get: pass
> _ set(v): pass
Несложно заметить, что выписанные в паблик определения полностью дублируют их определения в реализации ниже, поэтому будет логично вписывать публичные члены в интерфейсе/паблике/заголовке, затем дважды щелкать и редактор будет создавать копию внизу. Самая макотка такого подхода проявила бы себя в определении пропертей, в паблик засовываем только гет, а внутри прописываем и сет тоже.
>Ну хотя бы паб разреши?
На чужой лобок (pubis) не разливай фондюк (fondue).
>>1109083
Опять ты какой-то велосипед с квадратными колёсами изобретаешь...
Начнём с вопроса: зачем нужны эти public/private теги? Чтобы компилятор/IDE могла бы как-то сообщить другому программисту или нам-из-будущего, что вот эту вот фичу дёргать можно, а вот эту фичу дёргать нельзя/лучше не стоит. Ключевое слово - сообщить, так как запретить мы ему ничего не можем: желающий может просто залезть в исходники и переделать любой private в public, если ему это очень надо. Это просто такая условность, как запись зАбОрЧиКоМ или з_м_е_й_к_о_й, она нужна только для визуального ориентирования программиста на местности.
Далее, что нам важнее - public или private? Если мы пишем какой-то код, мы хотим его откуда-то вызывать, не так ли? Потому что невызываемый код нам нафиг не нужен. И даже если нам нужна только 1 точка доступа, мы можем захотеть получить доступ к чему-то кроме этого, например, в качестве теста или временного костыля-заплатки (впрочем, нет ничего более постоянного, чем временное). Поэтому очевидно, что начинать нужно с public, а как-то помечать только private.
Значит, нужен какой-то визуальный маркер для private, а public подразумевается по умолчанию. Почему бы... не начинать название со знака подчёркивания? Вот у нас есть eat(), который мы вызываем снаружи, а может быть _puke(), который вызывается изнутри автоматически, если нас накормили слишком сильно. Видишь, как просто? Всего один символ - и мы уже с первого же взгляда видим, что этот метод должен вызываться только изнутри класса - это его кишки.
Теперь мы можем настроить IDE так, чтобы она не выводила в качестве подсказки после "." поля, начинающиеся с "_", или загоняла их куда-нибудь подальше в конец списка. Помним о том, что мы не можем никому ЗАПРЕТИТЬ обращение, т.к. всегда можно поменять исходный код, и также помним, что иногда мы всё-таки хотим залезть в чьи-то кишки снаружи. Поэтому если кто-то и написал что-то вроде "person._puke()" - пускай оно выполняется, не проблема. Но главное - мы сразу видим, что этот код - костыль/заплатка, т.к. обращается к чужим кишкам - "_" в имени, и поэтому в будущем этот код нужно будет как-то переделать (отрефакторить программу).
И ты можешь не верить, но в Godot/GDScript это уже давно так принято и многими используется.
Да, действительно, так получается намного лучше. У меня буквально глаза открылись. Километры кода с кучей модификаторов типа private public protected sealed abstract были ошибкой. Нужно было делать всё публичным и просто ставить спецсимволы. Жаль что Хуан пошёл на поводу у этих, зашоренных, и ввёл @abstract - это буквально шаг назад к вот этим языкам!
Если на вкладке "Import" или в меню импорта модели нет такой кнопки, то нет.
Если нужно конвертировать очень много моделей сразу, можно написать скрипт:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
Можно даже свой импортер моделей сделать, если тебе это прям часто нужно:
https://docs.godotengine.org/en/stable/classes/class_editorimportplugin.html
Если модель одна или от силы десяток, то почему не сделаешь вручную в Blender?
Как-то вяло троллишь, старайся лучше.
>Километры кода с кучей модификаторов были ошибкой
Не путай айти энтерпрайз с их тысячами классов для тривиальной операции и суровый инди-соло-хобби-геймдев - бессмысленный и беспощадный, где запах свободы состоит из месячной немытости и смешивается с code smells.
>ввёл @abstract - это буквально шаг назад
Abstract нужен для наследования от общего предка-пустышки, он полезен в качестве предупреждения ошибок.
Задача: нужно 5 классов с одной функцией, у каждого своя реализация. Создаём класс-заглушку с чем-то типа:
>func do_something_generic(...args) -> GenericResult: return null
И в каждом потомке делаем то же самое, но вместо null возвращаем что-то полезное. Ноооо... спустя полгода решили добавить 6-й класс и ЗАБЫЛИ запилить эту функцию. Наш код валиден, проект запускается и никаких ошибок не выводит. Мы тестируем (если не забыли тщательно протестировать), и где-то через полчаса мы ВНЕЗАПНО натыкаемся на "whatever is null", из-за чего весь проект ломается. Приходится разбираться, что это и где нужно доделывать. Мы могли бы добавить самим-себе-из-будущего вот такое простое предупреждение:
>func do_something_generic(...args) -> GenericResult: assert(false, "implement this first"); return null
Но оно не вызовется, пока код не дойдёт до этой строчки, т.е. опять же тратим полчаса на тест. А вот если мы сообщаем компилятору заранее "это абстрактная функция, если ты её видишь - сообщи мне, что я забыл сделать реализацию этой функции в дочернем классе" - он предупредит нас сразу же, как только мы нажмём F5, и мы не будем тратить кучу времени на тестирование того, что в принципе не способно сработать по причине отсутствия.
Это не касается public/private, потому что обращение к private извне само по себе не влечёт к немедленным ошибкам. Конечно, код запутывается, превращается в "спагетти", копится "технический долг", но в общем и целом такой вызов может решать какую-то сиюминутную проблему (для хотфикса релизнутой с багом игры в ночь после релиза, например), поэтому этого следует избегать в нормальном коде, но ради "хорошей практики" не стоит засорять синтаксис языка, предназначенного для быстрого прототипирования игровых механик и склеивания различных API друг с другом.
В каком месте?.. Прости, я устал, поэтому невнятно пишу.
>может решать какую-то сиюминутную проблему ... поэтому этого следует избегать
Я тут как-то отвлёкся и собрал всё в кучу, лол.
Так... попробую так:
- маркер "private" нужен только программистам, а не компьютеру/компилятору;
- обращение к приватным кишкам приводит к запутыванию кода, а не к багам;
- запутанный код сложнее поддерживать, в т.ч. сложнее исправлять ошибки;
- но иногда такой хак может помочь быстро исправить критическую ошибку;
- поэтому не нужно запрещать хак, а маркер достаточен маленький ("_");
- "abstract" к этому не относится, т.к. предупреждает реальный баг.
Так понятнее?
Но это же скриптовый язык... И всего лишь в 45 раз медленнее чем нескриптовый. Даже не на два порядка. Зачем ждать от него скорости?
>И всего лишь в 45 раз медленнее чем нескриптовый. Даже не на два порядка.
Годотчую. Та же всемирно популярная Lua, кажется, в 150 раз медленнее C...
На реддите пишут, что простота не обязательно должна упираться в отсутствие возможностей. Поэтому там просят модификатор @private, ну, я бы согласился и на модификатор, так и быть. Подчёркивания в начале имён мне лично не нравятся.
C# с версии 10 можно юзать как скрипты (в том числе юникс shebang #! )
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/file-based-programs
> потому что тебя научили такому >>1108881 (You) безобразию.
Ансейв в расте - правильно и смелое решение, ансейвы в шарпах безобразие и ужасно. Какие же вы ведомые дебилы.
>>что ты выберешь - практичность или удобство?
>Значения русских слов забыл?
Если бы ты был программистом то знал что разработка языков это постоянная дилемма между удобством и эффективностью. Поэтому синтаксис часто неудобный там, где важна практичность.
То скобочки пугают, то модификаторы доступа. Ты точно разработчик?
Гдсрыге нет модификаторов доступа, потому что нет модулей, а не потому что гдскрипт такой прекрасный.
А модулей и неймспейсов нет потому что скрипт подключается как ресурс, в общем тянешь за одно место вылезает другое. При этом байткод настолько ужасен, что сдвиг миллионного массива в 45 раз быстрее свап-оптимизации (это без преувеличение безумие).
PS жопоскрипты и питоны критикуют за протекающую абстракцию и протекающую инкапсуляцию, а художники радуются этому в своем гдскрыге, ппц аборегены, с кем я тут сижу.
>Не путай айти энтерпрайз с их тысячами
Тысяча скриптов/классов для римворлд/факторио релиза выглядит как норм. Люди кроме демок ничего тут не делали, им чужды неймспейсы и модификаторы доступа.
>сдвиг миллионного массива в 45 раз быстрее свап-оптимизации
Можешь напомнить для тех кто уже потерял нить срача что это вообще за тест был и где смотреть код?
Где-то тут смотри SWAP тесты.
>>1106507 →
>>1106555 →
Чушь. Просто диды кодинга, писавшие первые компиляторы в далёких 60-70х не знали ещё тех подходов и оптимизаций, к которым пришли отцы 90х и 2000х. А те в свою очередь ещё не знали какие эффективные парсеры сделают сынки с внучками в 2010х.
Нахуя мне неудобства в написании кода, если компилятор сам выводит типы? Нахуя мне писать a := 0 если компилятор и из a = 0 выведет тип?
Нахуя мне писать скобки вокруг условия после if, если компилятор всё равно будет ожидать символ : который ознаменует конец условия и переход к подблоку?
Нахуя писать ; в конце строк, если компилятор и так знает, где концы строк?
И так в куче аспектов.
Языки буквально следуют моде, а не эффективности, про которую ты тут с умным видом талдычишь. Эффективность сегодня совсем на другом уровне. И самое интересное, большинство этих твоих настоящих программистов в упор не видят проблему в том что я тут написал.
Я когда-то видел в какой-то статье некое эмпирическое правило, как заценить что язык эффективен и его компилятор/транслятор/хуятор грамотно написан: Нужно написать программу в одну строку. Если язык нигде не потребует перехода на новую строку - он годный.
Вот и думойте.
Это как измерять качество программиста по количеству коммитов. Можешь не думоть, не твое.
>писать ; в конце строк, если компилятор и так знает, где концы строк?
А нафига ты точку в конце приложения ставишь?
>компилятор и так знает
Он нефига не знает, все его знания стоят времени компиляции.
Я помню в котлине ловили какие-то сложные баги с этой херней и до конца не решили их (я уверен из-за частичного решение там запихнули с десяток проходов).
>И самое интересное, большинство этих твоих настоящих программистов в упор не видят проблему в том что я тут написал.
Какие? Ты просто тот чело с аналогиями и графоманией, я тебя часто скипаю.
Ты из-за синдрома утёнка (вкусовщины) пытаешься раздуть проблемы синтаксиса. Это выглядит крайне не профессионально, как-будто у тебя в мозге проело паскалем или питоном. Как можно человеку что-то объяснить если он возмущается на модификаторы доступа? Это как возмущаться что у машины руль с лева, а не по середине. Наверное модификаторы доступа для чего-то нужны, да?
Если такой умный, собери свой парсер, да засунь в LLVM, сейчас каждый второй может создать свой язык, со своей шизой (этой глючной экзотики сейчас как грязи).
Не один язык до сих пор не решает проблему сложности, ООП с интерфейсами немного облегчает, но абстракции как текли - так и текут.
>Нахуя мне писать a := 0 если компилятор и из a = 0 выведет тип?
Это защищает от ошибки вида a = x; aa += 1; print(a)
В этом случае в некоторых языках заводится новая переменная, которая потом по тихому нигде не используется
Запись a := 0 это сокращение от a : autotype = 0, то есть это не только присвоение, но и объявление переменной.
>Нахуя мне писать скобки вокруг условия после if, если компилятор всё равно будет ожидать символ : который ознаменует конец условия и переход к подблоку?
Не знаю о чем именно речь, но там бывает много нюансов - вложенные if, какие-нибудь присваивания
>Нахуя писать ; в конце строк, если компилятор и так знает, где концы строк?
Потому что конец строк - довольно ненадежный ломающийся маркер. Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
> Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
>>1109181
> :
Как же достала эта хрень в каждом чихе. Серьезно, точка с запятой не так бесит как это, хз почему.
>Подчёркивания в начале имён мне лично не нравятся.
Эстетически? А мне вот кривые скобки не нравятся эстетически...
Ну, ладно, допустим, нужно твёрдо и чётко обозначить private. Почему бы не сделать это сразу для целого блока кода? Вот так:
>class MyObject extends Object:
>_ var public1: int
>_ var public2: float
>_ func create() -> MyObject: ...
>_ func do_at_public(): pass
>@private_part
>_ var private1: string
>_ var private2: Array
>_ func _ready(): pass
>_ func _process(): pass
>_ func do_in_private(): pass
>_ func _on_timer_timeout(): pass
>class MyOtherObject: ... # начался другой объект - приватная часть предыдущего завершена и закрыта, дальше снова публичное
И так далее. По-моему, это было бы проще и логичнее, и удовлетворило бы всех сразу без лишней писанины и переусложнения.
Если честно, я бы ещё блоки var и type вернул из Pascal в GDScript. Устал уже писать каждый раз var, const, enum и всё такое...
Алсо было бы полезно объединить все @export и @onready в один большой блок, чтоб не писать на каждой строке заново...
Да и, если честно, слово "func" совсем не обязательно каждый раз писать, если по заголовку понятно, что это функция...
>>1109126
>в расте
Я не знаю, что у вас там в этом вашем растишке, я его даже не пробовал. Увидел уродливый синтаксис и сразу пропустил.
>>1109127
>дилемма между удобством и эффективностью
Если ты пробовал создать свой язык программирования с нуля (как делал я), то знал бы, что удобство языка можно повышать без компроментации эффективности результирующего кода. Да, время компиляции может возрасти. Да, могут быть неочевидные конструкции, которые компилятор может сделать не так, как ожидает программист. Но результирующий машинный код никак не должен зависеть от того, как выглядит исходный код языка со стороны программиста. И язык не должен заставлять программиста задумываться о том, как лежат байты в памяти и какие операции выполняет процессор, пока он не пытается создать прошивку микроконтроллера с 16 КБ памяти на всё про всё и выполнить код в реальном времени как в какой-нибудь космической ракете. Большинство "неудобств" в существующих языках происходят не от "эффективности", а из-за необходимости поддерживать старый, давным-давно написанный код, т.е. чтобы твой "Компилятор v69.0" мог понять код, написанный во времена "Компилятор v0.01". Другими словами, кто-то когда-то сделал не слишком правильное решение, другие программисты были вынуждены применять это решение на практике, написав тонны кода, а когда нашли более правильное решение, оказалось, что нельзя просто взять и кинуть миллионы строк кода, полагающиеся на старое неправильное решение. Так языки и становятся уродливыми и неудобными. Ну, а большинство современных поделок зумеров - это буквально каргокульт, подобно создателям "убийцы ГТА" и т.п. - они способны написать рабочий код, но не понимают дизайнерской работы, которая стояла за созданием старых вещей, лишь копируя внешний вид.
Вот, кстати, наглядный пример карго-культиста в его естественном состоянии: >>1109128
>что сдвиг миллионного массива в 45 раз быстрее свап-оптимизации (это без преувеличение безумие).
Чувак в набедренной повязке на голое тело увидел "свап-оптимизации" в какой-нибудь книжке, и думает, что это какая-то священная техника, которая должна ускорять любой код быстрее скорости света, но его иллюзии разбиваются о суровую реальность, в которой реальная работа, требуемая для вызова функции интерпретатором в дебаг-режиме требует от компьютера больше, чем уже давно оптимизированный алгоритм, работающий в виде машинного кода на том же компьютере. То есть он буквально собрал "самолёт" из сухой травы и собранных палочек, танцует вокруг него и не понимает, почему с неба не падают большие ящики с провиантом.
>>1109129
>Тысяча скриптов/классов для римворлд/факторио релиза выглядит как норм.
Это совсем другие "тысячи классов": https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
>Люди кроме демок ничего тут не делали, им чужды неймспейсы и модификаторы доступа.
Делали. Нет, не чужды, но и не нужны (не обязательны - жить можно и без них).
>>1109150
Можешь не изучать, там школьник обмазался всеми проверками как по учебнику и удивляется, что они тормозят.
>>1109181
>Нужно написать программу в одну строку. Если язык нигде не потребует перехода на новую строку - он годный.
Ну, насколько мне известно, GDScript позволяет писать весь код в одну строку. Достаточно добавить ";" где нужно.
>>1109193
>А нафига ты точку в конце приложения ставишь?
Потому что он пишет несколько предложений на одной строке, и, кроме того, переносы строк (символы перехода на новую строку) в браузере для человеческого взгляда не видны явно, потому даже с переносами строк без точки или точки с запятой нелегко понять, где кончается одно предложение и начинается другое. С кодом всё иначе: код ты пишешь и читаешь через IDE, в которой переносы строк чётко обозначаются, а для компилятора/интерпретатора символы переноса строк видны так же, как и любые другие символы.
>Он нефига не знает, все его знания стоят времени компиляции.
Ты противоречишь сам себе в одном предложении... И что с того, что "стоят времени компиляции"? Компилируешь код ты один раз, а пользоваться результатом компиляции твои пользователи будут многие годы. Кроме того, медленные компиляторы - это не проблема дизайна языка, это проблема оптимизации компилятора. Если у тебя компилятор на JavaScript написан и выполняется через Electron, не нужно жаловаться, что он медленный, и тем более не нужно ломать удобство синтаксиса языка ради ускорения компиляции.
>Какие? Ты просто тот чело с аналогиями и графоманией, я тебя часто скипаю.
Ты серьёзно нас путаешь? Лол. Или я тебя чем-то так обидел, что ты меня теперь в каждом анонимусе здесь видишь? Расслабься, я не пытаюсь тебя обидеть или что-то вроде. Я только люблю спорить на всякие темы... это своего рода форумная игра.
>Это выглядит крайне не профессионально
Я никогда не называл себя профессионалом, и мы не на профессиональном форуме сидим, а на форуме хоббистов-самоучек.
>возмущаться что у машины руль с лева, а не по середине
Ты же в курсе, что есть машины с рулём по центру?.. А теперь представь, что у тебя в твоей личной машине висит книга по ПДД и специальная механическая рука бьёт тебя по лицу каждый раз, когда ты не зачитываешь вслух цитату из этой книги перед тем, как совершить описанное действие. Например, захотел повернуть направо? Сначала полистай книгу, прочитай вслух что-то наподобие "перед поворотом убедитесь, что дорога свободна, нет запретительных сигналов, и у вас включён поворотный сигнал", и только после чтения этой мантры ты можешь начать поворачивать, а если забудешь прочитать мантру - механическая рука разобьёт тебе лицо. И огромная толпа автомобилистов с разбитыми лицами защищает этот механизм, объясняя тебе:
>Как можно человеку что-то объяснить если он возмущается на механизм битья по лицу? Это как возмущаться что жидкое ешь ложкой, а твёрдое ешь вилкой. Наверное механизм битья по лицу для чего-то нужен, да?
>Если такой умный, собери свой парсер
Я уже делал несколько разных парсеров своих личных языков, мне пока достаточно.
>но абстракции как текли - так и текут
Абстракции текут из-за того, что ООП нужно учиться пользоваться. Язык не может решить твою проблему вместо тебя.
>>1109233
>Никогда не копипастил код с сайта или из чатбота
Аргумент уровня "никогда не пытался чистить уши кухонным ножом?" - сам себя поранил, а жалуешься на производителей ножей...
>>1109249
Лол, давайте ещё начнём жаловаться на то, что нужно ПРОБЕЛ нажимать.
>Почему нас заставляют нажимать ПРОБЕЛ? Можно ведь писать не просто в одну строчку, но и без пробелов! Ведь пробел после точки с запятой не нужен. И после "=", "+" и т.д. Но язык всё равно устроен так, что иногда приходится жать пробел. Это так плохо! Ненавижу пробелы! Хочу писать "a in b" и "a is b" без пробелов, чтобы компилятор сам догадывался, что значит "ainb" и "aisb", а то я на нажатие пробела драгоценные наносекунды трачу, которые мог потратить на просмотр порнушки или, например, мастурбацию.
>Если ты пробовал создать свой язык программирования с нуля (как делал я),
Не покажешь, да?
>И язык не должен заставлять программиста задумываться о том, как лежат байты в памяти и какие операции выполняет процессор
Что за бред, инты, чары, лонги, массив - это буквально указание того как лежат байты в памяти и что с ними можно сделать.
>>1109257
>Чувак в набедренной повязке на голое
Человек-аналогия, я не сразу тебя узнал.
Качество байткода гдскрипта напрямую влияет на производительность твоей игры, нафига ты маняврируешь? Если не поднимать проблему, то её никто не будет решать. Никто не говорит менять твой синтаксис, там качество интерпретатора хуже чем у питонов/руби, в этом проблема.
>Можешь не изучать, там школьник обмазался всеми проверками как по учебнику и удивляется, что они тормозят.
Школьник использовал больше if'ов чем положено, какая беспечность.
Скромнее надо быть, проверять аргументы хотя бы через раз.
>в дебаг-режиме
Тут ты уже лукавишь, гдсрыг в релизе дает чуть более чем нефига, это было проверено там же.
Подчеркивание у тебя в имени переменной, ты его всегда видишь. Это сразу сигнал - это что-то внутреннее, деталь реализации, это надо трогать только если точно знаешь, зачем.
>>1109269
Репорт.
>Не покажешь, да?
А смысл показывать тут, если это не касается Godot? Создание своего ЯП даже геймдева не касается.
>инты, чары, лонги, массив - это буквально указание того как лежат байты в памяти и что с ними можно сделать.
Тебе ещё многое предстоит узнать...
>Качество байткода гдскрипта напрямую влияет на производительность твоей игры
А у тебя и игры нет, чего ты волнуешься-то? Я вообще вкатился в Godot много лет назад, рассчитывая "по-быстрому накидать прототипчик, а когда будет играбельно - переделать на самодельный велосипед или более крутые библиотеки", но так за эти много лет и не пришёл ни к чему достаточно интересному концептуально, чтобы это имело смысл разрабатывать лично мне, а не играть в уже готовое (да я и в игры особо не играю). То есть я делаю прототип, вижу - скучно, бросаю его и думаю над тем, чем бы ещё заняться. О каком "качестве байткода" может вообще идти речь, когда упереться в нехватку производительности нужно постараться?.. Меня вообще из "тяжёлых" игр интересовала разве что Terraria, но в неё я давно наигрался и, попробовав её клоны и свои прототипы, понял, что это не моё. А всё остальное может и на GDScript потерпеть, ведь главное узкое горлышко - GPU.
>>1109272
База. Я вот привык почти всё начинать с подчёркивания, если мне это не нужно где-то снаружи вот прям сейчас.
> Подчеркивание у тебя в имени переменной, ты его всегда видишь.
Ладно-ладно. Стерпится-слюбится.
>Репорт.
Чего порвался то? От этого гдсрыг быстрее не станет.
Вахтерша протерпела два месяца, лол.
Все правильно тебя репортят. Хуйней страдаешь и тред дерейлишь на хуйню. Заменил движкосрач на языкосрач и типа хитрый дохуя.
>А у тебя и игры нет, чего ты волнуешься-то?
Ну, очевидно ты хочешь получить максимум.
У меня, кстати нет проблем с прокрастинацией как у вас, разработка это мое хобби (не важно что это игра или не игра, я все равно буду что-то писать, то есть я дропал прототипы по объективным причинам).
>Хуйней страдаешь и тред дерейлишь на хуйню.
Тебя поймал на лжи, от чего пердак порвался. Хватит прикрывать свои обиды тредом. Ты же умудрялся репортить даже в движкосраче, когда тебя возили лицом по некомпитентности.
Это не твой личный чатик, кому не нравится просто проигнорят.
Сейчас бы табулировать проблемы гдсрипта, которые подымаются везде.
PS
Забавно что начался учебный сезон, школьник опять сорвался и начал долбить в кнопку.
>тебя
Твой детектор настолько кривой, что дочитывать твое сообщение пойнта ноль. Я эту вкладку редко открываю, но каждый раз как захожу вижу тебя с абсолютно нерелейтед к треду хуйней. Так что тоже зарепорчу.
Вот в соседнем треде нет срача, там вообще уже ничего нет. Желаешь протухший тред? Как-будто кто-то будет спрашивать ньюфажные вопросы в эпоху ИИ.
>Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
Сколько душу питона нейронкой - не было таких проблем.
мимо
Лол, это что ты натворил, чтобы тебя даже в движкосраче репортили.