опубликовал Klonan

Факторио в Национальной технической библиотеке в Праге (Klonan)

Если вы находитесь в Праге этим летом и хотите насытить свою тягу к Факторио, вы можете зайти в Национальную Технологическую Библиотеку в Праге, где Factorio загружается на 150 компьютеров для всех, чтобы играть. Вход бесплатный для всех посетителей с понедельника по пятницу с 08:00 до 22:00 до 31 августа.  ПК работают на Linux (Fedora), загруженные с помощью специальной сборки игры HanziQ, и вы можете размещать серверы локальной сети и играть со своими друзьями.

23 июля в библиотеке будет проходить наша собственная вечеринка Factorio LAN, которая начнется в 16:00 CEST (время в Праге), чтобы вы могли вместе с нами поиграть. Рекомендуется принести свой собственный набор наушников, если вы собираетесь участвовать.

Оптимизация рендеринга (posila)

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

Но во-первых, нет необходимости изобретать колесо, поэтому давайте посмотрим, как Аллегро делает волшебство. Allegro использует рассылку спрайтов, что означает, что он рисует несколько спрайтов, которые используют ту же текстуру и состояние рендеринга, используя одну команду, отправленную на GPU. Эти команды рисования обычно называются вызовами рисования. Allegro рисует спрайты, используя 6 вершин, и переносит их в C выделенный буфер. Всякий раз, когда заканчивается пакет, он передается в функцию рисования OpenGL или DirectX, которая копирует ее (чтобы не останавливать процессор) и отправлять вызов рисования.

Это выглядит довольно разумно, но мы не можем сделать то же самое, потому что в DirectX 10 нет функций для прямого рисования с C-массивов, и обязательно использовать вершинные буферы. Таким образом, наша первая версия создала буфер вершин, для которого текущая партия всегда копировалась для использования в вызове рисования, и мы перераспределили бы буфер с большим размером, если текущая партия не подходит. Он работал довольно хорошо, вероятно, не так быстро, как версия Allegro, и он заметно отставал всякий раз, когда нужно было изменить размер буфера вершин.

После прочтения некоторых статей, например, оптимизации рендеринга в Galactic Civilizations 3 и потоковой передачи буфера на OpenGL (что было очень полезно), стало ясно, что путь заключается в том, чтобы иметь вершинный буфер фиксированного размера и продолжать добавлять в него пока он не будет заполнен. Когда мы закончим запись пакета в буфер, мы не сразу отправляем вызов рисования, мы пишем, где эта партия запускается и заканчивается в очередь, и продолжайте записывать в буфер. Когда буфер заполнен, мы удаляем его из системной памяти и отправляем сразу все очереди на очереди. Это экономит дорогостоящую операцию сопоставления и развязывания буфера вершин для каждой партии.

Поскольку мы пытались выяснить, как наиболее эффективно использовать данные в GPU, мы также экспериментировали с тем, какие данные отправлять на GPU. Чем меньше данных мы отправляем, тем лучше, и Аллегро использовал 6 вершин на спрайт с общим размером 144 байта. Мы хотели сделать точечные спрайты, которые потребуют всего 48 байт на спрайт и меньше общей математики для процессора для подготовки одного спрайта. Наша первая идея заключалась в том, чтобы использовать instancing, но мы быстро передумали, даже не пытаясь, потому что, исследуя метод, мы наткнулись на эту презентацию, специально предостерегая от использования instancing для объектов с низким количеством полигонов (например, спрайтов). Следующей идеей было внедрение точечных спрайтов с использованием геометрического шейдера.

Мы попробовали, и он отлично поработал. Мы получили некоторое ускорение из-за того, что ЦП должен был подготовить меньше данных, но при исследовании того, как разные API работают с геометрическими шейдерами, мы выяснили, что Metal (и, следовательно, MoltenVK) на macOS вообще не поддерживает геометрические шейдеры. После дальнейшего копания мы нашли статью под названием Почему геометрические шейдеры медленные. Поэтому мы протестировали использование геометрического шейдера на ряде ПК в офисе и обнаружили, что на ПК с новыми видеокартами было быстрее, более старые машины заметно снижали производительность. Из-за отсутствия поддержки macOS и возможного замедления работы на более медленных машинах мы решили отказаться от этой идеи.

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

Следующие результаты тестов относятся к различным компьютерам. Тест показал один кадр при максимальном уменьшении (около 25 000 спрайтов) в 600 раз быстрее, чем без обновления игры, а на графике показано среднее время подготовки и рендеринга кадра. На компьютерах с интегрированным графическим процессором было мало улучшений, потому что они, похоже, были узким местом для GPU.

новый и старый(темнее) рендеринг

Мы также заметили  ускорения на картах AMD по сравнению с картами nVidia. Например, на моем компьютере у меня есть GTX 1060 6GB и Radeon R7 360. В 0.16 рендеринг был намного медленнее на Radeon, чем на GeForce, но с новым рендерером производительность почти такая же (как и должно быть, потому что GPU заканчивает работа быстрее, чем процессор может подавать команды рисования). Затем нам нужно улучшить сторону GPU, в основном чрезмерное использование видеопамяти (VRAM), но больше на эту тему в некоторых будущих пятницах Факты …

Как всегда, дайте нам знать, что вы думаете на нашем форуме.


опубликовал  Klonan, Twinsen

Возможности мод портала (Klonan)

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

Модификация
Создательмода может отмечать мод как устаревший, что указывает на то, что они больше не обновляют или не поддерживают его. Типичный случай – мод добавляет что-то актуальное для текущей версии игры ( мод для сканирования стартовой площадки игроков), а затем обновление базовой игры делает мод устаревшим. Просто удаление мода может вызвать проблемы для людей, играющих в более старую версию, люди могут спросить, что с ним произошло.

Маркировка “устаревший” будет поддерживать модульность на портале, но она будет скрыта от любых общедоступных запросов. Таким образом, люди, загружающие с помощью функции «Синхронизация модов с сохранением», могут продолжать играть, в то время как новые игроки не будут спотыкаться на мод, который больше не является полезным или актуальным. Он также сохраняет загружаемые файлы и обсуждения в случае, если автор хочет возродить его позже.Читать далее


опубликовал kovarex

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

Текущая версия

Текущая версия библиотеки чертежей имеет несколько проблем:

  • Щелчок по чертежу в библиотеке чертежей означает создание плана почти всегда. Поэтому, если вы нажмете на чертеж схемы библиотеки, чтобы что-то построить, а затем нажмите клавишу Q, чтобы очистить курсор, он попадает в ваш инвентарь. Это может легко привести к случайным чертежам, медленно загромождающим ваш инвентарь, поскольку вы используете чертежи прямо из библиотеки чертежей время от времени.
  • Поскольку чертежи в игре и в библиотеке являются двумя отдельными вещами, игрокам необходимо вручную проверить, что версии чертежей обновлены. Когда вы играете в другие игры и используете библиотеку чертежей для совместного использования чертежей между ними, что является причиной его существования, естественно, что в конечном итоге вы получаете устаревшие версии чертежей в библиотеке, так как вы изменили их в предыдущей игре, но вы забыли обновить их в библиотеке. Кроме того, обновление библиотеки чертежей непросто, так как когда вы обновляете некоторые свои чертежи в игре, вам необходимо выполнить поиск соответствующего исходного чертежа в библиотеке, удалить его и перенести новую версию в библиотеку. Процесс, который раздражает, по крайней мере. Я считаю, что этот момент является самым тревожным, поскольку мы хотим, чтобы люди обновляли свои чертежи, когда они играют, а не просто бездумно копируют первую версию плана, который они добыли снова и снова.
  • Стандартный способ ввода нового чертежа в библиотеку чертежей просто помещает его в конец библиотеки чертежей, и удаление любого плана перемещает все под ним. Это означает, что некоторые чертежи постоянно меняют позиции и их трудно найти.
  • Когда новые игроки открывают возможность создания чертежей, они одновременно открывают для себя много вещей. Строительные роботы, чертежи и их создание, проектировщики деконструкции, книжки чертежей и библиотека чертежей. Чем проще (меньше) мы можем сделать этот шаг, тем лучше.
  • Другие неудобства для пользовательского интерфейса, такие как экспорт и импорт чертежей через непонятное окно «Бросьте сюда, чтобы переместить план».

Читать далее


Отчет о состоянии игры (Twinsen)

В понедельник, 18 июня, мы отметили, что последняя версия 0.16 является стабильной. Проблем больших не было, поэтому сейчас почти исключительно работаем на 0,17. Работа над 0,17 развивается хорошо:

  • Что касается новой кампании, мы уже тестируем сырую версию туториала для  игроков.
  • Мы по-прежнему пытаемся выяснить точный и окончательный стиль и концепции для улучшенного графического интерфейса, но у нас есть некоторые графические интерфейсы,  уже реализованные в игре, а также множество базовых виджетов. Мы используем их, чтобы понять, что работает, а что нет.
  • Переписывание нового графического интерфейса  близится к завершению. Закрытая бета была отправлена нескольким игрокам, чтобы проверить, что рендеринг работает правильно на разных аппаратных средствах. Рендеринг выполняется быстрее, и до сих пор не сообщалось о каких-либо серьезных проблемах. Но многое еще предстоит сделать, например, улучшения использования VRAM и много экспериментов с шейдерами.
  • Поскольку из отдела графики Альберт работает над графическим интерфейсом, а V453000 работает над новой кампанией, только Ernestas остается работать исключительно на графике объектов. Он перерабатывает еще несколько объектов для высокого разрешения, поэтому ожидайте некоторых тизеров в будущем.
  • Конечно, существуют и другие небольшие проекты, которые продолжаются, такие как улучшенная физика трубной жидкости и улучшенная генерация карт.

О, и наше кодирование всегда идет так, как планировалось, без каких-либо проблем.

Читать далее