2.1. Starling 구성

모든 Starling 구동 응용 프로그램의 첫 번째 단계: Starling 클래스 (starling.core 패키지)의 인스턴스 만들기. 다음은 Starling의 생성자에 대한 전체 선언 구문입니다:

public function Starling(
    rootClass:Class,
    stage:Stage,
    viewPort:Rectangle = null,
    stage3D:Stage3D = null,
    renderMode:String = auto,
    profile:Object = auto);

rootClass

Stage3D가 초기화를 완료하자마자 인스턴스화 되는 클래스입니다. starling.display.DisplayObject의 서브 클래스여야 합니다.

stage

Starling의 콘텐츠를 호스팅할 전통적인 Flash 스테이지 객체. Starling과 플래시 디스플레이 리스트를 서로 연결하기 위해 필요합니다.

viewPort

Starling에서 렌더링할 플래시 스테이지 내의 영역입니다. 전체 스테이지 크기인 경우가 많으므로 이 매개 변수를 생략 (즉 null을 전달)하여 전체 영역을 사용할 수 있습니다.

stage3D

렌더링에 사용되는 Stage3D 인스턴스입니다. 각 플래시 스테이지에는 여러 Stage3D 인스턴스가 포함될 수 있으며 그 중 하나를 선택할 수 있습니다. 그러나 대부분의 경우 기본 매개 변수 (null)로 충분합니다. Starling에서는 사용 가능한 첫 번째 Stage3D 객체를 사용하게 됩니다.

renderMode

Stage3D의 모든 아이디어는 하드웨어 가속 렌더링을 제공하는 것입니다. 그러나 소프트웨어 폴백 모드도 있습니다. Context3DRenderMode.SOFTWARE를 전달하여 강제 실행될 수 있습니다. 그러나 기본 (자동)을 권장합니다. 소프트웨어 렌더링은 대안이 없을 때만 사용하는게 좋습니다.

profile

Stage3D는 (Context3DProfile 내에서 상수로 정의) 다른 프로필로 그룹화하는 기능 세트를 제공합니다. 응용 프로그램이 실행되는 하드웨어가 좋을수록 더 좋은 프로파일이 가능합니다. 기본값 (자동)은 사용 가능한 최상의 프로파일을 선택합니다.

이러한 인수의 대부분은 유용한 기본값을 가지므로 모든 값을 지정할 필요는 없을 것입니다. 아래 코드는 Starling을 시작하는 가장 간단한 방법을 보여줍니다. Flash Player 또는 AIR 프로젝트의 Main 클래스를 보시죠:

package
{
    import flash.display.Sprite;
    import starling.core.Starling;

    [SWF(width="640", height="480",
         backgroundColor="#808080",
         frameRate="60")]
    public class Main extends Sprite
    {
        private var _starling:Starling;

        public function Main()
        {
            _starling = new Starling(Game, stage);
            _starling.start();
        }
    }
}

위 클래스는 Starling 변형이 아닌 flash.display.Sprite를 확장합니다. 이는 AS3의 모든 기본 클래스의 필수 요소입니다. 그러나 Starling이 시작되면 바로 로직이 Game 클래스로 옮겨져 starling.display 세계에 대한 링크가 만들어집니다.

프레임 속도(Frame Rate) 구성

일부 설정은 클래스 앞에 있는 "SWF" 메타 데이터 태그에서 바로 구성됩니다. 프레임 속도는 그 중 하나입니다. Starling 자체에는 동일한 설정이 없습니다. 항상 기본 스테이지의 frameRate를 사용합니다. 런타임시에 변경하려면 nativeStage 속성에 액세스하십시오.

Starling.current.nativeStage.frameRate = 60;

Starling의 설정 프로세스는 비동기식입니다. 즉, Main 메서드가 끝났다고 해서 아직 Game 인스턴스에 액세스할 수는 없습니다. 그러나 ROOT_CREATED 이벤트를 수신하여 클래스가 인스턴스화 될 때 알림을 받을 수 있습니다:

public function Main()
{
    _starling = new Starling(Game, stage);
    _starling.addEventListener(Event.ROOT_CREATED, onRootCreated);
    _starling.start();
}

private function onRootCreated(event:Event, root:Game):void
{
    root.start(); // 'Game' 클래스에서 'start'를 정의해야 합니다.
}

2.1.1. 뷰포트(ViewPort)

Stage3D는 Starling에 그릴 직사각형 영역을 제공합니다. 이 영역은 원래 스테이지의 아무 곳이나 될 수 있습니다. 즉 Flash Player 또는 응용 프로그램 창의 영역 (AIR 프로젝트의 경우) 내의 모든 위치를 의미합니다.

Starling에서는 해당 영역을 viewPort라고 합니다. 대부분의 경우 사용 가능한 영역을 모두 사용하고자 하지만 렌더링을 특정 영역으로 제한하는 것이 좋습니다.

16 : 9 화면에서 실행되는 종횡비가 4 : 3으로 설계된 게임을 생각해보십시오. 화면에 4 : 3 뷰포트를 중앙에 배치하면 상단과 하단에 검정색 막대가 있는 "레터 박스된(letterboxed)" 게임이 만들어집니다.

Starling의 스테이지를 보지 않고서는 viewPort에 대해 이야기 할 수는 없습니다. 기본적으로 스테이지는 viewPort와 정확히 동일한 크기입니다. 이는 물론 많은 의미가 있습니다. 디스플레이 크기가 1024 x 768 픽셀인 장치는 동일한 크기의 스테이지를 가져야 합니다.

그러나 스테이지 크기를 사용자 정의할 수 있습니다. stage.stageWidth 및 stage.stageHeight 속성을 통해 가능합니다:

stage.stageWidth = 1024;
stage.stageHeight = 768;

근데 잠깐만요, 그것은 심지어 무엇을 의미합니까? 현재 드로잉 영역의 크기가 viewPort 또는 스테이지 크기로 정의되어 있습니까?

걱정하지 마십시오. 해당 영역은 위에서 설명한대로 viewPort에 의해서만 설정됩니다. stageWidth 및 stageHeight를 수정해도 드로잉 영역의 크기가 전혀 변경되지 않습니다; 스테이지는 항상 전체 viewPort에 걸쳐 펼쳐집니다. 하지만 변화하는 것은 무대의 좌표계 크기입니다.

즉, 스테이지 너비가 1024인 경우 x좌표가 1000인 객체는 스테이지의 오른쪽 가장자리에 가까워집니다; viewPort가 512, 1024 또는 2048 픽셀인지 여부는 관계 없습니다.

이는 HiDPI 화면을 개발할 때 특히 유용합니다. 예를 들어, Apple의 iPad는 보통의 "레티나" 버전에 존재하며 후자는 픽셀 행과 열의 수를 두 배로 늘려서 (픽셀 수를 4 배 늘림). 이러한 화면에서 인터페이스 요소가 작아서는 안됩니다. 대신 그들은 더욱 선명하게 렌더링되어야 합니다.

ViewPort와 스테이지 크기를 구분하여 Starling에서 쉽게 재현할 수 있습니다. 두 기기 유형 모두 스테이지 크기는 1024 × 768; 반면에 viewPort는 화면 크기를 픽셀 단위로 나타냅니다. 이점: 응용 프로그램이 실행되는 장치에 관계없이 표시 객체에 대해 동일한 좌표를 사용할 수 있습니다.

Points와 Pixels 비교

이것을 생각해 보면 레티나 장치에서 x좌표가 1인 물체는 실제로 원점에서 2픽셀 떨어져 있는 것을 볼 수 있습니다. 즉 측정 단위가 변경되었습니다. 우리는 더 이상 픽셀에 대해 말하지 않습니다, 포인트를 말합니다! 저해상도 화면에서 한 포인트는 한 픽셀과 동일합니다. HiDPI 화면에서는 2픽셀 (또는 장치에 따라 그 이상)입니다.

포인트의 실제 너비 (픽셀 단위)를 확인하려면, view.width를 stage.stageWidth로 나눠서 간단히 구할 수 있습니다. 또는 Starling의 contentScaleFactor 속성을 사용하면 됩니다.

starling.viewPort.width = 2048;
starling.stage.stageWidth = 1024;
trace(starling.contentScaleFactor); // -> 2.0

모바일 개발 챕터에서 이 개념을 최대한 활용하는 방법을 알려 드리겠습니다.

2.1.2. Context3D 프로파일

Starling이 실행중인 플랫폼은 다양한 그래픽 프로세서를 탑재하고 있습니다. 물론 이러한 GPU는 기능이 다릅니다. 문제는 런타임에서 이러한 기능을 어떻게 구별 할 것인가 하는 것입니다.

이것이 바로 Context3D 프로파일 (렌더링 프로파일이라고도 함)입니다.

Context3D 란 무엇입니까?

Stage3D를 사용할 때 많은 속성과 설정이 있는 렌더링 파이프 라인과 상호 작용합니다. 컨텍스트는 해당 파이프 라인을 캡슐화하는 개체입니다. 텍스처 만들기, 셰이더 업로드, 삼각형 렌더링 - 모두 컨텍스트를 통해 수행됩니다.

실제로 Starling은 모든 프로필 제한 사항을 숨기려고 최선을 다하고 있습니다. 도달 범위를 최대한 넓히기 위해 사용 가능한 가장 낮은 프로필에서도 작동하도록 설계되었습니다. 동시에 높은 프로필에서 실행하면 자동으로 최고의 프로필을 사용합니다.

그럼에도 불구하고, 기본 기능에 대해 아는 것이 유용할 수 있습니다. 다음은 가장 낮은 프로필부터 시작되는 각 프로필에 대한 개요입니다.

BASELINE_CONSTRAINED

장치가 Stage3D를 지원하는 경우 이 프로파일을 지원해야합니다. 이는 몇 가지 의미가 있습니다. 2의 거듭 제곱인 사이드 길이를 가진 텍스처만 지원하고 셰이더의 길이는 매우 제한적입니다. 이 프로파일은 주로 오래된 데스크탑 컴퓨터에서 발견됩니다.

BASELINE

모바일 장치에서 찾을 수 있는 최소 프로필입니다. Starling은 이 프로필을 잘 수행합니다. 2의 거듭 제곱 제한을 제거하면보다 효율적인 메모리 사용이 가능 해지고, 셰이더 프로그램의 길이는 필요에 따라 쉽게 만족됩니다.

BASLINE_EXTENDED

최대 텍스처 크기를 2048x2048에서 4096x4096 픽셀로 높이며 이는 고해상도 장치에 중요합니다.

STANDARD_CONSTRAINED, STANDARD, STANDARD_EXTENDED

Starling은 현재 이러한 프로파일과 함께 제공되는 기능을 필요로 하지 않습니다. 이것들은 추가적인 쉐이더 명령과 다른 낮은 레벨의 향상을 제공합니다.

나의 추천: 단순히 Starling에게 가장 유용한 프로필 (자동)을 선택하고 그 의미를 다루도록 하십시오.

최대 텍스처 크기

여러분 스스로를 돌보는 데 필요한 것은 단 하나뿐입니다. 텍스처가 너무 크지 않도록 하십시오. 최대 텍스처 크기는 Texture.maxSize 속성을 통해 액세스 할 수 있지만 Starling의 초기화가 완료된 후에만 ​​가능합니다.

2.1.3. 네이티브 오버레이(Native Overlay)

Starling의 기본 아이디어는 Stage3D 기반 API로 렌더링 속도를 높이는 것입니다. 그러나 고전적인 디스플레이 리스트에는 Starling이 제공 할 수 없는 많은 기능이 있습니다. 따라서 Starling과 고전적인 Flash의 기능을 쉽게 조합하여 사용할 수 있습니다.

nativeOverlay 속성은 이렇게 하는게 가장 쉬운 방법입니다. 이것은 Starling 위에 직접 배치되는 viewPort 및 contentScaleFactor를 고려한 일반적인 flash.display.Sprite입니다. 기존의 Flash 객체를 사용해야 하는 경우 이 객체를 이 오버레이에 추가합니다.

하지만 Stage3D를 기반으로 하는 기존의 Flash 컨텐츠는 일부 (모바일) 플랫폼에서 성능 저하를 초래할 수 있습니다. 따라서 더 이상 필요하지 않은 경우 항상 오버레이에서 모든 객체를 제거하십시오.

질문하기 전에: 아니오. Starling 표시 객체 아래에 기존 표시 객체를 추가할 수 없습니다. Stage3D 서피스는 항상 맨 아래에 있습니다. 그 주위에는 방법이 없습니다.

2.1.4. 변경되지 않은 프레임 건너 뛰기

놀랍게도 종종 장면이 여러 프레임에 대해 완전히 정적인 상태로 유지되는 응용 프로그램이나 게임에서 발생합니다. 응용 프로그램은 정적 화면을 표시하거나 사용자 입력을 기다릴 수 있습니다. 왜 그런 상황에서 스테이지를 다시 그리는가?

이것이 바로 skipUnchangedFrames 속성의 핵심입니다. 활성화된 경우 정적 장면은 그대로 인식되고 백 버퍼는 그대로 왼쪽에 있습니다. 모바일 장치에서는 이 기능의 영향을 과소 평가할 수 없습니다. 배터리 수명을 향상시킬 수 있는 더 좋은 방법은 없습니다!

이미 귀하의 이의 제기를 듣고 있습니다. 이 기능이 유용하다면 왜 기본적으로 활성화되지 않는 것입니까? 캐치가 있어야 합니다. 그렇죠?

Render와 VideoTextures에서는 잘 작동하지 않습니다. 이러한 텍스처의 변경 사항은 표시되지 않습니다. 그것들을 사용하는 동안 skipUnchangedFrames를 일시적으로 사용하지 않도록 설정하거나 콘텐츠가 변경될 때마다 stage.setRequiresRedraw()를 호출하는 방법도 있습니다.

이제 이 기능에 대해 알았으니 항상 활성화시켜야 합니다. 향후의 Starling 버전에서 위에 언급된 문제를 해결할 수 있기를 바랍니다.

중요: 모바일 플랫폼에서는 주의해야 할 또 다른 제한 사항이 있습니다. 즉, 기본 (플래시) 단계 (예 Starling의 nativeOverlay를 통한)에 콘텐츠가 있는 경우 Starling은 어떤 프레임도 건너뛸 수 없습니다. 이것이 Stage3D 제한의 결과입니다.

2.1.5. 통계 표시

응용 프로그램을 개발할 때는 가능한 한 많은 정보를 원합니다. 그렇게 하면 문제를 조기에 발견하고 나중에 막다른 길을 피할 수 있습니다. 이를 위해 통계 표시가 도움이 됩니다.

_starling.showStats = true;

그림 4. 통계 표시 (기본적으로는 좌상단).

그 값들의 의미는 무엇입니까?

  • framerate은 이름 그대로입니다: Starling이 이전 초 동안 렌더링 할 수 있었던 프레임의 수.

  • 표준 메모리는 간단히 말해서 AS3 오브젝트가 채우는 내용입니다. 문자열, 스프라이트, 비트 맵 또는 함수이건 간에 모든 객체는 약간의 메모리가 필요합니다. 값은 메가 바이트 단위로 표시됩니다.

  • GPU 메모리는 그것과 별개입니다. 텍스쳐는 버텍스 버퍼와 쉐이더 프로그램처럼 그래픽 메모리에 저장됩니다. 대부분의 경우 텍스처가 다른 모든 것을 덮어 씁니다.

  • 드로우 콜(draw call) 수는 각 프레임의 GPU로 전송되는 개별 "draw" 명령 수를 나타냅니다. 일반적으로 드로우 콜 수가 적으면 씬이 더 빨리 렌더링 됩니다. 성능 최적화에 대해 이야기할 때 이 값으로 자세히 살펴보겠습니다.

통계 화면의 배경색이 검은 색과 진한 녹색으로 번갈아 나타납니다. 이것은 skipUnchangedFrames 속성을 참조하는 미묘한 단서입니다. 마지막 두 프레임의 대부분을 건너 뛸 수 있을 때마다 상자가 녹색으로 바뀝니다. 무대가 정지할 때마다 녹색으로 유지되는지 확인하십시오. 그렇지 않은 경우 일부 논리가 프레임 건너 뛰기가 시작되는 것을 방지합니다.

showStatsAt 메소드를 통해 화면에 통계 표시 위치를 사용자 정의할 수 있습니다.

results matching ""

    No results matching ""