Возможно я не прав, у меня не много опыта работы с dll. Но гугл выдал мне ряд нюансов:
1) у C++ нет стандартизованного ABI (бинарный интерфейс), следовательно dll на С++ могут не встать в других проектах (наверно получите undefined reference, но это не точно), и наверно там надо приводить все к стандарту С.
2) И возможно возникнут проблемы при переносе dll на другую платформу. Ну я никогда не видел чтобы dll использовали на Linux (нативно).
Хотя если прикладная библиотека полностью кроссплатформенна, то можно просто собрать несколько конфигураций - под каждую платформу.
Спасибо за ссылки на движки, посмотрю. Согласен, что каждый кадр отправлять вершинный буфер на gpu это дорого и надо это оптимизировать.
>dx12/Vulcan работают с команд буфферами, которые ещё и генерировать по хорошему нужно в многопотоке.
Почему комманд буферы надо генерировать в нескольких потоках? Я если честно вообще не понимаю преимуществ многопоточного рендеринга: окно для вывода одно, шина gpu/cpu одна. Везде будут сплошные критические секции, а отправлять на видеокарту все равно что-то нужно, пусть и не каждый кадр. Дк вот в чем преимущество, если там все равно записывает только один поток?
>Но мне не понятно, как это решит заявленную проблему обобщения апи
Наверно я тогда неправильно выразился, проблема не в том, как обобщить API. Проблема в том, как написать приложение, которое может существовать и работать под разными платформами и разными API и как при этом минимизировать свои усилия и кол-во написанного кода. Первое решение которое приходит в голову - сделать интерфейс над API (обобщить API) и использовать этот интерфейс во всей программе. И это сложное решение. И решение которое я предлагаю - вывернуть код наизнанку, засунуть код игры в библиотеку, сказать этой библиотеке какие массивы заполнять, где оставить свою информацию, а затем конкретное API возьмет оставленные игрой данные и нарисует. Это правда не решает проблему обобщения API, но позволяет портировать приложение в различные конфигурации не переписывая логику самого приложения.
1) SFML - не графический API, а оконный. В гитхабе просто представлено, что можно использовать различные конфигурации: GL/Vulkan + GLFW, GL/Vulkan + SFML, DirectX + WinAPI (пока не написал)
2) Проект на гитхабе просто модель программы, без всяких оптимизаций. Понятно, что не эффективно каждый кадр собирать заново этот вершинный буфер. Естественно тут нужна оптимизация, но я посчитал, что без нее будет более наглядно.
3) Исходники UnrealEngine это конечно хорошо, но еще поди разберись в них. Архитектура Unreal не такая прозрачная. Лично я две недели разбирался только с тем как там снять звук с Submix'а у AudioCapture, отправить этот звук в сокет, затем принять и воспроизвести. Эдакая система голосового чата. (Я не захотел использовать OnlineSubsystem, чтобы не привязываться к стиму и прочим сервисам. Возможно я сделал глупость). Понять как там устроен рендеринг это еще сложнее. Если ты в этом разбираешься, то я был бы рад прочитать объяснение как устроен рендеринг (поддержка всех API) в UnrealEngine.
>Если вы будете хранить его в классе, то мало того, что ответственность размажется, так оно еще и масштабироваться на потоки не будет.
Да, тут вы правы. Так будет лучше.
Спасибо за объяснение)
Возможно я не прав, у меня не много опыта работы с dll. Но гугл выдал мне ряд нюансов:
1) у C++ нет стандартизованного ABI (бинарный интерфейс), следовательно dll на С++ могут не встать в других проектах (наверно получите undefined reference, но это не точно), и наверно там надо приводить все к стандарту С.
2) И возможно возникнут проблемы при переносе dll на другую платформу. Ну я никогда не видел чтобы dll использовали на Linux (нативно).
Хотя если прикладная библиотека полностью кроссплатформенна, то можно просто собрать несколько конфигураций - под каждую платформу.
Спасибо за ссылки на движки, посмотрю. Согласен, что каждый кадр отправлять вершинный буфер на gpu это дорого и надо это оптимизировать.
>dx12/Vulcan работают с команд буфферами, которые ещё и генерировать по хорошему нужно в многопотоке.
Почему комманд буферы надо генерировать в нескольких потоках? Я если честно вообще не понимаю преимуществ многопоточного рендеринга: окно для вывода одно, шина gpu/cpu одна. Везде будут сплошные критические секции, а отправлять на видеокарту все равно что-то нужно, пусть и не каждый кадр. Дк вот в чем преимущество, если там все равно записывает только один поток?
Спасибо за комментарий)
>Но мне не понятно, как это решит заявленную проблему обобщения апи
Наверно я тогда неправильно выразился, проблема не в том, как обобщить API. Проблема в том, как написать приложение, которое может существовать и работать под разными платформами и разными API и как при этом минимизировать свои усилия и кол-во написанного кода. Первое решение которое приходит в голову - сделать интерфейс над API (обобщить API) и использовать этот интерфейс во всей программе. И это сложное решение. И решение которое я предлагаю - вывернуть код наизнанку, засунуть код игры в библиотеку, сказать этой библиотеке какие массивы заполнять, где оставить свою информацию, а затем конкретное API возьмет оставленные игрой данные и нарисует. Это правда не решает проблему обобщения API, но позволяет портировать приложение в различные конфигурации не переписывая логику самого приложения.
1) SFML - не графический API, а оконный. В гитхабе просто представлено, что можно использовать различные конфигурации: GL/Vulkan + GLFW, GL/Vulkan + SFML, DirectX + WinAPI (пока не написал)
2) Проект на гитхабе просто модель программы, без всяких оптимизаций. Понятно, что не эффективно каждый кадр собирать заново этот вершинный буфер. Естественно тут нужна оптимизация, но я посчитал, что без нее будет более наглядно.
3) Исходники UnrealEngine это конечно хорошо, но еще поди разберись в них. Архитектура Unreal не такая прозрачная. Лично я две недели разбирался только с тем как там снять звук с Submix'а у AudioCapture, отправить этот звук в сокет, затем принять и воспроизвести. Эдакая система голосового чата. (Я не захотел использовать OnlineSubsystem, чтобы не привязываться к стиму и прочим сервисам. Возможно я сделал глупость). Понять как там устроен рендеринг это еще сложнее. Если ты в этом разбираешься, то я был бы рад прочитать объяснение как устроен рендеринг (поддержка всех API) в UnrealEngine.