1.3. Starling이 뭐죠?

Starling Framework를 사용하면 ActionScript 3에서 하드웨어 가속 응용 프로그램을 만들 수 있습니다. 주요 목표는 2D 게임을 만드는 것이지만 Starling은 모든 그래픽 응용 프로그램에 사용될 수 있습니다. Adobe AIR 덕분에 Starling 기반 응용 프로그램은 모든 주요 모바일 및 데스크탑 플랫폼에 배포할 수 있습니다.

그림 1. 이 빨간 작은 친구는 Starling Framework의 로고입니다.

Starling은 Adobe AIR / Flash의 클래식 디스플레이 리스트 아키텍처를 모방하지만 훨씬 뛰어난 성능을 제공합니다. 모든 객체는 GPU에서 직접 렌더링됩니다 (Stage3D API 사용). 전체 아키텍처는 GPU와 잘 작동하도록 설계되었는데요. 이것은 일반적인 게임 개발 작업의 핵심 요소입니다. Starling은 Stage3D 내부를 개발자에게 숨기지만 완전한 성능과 유연성이 필요한 사람들을 위해 Stage3D 내부에 쉽게 액세스할 수 있게 해줍니다.

1.3.1. 다른 디스플레이 API가 필요한 이유는 무엇입니까?

위에 요약된대로 Starling의 API는 기본 Flash API와 매우 유사합니다. 즉: flash.display 패키지. 그래서 여러분은 묻습니다: 왜 플래시 내부에서 플래시를 개선하려는 모든 노력을 기울이지 않지 ... 플래시가 잘못 되었습니까?

그 이유는 유연한 디스플레이 리스트, 벡터 기능, 텍스트 렌더링, 필터 및 기타가 포함된 원래의 flash.display API가 데스크톱 컴퓨터 시대에 설계 되었기 때문입니다. 이 컴퓨터는 강력한 CPU를 갖추고 있었지만 (현대 표준에 따라) 원시적이고 고정 논리 그래픽 하드웨어를 사용했습니다. 반면 오늘날의 모바일 하드웨어는 거의 반대의 설정을 가지고 있습니다: 매우 진보된 그래픽 칩을 가진 약한 (배터리 절약형) CPU.

문제점: 순수 CPU 렌더링을 위해 설계된 API를 갑자기 GPU를 효율적으로 사용하도록 변경하는 것은 (불가능하지는 않지만) 매우 어렵습니다.[2] 따라서 이러한 시도는 크게 실패했으며 플래시 플러그인은 요즘 휴대 전화와 태블릿의 브라우저에서 완전히 사라졌습니다.

Adobe는 이 문제에 대해 매우 잘 알고 있었습니다. 그래서 2011년에 Stage3D라는 저수준 그래픽 API를 도입했습니다. 그 API는 확실히 로우 레벨입니다; 이것은 기본적으로 OpenGL과 DirectX의 래퍼입니다. 개발자는 GPU의 순수 파워(raw power)에 액세스할 수 있습니다.

문제점: 그러한 낮은 수준의 API는 고전적인 디스플레이 리스트의 사용자에게 당장은 도움이 되지 못했습니다. Stage3D API는 로우 레벨이기 때문에 일반 개발자가 앱이나 게임을 만들 때 직접 작업할 수있는 것은 아닙니다.[3] 분명히 Adobe는 Stage3D 위에 구축된 더 높은 수준의 flash.display 같은 API가 필요했습니다.

흠 …​ 이것이 Starling이 무대(stage 객체를 비유함)에 들어선 이유죠 (말장난)! Starling은 가능한 한 많이 고전적인 Flash API를 모방하면서 Stage3D에 맞게 설계되었습니다. 이를 이용하면 무수한 개발자가 익숙한 개념을 사용하면서 오늘날의 강력한 그래픽 하드웨어를 최대한 활용할 수 있습니다.

물론 Adobe는 그러한 API를 직접 만들 수 있었습니다. 그러나 대기업이 만든 모놀리식 API는 크고 유연성이 없는 경향이 있습니다. 반면에 동등한 개발자 커뮤니티가 제공하는 소규모 오픈 소스 프로젝트는 훨씬 신속하게 행동할 수 있습니다. 이는 2011년 Flash 및 AIR 플랫폼의 제품 관리자인 Thibault Imbert가 Starling 프로젝트를 시작해야겠다는 통찰력을 갖게 했습니다.

현재까지는 Adobe에서 후원과 지원을 받고 있습니다.

1.3.2. Starling의 철학

Starling의 핵심 목표 중 하나는 가능한 한 가볍고 사용하기 쉽도록 만드는 것이었습니다. 필자가 생각하기에 오픈 소스 라이브러리는 사용하기 쉽고 — 또한 코드에 푹 빠지도록 용기를 북돋워야 합니다. 나는 개발자들이 보여지는 씬 뒤에서 무슨 일이 벌어지고 있는지 이해할 수 있기를 바랍니다. 그런 다음에는 자신의 필요에 완벽하게 맞을 때까지 확장하고 수정할 수 있어야 합니다.

이것이 바로 Starling의 소스가 잘 정리되어 있고 놀랍도록 간결한 이유입니다. 약 15k 라인 크기로 작성된 코드는 대부분의 게임보다 작을 것입니다!

정말 강조하고 싶습니다. 언젠가 코드가 예상대로 작동하지 않는 이유나 언젠가 멈추거나 혼란스럽다면 Starling의 소스 코드를 뜯어보는 것을 주저하지 마십시오. 종종 잘못된 점을 빠르게 파악하고 내부에 대해 더 잘 이해하게 될 것입니다.

Starling의 또 다른 중요한 목표는 물론 디스플레이 리스트 아키텍처와의 친밀성입니다. 디스플레이 리스트 뒤에 있는 전체 아이디어가 정말 마음에 든다는 것 뿐만 아니라 개발자가 Starling으로 쉽게 전환 할 수 있기 때문입니다.

그럼에도 불구하고, 필자는 절대로 완벽한 복제본을 만들려고 시도하지 않았습니다. GPU를 타깃으로 하는 것은 특정한 개념을 필요로 하며 이를 통해 빛나야 합니다! Textures, Meshes와 같은 개념은 마치 GPU 용으로 항상 설계된 것처럼 원래 API와 완벽하게 조화를 이루고자 합니다.