Должна ли каждая текстура иметь свой собственный рендерер в SDL? - PullRequest
0 голосов
/ 31 мая 2018

Я пытаюсь изучить SDL2 и испытываю трудности с практической точки зрения.Я чувствую, что у меня есть хорошее понимание окон SDL, средств визуализации и текстур с абстрактной точки зрения.Тем не менее, я чувствую, что мне нужно больше знать о том, что происходит под капотом, чтобы правильно их использовать.

Например, при создании текстуры мне необходимо предоставить ссылку на средство визуализации.Я нахожу это странным.Текстура выглядит так, как будто это ресурс, который загружается в VRAM.Зачем мне нужно давать ресурсу ссылку на рендерер?Я понимаю, почему было бы необходимо дать рендереру ссылку на текстуру, однако, наоборот, это не имеет никакого смысла.

Так что это приводит к другому вопросу.Поскольку каждая текстура требует рендерера, должна ли каждая текстура иметь свой собственный рендерер, или несколько текстур имеют общий рендерер?

Я чувствую, что есть последствия перехода одного маршрута против другого.

1 Ответ

0 голосов
/ 31 мая 2018

Короткие ответы

Я полагаю, причина, по которой SDL_Texture требует рендерера, заключается в том, что некоторые реализации бэкэнда (OpenGL?) Имеют контексты (это, по сути, SDL_Renderer), и данные изображений должны быть связаны сконкретный контекст.Вы не можете использовать текстуру, созданную в одном контексте внутри другого.

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


Как правильно указывает @keltar, никто из рендерера не будет работать с текстурой, созданной с помощью другого рендерера.из-за регистрации в SDL_RenderCopy.Тем не менее, это строго требование API для обеспечения согласованности. Выше я хотел бы подчеркнуть, что даже если бы эта проверка отсутствовала, она не работала бы для бэкэндов, таких как OpenGL, но нет технической причины, по которой она не будет работать для средства визуализации программного обеспечения..


Некоторые сведения о SDL_Renderer

Помните, что SDL_Renderer - это абстрактный интерфейс для нескольких возможных бэкэндов (OpenGL, OpenGLES, D3D, Metal, Software, и т. Д.).Каждый из них, возможно, будет иметь ограничения на совместное использование данных между контекстами, и поэтому SDL должен ограничивать себя таким же образом, чтобы поддерживать здравый смысл.

Пример ограничений OpenGL

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

Как видно на этой странице, у обмена между контекстами есть ограничения.

  1. Совместное использование может происходить только в той же реализации OpenGL

Это означает, что вы, безусловно, не можете делиться между SDL_Renderer, использующим OpenGL, и другим SDL_Renderer, использующим другой бэкэнд.

Вы можете обмениваться данными между различными контекстами OpenGL ... Это делается с помощью специфических для ОС расширений

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

каждый дополнительный контекст рендеринга оказывает существенное влияние на производительность приложений

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

Заключительное примечание: «S» в SDL означает «простой».Если вам нужно обмениваться данными между контекстами, SDL - просто неправильный инструмент для работы.

...