답변:
몇 가지 고려 사항 :
언급했듯이 각 스프라이트는 사용할 비트 맵을 "힌트"해야하지만 엔터티가 자체 렌더링해야하는 경우입니다. '힌트'는 무엇입니까? 각 스프라이트에 대해 다른 비트 맵, 스프라이트 시트 등을 참조하는 경우 필요 이상의 메모리를 사용하거나 해당 메모리를 관리하는 데 문제가있을 수 있습니다. 별도의 렌더러의 장점은 자산 관리를 담당하는 클래스가 하나뿐이라는 것입니다. SF2와 같은 격투 게임에서는 두 개의 스프라이트 만 가질 수 있습니다.)
다른 곳에서 언급했듯이 그래픽 API를 변경할 때마다 모든 스프라이트의 코드를 변경해야합니다.
일부 그래픽 컨텍스트에 대한 참조없이 렌더링은 거의 수행되지 않습니다. 따라서이 개념을 나타내는 전역 변수가 있거나 각 스프라이트에는 render (GraphicalContext ctx) 인터페이스가 있습니다. 그래픽 API와 게임의 논리 (일부 사람들이 부적절하다고 생각하는 논리)를 혼합하여 컴파일 문제를 일으킬 수 있습니다.
필자는 개인적으로 렌더링을 개별 엔티티에서 분리하는 것이 그래픽을 전혀 필요로하지 않는 시스템으로 게임을 보는 방향에서 흥미로운 첫 번째 단계라는 것을 알고 있습니다. 내 말은 렌더링을 방해 할 때 엔터티, 내부 상태 등의 좌표가 중요한 "그래픽이 아닌 세계"에서 많은 게임 플레이가 발생한다는 것을 깨닫게됩니다. 이것은 자동화 된 테스트, 더 많은 분리 된 시스템 등의 문을 엽니 다.
대체로 렌더링이 별도의 클래스에 의해 수행되는 시스템을 선호하는 경향이 있습니다. 그렇다고해서 렌더러를보다 쉽게 작성하거나 더 효율적으로 만들 수있는 경우 스프라이트에 "그래픽 관련"(애니메이션 이름, 애니메이션 프레임, 높이 x 너비, 스프라이트 ID 등) 속성을 가질 수는 없습니다.
그리고 이것이 3D에 적용되는지 알지 못합니다 (메시 개념과 사용하는 좌표 변수가 3D API와 관련이있을 것입니다 .x, y, h, w는 2D와 거의 무관합니다) API).
도움이되기를 바랍니다.
렌더링 시스템이 언제 그려지는 것을 제어하기를 원합니다. 대신 스프라이트가 렌더링을 제어하는 경우 많은 효율성 향상과 유연성을 잃게됩니다. 제어 시스템에 렌더링 시스템을 사용하면 코드가 깨끗해진다는 의견이 있습니다.
중앙 집중식 렌더링의 몇 가지 장점 :
게임에서 이것을 구현하는 방법은 게임 오브젝트가 렌더링 시스템으로 그린 스프라이트를 등록하도록합니다. 오브젝트가 더 이상 오브젝트를 그리 길 원하지 않으면 스프라이트를 등록 해제하거나 비활성 상태로 표시합니다.
그게 다야 게임 오브젝트를 스스로 렌더링하는 것이 더 쉬운 경우에는 반드시 그렇게하십시오. 완벽한 아키텍처를 구축하는 것보다 발전하고 무언가를 끌어내는 것이 훨씬 중요합니다.
면책 조항 : 귀하의 질문에 자세한 내용이 없으므로 일반적인 원칙으로 답변하고 있습니다. 내가 당신의 사용 또는 '렌더링'을 오해 한 경우 실례합니다.
나는 일반적으로 외부 객체를 사용하여 장면의 다양한 액터를 개별 '액터 객체'외부의 장면 레벨 속성 및 메소드를 캡슐화하는 방법으로 렌더링합니다. 장면의 오브젝트는 내부 메소드와 속성 만 포함해야합니다. 그들은 자신이 무엇이며 무엇을하는지 알아야합니다. 아마도 사용자 입력뿐만 아니라 게임의 다른 개체의 영향을받을 것입니다. 이것은 화면에서 렌더링 방법에 따라 달라집니다. 예를 들어 '디렉터 객체'는 'w'키를 눌러 점프 한 다음 액터 객체에 .jump ()를 알려줍니다. 이러한 디렉터 레벨 로직은 액터에게 장면에 완전히 들어가거나 나가도록 지시 할 수도 있습니다.
건배, 데이비드
언젠가 게임을 다른 해상도 (예 : iPhone 및 친구)로 이식하려면 어떻게해야합니까? 따라서 변경 사항 렌더링에 대한 전역 속성, 코드를 쉽게 업데이트하는 방법은 무엇입니까?
내가 사용한 것은 관찰자 기반 디자인이었습니다. 클래스의 인스턴스를 만들 때 렌더링하고 싶었고 포인터를 중앙 렌더러 클래스에 저장했습니다. 을 호출 RenderFrame()하면 렌더러에는 이미 렌더링해야하는 기존 객체가 모두 있고 속성에 액세스하여이를 수행합니다. 수업 자체는 전혀 렌더링 될지 몰랐습니다. 이 API는 훌륭하고 깨끗하며 사용하기 쉽습니다.
일반적으로 코드를 유지하고 확장하는 것이 얼마나 쉬운 지 항상 중요합니다. 내일은 현재 사용중인 그래픽 API가 마음에 들지 않고 전환하고 싶다는 것을 알았습니다. 이제 모든 객체 클래스를 살펴보고 모든 것을 변경해야합니까, 아니면 여전히 프로젝트의 한 중심점에서 코드를 변경해야합니까?
render ()를 호출 할 때 객체가 실제로 수행하는 작업에 따라 다릅니다. 그들이 그래픽 엔진 주위에 메소드 호출을 감싸는 한, 논리 <-> 그래픽 구별이 여전히 주어지기 때문에 완전히 괜찮습니다.
예를 들어, render () 메소드가 기본적으로 편리한 메소드이고 다음과 같은 경우 :
void MyClass::render(const Graphics &g)
{
g.draw(this);
}또는
void MyClass::render()
{
mySprite->render();
}또는
void MyClass::render()
{
mySprite->UseShader(thatshader);
mySprite->render();
}또는 그와 가까운 곳에서는 그것이 문제라고 생각하지 않습니다.