В чем причина sf :: Sprites, владеющая своим положением и вращением? Это запутывает мой компонент/Entity/System

Question

Я делаю базовую реализацию астероидов, использующих SFML в C++, для практики с использованием инфраструктуры компонента-сущности.

Концептуально это имеет смысл для объектов, таких как корабль игрока, плавающих астероидов и т. Д., Для обмена общими «компонентами», такими как графический компонент, компонент скорости и ориентационный/позиционный компонент. Это сохраняет самостоятельность и имеет целый ряд преимуществ.

Однако, в SFML, спрайты отображаются в фиксированном положении, о котором только знают! Это немедленно означает, что мой графический компонент и компонент ориентации/позиционирования должны быть объединены или должны знать друг о друге, что противоречит всей идее подхода, основанного на компоненте-сущности. В SDL, с другой стороны, вы можете легко превратить текстуру в отдельный прямоугольник, построенный из любого места.

Мой вопрос таков: должны быть некоторые конкретные аргументы в пользу того, почему Sprites в SFML зависают на их собственной позиционной информации - что это такое? Возможно, если бы я понял это лучше, я мог бы составить хорошее решение.

Answer 1

Класс sf::Sprite в основном предназначен для быстрого способа рисования спрайтов простым в использовании способом.

Они не всегда являются лучшими для более продвинутых случаев использования, главным образом потому, что они довольно медленные (поскольку они не откупорены).

sf::Sprite предназначен, в первую очередь, для тех, кто хочет получить спрайт на экране, не беспокоясь о деталях реализации (как и другие sf::Drawable производные классы).

Вместо этого вы должны реализовать свой собственный привлекательный или визуальный компонент, который сохраняет цвет, текстуру и координату UV. Mabye что-то вроде этого:

struct DrawableComponent { 
    sf::Color color; 
    sf::Texture *texture; 
    sf::IntRect uv; 
} 

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

Затем, рисуя, перебирайте все объекты с той же текстурой, которые можно выставить, и поместите их вершины в std::vector или sf::VertexArray и используйте их для быстрого рендеринга.

Answer 2

SFML следует объектно-ориентированному дизайну. A sf::Sprite моделирует видимую вещь, которая имеет текстуру и преобразование. Таким образом, как обычно в OOD, он содержит оба этих атрибута.

Это прямо противоречит дизайну ECS, который стремится превратить это наизнанку из-за отсутствия сущности на чем-либо. Вы действительно не сможете интегрировать класс sf::Sprite в свой дизайн - это принципиально несовместимо. Лучшее, что вы можете сделать, это создать временный sf::Sprite во время отображения, когда вы собрали все необходимые данные.

Что касается SDL ... Ну, в отличие от SFML, это всего лишь графический API с низким уровнем Иш (среди прочих). Он не пытается ничего моделировать: возьмите текстуру, похлопайте ее по фреймбуферу, вот и все. Два очень разных инструмента для самых разных целей.