Добрый день делал бенч на скорость математики и переборов с логикой
Gd скрипт показал себя очень плохо почти в 5 раз медленней чем на c# но у меня проблемы с компиляцией под линухом(может кто поможет)
Есть ли люди у которых есть опыт создания своих компонентов на с++ с логикой своей по инету нет что-то легко доступного под линух
ЗЫ сори если сложно описал свою мысль
DanQuimby
> Есть ли люди у которых есть опыт создания своих компонентов на с++ с логикой своей по инету нет что-то легко доступного под линух
Я на линуксе, на gdnative/gdextension С++ пишу.
По мне так кресты на линуксе гораздо проще: они там практически везде из коробки.
DanQuimby
> ЗЫ сори если сложно описал свою мысль
Есть такое, но ты пытайся. Знаки препинания могут помочь.
Пишу из поезда с телефона, скажи лучше изначально все писать на крестах или совмещать со скриптами? Я хочу попробовать второй вариант. Хотелось бы узнать нение кто в курсе.
Вообще, все зависит от задачи. Некоторые вещи можно сделать только на скриптах и не париться.
Что у тебя за математика сложная в игре?
nklbdev
Ртс на 100 на 100 активных юниоов
Вопрос философский. Когда как. У меня есть все 3 варианта.
У крестов есть и недостатки: их надо настраивать (в отличие от gdscript) и их надо компилять на целевые платформы.
Я пишу на С++ не из-за скорости, а потому что язык мощнее, как ни крути.
Кроме того, если много своего тайм-критичного кода, надо следить, чтобы маршалинг между приложением и ядром движка
был минимальным. Есть примеры, когда кресты медленнее gdscript-а.
Но это лечится, если делаешь "модули", т.е. по сути внедряешься в само приложение.
Вообще да, если хочешь самой большой скорости - вообще все лучше написать на ассемблере и использовать двиг только для отображения болванчиков. Например, каждый раз, когда приходит
_physics_process(delta)
в корневой узел - выполнять вообще всю логику своими методами в отвязке от всех процессов Godot. В конце лишь обновив позиции юнитов, номера кадров анимаций, вызвав нужные звуки.
Но тогда встает вопрос - нужен ли тебе Godot вообще?)))
У любой технологии своя цена использования.
В любом случае биндинги к любому языку - уже не бесплатная штука и занимают какое-то время исполнения.
Я не изучал тему, но слышал, что есть движки, которые занимаются только отображением чего бы то ни было (не обязательно что-то похожее на игру). Например, раньше я много слышал про Ogre. Наверняка таких еще куча.
Суть в том, что ты можешь основной цикл вообще использовать свой. Вообще все процессы использовать свои. Использовать графический двиг только для вывода графики, а звуковой - для звуков. Отдельные библиотеки - для сети и т.п. Простор огромен, но и разработка превратится в трудную дичь, в которой можно легко утонуть. Тут уж придется штудировать все паттерны проектирования)))
nklbdev
Точно вопрос а нафига годот сразу встаёт)
Спасибо народ,решил сделаю 90% игры на gd и все что будет критично по скорости переводить на шарп
ЗЫ как бывший разработчик на плюсах так и неполюбил билды и магичить с симэйками
nklbdev
> Я не изучал тему
Я, кроме того, что изучал тему, еще могу сообщить, что в Godot можно оптимизировать
пользуясь т.н. серверами, отказавшись от нод по мере надобности.
Хотя изначально, была попытка задать вопрос про медленные вычисления.
Der FlugSimulator
кстати лучше много отдельных нод, или 1 большая нода с компонентами
чую что второй ответ, но все же :)
DanQuimby
Для производительности может лучше второе.
Для скорости и удобства разработки - наоборот.
Ты мне кажется преждевременной оптимизацией занимаешься.
У тебя игра то уже есть, чтобы понимать, как именно оптимизировать?
Der FlugSimulator
> Ты мне кажется преждевременной оптимизацией занимаешься.
вот именно, потому и плюнул на это и делаю на гд скрипте. Ибо все это от лукавого ) нужно что то сделать
DanQuimby
> плюнул на это и делаю на гд скрипте
Разумно. Я тоже после долгих изысканий перешел к этому подходу. Если будет что-то надо - тогда и буду переезжать на другие.
В большинстве случаев я обнаружил, что решает скорее не скорость исполнения языка, а то, как ты организуешь данные.
Например, у меня была проблема, как обновлять туман войны. Первичная реализация была наивной, и очень тормозила игру. Я его разбил на квадраты по сетке с определенным шагом, придумал всякое кэширование и т.п., и стало работать быстро.
Слышал от друга якобы чью-то цитату (попробую сейчас узнать, откуда она):
>Вся суть программирования - это упражнения в кэшировании
Ну... не могу сказать, что эта цитата сильно правильная, но довольно занимательная)))
nklbdev
> Вся суть программирования - это упражнения в кэшировании
Ну как сказать. Не вся и не всегда.
Вот ровно в соседней теме товарищ на нём и погорел.
На запутанном кэшировании и неоправдвнной оптимизации.
Надо к месту применять приемы.
Ну.. это и есть упражнение - использовать для конкретного кейса правильную комбинацию)))