В прошлой части я остановился на моменте когда случайно решил проблему изменения размера окна при использовании Godot Engine:
Продолжаю работу над проектом ChimbaBench, и как забытая строчка кода решила большую проблему
Сейчас пришло время преобразовать костыль в рабочее решение, да, в том же Unity Engine достаточно одной максимально логичной и простой строчки кода для изменения разрешения, причем эта строчка отлично документирована в мануалах, но сейчас я работаю не с Unity, а с Godot Engine, потому сначала использую недокументированный метод set_windows_size, а после использую недокументированный метод set_windows_fullscreen:
Причем важно заметить, есть несколько видов "fullscreen".
Есть полноценный полноэкранный режим (эксклюзивный), это тот режим при котором работали абсолютно все игры в среде Windows вплоть до XP, и есть полноэкранный оконный режим, это уже ущербный полноэкранный режим по своей сути, ибо работает под слоем композитора рабочего стола со всеми вытекающими последствиями для задержек вывода изображения.
Следующие два видео наглядно продемонстрируют почему композитор рабочего стола это плохо:
Впрочем, Godot Engine похоже не умеет в полноценный полноэкранный режим, а значит нет смысла плясать вокруг этого нюанса, хотя это досадно.
Ладно, сначала нужно решить проблему с масштабированием окон, ибо это действительно проблема которую нужно решать хоть как-то:
Так гораздо лучше, теперь окно сообщений масштабировано, осталось другие части интерфейса сделать масштабируемыми:
Довольно кустарное решение, но рабочее, а значит всё отлично что бы не говорили на этот код. В конце концов никто же не кричит на разработчиков софта с закрытым исходным кодом, что там в коде всё неправильно? Никто не кричит, ибо код закрыт и неизвестно какими костылями внутри всё реализовано, я тоже мог бы закрыть всё и показывать только результат работы, но тогда будет непонятно как я всё сделал, вдруг вирусы заложу в закрытый исходный код...
В процессе было прикручено диалоговое окно чтобы пользователь мог выбрать любой шрифт какой пожелает, правда этот функционал пока имеет весьма мало смысла:
Само собой скармливать нужно файлы шрифта, чтобы у пользователя случайно ничего не поломалось я поставил условие проверяющее расширение файла, таким образом ничего не произойдет при попытке загрузить любой файл как шрифт.
Да, это легко обойти просто переименовав расширение скармливаемого файла, но это уже проблемы пользователя, если он усердно хочет себе поломать что-нибудь - грех ему мешать:
Раздел с настройками теперь более-менее неплохо выглядит, правда некоторые кнопки вышли за пределы окна подгоняясь под размер шрифта, но эту проблему я пожалуй оставлю на потом, сейчас есть более важные задачи.
Как можно заметить, всё лишнее было убрано, справа вверху осталось лишь две кнопки, одна для выбора шрифта, а вторая для сохранения текущих настроек:
Далее нужно сохранение и автоматическую загрузку настроек реализовать, и у меня это получилось, а заодно исправил косяк с неправильным положением кнопки после смены шрифта, адаптивный интерфейс стал еще более адаптивным, и это отлично:
Вот так и выглядит на текущий момент файл конфигурации, не густо, ну и ладно:
В виде кода это выглядит примерно так:
Точно... Совсем забыл... Нужно же прикрутить костыль для смены разрешения... Один момент.
Хотя ладно, это был не совсем "один момент", в процессе был выявлен недостаток, стандартное выпадающее меню от Godot Engine ведёт себя как типичный Open Source, то есть криво... Выпадающее меню никак не масштабируется в зависимости от разрешения, не то чтобы это было проблемой с 2560x1440 монитором, но с 4к мониторами и выше могут быть проблемы, мой интерфейс масштабируется, а всплывающее меню нет...
В любом случае проблему с размером всплывающего меню я пока оставлю как есть, сейчас нужно сделать чтобы оно работало хоть как-то, и вот здесь мне пришлось немного схитрить.
Так как я не могу просто взять и вставить массив Vector2 в ассоциативный или даже обычный массив, то естественно я не могу обратиться к массиву и взять нужное значение. Почему мне вообще это нужно делать? Как минимум потому что всплывающее меню возвращает номер выбранного пункта в формате int.
Таким образом я имею ответ от "кнопки" в виде числа, и в зависимости от числа мне нужно задать конкретное разрешение, можно было бы через гирлянду if-else реализовать, но мне показался этот метод не очень интересным, потому я всё же засунул Vector2 в массив, просто значения записал ассоциировав их с числами по возрастанию.
Мне очень не хотелось писать отдельную функцию что сожрёт строку из массива и преобразует в значения для Vector2, потому я сделал именно так как сделал, в итоге просто получаю номер выбора от "кнопки", выбираю из массива значение ассоциированное с номером, и собственно всё:
А после я так подумал, ведь у каждого элемента есть ID который я могу присваивать как хочу, только вот этот ID нужно ещё достать из "кнопки":
В принципе достать ID элемента не сложно, но это только увеличивает размер кода, практической пользы на данный момент нет. Я не могу в качестве ID задать 640 и ассоциировать его с 480 в массиве, ведь есть такие размеры как 2560x1440 и 2560x1080, начинаются они с одного и того же числа, а значит я не смогу их ассоциировать простыми методами ради сокращения размера массива...
Ладно, всё равно уже намесил всякого в коде, так что сделаю получение элемента массива по ID элемента из списка, хуже уже точно не будет, а потом что-нибудь придумаю.
Может быть неправильно, всё ужасно и вообще демоны в адских котлах захлебнулись! Ну и ладно, оно работает и это главное, тем более могу себе позволить ибо я не программист, мне безразлична красота кода. Всё равно никто за меня код не напишет, разве только в комментарии набегут хейтеры, чтобы нагадить и убежать даже не подтерев попу.
Ладно, далее прикручиваю галочку для переключения полноэкранного режима, при активном полноэкранном режиме блокирую настройку разрешения экрана, движок всё равно не может в полноценный полноэкранный режим чтобы от этой кнопки был смысл когда окно растянуто под композитором:
Правда выглядит эта галочка ну вообще никак...
Далее прикрутил сохранение и загрузку настроек, причём добавил автоматическое центрирование окна при изменении размера, хотя как показала практика, работает центрирование адекватно только в среде Windows, ибо в дистрибутивах Linux оно работает через место которым справляют нужду ввиду нехороших особенностей самих дистрибутивов:
Хм, что же дальше... Точно, привести в порядок окно About, по идее здесь должно быть описание программы, ну в общем тут должно было быть описание, но пока сойдёт и так...
Ладно, нужно бы проверить в Linux дистрибутиве работу сохранения настроек и интерфейса в целом:
В целом всё отлично работает, только после возвращения из тестовой сцены параметры в разделе настроек приходят в значения "по умолчанию", но это дело поправимое всего одной строчкой кода.
А ещё я заметил один неприятный момент, можно установить любое разрешение в настройках и оно будет задано, и если разрешение больше чем размер экрана, то окно выйдет за пределы экрана... Пришлось добавить проверку на выбор пользователя.
Далее нужно поработать над интерфейсом тестовой сцены:
И прикрутить сам бенчмарк собственно, можно конечно и просто смотреть на FPS в правом верхнем углу, но почему бы не ввести "ЧимбаПоинты"? Откуда взялись "ЧимбаПоинты" (ChimbaPoints, CPs)? Просто так получилось, даже не спрашивайте...
В плане кода процесс тестирования выглядит следующим образом: Пользователь нажал кнопку, 2 секунды ожидания, и только после этого запуск главного таймера с открытием условия в функции _process(delta), после того как главный таймер отработает (60 секунд) происходит подсчёт результатов и остановка процесса:
Точно, совсем позабыл, нужно ещё вывести название процессора и количество потоков, ведь не всегда результат может быть лимитирован именно видеокартой, особенно при тестировании простой сцены при наличии производительной видеокарты. В общем добавил дополнительную информацию:
Да и мрачную сцену надо бы сделать более весёлой на вид:
На этом пока всё, для версии 2.0 хватит.
-
--
---
Результаты тестирования
Прежде всего укажу ссылку на репозиторий с бенчмарком: ( https://github.com/Shedou/ChimbaBench ).
А теперь можно и перейти к тестированию, тут ничего сложного, просто выставить нужные настройки, перейти в тестовую сцену, нажать кнопку Start Benchmark и ждать результаты.
Первые результаты собраны на ПК с процессором i5-6500 и видеокартой Radeon RX 6600, операционная система Vanilla OS:
Теперь пора и мне собрать результаты, буквально 5-6 минут и результаты собраны в среде Windows 10:
Далее результаты собранные в среде Windows 7:
И в XUbuntu 22.04.1 с нормальным драйвером от NVIDIA (525.60.11):
Пора перейти к сводке результатов:
Для полноты картины были сделаны тесты в разрешении 640x360 без сглаживания, правда у человека с RX 6600 уже поменялась операционная система, была Vanilla OS, а теперь Fedora, потому отдельным графиком покажу дополнительные результаты:
На этот раз специально выбрано минимальное разрешение без сглаживания, чтобы наверняка узким местом стал именно процессор а не видеокарта, и это сработало, в разрешении 640x360 процессоры действительно стали узким местом.
А ещё узким местом стала Windows 10, дистрибутивы Linux показали гораздо более высокую производительность при разрешении 360p:
Было бы интересно посмотреть на производительность i5-6500 и RX 6600 в среде Windows, но у человека с этим "железом" только Linux установлен, а у меня есть только мой компактный ПК в самодельном корпусе с R7 2700X и GTX 1070, так что увы.
-
--
Заключение
Вот я и завершил ChimbaBench v2.0, первую пригодную для сравнительного тестирования версию, теперь осталось только исправлять недостатки и вносить новый функционал.
Теперь любой линуксоид может легко запустить мой бенчмарк и помериться ЧимбаПоинтами с другими людьми, ну или средним FPS достигнутым за время тестирования если религия не позволяет использовать ЧимбаПоинты:
На этом наконец завершу статью...
P.S. Открою очевидный "секрет", на самом деле это дистрибутивы Linux не дружат с пользователями, и да, я не программист, тем не менее я осилил разработку своего бенчмарка, чтобы дистрибутивы Linux были не столь ущербны на портативный софт коими являются по факту, а некоторые тем временем могут осилить только гадости в комментариях судя по всему.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
