본문 바로가기

Starling

Starling - Introducing 번역 6 > Tween,AssetManagement, MultiResolution & resize, Plugging...



목차

First Flight ------------------------------------------------------------------------------------------------- 

What Is Starling?

Why Starling?

Philosophy 

Intuitive 

Lightweight 

Free 

How 

Layering Restrictions 

Getting Started

Setting Up Your Scene

Wmode Requirements

Stage Quality

Progressive Enhancements

The Display List

Event Model

Event Propagation

Touch Events

Simulating Multi-touch

Texture

Image

Collision Detection

Drawing API

Flat Sprites

MovieClip

Texture Atlas

Juggler

Button

TextField

Embedded Fonts 

Native Display List Overlay

Bitmap Fonts 

RenderTexture

Tweens

Asset Management

Multi Resolution Development

Static Approach

Dynamic Approach

Handling Screen Resizes

Plugging Starling with Robotlegs

Plugging Starling with Box2D

Particles

-----------------------------------------------------------------------------------------------------------------


Introducing Starling 번역의 마지막 편입니다.

항상 말씀드리지만 미천한 영어실력이기 때문에 언제나처럼 오역은 있을 수 있습니다.



Tweens


Starling 은 내부에 트위닝 엔진이 PO장착WER 되어 트위닝을 지원하고 있다.

그림 56에서 보이는 것처럼 일반적인 트윈 대부분을 지원한다.


그림 56. Starling 에서 사용가능한 easing 방정식



아래의 코드는 텍스트필드의 x,y 속성을 트윈시켜 팅기는 효과를 낸 것이다.



Tween 객체에서 사용가능한 API 목록을 알아보자.


animate

객체의 속성을 목표 값으로 애니메이션 시킨다.

하나의 트윈객체에서 여러번 호출 될 수 있다.


currentTime

트윈의 현재 시간.


delay

트윈이 시작의 지연 값.


fadeTo

대상의 alpha 속성을 목표값으로 애니메이션 시킨다.

하나의 트윈객체에서 여러번 호출 될 수 있다.


isComplete

트윈이 완료되었는지 아닌지 알려준다.


moveTo

객체의 x와 y 속성을 동시에 애니메이션 시킨다.


onComplete

트윈이 완료되었을 때 호출되는 콜백함수.


onCompleteArgs

트윈이 완료되었을때 콜백함수에 전달되는 파라메터들.


onStart

트윈이 시작할 때 호출되는 콜백함수.


onStartArgs

트윈이 시작할 때 콜백함수에 전달되는 파라메터들.


onUpdate

트윈이 진행될 때 호출되는 콜백함수.


onUpdateArgs

트윈이 진행될 때 콜백함수에 전달되는 파라메터들.


roundToInt

트윈 진행 중 실수 값을 정수로 캐스팅할지를 나타낸다.


scaleTo

객체의 scaleX 와 scaleY 속성을 동시에 애니메이션 시킨다.

하나의 트윈객체에서 여러번 호출 될 수 있다.


target

애니메이션 되는 대상.


totalTime

트윈에 소요되는 총 시간. (초단위 )


transition

애니메이션에 사용되는 트랜지션 함수.




예를 들어,

아래의 코드에서 우리는

트윈이 끝나는 시점을 청취하여 (listen) onCompleteArgs API 에 인자를 전달하여 객체를 제거하고 있다.



( 역자주. removeFromParent  메소드에 true 를 전달하면 자동적으로 dispose 가 호출되게 된다 )



다음의 코드는

onStart, onUpdate, onComplete 이벤트에 할당된 3개의 콜백을 사용하여 트윈의 진행상태를 청취하는 것을 보여준다.




TweenLite 같은 기존의 인기 트위닝 라이브러리 역시 Starling 에서 문제없이 작동한다는 것도 기억해두자.

몇몇 라이브러리는 일부 조정이 필요할 수 있지만, Starling 과 함께 사용하는 방법은 매우 쉽다.


( 역자주.

기존의 트윈라이브러리와 Starling 트윈엔진은 장단점이 있다. 

Starling 트윈엔진의 가장 큰 장점은 Juggler 의 advancedTime 을 통해 전달된 시간기반으로 진행된다는 점이다.

예를들어,

플래시에서 대중적으로 사용되었던 greensock 라이브러리의 경우,

이들 트윈의 진행은 모두 getTimer 를 통해 진행되었었다. 이는 각트윈의 시간이 동일하게 진행된다는 의미이다.

반면, Starling 은  Juggler 의 advanceTime  메소드가 enterframe 마다 실행되고 

각 Juggler 가 자신에게 포함된 Tween 객체의 advanceTime 메소드를 실행하는 형태로 구현되어 있다.

이때 advanceTime 에 전달된 시간으로 트윈이 진행되는데 중간에 Juggler 라는 단계를 하나 둠으로써

각 트윈들은 flash 내부 getTimer 시간에서 분리되어 grouping 이 가능해지고

원할 경우 특정 트윈 그룹만 독립적으로 핸들링 할 수 있게 된다. (Juggler 는 여러개 생성 가능하다)


몇가지 예를 들면,

MMORPG 에서 특정 캐릭터만 일정시간동안 SLOW 가 걸려 모든 행동, 사용된 스킬이 천천히 진행되는 상황이라던가,

혹은 영화에서 총알이 발사되었을 때 시간의 흐름이 페이드인,아웃 되며 천천히 움직이는 등장인물 사이로 총알의 스쳐지나가

는 모습을 보여준다거나 하는 연출을 떠올려보자.

일부 액션영화는 이처럼 시간흐름 자체를 빠르게 진행시켰다, 느리게 진행시켰다를 반복하며

스타일리쉬 한 영상을 보여주곤 한다.

각 모션의 시간흐름이 독립되어 있다는 말은 게임 내에서 이러한 것들이 쉽게 가능하다는 의미이다.

물론 이를 위해선 게임 설계 시점에서 몇가지를 고려해야 한다.)



이젠 자원을 어떻게 하면 좀 더 체계적으로 관리 할 수 있는지를 살펴보자.

우린 지금까진 필요한 것을 프로그램에 포함시키기 위해 간단한 embed 태그를 사용하였다.


규모가 큰 프로젝트에서, 당신은 당신의 자원들을 한 곳에서 체계적으로 관리하기를 바랄 것이다.

다음 섹션에서 자원을 그룹화 하고 재사용할 수 있는 몇가지 간단한 테크닉을 알아보도록 하자.




Asset Management


지금까지 우리는 매우 간단한 방법으로 자원들을 사용해 왔다.

자원을 사용하는 작업방식을 최적화 하기 위해,

리소스를 얻기 위한 작업의 중심이 될 하나의 Assets 객체를 사용하는 것을 권장한다.


이 Assets 객체는 사용 될 자원들을 풀링하고, 버려지지 않고 재사용되게끔하고,

인스턴스화 할때 마다 GC에 압력을 가하는 등의 책임져야 한다.


아래의 코드에서,

우리는 embed 된 텍스쳐를 검색 할 수 있도록 Assets 객체에 getTexture 라는 API 를 정의했다.



자원을 저장할 Dictionary 객체를 이용하여

다음에 다시 자원을 필요로 할 때 재생성 하는 대신 pool 에서 가져오는 부분을 주목하자.


늘 그래왔듯이, 텍스쳐는 Embed 태그를 통해 포함되어 있는 상태이다.



우리는 여태껏 계속해서 Embed 태그를 사용했지만 Starling 은 이런방식을 강요하고 있진 않다.

원한다면 Loader 와 같은 객체를 사용하여 동적으로 텍스쳐를 로드할 수도 있다.



이러한 방법을 사용하면 시작 성능이 개선될 뿐만 아니라 메모리 사용량도 감소된다.

Embed 된 이미지는 사용되지 않은 채 단지 embed 만 되어있다해도 디바이스의 램에 저장되게 된다.

이것은 데스크탑에서는 이슈가 되진 않지만 모바일 디바이스에서는 정말 주의해야 할 점이다.


자원들을 embedding 하는 것보다

런타임 시 응용 프로그램 디렉토리에서 항상 자원을 로드하게끔 하는 것도 좋은 전략중 하나가 될 수 있다.


( 역자주. Starling 1.3 버전에서 AssetManager 라는 클래스가 추가되어있다.

기능이 약간 모자란 감이 있지만, 매우 편리한데다

코드자체가 알아보기 쉽고 짧게 작성되어 있어 입맛대로 커스텀 하기 쉽다.

적당히 프로젝트에 맞게 고쳐서 쓰도록 하자. 그대로 사용해도 무방하다. )




Multi Resolution Development


데스크탑 브라우저 용으로 개발할 경우

다중 해상도에 걱정할 필요는 없다.

최소한 애플이 데스크탑 컴퓨터에 레티나 디스플레이를 도입하기 전까지는 

정말로 전혀 걱정할 필요가 없다.

당신은 그저 720 DPI 해상도에 맞게 디자인 하면 되었다.


모바일 디바이스에서 개발 할때,

특히 같은 고해상도 레티나 디스플레이가 탑재된 iOS 기기의 경우

자원을 디자인할 때 이를 고려 해야 한다.



Static Approach


데스크탑의 브라우저가 대상이 된 경우,

아래처럼 Starling 객체를 생성해 사용하면

viewport 속성은 동적으로 쓰여지고, 자동으로 스테이지의 크기에 맞게 설정된다.



이러한 상황에서, 브라우저 내에서 실행되는 경우

스테이지크기와 viewport 간의 차이는 없다. 이들은 동기화 된다.


• viewport 는 Starling 에서 렌더링되는 화면의 영역을 결정한다.(Stage3D back buffer).

영역은 항상 픽셀단위로 지정된다.


하지만 당신은 다양한 모바일 디바이스에서 컨텐츠가 실행되기를 기대하고 있고

이들 중 일부는 아마 비극적이지만 다른 해상도를 가지고 있을 것이다.

그럼 모바일 개발의 흔한 예로,

iPad1 과 iPad2, 그리고 HD 레티나 디스플레이를 가진 iPad3 에서의 실행을 예로 들어보자..


일단 iPad1 과 iPad2 ( 레티나 x ) 와 iPad3( 레티나디스플레이 ) 을 잠시 머리속에 그려보자.

아래는 각 디바이스의 정보이다.


Pad 1 and 2  > 1024×768

iPad 3  > 2048×1536


레티나 해상도는 정확하게 일반 해상도 보다 2배인 것을 알수 있다.

자 이젠 iPad1 과 2 같은 비고해상도 장치로 시작해보자.

이 경우, 우리는 아래와 같이 작성한다.




스테이지의 크기는 viewPort 에서 표시되는 시스템 좌표계의 크기를 결정한다.

스테이지의 폭이 1024 일때

x 값이 0 ~ 1024 사이인 모든 객체는 스테이지 내에 존재하고, 뷰포트의 크기는 중요하지 않다.

1024 x 768 에서의 요소 배치는,  iPad3 의 해상도, 2048 x 1536 에서 완벽하게 배치되어야 한다.


그럼 이를 위해 어떻게 해야 할까?


Starling 은 viewPort 폭을 stage 폭으로 나눈 매유 유용한 contentScaleFactor 속성을 제공한다.

위의 상황에서, 레티나 디바이스인 경우 2가 되고 레티나가 아닌 디바이스에서는 1이 된다.


디바이스에 따라 적절한 자원을 사용할 수 있도록 우리는 높은 해상도의 자원 역시 제공해야 한다.


iPhone 3GS 의 화면 반을 가릴 160 픽셀의 폭을 가진 이미지가 있다고 할 때

높은 해상도의 자원을 사용하게 되면

그에 해당하는 HD 텍스쳐는 (320px) 화면 전체를 가리게 되어 버린다.(IPhone 3GS 의 해상도는 480 x 320 )


하지만 다행히

우리가 사용하게 될 contentScaleFactor  속성을 디스플레이 해상도에 따라 텍스쳐의 또 다른 세트를 선택할 수 있다.


아마 당신은 이렇게 생각할지도 모른다.

"그냥 고해상도 자원만 제공해서 줄여서 쓰면 안돼?"


돼! 라고 말하고 쉽지만 안타깝게도 그렇게 해선 안된다.

그럴 경우,

높은 해상도의 자원을 작고 약한 디바이스에서 사용하게 되어 너무 많은 GPU 대역폭을 활용하게 되고,

퍼포먼스에 많은 영향을 끼치게 된다.

다시말해, 우리는 디바이스 해상도에  부적절한 자원을 사용하게 된다.


이러한 작업을 하기 위해

텍스쳐에 크기를 조절할 계수( scaling factor) 를 전달할 방법이 필요하다.


그것이 fromBitmap,fromBitmapData , fromAtfData API 모두가 scaleing 을 지원하는 이유이다.



이젠 런타임에서, contentScaleFactor 값에 따라, 우리는 어떤 자원을 사용해야 할지 알아낼 수 있다.


이미지의 크기를 요청할 때, scaleFactor 는 다음처럼 사용된다.


SD Texture (width 1024 pixels, scale factor 1): texture.width == 1024 (1024 / 1)

HD Texture (width 2048 pixels, scale factor 2): texture.width == 1024 (2048 / 2)


항상 멀티 해상도에 대한 준비가 되어있다면 

이런식으로 동적으로 스테이지의 크기와 관련된 요소들을 배치 시킬 수 있게 된다.

근데 잠깐,

여기에 더욱 강력한 솔루션이 있다. 지금 살펴보자.



Dynamic Approach



우리는 미리 만들어진 자원의 사용으로 다중해상도 문제의 해결을 해결하는 정적접근을 다루었다.

하지만 더 유연한 해결책이 있다.


플래시는 항상 독립적으로 벡터에 에대한 지원을 하고 있다.

그런데 왜 다중 해상도 개발을 하기위해 이것을 활용하지 않는가?


미리 제작되어 패키징된 자원은 당연히 그 크기만큼의 비용을 가지고 있고,

만약 다양한 해상도를 지원해야 한다면 다른버전의 자원을 여러개를 가지고 있어야 하기 때문에

또다른 문제에 빠질 수 있다.


그래서 우린 어떻게 이문제를 해결 할 수 있을까?


아이디어는 간단하다.

자원을 미리 만들어 두는 대신 스프라이트시트를 런타임 시 생성하는 것이다.

이를 위해선, 런타임 시 자원을 인스턴스화 한후 디바이스의 해상도에 따라 스케일을 조정하고

BitmapData 를 이용해 Bitmap 으로 래스터화 해야 하는 작업이 필요하다.


draw 나 BitmapData.copyPixels 을 사용하면 텍스쳐를 업로드 할 수 있게 되어,

디바이스에 따라 최적의 해상도를 가진 자원을 100% 동적으로 생성할수 있게 된다.


아래는 그 기본을 보여주는 예제이다.

우리는 Texture 클래스의 fromBitmapData API 를 사용했다.


이 아이디어로

Starling 커뮤니티의 몇몇 개발자는  동적 텍스쳐 아틀라스 생성을 제공하는 확장 기능을 만들었다.

2개의 라이브러리를 소개한다.


 Emiliano Angelini 가 만든 Dynamic Texture Atlas  와 Bitmap Font Generator

https://github.com/emibap/Dynamic-Texture-Atlas-Generator


•  Richard Lordd 가 만든 Starling 의  dynamic asset 관리 클래스 Fruitfly.

https://github.com/richardlord/Fruitfly



Fruitfly 는 AIR 에서 사용될 때 캐싱 메카니즘도 제공하여,

스프라이트시트가 생성되면, 이를 캐싱 하여 나중에 재사용 할 수 있게 된다.


Dynamic Texture Atlas 는 매우 가볍고 사용하기 쉽다.

몇개의 정적 API 가 노출되어 있으며, 전혀 객체화 할 필요가 없다.


API 는 정말 간단하다.


TextureAtlas 에 배치하고 싶은 모든 무비클립이 포함된 기존의 MovieClip( flash.display.MovieClip ) 을 전달하여

fromMovieClipContainer API 를 호출 하면 TextureAtlas  객체가 반환되고,

이를 통해 Starling 의 각 MovieClip 를 TextureAtlas 객체의 getTextures  API 를 호출해 재구성 하면 된다.

각 무비클립의 이름은 나중에 적절한 텍스쳐 객체를 검색 할 수 있도록 보존된다.


자 그럼 'runningBoy' 라는 인스턴스 네임을 가진 기존의 MovieClip 이 있다고 가정하자.

이 소년의 텍스쳐들을 검색하는 방법은 아래와 같다.


아래의 API 를 사용하여 폰트에 대해서도 같은 방식으로 사용할 수 있다.


위의 API 들은 TextureAtlas 를 반환하지 않는 다는 것을 주목하자.

bitmapFontFromString 으로 화면 뒤에서 문자를 표시하기 위한 TextField 를 생성한뒤

내부적으로 registerBitmapFont API 를 호출하는 BitmapFontFromTextField API 를 호출하면

폰트는 자동적으로 등록되어 TextField API 를 사용할 준비가 된다.



당신의 Starling 어플리케이션은 모바일 디바이스, 데스크탑브라우저등, 다양한 크기의 스크린에서 실행될 가능성이 있다.

스크린의 크기가 변경될 때 쉽게 처리하기 위해 어떻게 해야 할지 다음 섹션을 보자.



Handling Screen Resizes


플래시 개발자는 

스크린의 크기 변경 이슈를 처리하기 위해 일반적으로  Event.RESIZE 라고 하는

간단한 이벤트에 의존하고 있고, 이 이벤트는 페이지의 크기가 변경 될 때마다 매번 통지된다. 


stage.stageWidth 와 stage.stageHeight 속성을 사용하면 목표가 된 화면 크기가 무엇이든 상관없이

컨텐츠를 적절하게 배치할 수 있다.


이를 위해, Starling 에서 사용되는 starling.display.Stage 역시

당신이 동적으로 우아하게 이를 처리할 수 있도록

ResizeEvent.RESIZE 불리는 비슷한 이벤트를 전파한다.


아래의 코드에서,

우리는 화면이 resize 될 때 quad 가 화면의 중앙에 오도록 하고 있다.


SWF 가 resize 될 때 마다 ResizeEvent.RESIZE 는 전파된다.

ResizeEvent  객체를 통해 새로운 화면 크기가 전달되면,

직접 스테이지의 stageWidth, stageHeight 속성에 입력하자.

그리곤 스테이지의 크기에 따라 각 콘텐츠를 올바르게 재배치 하면 된다.

SWF 가 풀스크린이 될 때도 ResizeEvent.RESIZE 이벤트는 발생하며 처리방법은 위와 같다.




Plugging Starling with Robotlegs


당신은 이미 Robotlegs (로봇다리ㅋ) 프레임워크를 사용하여 깔끔하고 효율적으로 코드를 짜고 있을 지도 모른다.

Omar Gonzalez 는 Statrling 에서 Robotlegs 를 사용할 수 있게 Robotlegs 플러그인을 만들어 주었다.

다음 링크에서 조금 더 자세한 정보를 찾을 수 있다.

http://www.robotlegs.org/

https://github.com/s9tpepper/robotlegs-starling-plugin




Plugging Starling with Box2D


Starling 의 끝내주는 장점은 기존의 다른 프레임워크와 쉽게 연결 되는 displaList API 이다.


예를 들어,

게임에 물리현상을  추가하기 위해 Box2D 프레임워크를 사용하고 싶은가?

http://box2dflash.sourceforge.net/ 에서 Box2D 에 대한 자세한 정보와 다운로드가 가능하다.


아래의 코드에선, 간단한 중력을 통해 상자들을 바닥에 떨어뜨리고 있다.

물론, 모든 렌더링은 GPU 에서 이루어진다.




이 코드를 실행하면, 그림 57 같은 결과를 볼 수 있다.

Starling 에서 사용된 Box2D



아래는 iPAD 3 에서 AIR for mobile 로 만들어진 같은 컨텐츠이다.

Figure 58. 테블릿에서 60 fps 로 실행되는 같은 어플리케이션.


당연히 이 사각형들은 손쉽게 텍스쳐로 바꾸거나 다양한 그래픽을 사용하여 빠르게 작업을 끝낼 수 있다.

우왕 당신 지금 끝내주는 2D GPU 컨텐츠를 만들어냈다!  

( 역자주. 유머인거 같다. 양키유머는 여전히 내게 혼란을 준다.)




Particles


멋진 효과를 만들려고 할 때 파티클은 확실히 내가 자주 애용하는 것 중 하나이다.


믿거나 말거나, 파티클은 보기만큼 복잡하지는 않다.

기술적으로 파티클은

말그대로 특정 블렌딩 모드를 사용하여 아름다운 조합을 만들어내며 돌아다니는 텍스쳐 입혀진 입자일 뿐이다.


Starling 에서 사용 될 파티클을 디자인 하기 위해 ParticleDesigner  라는 매우 편리한 도구가 사용될 것이다.

(bitmap font 를 사용할 때 썼었던 GlyphDesigner 툴을 제작한 71 squared 라는 회사에서 개발되었다.)


그림 59 는 ParticleDesigner 의 화면이다.


오른쪽에 보이는 에뮬레이터로 당신이 디자인한 파티클을 미리 볼 수 있다.

왼쪽의 메인창은 단지 파티클을 수정하기 위한 파라메터들의 집합이다.

원하는 파티클을 만들기 위해 이 옵션들을 가지고 놀며 시간을 보낼 수 있다.

자동으로 파라메터들을 생성하는 랜덤 버튼을 통해 각기 다른 파티클 효과를 생성할 수도 있다.


그림 59. MacOS 의 ParticleDesigner.

( 역자주. 좋은 툴은 맥에 다있는것 같다)



그림 60은 ParticleDesigner 의 save_as 창이며

파티클을 렌더링 할 텍스쳐와 ParticleEmitter 파일 (.pex ) 을 내보낸다.

이 두개의 파일이 ParticleDesignerPS 객체를 사용하기 위해 필요한 녀석들이다.


그림 60. MacOS 의 Particle Designer.



그림 61은 ParticleDesigner  에서 만들어진 파티클을 Starling 에서 사용한 예제이다.

그림61. Starling에서 실행되는 커스텀 파티클들.


쩔지?

이걸 보고 설레일테지만 Starling 에선 이러한 파티클 기능을 찾을 수 없ㅋ겠ㅋ짘


파티클 엔진은 Starling 의 확장기능으로 https://github.com/PrimaryFeather/Starling-Extension-Particle-System 에서 

다운받을 수 있다.


그림 62는 파티클의 다른 예제이다.

그림 62.  Starling에서 실행되는 커스텀 파티클들.



파티클은 Starling 내의 다른 애니메이션 되는 객체들과 동일하게 간주된다는 것을 명심하자.

( 역자주. IAnimatable 인터페이스를 구현한 클래스라는 의미이다.)

그 결과,

파티클 객체의 애니메이션을 재생시키기 위해선 Juggler 에 추가해야만 한다.



ParticleDesignerPS 객체는 DisplayObject 를 상속하였으므로

원하는대로 파티클을 배치시킬 수 있게 하기 위해 필요한 모든 기능이 사용가능하다.


물론, 언제나 처럼

사용이 끝나면 파티클들은 juggler 에서 제거되어야 하고

ParticleDesignerPS  dispose API 를 통해 객체도 dispose 해야 한다.



Lee Brimelow (leebrimelow.com) 가 만든

파티클을 사용해 우주선에서 불이 뿜어져 나오는 예제를 보자( 그림63)

그림63. 우주선과 합쳐진 파티클 이펙트.



우린 이젠 우주선이 발사한 로켓에 몇가지 파티클을 추가할 수 있다.

그림 64. 불꽃을 휘날리는 로켓.



로켓이 화면밖으로 빠져나가면

우리는 그들을 화면과 저글러에서 제거해야 할 필요가 있다.



우린 여기서 매우 중요한 부분, 파티클객체를 처리하는 것을 놓쳤다.

이는 그들이 GPU 메모리에서 제거되지 않았다는 것을 의미한다.

그래서 위의 코드는 아래처럼 변경되어야 한다.


파티클을 화면에서 제거하고 dispose 하도록 하는 removeChild API 또한 사용가능하다.


( Rocket 클래스의 dispose 메소드 자체를 오버라이드 하여 사용된 파티클, 트윈등..

모든것을 처리하도록 하는 것도 하나의 방법이다.)



긴장을 늦추지 말라. 당신에게 닥칠 좋지않은 잠재적 시나리오가 있다. 


앞의 예에서 파티클은 로켓에 부착되어 화면밖으로 이동되고 있고

로켓이 영역 밖으로 나갔을 때 파티클의 위치를 확인하고 제거하는 것은 쉽다.


당신에게 닥칠 좋지않은 시나리오는

파티클이 화면 밖으로 나가지 않고 임의의 위치에서 폭팔하여 게임화면에서 사라지는 것이다.


이러한 상황에서 파티클의 위치를 검사하는 것은 전혀 도움이 되지 않고,

당신은 파티클의 폭팔 애니메이션의 완료를 확인하고, 애니메이션이 완료되면 이를 처리해야한다.


다행스럽게도,

파티클 시스템에는 완료에 대해 알리는 이벤트가 있다.

필요한 경우 파티클 객체에 Event.COMPLETE 리스너를 등록하기만 하면 된다.

심플! 이젠 모든것이 끝났다!



우리는 Starling 의 소개를 끝냈다.

당신이 Starling 을 즐기기를 바란다.

이젠 Starling으로 끝내주는 걸 만드는 것만 남았다.



만약 질문이나 코멘트츠가 있다면  http://forum.starling-framework.org/  에 남기자.




About the Author


Thibault Imbert 는 그래픽, 언어, VM 및 Monocle ( flash 프로파일링 툴 )  에 집중한

어도비 게임 팀의 수석 Product Manager 이다.

플래시 개발자로 프랑스의 에이젼시에서 몇년간 작업한 후 어도비 공인 강사가 되어

어도비 교육센터에서 ActionScript  가르쳤다.

2008년 무료이고 오픈 소스인  Pratique d’ActionScript 3, 라는 ActionScript 3 책을 발간 했고

이 책은 2009 년, 출반사 Pearson 에서 Flash Player 10 를 위해 재집필 되었다.

Flash Platform 의 성능 최적화에 관한 백서를 발간(발표) 했다.

그의 실험 대부분은 자신의 블로그  ByteArray.org 에서 구할 수 있다.

Thibault  는 ActionScript 에 관한 컨퍼런스에 참석하며

펑키음악을 듣는것과 마카롱을 만드는 것을 좋아한다.



여기 저기서 많이 뵌 만나보진 못했지만 알만한 사람은 다 아는 익숙한 바로 이분이 이 e-book 의 저자.


이 형이 이책을 쓴게 아니였다. 두둥




- 마지막 역자주 - 

드디어 마지막 까지의 번역이 끝이 났다.

제대로 했는지 오타는 없는지 줄바꿈은 이쁘게 되었는지 확인하고 싶지만

일단... 너무 잠이 온다. ( am 2:31 ㄷㄷㄷㄷ) 

Starling 관련 정보가 국내에서 거의 없다시피 하니

(아니 actionScript 를 하는 사람들 자체가 이젠 온라인에서 멸종된 기분)

나라도 남겨보자 하는 마음으로 시작해서

처음 시작할 땐 시간날 때 조금씩 하면 금방 끝나겠네..라고 생각했었는데

작년 5월 시작하여  일년이 지나서야 끝. 이놈의 귀차니즘 ㅋㅋㅋ

그래서 도중에 Starling 의 버전업도 몇번되고 e-book 도 도중에 업데이트 되어버림 ㅋㅋㅋ


2012 년 7월이면 끝날거라 생각했던....


이러고보니 작년 초 Starling 처음 보고 '우왓! 멋지다! ' 하며 남들 다 플래시접고 여기저기로 갈아탈 때 혼자 끄적거리며

시작한게 벌써 1년 반이 흘렀다. 근데 여전히 잘 모르겠음.


보는 분들이 몇이나 되셨는지 모르겠지만...

도움이 되었길 빌며!


끝.