지난 5월 Adobe 는 Photoshop Touch SDK 를 발표했습니다. 이전에도 포토샵은 Photoshop SDK 를 지속적으로 발표해왔는데 이 SDK 를 통해 다양한 포토샵 플러그인과 매크로등을 만들 수 있었습니다. 이 SDK 는 상당히 강력해서 포토샵의 거의 모든 기능을 통제 할 수 있습니다. 하지만 대중적으로 그렇게 널리 사용되지는 않는 것 같습니다. 포토샵의 주 사용층인 디자이너들은 코드와는 안 친하니까요.
Photoshop Touch SDK 의 발표와 함꼐 재미난 아이패드 앱 3종이 같이 발표되었습니다. 이전 제 글 중 Photoshop CS5 apps for iPad 를 보시면 좀 더 자세한 내용이 있습니다. 이 앱들은 기존에 포토샵에 없는 기능을 추가하거나 쉽게 네트워크를 만들어주고 포토샵의 기능을 보조 하는 등 매우 흥미로운 것들 이었습니다. 물론 Adobe 가 직접 만들었으므로 앱 자체 퀄리티가 모두 매우 뛰어납니다. 그래서인지 모두 유료 앱니다. ^^
현재 Adobe 는 CS5.5 를 출시하며 모바일 시장을 장악하기 위해 나름 안간힘을 쓰고 있습니다. 이번 Photoshop Touch SDK 의 발표도 그러한 움직임의 하나겠지요. 그리고 이 Photoshop Touch SDK 는 당연하게도 ActionScript 를 지원하고 있습니다. 그래서 저도 간단히 포토샵 툴 어플을 만들어 보았습니다.
이번 어플의 목표는 두가지였습니다. Photoshop Touch SDK 의 작동원리를 이해하고 Flash Builder 4.5 를 이용해 iOS 와 Android 앱을 런칭해 보는 것 입니다. 앱의 기본적인 기능은 SDK 에서 제공하는 예제에서 가져왔습니다. 다만 가장 어려웠던 부분은 63개에 이르는 툴의 id 이름이 그 어떤 문서에도 나와있지 않았다는 겁니다. 결국 쌩 노가다로 일일이 확인했습니다.ㅠㅠ 그리고 두번째 목표였던 iOS 와 Android 두 플렛폼의 런칭은 너무나 당연하게도 정말 간단했습니다. 그냥 퍼플리싱 옵션만 선택해주면 모든게 끝 이였습니다. 다만 약간 주의 해야 할 점은 Android 의 경우 화면 크기가 제각각이라 이걸 조금 신경 써 줘야 했습니다. 이번 Flash CS5.5 의 새로운 기능 중 이와 같은 화면크기 변화에도 능동적으로 대응 해 주는 기능이 추가되었으니 이 문제는 앞으로 좀 더 쉽게 해결 되리라 봅니다.
다만 앱스토어에 등록까지는 조금 난항이 있었습니다. 안드로이드의 경우 리뷰없이 등록되므로 제작 완료 후 바로 등록 할 수 있었지만 앱스토어의 경우 리뷰를 통과해야 했습니다. 애플 정책상 애플 리뷰어가 앱의 기능을 확인 할 수 있어야 하는데 psTools 의 경우 최신의 Photoshop 이 필요하므로 리뷰어가 리뷰를 할 수 가 없었습니다. 결국 여차여차 하다 동영상으로 컨펌을 받고 sale 에 들어 같습니다.
다음 버전으로는 psWindow 를 기획하고 있습니다. 결국 Nav 의 기능이 쪼개지는 것이군요. ㅎㅎㅎ 만들어진다면 psTools 보다 psWindow 가 확실히 더욱 유용할 것 같습니다. 개인적으로 늘 원했던 기능이기도 하구요. psTools 는 저 처럼 괜한 고생하지 마시라고 소스를 공개합니다. 가장 핵심이 되는 부분은 ToolStringConverter.as 파일이니 이와 같은 툴을 만들어보고 싶으신분은 이용하셔도 좋습니다.
Detail
[button url=’http://itpointlab.com/?page_id=3081′ target=’_blank’ size=’large’]PsTools 정보[/button]
Download
[button url=’http://itunes.apple.com/us/app/pstools/id439575466?l=ko&ls=1&mt=8′ target=’_blank’ size=’large’]iOS[/button]
[button url=’https://play.google.com/store/apps/details?id=air.it.pstools’ target=’_blank’ size=’large’]Android[/button]
Source
[button url=’https://github.com/sewonist/PsTools’ target=’_blank’ size=’large’]PsTools in GitHub [/button]
]]>
조립툰이 2.0 으로 업그레이드 됐습니다. 말이 업그레이드지 거의 완전 다른 앱입니다. 그러다 보니 코드도 전부 새로 다시 작성 되었습니다.ㅠㅠ 기존의 조립툰은 이미지가 앱에 포함되어 있는 오프라인 방식이였습니다. 이러한 오프라인 방식을 채택한 이유는 저 한테 터치밖에 없었기 때문입니다. 저 처럼 온라인이 힘든 유저들도 매일 새로운 툰을 볼 수있게 해주자는게 처음 컨셉이었습니다. 하지만 많은 문제점이 노출 되었고 (툰이 한번에 열려버리는 버그라든가 컨텐츠 업데이트가 힘든 문제점들 ) 결국 온라인버전으로 변경하게 되었습니다.
온라인이 되어야 하는 불편함은 있지만 대신 매일 따끈따끈한 조립툰을 볼 수 있게 되었으니 나름 괜잖은 딜이라고 생각합니다(변명입니다;;;) 그리고 이번 업그레이드를 통해 아이패드 지원도 추가되었습니다. 아이패드 전용 UI 로 좀 더 크게 즐기 실 수 있습니다.
다만 너무 짧은 작업시간으로 ( 서버 구축부터 앱 등록까지 추석연휴 4일 이라는 경이적인 속도 ;;; ) 여러군데 부족한 부분이 눈에 보이는데 이는 차차 개선해 나가겠습니다.
그럼 조립툰 앱의 두번째 이야기를 즐겁게 즐겨 주시기 바랍니다. 감사합니다.
Download
[button url=’http://itunes.apple.com/kr/app/id377165407?mt=8′ target=’_blank’ size=’large’]조립툰 다운로드[/button]
추가로 조립식 작가의 신작 <만화경제상식사전> 에도 많은 관심 부탁드립니다. ㅎㅎㅎ
yes24 : http://www.yes24.com/24/goods/4648881?scode=029
알라딘 : http://www.aladin.co.kr/shop/wproduct.aspx?isbn=8966180000
교보문고 : http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788966180004&orderClick=LEA
cacheAsBitmap을 as3 help 에서 찾아보면 DisplayObject 의 속성으로 나옵니다. 이 속성을 true 로 하면 Bitmap 으로 메모리상에 캐싱 해줍니다. 그래서 주로 복잡한 벡터드로잉이나 텍스트에 마스크를 줄때 사용합니다. 그리고 가장 많이 사용하는게 그라데이션 마스크를 줄 때 사용하지 않나 싶습니다. 이 cacheAsBitmap 은 잘 알고 사용하면 엄청난 성능향상을 볼 수 있지만 조금만 잘 못 사용하면 오히려 반대의 효과가 납니다. 저는 그것도모르고 어디서 주워 들은 건 있어가지고 cacheAsBitmap 만 사용하면 무조건 엄청난 성능향상이 있는 줄로 알고 닥치는데로 사용했다가 아주 낭패를 봤습니다. 그래서 이 cacheAsBitmap 은 언제 사용하면 좋고 언제 사용하면 안되는지 정리 해보려고 합니다.
사실 이와 관련된 여러글이 2008년 전부터 많이 올라와 있었는데 전혀 모르고 있었다는게 참 부끄럽네요.
cacheAsBitmap 을 사용하면 좋은 경우
1. 복잡한 벡터를 캐싱 할 때. 아마 cacheAsBitmap 가 가장 큰 효과를 내는 경우 입니다. 하지만 어차피 외부에서 가져오는 벡터이미지라면 그냥 png 등 비트맵으로 바꿔서 가져오는게 더 효과적일 것 같네요.
2. 많은 양의 텍스트가 있을 때. 최근에는 많이 없어 졌지만 플래시 게시판 처럼 플래시 안에 많은양의 텍스트가 들어 있을 때 이걸 캐싱 해주면 매우 효과적입니다.
3. 아이폰 AIR 처럼 cacheAsBitmap 이 활성화된 오브젝트만 GPU 렌더를 해줄 때. 이런 경우에는 무조건 걸어서 GPU 렌더 효과를 보는게 좋습니다. 다만 이건 아이폰의 경우이고 일반 PC는 상관 없습니다.
cacheAsBitmap 을 활성화 시킬 오브젝트
cacheAsBitmap 은 애니메이션이 변화는 오브젝트에는 절대로 절대로 걸면 안됩니다. 위의 3번 처럼 cacheAsBitmap 를 꼭 걸어줘야 하는 상황에서 오브젝트의 최상단에 cacheAsBitmap 을 true 설정했다가는 바로 아이폰이 멈춰버립니다. cacheAsBitmap 은 하위 변화가 없는 오브젝트에 걸어줍니다.
예를 들어 위와 같은 상황에서 사과가 애니메이션 되고 있습니다. 이럴때 파란선영역의 부모오브젝트에 cacheAsBitmap 을 사용하면 안 됩니다.
이와 같이 하위에 전혀 애니메이션이 없는 사과에만 cacheAsBitmap 을 활성화 해줘야 사과가 애니메이션 될 때마다 캐쉬를 다시 잡아 성능을 떨어 트리지도 않습니다. 그리고 불필요한 영역을 캐싱하지 않으므로 메모리도 최소한 으로 사용 할 수 있습니다.
cacheAsBitmap 제한사항
1. x, y 의 평행이동 이외의 변화가 있는 오브젝트에는 사용하지 않는다. 즉 알파, 회전, 확대가 되는 오브젝트에는 사용하지 않는다.
2. Video 에는 사용하지 않는다.
3. 1, 2의 조건에 해당되는 오브젝트에는 필터를 적용하지 않는다. 필터를 적용하면 자동으로 즉시 cacheAsBitmap 이 활성화 된다.
캐시된 동영상 클립의 재생 헤드가 이동할 때마다 업데이트되는 비트맵이 필터에 사용됩니다. 따라서 필터를 사용하면 cacheAsBitmap 속성이 true로 자동 설정됩니다.
4. 비트맵캐싱을 사용하고 싶지만 평행이동 이외의 변화가 있다면 수동 비트맵 캐싱을 이용한다.
cacheAsBitmapMatrix
cacheAsBitmapMatrix 는 모바일 AIR 에서만 사용 할 수 있는 특수한 속성입니다. cacheAsBitmap 의 경우 평행이동 외에는 효과를 볼 수 없지만 cacheAsBitmapMatrix 를 활성화 해주면 평행이도 외에 회전, 크기 변화시에 비트맵 캐시를 다시 잡지 않습니다. 메트릭스만 갱신 되므로 매우 효과적으로 오브젝트를 사용 할 수 있습니다. 사용시 주의 할 점은 cacheAsBitmapMatrix 가 cacheAsBitmap 보다 먼전 선언 되야 한다는 겁니다. 그렇지 않을경우 오히려 성능이 떨어 질 수 있습니다.
참고: AIR 또는 Packager for iPhone Preview에 사용 가능한 DisplayObject.cacheAsBitmapMatrix 속성에는 이러한 제한이 없습니다. cacheAsBitmapMatrix 속성을 사용하여 비트맵을 다시 생성하지 않고 객체를 회전하거나 크기를 조절할 수 있습니다. 이 속성은 GPU가 화면에 비트맵을 렌더링하는 데 사용되도록 하므로 성능을 향상시킵니다.
Example
Figure-1
가장 기본적인 cacheAsBitmap 사용예 입니다. cacheAsBitmap 을 활성화 해주면 성능이 좋아지는 걸 확인 할 수 있습니다. 하지만 cacheAsBitmap 을 활성화 한 상태에서도 rotation 이 들어가면 캐시를 다시 잡아야 하므로 오히려 성능이 떨어 집니다.
Figure-2
위와 같은 문제를 해결 할 수 있는 방법으로는 수동 비트맵 캐싱이 있습니다. 캐시를 미리 BitmapData로 만들어서 오브젝트를 그립니다. 이럴 경우 Figure-1 과 같이 매번 캐시를 다시 생성하지 않으므로 성능 저하가 덜 합니다. 흠.. 이건 이론상으로는 성능저하가 없어야 할 것 같은데 떨어지는 걸 보면 뭔가 완벽하진 않는 것 같네요;;;
Figure-3
맨 처음 잠깐 언급한 처음부터 png 파일로 가져오는 경우 입니다. png 파일이므로 cacheAsBitmap 을 활성화 하지 않은 상태에서도 괜잖은 성능을 보여줍니다. 하지만 이 경우도 cacheAsBitmap 활성화 된게 더 빠르네요. 또 한가지 재미난 점은 cacheAsBitmap 이 활성화 된 상태에서 rotation 이 비활성화 상태보다 빠르네요. 흠.. 이건 cacheAsBitmap 으로 보는 이득이 cache 보다 높기 때문일까요? 정확한 이유가 궁금하네요.
소스 다운로드 : cacheAsBitmap.zip
Conclusion
cacheAsBitmap 은 잘쓰면 약이 되지만 잘못쓰면 독이 될 수 있는 녀석입니다. 잘쓴다고 해도 성능을 위해서 메모리를 희생해야 하는 부분도 있습니다. 결국 개발자가 cacheAsBitmap 에 대해 정확하게 이해하고 필요한 시점과 상황을 잘 파악해 적재적소에 사용 해야 겠습니다. 물론 저도 아직 완벽하게 이해하고 있지는 못합니다 그러나 근본적으로 자신이 만든 소스가 최대한의 성능을 발휘 할 수 있도록 최적화 하는데 노력을 게을리 하면 안되겠습니다.
– 참고 –
http://help.adobe.com/ko_KR/as3/mobile/index.html
http://www.bytearray.org/?p=290
http://blog.jidolstar.com/382
http://blog.naver.com/q3korea/120119101146
http://blog.naver.com/jongx2/40018595325
지금까지 써온 아이폰 관련 글에 최종회 입니다. 파워플에 올린 글은 본인 블로그에도 못 올리는 엄청난 룰때문에 링크로 대신 합니다. 지금 당장 우리의 귀여운 도둑아찌를 구해주세요~ ㅎㅎㅎ
Jailbreak – Flash game for iPhone
]]>
새로운 앱을 소개합니다. 이름은 부엌1274 입니다. 부엌1274는 창성동에 위치한 쿠킹 스튜디오 부엌1274(http://blog.naver.com/buuk1274) 전용앱 입니다. 이 앱의 주요기능은 매주 업데이트 되는 도시락메뉴를 확인 할 수 있습니다. 이 외 부엌1274의 소개, 약도 그리고 갤러리 등의 컨텐츠가 있습니다. 안내페이지에서 바로 주문문의 버튼이 있으니 궁금하신 점은 직접 문의 해보시는 것도 좋을 것 같습니다.
앱스토어에서 부엌으로 검색하면 바로 나옵니다.
제가 만드는 앱들이 다 그렇지만 대부분 여러가지 개인 연구 목적으로 제작 되고 있습니다. 원래 이번 앱은 탭바컨트롤러, 외부 라이브러리, 서버자원 사용 을 주 과제로 제작하였습니다. 하지만 최종 결과물에서는 탭바컨트롤러가 빠지게 되었습니다. 이유는 첫 버전이 리젝을 당했기 때문입니다. 탭바컨트롤러 때문에 리젝을 당한건 아니고 전체 앱의 컨셉이 광고였기 때문입니다.
앱스토어에 광고성 앱을 못 올리는 것도 이번에 처음 알게 되었네요. 결국 원래 있던 기능을 많이 축소하고 매주 업데이트 되는 도시락 보기를 메인으로 강조해서 다시 신청하니 리뷰에 통과 했습니다. 앱스토어의 리뷰 기준은 결국 애플 맘이 이기는 하지만 어쨋거나 유저에게 유용한 기능을 가지고 있는 앱만 올리겠다는 애플의 의지가 새삼 놀랍네요.
그러므로 광고성 앱과 유용한 앱의 척도가 결국은 컨셉이라는 점에서 앞으로 만들 앱들의 컨셉도 신중하게 생각해 봐야겠습니다.
]]>맵핑이란 말 그대로 모델링 된 데이터에 다양한 메터리얼을 맵 해주는 것을 말합니다. 사실 이 맵핑이라는 주제는 책 한권을 가지고 모자른 엄청난 내용이므로 저는 아주 축소하고 엄청 겉핡기로 알아보겠습니다.
매터리얼 채널, 매터리얼 투사 방법은 위의 이미지에서 보듯이 엄청나게 많습니다. 하지만 그중 실제로 플래시에서 사용 할 수 있는건 매우 제한적입니다. 그간 플래시의 기능향상(픽셀벤터 같은)과 3D 라이브러리들의 발전으로 NormalMap 같은 것 까지 사용 할 수 있게 되었지만 그럼에도 전용 3D툴에 비하면 미약하죠. http://labs.adobe.com/technologies/flash/molehill/ 같은 프로젝트를 통해 GPU를 통한 성능개선이 이루어지면 더 많은 선택을 할 수 있게 될지도 모르겠습니다. 어차피 그래도 라이브러리들이 지원 해 줘야 겠지만요.
Away3D는 그 중 가장 많은 기능을 제공 하고 있습니다. 이중 큐브에 맵핑 할 수 있는 간단한 3가지 투사 타입에 대해서 알아보겠습니다.
1. Normal
기본형입니다. 사실 이건 투사라고 할 수 없습니다. 원래 투사라는 건 한장의 맵핑소스를 어떻게 모델에 투사 할 것이냐를 결정하는 것 이기 때문이죠. 기본형은 각 면에 각각의 메터리얼을 지정해줍니다. 각각 지정해 주지 않으면 한장의 메터리얼이 각각에 맵핑 됩니다. 기본적으로 다른 라이브러리들도 이 형태입니다. 정확하지는 않은나 Alternativa3d 경우는 이 옵션조차 없는 것 같더군요.
재미난 점은 Top 과 Bottom 이 바뀌어 나온 다는 점입니다. 이유는… 모르겠습니다. 이미지가 회전 되어있는 건 뒤에 설명하겠습니다. (메터리얼에 마우스를 올리면 크게 볼 수 있습니다.)
2. Map6
Away3D 에서 만 제공하는 독특한 타입입니다. 맵 한장으로 쉽게 맵핑 할 수 있습니다. hika 님이 알려주셨습니다.
mappingType property
mappingType:String [read-write]
Defines if the cube should use a single (3 cols/2 rows) map spreaded over the whole cube. topleft: left, topcenter:front, topright:right downleft:back, downcenter:top, downright: bottom Default is false.
이건 Top 과 Bottom 의 위치가 제대로 나오는군요. 이 Map6 의 단점은 큐브가 정육면체가 아니면 이미지 왜곡이 생긴다는 점입니다. 그래도 메터리얼을 하나로 끝낼 수 있다는건 큰 장점입니다. 이전 Papervision3D 를 쓸때는 주사위 하나 만들어 주려면 메터리얼이 6개 필요 했으니까요. ㅠㅠ
3. UV
이 UV 도 할 이야기가 많지만 잘 모르므로 역시 패스~;;; 간단히 설명하자면 3차원인 x, y, z 를 2차원인 u, v (, w) 에 매칭해주는 걸 말합니다. 이런게 필요한 이유는 당연히 맵 이미지가 2D 이기 때문입니다. 이 UV 는 기본 프리머티 오브젝트에서는 사용 할 수 없습니다. 그러므로 이 예제는 기본 큐브가 아니라 Collada 데이터 입니다. Front 대신 Left 가 정면으로 보이는데 아마도 Cinema4D 와 좌표계 차이로 그런게 아닌 가 싶습니다.
UV 를 사용하게 되면 투사를 원하는데로 매우 정확하게 할 수 있습니다. 각 Vertext 좌표들이 1:1로 맵핑되어 있으니까요. 그리고 위에서 볼 수 있듯이 맵핑소스의 왜곡도 피할 수 있습니다. 단점이라면 불필요한 여백과 데이터들이 생긴 다는 점입니다.
이 UV 예제를 만들면서 알았는데 Top 과 Bottom 부분의 UV 가 원래는 Right 쪽에 있더군요. 이걸 위의 그림처럼 Front 쪽으로 옮기면서 좌표를 회전 시켜줘야 했습니다. 이런 이유 때문에 처음 두 맵 이미지들도 Top 과 Bottom 을 회전 시켜 줘야 했던게 아닌 가 싶습니다. (역시 추측;;)
정말 3D는 해도해도 그 끝이 없는 것 같습니다. 간단한 육면체에 맵핑 할 수 있는 방법만 해도 수 없이 많을 걸 보면 말이죠. 간단하게나마 Away3D 에서 큐브에 맵핑하는 방법에 대해서 알아봤습니다. 각각의 방법에 모두 장단점이 있지요. 결국은 개발자가 필요한 상황에 맞게 선택 해서 사용 해야겠습니다.
]]>
위모트를 플래시에서 사용하기 위해서는 이전 아두이노 처럼 위모트와 플래시를 연결 해 줄 서버가 필요합니다. 아두이노의 경우 아두이노 자체 설정도 조금 해줘야 하지만 위모트의 경우는 단순 입력디바이스이기 때문에 서버만 실행하고 플래시에 클라이언트 설정만 해주면 매우 간단히 연결 할 수 있습니다. 얼마전 MAX 행사를 보니 앞으로는 플래시플레이어 자체에서 조이스틱을 지원할 듯 한데 위모트도 지원해 줄지는 모르겠네요. 뭔가 공통 인터페이스를 쓰는 조이스틱들을 지원해 주려나요? 여튼 그럼에도 불구하고 위모트는 참 매력적인 디바이스 입니다. 무선이라는 점도 큰 이점입니다.
1. Download
먼저 http://wiiflash.bytearray.org/?page_id=50 에서 WiiFlash 서버와 클라이언트를 다운 받습니다.
2. Wiimote
플래시 쪽에 클라이언트 세팅을 해줍니다. 위의 소스를 다운받으시면 상세한 예제가 있으니 그걸 참고해서 Wiimote를 만들어 주시면 됩니다. 아래는 최근 작업한 게임 소스 중 일부 입니다. 원래 키보드입력으로 작동하는 게임이라 간단히 ButtonEvent 를 KeyboardEvent 로 넘겨 주고 있습니다.
[as3]
private var wiimote:Wiimote;
public function Player(x:int = 0, y:int = 0)
{
// create a new Wiimote
wiimote = new Wiimote();
// connect wiimote to WiiFlash Server
wiimote.connect ();
wiimote.addEventListener( ButtonEvent.UP_PRESS, handleWiimotePress );
wiimote.addEventListener( ButtonEvent.UP_RELEASE, handleWiimoteRelease );
wiimote.addEventListener( ButtonEvent.DOWN_PRESS, handleWiimotePress );
wiimote.addEventListener( ButtonEvent.DOWN_RELEASE, handleWiimoteRelease );
}
private function handleWiimotePress(e:ButtonEvent):void
{
var keyCode:int;
switch(e.type) {
case ButtonEvent.UP_PRESS :
keyCode = Key.LEFT;
break;
case ButtonEvent.DOWN_PRESS :
keyCode = Key.RIGHT;
break;
case ButtonEvent.ONE_PRESS :
keyCode = Key.SPACE;
break;
case ButtonEvent.TWO_PRESS :
keyCode = Key.SPACE;
break;
}
FP.stage.dispatchEvent(new KeyboardEvent(KeyboardEvent.KEY_DOWN, true, false, 0, keyCode));
}
[/as3]
3. Bluetooth
위모트를 켜서 블루트스 장비에 등록합니다.
4. Server
서버를 실행해서 위모트를 연결합니다. 이제 이 서버를 통해서 플래시와 위모트가 통신을 할 수 있게 됩니다. 재밌는 것은 단순히 위모트에서 이벤트만 받는 것이 아니라 위모트로 피드백을 줄 수도 있다는 점 입니다. 위모트에는 기본적으로 진동기능이 있는데 이걸 플래시에서 제어 할 수 있습니다. 경험해보신 분은 아시겠지만 컨트롤러에 있는 진동기능은 사용자에게 확실한 피드백 경험을 할 수 있게 해서 매우 유용합니다.
5. Result
위모트와 플래시의 연동에 대해서 간략히 알아봤습니다. 위모트의 경우 당연겠지만 게임 컨트롤에 매우 좋은 사용자경험을 제공합니다. 물론 게임 컨트롤 외에도 다양한 시도가 이루어지고 있습니다. 위스프레이 같은 경우가 좋은 예일 수 있습니다. 키오스크 등의 프로모션 용으로의 활용도 괜잖을 것 같네요. 결국 아이디어 싸움이겠네요~ ^^
영상에 사용된 게임은 최근작업한 더블에이 게임입니다. 전체 게임은 아래 링크에서 즐길 수 있습니다.
더블에이 지구를 지켜라! 더블에이 쓰고, 이산화탄소 없애고~ Better Paper, Better World
http://www.doubleapaper.co.kr/betterworld/
이런 시점에서 Adobe Labs 에 Packager for iPhone 의 업데이트 되었습니다. 지금까지는 Flash CS5 를 이용해서만 앱을 만들 수 있었지만 이제는 Flash Builder 나 Flex SDK 를 사용하는 다른 툴에서 아이폰용 앱을 만들 수 있게 되었습니다. 그래서 Flash Bulider 에서 앱을 만들어보려고 Packager for iPhone 를 Flash Builder 의 SDK 에 넣었지만 당연하게도 탬플릿이 없어서 만들어 볼 수가 없었습니다. 제 기억에 Packager for Android 의 경우에는 xmp로 배포해서 Flash Builder 에 바로 설치 했던 것 같은데 말이죠. 그래서 일단 다른 템플릿을 찾아봤는데 다행히도 FlashDevelope용 템플릿을 벌써 누군가 만들어 놨더군요. 아마 다음버전에는 템플릿이 포함될 것 같습니다. 오늘은 이 FlashDevelop를 이용해서 앱을 만들어 보기로 하겠습니다.
그전에 잠시~
플래시가 스마트폰에서 돌아가는 걸 잠깐 살펴 보겠습니다. 플래시가 아이폰에서 돌아갈 수 있게 되서 1희1비 하시는 분들도 있을 것 같습니다. 하지만 실상은 그렇게 좋기만 한 건 아닙니다. 물론 앱스토어에 플래시를 올릴 수 있게 되었으니 플래시개발자로서 더 많은 기회를 얻은 것은 사실입니다. 하지만 그 기회가 그렇게 생각처럼 크지 않다는게 문제 입니다. 위의 표는 플래시가 스마트폰에서 구동되는 상태를 아주 대강 보여주고 있습니다. 각OS 가 있고 그 위에 VM 인 AIR 가 있습니다. 그 위에서 우리의 플래시 파일이 돌아갑니다.
1차문제는 각 폰의 스펙이 천차만별이라는 겁니다. 뭐 이건 노가다로 어느정도 해결 할 수 있습니다. 하지만 2차문제는 조금 본질적입니다. 우리가 플래시에서 구현 할 수 있는 액션은 OS 와 SWF 중간에 있는 AIR에 의존적입니다. 근데 이 AIR 가 폰의 모든 기능을 소화해 주지 않는 다는 겁니다. 예를 들자면 제 아이폰은 500만 화소의 카메라가 있지만 AIR 는 카메라를 지원하지 않습니다. G센서라던가 GPS 모두 지원하지 않습니다. 결국 스마트폰을 그닥 스마트하게 사용 할 수 없게 되지요. 아래는 AIR 에서 지원하지 않는 기능 목록입니다.
물론 앞으로 버전업을 하면서 지원여부가 어떻게 될지는 모르겠습니다. 그리고 기존 AIR 에 없던 기능들도 아이폰용으로 추가된게 있는 걸 보면 각 OS별로 AIR의 지원스펙이 다르게 나올 수도 있을 것 같습니다. 여튼 결론은 Object-C 같은 Native 언어로 만드는 앱과 플래시로 만드는 앱의 성격이나 기능이 분명히 나뉠 거라는 겁니다. 이에 플래시개발자들은 프로젝트의 요구사항을 잘 판단해서 앱개발을 해야 될 것 같습니다.
서론이 상당히 길어졌는데 본론인 FlashDevelop에서 앱만드는 과정을 살펴 보겠습니다. 우선 먼저 준비물들 입니다.
- Flex 4 SDK – http://www.adobe.com/cfusion/entitlement/index.cfm?e=flex4sdk
- Packager for iPhone – http://labs.adobe.com/downloads/packagerforiphone.html
- FlashDevelop – http://www.flashdevelop.org/community/viewforum.php?f=11
- FlashDevelop iPhone Project – 090-ActionScript-3-iPhone-AIR-AS3-Projector
- .p12 & .mobileprovision
5번의 인증서는 제가 전에 올린 글을 참고 해서 만들면 됩니다. (Flash CS5 iPhone os settings) 이제 모든 준비물이 준비되었습니다.
아래 내용과 이미지는 http://blubl.geoathome.at/2010/09/flash-iphone-entwicklung-mit-flashdevelop-und-dem-adobe-packager-for-iphone/ 를 수정, 변경 한 것임을 먼저 알립니다.
Flex 4 SDK 와 Packager for iPhone
제일 먼저 다운받은 Flex 4 SDK 폴더에 Packager for iPhone 를 복사해서 합칩니다.
FlashDevelop iPhone Project Template
FlashDevelop 프로젝트를 다음의 경로에 복사합니다.
C:[FlashDevelop]FlashDevelopProjects
이제 프로젝트 생성 메뉴에서 iPhone 프로젝트를 볼 수 있습니다.
Flex SDK 경로 수정
아이폰 패키지가 들어가 있는 SDK로 경로를 자신에 맞게 수정합니다. 위치는 다음과 같습니다. Project -> Properties… -> “Compiler Options” -> “Custom Path to Flex SDK”
PackageApplication.bat 수정
PackageApplication.bat 파일 13번줄의 Flex SDK 위치도 변경해줍니다. 주의할 점은 경로에 bin 폴더까지 포함 된다는 점 입니다. 사실 이 배치파일이 이 템플릿의 핵심이 아닐가 싶습니다. 요것만 있으면 Flash Builder에서 만든 swf 를 ipa 로 바꿀 수 있으니까요. Flash Builder 의 프로젝트 SDK 와 ADL 도 경로만 수정해 주면 될 듯 합니다.
인증서 복사
swf 를 만들고 테스트 하는데 까지는 인증서가 필요 없지만 .ipa로 만들기 위해서는 반드시 인증서 파일이 필요합니다. 인증서 파일을 “certificates” 폴더에 복사합니다. 인증서 이름은 “iphone_dev.p12” 와 “iphone_dev.mobileprovision” 로 변경합니다. 이 파일 이름은 PackageApplication.bat 에 정의 되어 있습니다.
SWF 테스트
이미 프로젝트 탬플릿에 텍스트가 들어가 있으니 바로 빌드를 해봅니다. 만약 정상적으로 “Air Debug Launcher” 를 실행시키지 못한다면 Project -> Properties… -> Test Movie… -> “Run custom command…” -> Edit 에서 아이폰패키지 SDK 의 ADL.exe 를 실행 할 수 있도록 경로를 수정합니다.
.ipa 만들기
PackageApplication.bat 을 실행합니다. 만들 ipa 의 종류를 묻는 질문이 나옵니다. 해당상황에 맞게 선택합니다. 각 옵션이 정확하게 어떤차이가 있는지 정확히는 모르겠습니다. 다만 test 의 경우 컴파일 시간이 짧은 대신 최종 ipa 의 용량이 조금 큽니다. store 의 경우 는 반대로 컴파일이 오래걸리고 ipa 용량이 조금 작습니다. store의 경우 아마 컴파일을 최적화 해 주는게 아닌가 싶습니다.
please be patient~ ㅎㅎㅎ
드디어 그토록 원하던 ipa가 생성 되었습니다.
해당 파일은 아래의 위치에 생성됩니다.
다음에는 실제로 ipa를 만들어 아이폰에서 구동되도록 만들어보고 이때 주의할 점과 팁을 알아보도록 하겠습니다.
]]>
지난 7월 23일 홍대에 와우산107 이라는 나이키 스포츠웨어 매장이 생겼습니다. 그러면서 한달간 티프로젝트 라는 이름으로 대대적인 프로모션을 진행하였습니다. 여기에 등장한게 바로 모모트 입니다. (http://blog.naver.com/nswblog/50095307516) 우연히 홍대 앞을 거니달가 이 프로모션을 발견하였고 저는 그동안 제가 연구(?)해 오던 3D 애니메이션을 Flash 에 적용 시키는 작업을 이 귀여운 종이인형에 적용시켜 보기로 마음 먹었습니다. 그렇게 해서 탄생하게 바로 Dance MOMOT 입니다.
작업과정을 간략히 설명 하면 우선 모델링을 합니다. 그리고 먼저 사용할 Mocap 데이터를 구합니다. 직접 만들거나 쓰기편한 상용 데이터를 쓰면 좋겠지만 제 경우는 웹상에 있는 무료 데이터를 이용하였습니다. 이럴 경우 Mocap 의 본이 제 각각인 경우가 많습니다. 해서 실제로 쓸 Mocap 데이터를 구하고 그에 맞게 모델링에 Joint 를 심어 주었습니다. Joint 와 Mocap 의 본은 그 구조가 정확하게 일치 하여야 합니다. 그 이유는 Mocap 의 애니메이션 데이터를 Cinema4D 의 Retarget 태그를 이용해서 전이 시킬 것 이기 때문입니다. 이 Retarget 을 위해 뭔가 더 좋은 툴이 있을 것 같지만 찾지를 못하였습니다.
Mocap 을 이용한 애니메이션은 쉽고 빠르게 만들 수 있다는 장점이 있지만 DAE 파일이 엄청나게 커진다는 단점이 있습니다.(프레임 마다 각 Vertex의 정보를 지정합니다.) 이러한 최적화 문제는 좀더 고민해 봐야겠습니다.
Nike, MOMOT 의 모든 권리는 해당 회사에 있습니다.
]]>2010년 7월 8일 5시 27분 추가
어제 Frash 에 관한 글을 올리고 금일 바로 테스트에 들어갔습니다. 다른 회사일도 밀려 있는데 너무 해보고 싶은 얼리정신에 다른 일 다 팽개치고 일단 테스트 들어갔습니다. 우선 처음 시도는 http://wiki.github.com/comex/frash/configuring-and-installing-frash 에 나와있는 방벙을 시도 했습니다. 하지만 역시 뭔지도 모르고 따라하려니 결국 빌드에 실패했습니다. 이렇게 포기해야 하나 하던 중 아이패드에서 플래시 보는 법~~~ 이라는 글을 발견했습니다. 오~ 이미 어떤 착한 분이 .deb 파일을 만들어 놨군요. 언능 받아서 설치해 보았습니다. Frash 를 설치하기 위해서는 다들 아시다시피 iPad 를 탈옥해야 합니다. 이 과정에 한번 별돌 만들어서 데이터 다 날려먹고 결국 복구 했습니다. 중간에 복구하면 앱을 다시 사야한다는 무시무시한 경고문이 있었지만 막상 복구 하고 복원해서 앱을 다시 동기화 해서 넣으니 무사히 들어갔습니다. (아 살떨려라~~) 여튼 다행히도 상당히 쉽게 Frash 를 설치 할 수 있었습니다.
Flash가 있는 페이지에 들어가면 위의 이미지 처럼 Flash 로고가 보입니다. 바로 실행은 안되더군요. 아이콘이 있는 Flash 영역을 한번 클릭해 주면 드디어 사파리에서 Flash 를 볼 수 있게 됩니다.
iPad 에서 처음 만난 Flash 가 광고라는게 좀 찜찜하지만 온라인광고에서 Flash 가 차지하는 파이가 엄청나다는 점을 감안하면 쉽게 이해 할 수도 있을 것 같습니다. 특히 베너의 경우 일단 Flash 버전이 낮고 최대한 경량화 되어있기 때문에 테스트용으로 나쁘지 않은 것 같습니다.
우선 제가 가장 궁금했던 퍼포먼스는 참 뭐라 해야 할지.. 이건 나쁜것도 아니고 좋은 것도 아니여;;; 일단 애니메이션 속도는 확실히 불편함 없이 빨랐습니다. 다만 필터나 큰이미지 트랜지션에서는 확연히 느려지는 느낌이었습니다. 알려진대로 flv 재생 안되고 as 도 정상적으로 작동하지 않는 것 같습니다. 특히 큰 문제는 키보드 입력은 아직 안되고 마우스 입력(터치)도 제대로 되지 않는다는 점입니다.
개인적으로 이번 사파리에서 Flash 가 되는 것은 매우 큰 사건이라고 생각합니다. CS5 에서 앱만들어서 올리는 삽질 없이 간단한 데모나 테스트는 그냥 바로 할 수 있게 되었으니까요. 된다와 안된다의 차이는 엄청납니다. 다만 앞으로 얼마만큼의 성능 개선이 이루어질지가 기대되는군요.
iPad
iPhone
프로젝트 사이트 : http://github.com/comex/frash
]]>