Кодил по фану на Pascal/Delphi с конца нулевых, но последние несколько лет сижу только на Godot и он полностью удовлетворяет моё желание покодить.

>>80147

>Калькулятор сделаный в делфи занимает 10мб

Справедливости ради, 10 МБ - это debug билд, с кучей дополнительной информации и без оптимизаций. С оптимизациями простой калькулятор на достаточно современном компиляторе Object Pascal будет весить примерно мегабайт или меньше. На старых версиях, например, Delphi 7, минимальное VCL приложение занимает 300 КБ, а без VCL - где-то 30 КБ, не помню. Основной вес здесь - стандартная библиотека. VCL достаточно увесистая и в актуальных версиях Delphi, видимо, разжирела ещё больше...

>0% проца

Под капотом там есть небольшая фоновая нагрузка:

>Application.Run;

>This starts the application’s main event loop, allowing the application to process user inputs and events.

Т.е. у любого GUI приложения архитектура а-ля игра: специальный бесконечный цикл каждые несколько миллисекунд проверяет, есть ли сообщения от ОС. Данная проверка обязательна, если приложение не отвечает вовремя на запрос ОС - его окно "мутнеет" и ОС может предложить юзеру закрыть программу.

>0% видюхи

Спорный вопрос. VCL в Delphi использует нативные окошки из API ОС, например, WinAPI. Это дешевле продвинутой игровой графики, но ОС под капотом пользуется видеокартой для рендеринга окошек приложений. Поэтому, например, часто проблемы с видеокартой или видеодрайвером ломают все окна, включая системные, а не только игровые окна. Т.е. нагрузка никогда не бывает 0%, даже если диспетчер задач указывает 0% напротив твоей программы.

>Калькулятор сделаный в годоте в 2D

Зачем тебе нужен калькулятор на игровом движке?

>200мб

Во-первых, не 200, а около 100 МБ в расжатом виде. Сжатие файловой системы может снизить до 50 МБ.

Во-вторых, это сборка движка со всеми функциями, включёнными по умолчанию: 3D рендер, физика, библиотека звука, библиотека для сетевых операций, локализации движка, очень много GUI компонентов и множество других, реже требуемых компонентов.

В Delphi компилятор собирает EXE только из тех библиотек, которые ты сам указал после "uses". Это позволяет избегать включения лишнего кода. Да, разумеется, аналогичное справедливо для любого компилируемого языка, но особенность потомков Pascal в том, что они компилируют крайне быстро, практически мгновенно собирая юниты в EXE.

Т.е. можно собрать Godot без лишних модулей, вот только Godot написан на C++ и компиляция C++ занимает крайне много времени (несколько часов). Поэтому Godot не собирается сам из исходников, а разработчики предоставляют сборку "всё включено".

Разница в компиляции также влияет на то, что код, скомпилированный C++, весит меньше и работает немножко быстрее кода на Pascal-подобных языках (примерно в 2 раза быстрее, судя по тестам), т.к. применяется больше разных оптимизаций.

Что получается:
- делай игру быстро на стандартной сборке;
- если потребуется, потом сделаешь свою сборку.

>40% проц

Это у тебя какая-то проблема в коде. Делал себе GUI приложения на Godot, и по ЦПУ они тратят не сильно больше GUI приложений на Delphi (в районе 1%). Там необходимо включить специальный режим для GUI приложений, если нужно снизить фоновую нагрузку.

>сколтко то там % видюху

Это нормально. GUI в Godot не пользуется API ОС, т.е. отображает все GUI-элементы самостоятельно, через графическое API видеокарты. Поэтому, во-первых, это детектится диспетчером задач, во-вторых, это менее эффективно, чем нативные окошки ОС.

Но в этом есть свои преимущества:
1. GUI в Godot не зависит от:
- семейства ОС (Windows/Linux/MacOS/Android/iOS);
- версии ОС (например: Windows 7/8/10/11);
- используемого оконного менеджера (Linux);
- настроек ОС (тема, цвет окон и прочее);
- нативное приложение или в веб-браузере.
Т.е. везде и всегда GUI будет таким, как ты задумал.
2. Ты можешь с лёгкостью расширять компоненты интерфейса своими велосипедами без оглядки на разношёрстные API, пользовательские темы и т.д. - велосипед будет работать на любой платформе.
3. Проще поддержка скинов интерфейса, что очень важно для любых игр, но также может быть очень полезно для кастомизации пользователем. У чисто нативных приложений с этим обычно проблемы.
4. Такой GUI легче анимировать, добавлять разные визуальные эффекты и т.п. Конечно, это не нужно утилитарным приложениям, но играм очень важно. Нативные окошки оптимизированы под статику, т.е. анимации нативных окон крайне неэффективны.
5. Разработчикам движка проще поддерживать библиотеку такого GUI, поскольку графические API стабильны - не меняются так часто, как API ОС. А следовательно, твой проект проще перекатить на актуальную версию движка, даже если целевая платформа претерпела существенные изменения.

>Что будет с 3D инженерным калькулятором?

Не вижу проблемы. Базовая нагрузка не изменится, результат зависит от эффективности твоего кода. 3D калькуляторы не рисуют много графики, там обычно достаточно один 3D меш создать (график функции).

>>80232

>Я описал часть игры, симулятор школьника

Так сразу и говори. Для игры на Delphi тебе в любом случае потребуется подключать дополнительные библиотеки: графическую, физическую, звуковую. Стандартная VCL для игр не подходит, если делаешь полноценную игру, а не классического "Сапёра". Не говоря о том, зачем тебе вообще калькулятор в игре?

>игра раком встает при одном только калькуляторе

Скорее всего, дело в твоём коде или сценах. Я делал достаточно сложные GUI в Godot и никаких проблем производительности не встречал. Да, он всё же не настолько эффективен, как нативные окошки, но преимущества перевешивают недостатки (для игр).

>таких бешеных лагах

Ты описал нагрузку в 40%, где там "лаг"? Задержки возникают, когда ядро ЦПУ нагружено на 100%.

Также напоминаю, что последние несколько лет набирают популярность приложения на Electron.

Что такое Electron-приложения? Это сборка Хромиум, весящая минимум 150 МБ, которая локально крутит JavaScript код, делая вид, будто это нативное окошко. Однако, браузеры рендерят код подобно играм, т.е. нативных окошек ОС в них не так много, как кажется. Приложения на Electron весят как браузер и тормозят как браузер, но всё равно набирают популярность. Например, очень популярный Obsidian - на Electron. Я заметил, что некоторые старые нативные программы перекатывают на Electron, из-за чего они становятся значительно тяжелее и медленнее. Это печально, но тенденция на лицо. По сравнению с Electron, Godot использует более удобный язык (GDScript), удобнее в разработке приложения, не срёт по системе своими файлами как Хромиум, быстрее запускается и имеет стабильный отклик вместо браузерных пропуков. Поэтому, если выбирать между модным Electron и необычным Godot, я бы выбрал Godot.

Кроме того, прикладное приложение на Godot имеет большой смысл, если его работа касается разработки контента для игры, новых игр или компонентов игр. В таком случае тебе доступна вся экосистема Godot напрямую, без внешних библиотек и велосипедов. Особенно если делаешь утилиту для моддинга игры.

Один неочевидный факт: EXE в папке Godot-игры по умолчанию способен запускать любые PCK файлы. Поэтому, если твоя игра идёт в комплекте с набором специальных программ, программы эти могут быть в формате PCK - очень маленькие файлы - а их запуск осуществляется единственным EXE в папке игры. Фактически, тебе даже не обязательно давать игроку специальный EXE-файл, если твоя игра формата PCK работает на стандартном Godot; игроку достаточно скачать Godot с официального сайта и подложить скачанный у тебя PCK файл. Особенно актуально для мелких игр, если у тебя сотня игр на одном движке: предоставляешь ссылку на PCK-файлы отдельно от исполняемого файла движка. Было бы удобно.

Ну, или можно написать свой лаунчер игр, который автоматически скачивает только PCK файлы, и сам использует себя для запуска этих PCK файлов. Типа лаунчера Blizzard и многих других компаний.