Кроссплатформенный графический API низкого уровня

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

Принимая во внимание различные современные (без конвейера с фиксированной функцией) интерфейсы графических интерфейсов: OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM

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

10 голосов | спросил NocturnDragon 18 J000000Sunday10 2010, 19:30:49

5 ответов


6

Самый низкий уровень, который имеет смысл с моей точки зрения, - это то, что говорит о ресурсах, участвующих в рендеринге - vb /ib, визуализации поверхностей, текстур, шейдеров, государственных блоков и т. д.

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

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

(Sidenote: если вы рассматриваете трюки, специфичные для платформы, как особый вид ресурса, вы можете продвигать эту концепцию довольно далеко.)

Таким образом, вы создадите две вещи: диспетчер аппаратного ресурса, а также набор инструментов для создания DAG этих ресурсов.

ответил Rachel Blum 19 J000000Monday10 2010, 08:26:38
10

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

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

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

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

ответил Jason Kozak 19 J000000Monday10 2010, 01:09:42
1

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

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

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

ответил Sean James 19 J000000Monday10 2010, 00:21:29
0

Об этом читает статья о GPU Pro, Эмиль Перссон (Humus)

http: //gpupro.blogspot. ком /2009/12 /сделать-это большой красивый-быстро-and.html

  

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

ответил NocturnDragon 19 J000000Monday10 2010, 10:34:03
-4

Возможно, вы захотите проверить библиотеку SDL или Allegro . Обе из них - низкоуровневые, очень портативные библиотеки игр, которые могут подключить их в контексте OpenGL, чтобы вы могли визуализировать свою графику. SDL славится тем, что он использует неработающие игры Loki для портирования некоторых популярных игр с 2000-х годов на Linux, и у Allegro много времени, и у него отличное сообщество разработчиков любительских игр.

ответил chiguire 18 J000000Sunday10 2010, 23:27:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132