Ответы пользователя по тегу DirectX
  • Как начать программировать с использованием DirectX?

    @MarkusD Куратор тега C++
    все время мелю чепуху :)
    ISBN 978-1-56881-720-0
    Jason Zink, Matt Pettineo, Jack Hoxley: "Practical rendering and computation with Direct3D 11".

    На русском книги нет. Книга легко читается и в оригинале. Уже с первых глав дает понимание современного пайплайна графики, стадий инициализации систем DirectX 11, способов загрузки и представления в памяти требуемых для отрисовки данных. В книге хорошо описан и язык HLSL.
    Книга хорошо подходит для холодного старта в работе с DirectX 11.
    Ответ написан
    Комментировать
  • Каким образом одна и та же игра может рендериться за счёт разных графических библиотек?

    @MarkusD
    все время мелю чепуху :)
    Любой GAPI является инструментом прикладного уровня, который инженер может встроить в свой код с целью пользоваться его возможностями. Прямое использование любого API является примером тесной интеграции кода программы с кодом целевой платформы.
    Целевой платформой является аппаратно-программный комплекс, на котором планируется запускать разрабатываемый код. Целевой может быть Sony Playstation, ПК с виндой, Мак или мобила с Андроидом.

    Код с тесной интеграцией целевых API нередко пропитан их общей "атмосферой". Это выражается в стиле кода, в общих конструкциях, в заточенности кода проекта на использование совместно с конкретными API.
    Использующий DirectX8 код не так просто перевести на использование DirectX9, еще сложнее перевести на использование DirectX10/11 или DirectX12. Код с использованием OpenGL1.1 тяжело поддается модификации для использования OpenGL2.0, 3.0 или дальше. Любая кодовая база с тесной интеграцией DirectX/OpenGL очень тяжело переводится на Vulkan, Metal или профильные GAPI некоторых закрытых целевых платформ.

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

    В задачах кроссплатформенности решающую роль играет знание архитектуры П.О. Потому что кроссплатформенность требует разработать агностический слой, под которым будет находиться настраиваемая связь с целевым API. Когда речь идет о системных API целевых платформ, агностический слой представляет из себя фасад универсальной операционной системы. Когда речь идет о GAPI, агностический слой представляет собой API для универсального GPU. Когда речь идет о звуке, агностический слой представляется универсальной звуковой системой.
    Без всеобъемлющего знания архитектуры П.О. такие инструменты разработать крайне сложно. Без глубокой экспертизы во всех целевых API и целевых платформах разработать такой слой возможным не представляется. Без экспертных знаний используемых в разработке языков построение кроссплатформенного кода выливается в не распутываемый клубок взаимопереплетающихся проблем, решение каждой из которых на одной платформе гарантированно сломает поддержку другой.
    Я об этом пишу потому что знаю множество подходов к решению задач разработки кроссплатформенного кода. Я сталкивался с подходами которые не решают задачу кроссплатформенности и знаю пути более эффективного решения этих задач для конкретных случаев в конкретных проектах.

    Когда агностический слой выведен, весь кроссплатформенный код пользуется только им. Под агностическим слоем, тем или иным способом, весь код сводится к использованию целевого API.
    Таким образом, для того чтобы позволить игре рендериться и через DirectX, и через OpenGL, и через Vulkan, нужно в движке игры разработать универсальный внутренний GAPI, вызовы которого будут передаваться в выбранный пользователем целевой GAPI. Форматы данных, ресурсы и шейдеры, при этом, ровно так же выбираются исходя из выбранного пользователем целевого GAPI и могут пересекаться между разными GAPI.
    Те же шейдеры сегодня спокойно транслируются из HLSL в GLSL или SPIR-V специальными трансляторами. Геометрия может быть одинакова, форматы текстур на целевой платформе между всеми GAPI, как правило, одинаковы.
    Дело остается только за грамотной разработкой своего маленького виртуального GPU.
    Ответ написан
    Комментировать
  • Что выбрать для освоения DirectX - UWP или Win32 API?

    @MarkusD Куратор тега C++
    все время мелю чепуху :)
    Microsoft UWP является надстройкой для создания универсальных приложений, которые, в теории, должны легко переноситься между различными аппаратными слоями платформы Windows. UWP поддерживается только в Win10, реализована на базе расширения C++/CX стандарта C++17 и выполна преимущественно в объектном стиле.

    Windows API является низкоуровневым слоем взаимодействия между приложением и операционной системой. Win32 API поддерживается всеми версиями Windows, начиная с Windows 95. Однако, разные версии Windows поддерживают разные наборы функций. Поэтому уровень поддержки той или иной функции из набора API всегда следует уточнять в документации. Реализован Win32 API на языке C стандарта C99 и выполнен в процедурном стиле.

    Данная информация создает ряд допущений и ограничений для использования как UWP, так и WinAPI. Исходя из требований проекта и опираясь как на допущения, так и на ограничения, можно вывести однозначное решение о выборе только одной из этих двух технологий.

    C++/CX является расширением стандарта и не поддерживается другими платформами, а так же всеми компиляторами кроме компилятора Microsoft. При этом, существуют такие условия, когда отказаться от использования C++/CX и UWP невозможно. В иных ситуациях следует принимать к сведению особый синтаксис расширения и объектную организацию. Скажем, я бы не стал полностью весь проект делать на базе C++/CX.

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

    В любом случае, выбрав UWP или WinAPI, дальше тебе все равно лучше работать исключительно со стандартным C++ и стандартной реализацией DirctX для C++. От C++/CX стоит избавляться на как можно ранних слоях абстракции палатформозависимого кода. От типов и абстракций WInAPI, равно как и от наследия C99, тоже лучше избавляться как можно раньше и переходить на работу исключительно со стандартным C++.
    Ответ написан
    1 комментарий
  • Как создается единая физическая-графическая модель?

    @MarkusD Куратор тега C++
    все время мелю чепуху :)
    И почему крупные компании не могут реализовать свою такую технологию, а покупают ее у других?

    Ответ будет таков
    5a2b8fc21c685856187802.jpeg

    Если компания крута, она, как мыслящий организм, прекрасно поймет, на что время тратить разумно, а на что - нет.

    А почему так мало игр ее использует?

    Скажем прямо, с "еще парой игр" ты слегка промахнулся, ведь Morpheme и Euphoria от Natural Motion используется далеко не в паре просто игр. Полный список игр не раскрывается и не может быть раскрыт по простым причинам своей масштабности. Это очень распространенный и очень мощный инструмент.

    Теперь стал интерисовать вопрос - как прикрутить к этому всему физику.

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

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

    Тебе стоит представить сцену как набор параллельных пространств. Одно пространство ты видишь. Другое - можешь только потрогать. Третье пространство лишь ощущается как набор сил, действующих на тебя. Есть еще много таких пространств, некоторые из них и вовсе недоступны для нормального представления.
    Пространство анимаций никак не связано с графическим пространством, но косвенно влияет на деформации объекта в графическом пространстве. Все дело в том, что и пространств анимации может быть несколько. Физическое пространство может оказывать влияние на анимации, эту связь лучше выделить в отдельное пространство со своими правилами.
    Все пространства наделяют объект своими свойствами благодаря работе мат. модели мира.

    Более подробно можно узнать в соответствующих источниках. Нужна секция: "Game engine development".
    Часть этих книг есть в русском переводе.
    Ответ написан
    Комментировать
  • Что такое анимация и с чем ее кушать если OpenGL?

    @MarkusD Куратор тега C++
    все время мелю чепуху :)
    Spine C runtime.
    https://github.com/EsotericSoftware/spine-runtimes...
    Это не серебряная пуля и не идеальные практики. Пожалуй, в плане кода это пример наоборот, как код писать точно не надо.
    Но вот в плане реализации анимаций эта репка тебе очень поможет.

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

    С помощью SRT таймлайнов можно анимировать объекты в пространстве целиком, но если тебе захочется точно так же анимировать части меша модели, то впереди тебя будут ждать трудности.
    Анимацию меша лучше реализовать на основе скелета. Это дело в двух словах уже не описать, тут лучше читать статьи.
    www.gamedev.ru/code/terms/SkeletalAnim
    www.gamedev.ru/code/articles/skeletal_animation
    https://habrahabr.ru/post/219509/
    https://habrahabr.ru/post/304042/
    www.gamedev.ru/code/articles/?id=4182

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

    Только на одной скелетной анимации далеко все равно не уедешь. Когда требуется на одной модели одновременно задействовать сразу несколько скелетных анимаций, если сделать в лоб, то меш поплывет во все стороны.
    Для смешивания различных скелетных анимаций применяют так называемые Blend Trees (ссылок под рукой нету, так что сорри).

    В общем, как то так анимация выглядит. Анимируем в цикле обновления, вершины трансформируем в момент формирования кадра. OGL нам нужен, собственно, чтобы нарисовать раскоряченый анимацией меш.
    OGL для непосредственного анимирования мешей тебе понадобится только тогда, когда ты достаточно глубоко нырнешь в анимации, в тот же момент ты уже полностью поймешь что от OGL понадобится для этого.
    Ответ написан
    2 комментария