Продолжаю работу над проектом ChimbaBench, и как забытая строчка кода решила большую проблему

Судя по информации в GitHub, я не работал над проектом уже два месяца, и это очень неприятно:

Почему это неприятно? Просто я не программист, а потому лепил код как получалось, теперь мне нужно возвращаться к старому коду и работать с ним.

Впрочем, ничего страшного не произошло, однако я понял одну важную вещь, код нужно делать модульным и портативным насколько это возможно, чтобы потом не работать над всем проектом целиком полностью запоминая всю структуру проекта, а просто собирать по кусочкам всё воедино.

Таким образом было решено разнести куски проекта по разным объектам:

Ведь мне захотелось сделать не простой бенчмарк, а многофункциональный, и тут никак без разных тестовых сцен для разных задач, а создавать каждую сцену с нуля... Ну в общем мне нужны объекты которые я смогу просто добавить в сцену и получить что мне нужно.

При этом мне нужно сохранить функционал локализации, но с этим нет проблем, функционал локализации я оставлю, но только для главного окна бенчмарка, а вот тестовые сцены будут строго такими как я сделаю, и никак иначе, просто чтобы результаты тестов не зависели от локализации.

Вот так легко и просто теперь можно добавить блоки с базовой информацией в сцену:

А теперь поработать над кодом, нужно будет сломать что работало ранее и починить обратно, но уже по другому.

Заодно нужно решить одну проблему, интерфейс сейчас статичен, и не растягивается за окном:

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

Впрочем, нужно предусмотреть и такой вариант, что пользователь изменит размер окна уже после перехода в новую сцену, просто ловлю событие изменения размера окна и подгоняю интерфейс под разрешение. А ещё я позаботился о том, чтобы пользователи с 4K мониторами прекрасно видели всю информацию:

Выглядит это примерно так:

Я не стал подгонять размер шрифта динамически от размера экрана вплоть до пикселя, хотя это было бы проще в плане написания кода, как сказать... Просто по совокупности факторов я решил что сейчас лучше именно так сделать.

Так я и работал над кодом, пока мне не захотелось изменить разрешение в "игре"... Казалось бы, типичный функционал который поддерживают даже игры из 90х годов! Да, функционал типичный, но не для Open Source линуксоидного недоразумения...

Я уже как только не извращался, но так и не смог прямо из "игры" изменить размер окна, результат всегда примерно одинаковый был:

Вообще я раньше писал всякое на голом C++ и OpenGL, и скажу честно, у меня не было проблем с тем, чтобы изменить размер окна во время работы приложения, а в Godot Engine это просто "матерная ругань"...

В итоге я наткнулся на забавный ответ в интернете, изменение разрешения это "bad experience" для пользователей macOS и Linux! Так вот где зарыта собака! Видите ли, линуксы не способны адекватно обработать падение игры и восстановить разрешение экрана как это делает Windows!

Мда... Впрочем, я не удивлён, Linux дистрибутивы действительно максимально отвратительны как операционные системы для обычных пользователей, но вашу кочергу!

Мне что, теперь брать исходный код Godot Engine и переписывать чтобы он научился изменять размер окна/разрешение экрана в полноэкранном режиме?! Почему по вине неполноценных и убогих дистрибутивов Linux должны страдать все? Ну не умеют линуксы адекватно восстанавливать разрешение экрана, ну и пусть передёргивают как хотят себе там! Почему пользователи нормальных операционных систем (Windows) должны страдать и не иметь базовый функционал?!

По итогу я не могу полноценно разработать бенчмарк потому что дистрибутивы Linux весьма убоги как операционные системы, а разработчики Godot решили что нужно подстраиваться именно под убогие дистрибутивы, а не под разработчиков игр и пользователей...

Ладно, придётся извращаться, имея дело с линуксоидным софтом без извращений не обойтись! Но оставлю пока этот нюанс на потом, сейчас гораздо важнее привести в порядок модуль с информацией.

Хотя да, я же забыл сделать скриншот как было... Но ничего страшного, ещё так много всего сделать нужно.

Чтобы не забивать экран лишней информацией, было решено ту самую "лишнюю" информацию показывать только если пользователь сам в настройках укажет что хочет эту информацию получить:

Выглядит как-то так:

Хм, довольно сложно определить влияние на FPS от наличия дополнительной информации, ведь куб постоянно во вращении... Так как сцена простая я отключил вращение кубику, и да, дополнительная информация слегка влияет на FPS, совсем незначительно, в районе ~1%, но всё же влияет:

Далее я так подумал, а ведь мой модуль GUI_BaseInfo могут взять другие люди и использовать в своих проектах, так почему бы не сделать модуль более удобным в использовании? Ведь любой обычный пользователь рано или поздно может сам начать творить:

После поработал над кодом скрипта выводящего информацию о производительности, по итогу сократилось несколько лишних функций и кода стало меньше, а ещё я убрал вывод степени анизотропной фильтрации, возможно потом вообще уберу всё связанное с анизотропией...

Почему такую важную информацию я убираю? Всё просто, это же Open Source движок, и он подстраивается под изначально убогие дистрибутивы Linux, вот и не работают по итогу такие вещи как смена разрешения, анизотропная фильтрация, и может быть что-то ещё.

Такими темпами мне придется самому писать движок, ибо Godot Engine слишком неполноценен на базовый функционал, прямо повторяет неполноценность Linux дистрибутивов, при этом фанатики Linux будут ещё что-то рот свой открывать рассказывая какие все пользователи криворукие и глупые, а линуксы прекрасны, для своих сферических в вакууме задач...

Может это я такой плохой программист "не осилил" прекрасный линуксоидный движок? Хотя я не программист, но ладно, вбиваю в поисковике "сменить разрешение экрана unity" и сразу же получаю видео где за 3 минуты показано как сделать настройку позволяющую правильно сменить разрешение экрана в игре:

Причём в Unity Engine изменение разрешения происходит буквально одной строчкой максимально логичного и простого кода! Тем временем в Godot Engine даже через ковыряние Visual Server хрен (продолговатой формы овощ) там плавал, а не адекватное изменение разрешения!

А ещё я посмотрел в документацию Unity Engine, и это прекрасная документация, мне достаточно было просто взглянуть один раз и всё как на ладони, просто, наглядно и понятно!

Эх, такую бы документацию для Godot Engine, а то даже богам неведомо, что творится в документации на Godot... Разработчики игр наверное экстрасенсы и нечеловечески разумны, без документации прекрасно поймут что вообще есть в движке и как работает...

Я уже молчу про "сухость" документации на Godot Engine:

Может ну подальше этот Godot Engine недоразвитый...

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

Ладно, поворчали и хватит, нужно дальше работать над проектом.

Для масштабирования информации о сцене я применял три уровня масштаба в зависимости от текущего разрешения, но у меня получился довольно громоздкий код... Однако ради разнообразия я сделал динамическое масштабирование для шрифтов в пределах главного меню.

В итоге 16 строчек кода превратились в 4 строки, причём больше не нужно использовать лишние переменные и условия, ведь я просто задаю размер шрифта как размер окна поделенный на 45, таким образом размер шрифта зависит от ширины окна.

Выглядит это следующим образом:

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

Впрочем, и это можно решить:

Вообще в настройках проекта можно задать "растяжение" и все проблемы масштабирования одним махом будут решены, это для тех, кто не знает про такой функционал, или будет пытаться меня поучать "как правильно":

Я и не собирался выпендриваться максимально "правильным и красивым" кодом, пусть этим занимаются разработчики кривых дистрибутивов и софта бесконечно клепающие хлам падающий от любого дуновения ветра со стороны, а я просто работаю над полезным софтом в первую очередь для себя любимого.

Однако, как можно было уже давно понять, я не ищу простых путей, и написал свой вариант адаптации кнопочек, и это мне самому не нравится если честно, но потом что-нибудь придумаю:

А вот дальше был обнаружен неожиданный костыль позволяющий изменить размер окна не перезапуская "игру". Это было настолько удачное стечение обстоятельств, что я не уверен насчёт того, догадался ли такое сделать кто-либо ещё кроме меня...

В интернете я не встречал решений позволяющих изменить размер окна вопреки неполноценности Godot Engine, да, есть вариант с полным перезапуском "игры", но это требует перезапускать "игру", а ещё вариант далеко не идеален и имеет свои проблемы.

Экспериментируя с переключением "игры" в полноэкранный режим и обратно я забыл закомментировать лишний код который по сути не работал, и этим кодом был метод "set_window_size", как оказалось он работает, правда только если перевести игру в полноэкранный режим и обратно в оконный.

В чём суть костыля? Сначала недокументированным методом "set_window_size" задаю размер окна, а после другим недокументированным методом "set_window_fullscreen" передёргиваю "игру" в полноэкранный режим и обратно в оконный.

Таким образом задаю размер окна и заставляю движок перейти в полноэкранный режим, а когда он выходит из полноэкранного режима то создает заново окно, но уже с разрешением которое я задал ранее!

Впрочем, в линуксоидном софте и самих дистрибутивах иначе ничего и не работает, только такими злостными костылями можно заставить работать что не работало...

Да, костыльное решение, но оно работает, и это гораздо лучше, чем ничего! Теперь можно будет изменить размер окна не только растягиванием, но и через настройки "игры"! Только один момент, нужно бы проверить это в дистрибутивах Linux, а то вдруг дистрибутивы не переживут такие костыли, тогда в очередной раз настанет время переустанавливать линукс...

И этот костыль сработал в дистрибутиве Linux, а значит всё отлично! Меня только забавляет тот факт, что костыль сделан из недокументированных в документации методов, а потом фанатики Linux будут ещё посылать читать мануалы при каждой непонятной и неожиданной проблеме.

Есть только один не очень хороший момент, статья уже набирает неприличную массу и пора бы заканчивать данную часть. Я хоть и старался в статью выписывать лишь часть нюансов из работы над новой версией ChimbaBench, однако это не сильно то и помогает сокращать объём.

Так что на этом пожалуй завершу текущую статью, а продолжение начну писать уже в отдельной статье, просто мне самому сложно оформлять слишком массивные статьи, а работы ещё довольно много нужно проделать перед выпуском новой версии ChimbaBench.

Вообще я думаю сейчас над версией проекта, по идее делаю версию 1.4, но у проекта слишком много изменений выйдет относительно версии 1.3, так что рассматриваю вариант сразу выпустить версию 2.0, даже если перфекционисты будут негодовать по поводу такого назначения версий...

Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.