Try & Error

링크 : http://v-play.net/2015/06/16-sites-featuring-free-game-sounds/

개발자를 위한 16개의 무료 사운드(로얄티 프리) 웹사이트를 모아놓았다고 합니다.

링크 : http://betrayrokeu.tistory.com/entry/NGUI-%EC%8A%A4%ED%81%AC%EB%A1%A4%EB%B7%B0-%EC%9E%AC%EC%82%AC%EC%9A%A9

시작하는 프로그래머를 위한 10원짜리 조언 몇 개…
by 신영진(YoungJin Shin), codewiz at gmail.com, @codemaru, http://www.jiniya.net

개인적인 경험에 기반에 쓴 것이니 너무 심각하게 받아들이진 말자. 모든 글이 그렇지만 취할건 취하고 버릴건 버리면 된다. 직접 해보니 도움이 된 것들도 있고, 지금 시점에 돌아보니 했었으면 더 좋았을 것 같다고 느낀 것들도 있고 그렇다. 참고로 태생적으로 머릿속에 포인터와 재귀 호출 스택 프레임이 내장된 프로그래머들을 위한 글은 아니라는 점 명심하자!!!

#0
연애를 하자. 대다수 프로그래머들의 커뮤니케이션 스킬은 다른 직종 사람들에 비해서 떨어지는 것이 사실이다. 인정할 건 인정하자. 그런 점들을 보완해주는데 연애만큼 좋은게 없다. 그리고 자신의 바닥도 보고 겸손해지기도 한다는 점에서 여러 좋은 점들이 있으니 프로그래밍 공부만큼 연애에도 관심을 가지고 꼭 해보기를 추천하고 싶다. 특히 요즘은 돈 든다고 안 하는 추세도 있는것 같은데 그 돈 투자해 보는게 손해는 아닌 것 같다.

#1
빨리 시작하는 편이 유리한 건 어쩔 수가 없다. 대학교때 컴퓨터 학원에서 C언어를 일년정도 가르친 경험이 있다. 그때 난 어른과 어린 학생들 사이의 명백한 차이가 있는 걸 알게 되었다. 어른들은 무엇인가 자신이 납득할 수 있는 이유가 없다면 잘 받아들이지를 못하고, 또 지루한 과제를 반복하지 못한다는 특징이 있다. 천재 프로그래머인 리누스 토발즈도 그의 자서전에서 밝혔지만 처음 작성한 프로그램은 Hello, World였다. 어린 학생들은 그 단순한 Hello, World 조차도 글자를 바꿔가면서 만드는 과정에서 재미를 느끼는데 어른들은 그렇지가 않다. 그래서 연습이 부족해질수밖에 없고 그러니 당연히 진도가 더디다. 어리다는 것은 지루한 것도 반복할 만큼 호기심이 많다는 것을 의미하기 때문에 지루한 초반 과정을 버티는데 정말 좋다. 더불어 시간이 많다는 것도 장점이다.

#2
늦게 시작했더라도 체력이 좋다면 다행이다. 고등학교 때 알던 녀석 중에 한 명이 2년 내도록 놀다가 3학년 때 일년 바짝 공부 해서 의대를 간 녀석이 있었다. 사실 그 누구도 그 녀석이 의대에 진학할 것이라고는 생각지도 못했었기에 다소 충격이었다. 물론 같이 놀았던 친구 녀석들은 부러워 한 정도로 끝났지만 3년 내도록 공부하고 수능을 망친 친구들의 상실감은 이루 말할 수가 없었다. 그 의대에 간 녀석의 장점은 강철 체력이라는 점이었다. 남들이 하루 밤샐 수 있다면 녀석은 3일쯤은 거뜬히 멀쩡하게 밤샐 수 있었다. 대학교 때에도 비슷한 선배가 있었다. 늦게 프로그래밍을 시작했는데 전산소에서 일주일씩 밤새는건 기본인 선배였다. 이상엽씨가 쓴 Visual C++ 6.0 바이블 한글 파일을 들고 다니면서 하루종일 전소에 앉아서 코딩을 하곤 했었다. 난 다소 의아했었는데 지금은 MIT에 유학을 갔던 정말 똑똑한 형이 옆에서 그랬다. 저렇게 체력이 좋은 아이들은 이길 수가 없다고… 그러니 체력 관리가 중요하다.

#3
책을 많이 읽는 것이 여러모로 도움이 된다. 책을 읽는다는 사실이 여러분을 더 똑똑하고 유능한 프로그래머로 만들어준다는 것을 의미하진 않는다. 하지만 적어도 바보같은 프로그래머가 되지 않도록은 만들어 준다는 점에 50원 정도는 걸 수 있을 것 같다. 그러니 책을 부지런히 읽자.

책을 많이 읽지 않는 사람들이 하는 흔한 실수 중에 하나가 이해가 되지 않는다고 계속 1장만 보는 것이다. 모든 것은 유기적으로 연결되어 있으니 당장 이해가가지 않는 부분은 냅두고 끝을 향해 달려가자. 끝을 보고 나면 자연스레 1장은 저절로 이해가 되기 마련이다. 참고로 그때도 이해가 되지 않으면 한번더 끝까지 보면된다.

#4
영어를 잘하는 것이 막판 광역 버프를 받는 지름길이다. 직업 프로그래머를 하면서 다양한 프로그래머들을 만났다. 그중에 더러는 늦게 프로그래밍을 시작한 사람도 있었고, 나보다 훨씬 더 일찍 시작한 사람도 있었다. 그런데 한 가지 신기한 사실은 처음에는 실력 차이가 많이 나는데 한 3년 정도가 지나면 거의 실력이 비슷해진다는 점이었다. 그때부터는 누가 언제 시작했는지 보다는 해당 도메인 지식을 누가 더 빨리 습득할 수 있는가가 실력을 결정짓는 주요한 요소가 된다. 안타깝게도 거의 모든 프로그래밍 자료는 영어인 경우가 대부분이다. 따라서 나중에 줄창나게 버프를 받기 위해서는 영어는 필수적으로 할 수 있어야 한다.

#5
대학 교육을 받는 대부분의 프로그래머들은 기본적인 전산 지식을 중요하게 여기고 도메인 지식을 가볍게 여기는 경향이 있다. 하지만 아이러니하게도 대부분의 경우에는 기본적인 전산 지식보다는 도메인 지식이 중요하다. MS나 구글같은 회사에서 도메인 지식보다 기본 지식을 가진 똑똑한 직원을 뽑는다는 소리를 듣고 그게 중요하다고 생각하는 경우가 많다. 그런데 정말 아주 많이 안타까운 사실은 우리 대부분은 그런 똑똑한 사람들이 아닌 경우가 많다는 점이다. 현실을 직시하자. 평범한 우리들은 기본 전산 지식만 가지고 있는 상태에서 도메인 지식을 그 독똑한 친구들이 하듯이 스펀지처럼 빠르게 빨아들일 수 있는 능력이 없다. 그러니 자신이 하고 싶은 도메인을 일찍 정하고 해당 지식을 빨리 습득하는 것이 중요하다. 백신 업체에 취직하고 싶은데 그림판만 매일 만들고 있는건 도움이 되지 않는다는 말이다. 물론 이 말이 기본 지식이 중요하지 않다는 것을 의미하진 않는다. 컴퓨터 공학과에서 열심히 공부한 대다수 졸업생의 기본적인 전산 지식은 도찐개찐인 경우가 많기 때문에 그게 여러분을 돋보이게 만들어주지 않는다는 의미다.

#6
코드를 많이 읽는 것이 중요하다. 대학을 졸업한 대부분의 프로그래머가 오픈소스 프로젝트 코드를 수정하는 것은 둘째치고 읽지도 못하고 심지어는 빌드도 못하는 경우가 많다. 이는 정말 큰 문제다. 적어도 여러분이 직업 프로그래머를 하려고 한다면 기본적인 코드는 읽고 이해하고 수정하는 것이 가능해야 한다. 여러분의 경력 대부분의 시간 동안 새로운 코드를 쓰는 시간보다는 다른 사람이 이미 만들어둔 코드를 수정하고 고치는 작업을 하는 경우가 많기 때문이다. 남이 작성한 코드를 읽고 이해하는 능력이 없다면 직장 생활 자체가 매우 힘겨워질 수 있다. 자신이 주력하는 분야의 오픈 소스 코드를 매일 일정 분량 이상씩 읽도록 하자. 물론 참여하기까지 한다면 금상첨화다.

#7
코드를 읽는 것 만큼이나 쓰는 것도 중요하다. 많은 사람들이 생각을 잘 하면 코딩도 잘 할거라 전제하는데 생각하는 것과 코딩하는 것은 조금 다른 측면이 있다. 머리보다 손이 기억한다는 말이 있다. 그러니 알고 있는 것이라도 반복적으로 구현해 보는 것이 좋다. 그리고 심심할 때 유용하진 않더라도 작은 프로그램을 직접 많이 만들어 보도록 하자. 코딩도 연습할 수 있고 전체 프로젝트를 기획부터 릴리즈까지 해볼 수 있는 좋은 훈련이 된다.

#8
블로그나 위키를 만들자. 그리고 그곳에 자신이 공부한 것들을 정리해서 올려놓자. 이건 정말이지 여러가지 장점이 있는데 1) 세상 사람들이 내가 무슨 일을 했는지 알 수 있게 해준다, 2) 긴 글을 작성하는 훈련을 할 수 있다, 3) 나만의 지식 기반을 구축할 수 있다, 등등 장점은 수도 없이 많다. 그러니 꼭 이 활동을 지속적으로 하자. 보는 사람이 없어도 꾸준히 하는 것이 중요하다. 그리고 본인 생각에 정말 보잘것 없는 것들도 무조건 올리도록 하자. 우리가 구글링해서 알 수 있는 대부분의 지식은 다른 사람들이 그렇게 별 볼 일 없다고 생각하면서 올려둔 지식인 경우가 대다수다. 하찮다 생각하지 말고 꾸준히 정리하고 공개하는 습관을 들이도록 하자.

#9
다양한 문화 생활을 경험해 보자. 드라마도 보고, 영화도 보고, 미술관도 가고, 뮤지컬도 보고, 음악회도 가고, 콘서트도 가고, 만화책도 보고, 게임도 하자. 다 피가 되고 살이 된다. 개그콘서트와 웃찾사를 보는게 꼭 시간 낭비만은 아니다. 오히려 컴퓨터만 주구장창 하는 사람들보다 더 넓은 시각을 가질 수 있게 만들어 준다는 점에 100원은 걸 수 있다. 파이썬 개발자 귀도 반 로섬도 몬티 파이썬의 팬이었다. 그러니 맘놓고 보자. 스트레스 해소도 하고… ㅋㅋㅋ~

#10
컴퓨터 공학과를 졸업한다고 모두 프로그래머가 되어야 하는 것은 아니다. 컴퓨터를 좋아한다고 프로그래머가 되어야 하는 것도 아니다. 그리고 심지어는 프로그래밍이 좋다고 직업 프로그래머가 될 필요가 있는 것도 아니다. 직업 프로그래머가 되는 것에 관해서 진지하게 생각해보자. 그리고 학교에서 시간이 있을 때 아르바이트던 인턴이던 직업 프로그래머로써의 경험을 조금은 가져 보는 것이 좋을 것 같다. 돈을 받고 일을 한다는 것이 어떤 느낌인지에 대해서 약간은 알아둘 필요가 있기 때문이다. 아마도 재미삼아 만들때와는 사뭇 다른 느낌인 경우가 대부분일 것이다.

Read more: http://www.jiniya.net/wp/archives/10460#ixzz3dmThVhhM

링크 : http://blog.naver.com/blue9954/220393256568

참조 : http://blog.naver.com/blue9954/220391202268

A lot of people in the use of NGUI time, released to the device that the picture becomes fuzzy, below is a simple method to correct the problem.

This refers to the automatic generation of NGUI Atlas Texture.

The following:

1, Texture Type, Use Advanced to display all properties

2, Generate Mip Maps, UI don't need, so check out.

3, FilterMode, Select the Bilinear would be more clear

4, Max Size, Depends on your target platform, general control in 2048 words can be suitable for the majority of mobile platform

5, Format, Depending on the original mass of your picture, Automatic Truecolor is the best, but the picture is also the largest.

출처 : http://www.programering.com/a/MzM5ADNwATc.html

Unity3D v.3.5.5f3 Pro / iOS Pro (with 2D ToolKit) 기준.

1. 이미지 자체 최적화

png 등의 이미지를 import 하면 압축된 용량이 아닌 원래 용량으로 인입됨.

아이폰의 경우 pvrtc로 압축하여 용량 줄일 수 있음.

256 x 256 size 이미지 크기 비교

 - RGBA 32bit : 256 kb

 - RGBA 16bit : 128 kb

 - RGBA Compressed PVRTC4 : 32 kb

 - RGBA Compressed PVRTC2 : 16 kb

texture type 설정

 - GUI/HUD 용도로 사용하는 이미지는 GUI로 설정 (이미지 품질이 가장 좋음)

 - 그 외는 Texture 혹은 Advanced 선택

   - Advanced는 Texture 설정에서 사용자가 옵션 선택 가능

   - Advanced에서 "Generate Mip maps" 설정을 해제하면 용량을 줄일 수 있다. 

    (2D에선 불필요. 게임 화면과 카메라와의 거리를 가깝게 잡은 경우 화질 개선에도 도움이 됨)

이미지 비율 조정

 - Unity3d에서는 한 변의 길이가 2의 배수인 정사각형으로 이미지를 사용하게 됨. (2, 4, 8, 16 …)

 - 압축할 때 이를 2의 배수인 정사각형으로 늘려주므로 정사각형 안에 들어가도록 사용할 것.

   - 9 x 9 이미지는 16 x 16 으로 늘어나게 됨.

   - 툴을 통해 이미지 병합시 만약 8 x 16 처럼 비율이 맞지 않을 경우 동일하게 16 x 16으로 늘어나므로

     8 x 8 두장 혹은 다른 이미지를 더 합쳐 16 x 16으로 만드는 것이 용량면에서는 좋음 (성능과 반비례)

   - 실제 1024 x 1024 altas를 PVRTC4로 압축시 용량은 0.5 mb정도 (2048 x 2048 : 2mb)

2. 이미지 화질과의 상관관계

개별 이미지를 atlas로 합치는 것이 성능 면에서는 도움이 됨.

 - but atlas size가 커질 경우 화질이 떨어질 수 있음. (정확한 원인은 파악 못함)

 - 개인적인 관점에서 1024정도가 적당한 듯. (2048 이상일 경우 화질 저하 정도가 꽤 큼)

 - 4096 사이즈의 경우는 iphone에서 이미지가 보이지 않음

    - Edit / Graphic Emulation 설정을 No emulation으로 설정할 경우 보인다는 글이 있었으나 적용해도 보이지 않아 실패함.

3. 용량 & 성능

이미지를 import하고 이를 atlas로 병합하는 과정을 거칠 경우 원본 이미지가 프로젝트에 포함되어 있을 수 있음.

 - 실제 build시 unity에서 사용하지 않는 이미지는 포함시키지 않게 되어 있으나

   Asset 폴더 내에 Resource 폴더가 있을 경우 Resource 폴더 내의 모든 내용은 강제로 프로젝트에 포함됨. (동적 로딩용)

 - 원본 이미지를 별도로 압축하지 않은 경우 앱 용량이 매우 커질 수 있음. =_=

iOS build 시 설정

 - Target Device : iPhone / iPad보다 iPhone 혹은 iPad 단독으로 설정

 - Target Platform : armv6 < armv7 < armv6 & 7

 - Api Compatibility Level : .NET 2.0 Subset < .NET 2.0

 - Stripping Level : Use micro mscorlib < Strip ByteCode < Strip Assemblies < Disabled

 - Script Call Optimization : Fast but no Exceptions < Slow and Safe

출처 : http://neojsm.tistory.com/10

약 2~3 주 전 빌드를 하다 보니 apk 파일 용량이 50MB 가 넘어가는 상황이 벌어졌다....

(google 정책상 50 MB가 넘어가면 안된다고 한다 )

당장 내일이 업데이트라 급한대로 부랴부랴 별로 티 가 나지 않는 아이콘 이미지들의 크기를 줄여서

빌드를 해서 간신히 50MB 이하로 줄이긴 했지만

앞으로 추가적인 콘텐츠에 의해 이미지 들이 추가 될 시에 같은 문제가 발생할거 같기에 

대처방안이 필요했다.

대부분의 리소스 파일들은 CDN 서버에서 다운 받아 사용하는 방식을 쓰고 있으니

제일 큰 용량을 차지하는 Atlas 파일들 또한 CDN 서버에서 다운 받아 로드 하는 방식으로 변경하면

될거 같기에 구글링을 시작 하였다. 

찾아 보니 의외로 간단 하였다

Unity Pro 에서는 assetbundle 파일을 만들기 및 로드하기가 된다고 한다 (Unity Basic 버전에서는 안된다고 한다 실제 테스트 는 해보진 않았다 ) 

1.스크립트 작성 (AssetBundle Create)

Atlas 가 있는 프로젝트 내부에 위와 같은 스크립트를 넣기만 하면 

유니티 상단의 메뉴 바에  Export 라는 항목이 생길것이다 

2. AssetBundle 생성하기 

그 다음은 프로젝트 뷰에 있는 아틀라스를 선택후 상단의 새로만든 Export메뉴를 눌러서

저장할 위치를 정하고 저장을 누르면 AssetBundle 이 생성된다

이때 중요한건 Atlas는 3가지로 구성되어 있따 GameObject(Prefab), Material, Texture 로 이루어져있는대

AssetBundle을 만드는건 GameObject만 선택한 상태로 만들면된다. 

또한 각각 GameObject , Material, Textture 의 이름은 달라야 한다 . 

예를들어 Atlas_Test_go, Atlas_Text_mat, Atlas_Test_tex, 이런식으로 이름을 다르게 해야 한다 이름이 같으면 잘안된다는대 이는 직접해보진 않고 처음부터 따로 이름을 바꾼뒤 어셋번들을 생성하였기에 이것은 궁금 하신분은 직접 해보도록..

또한 GameObject가 아닌 Material 이나, Texture로만 Assetbundle을 뽑아서 로드 하려고하면 실제 궁극적으로 필요한 Ngui의 UIAtlas 라는 객체가 없어서 필요한 Sprite에 Atlas를 세팅할수 없다.

GameObject 만 AssetBundle 을 생성하여도 AssetBundle 을 뽑는 함수의 옵션 때문인지 하위의 정보들도 같이 합쳐져서 만들어 지는 거 같다. 실제로 해당 파일을 로드할때 디버깅을 하면서 보니 로드된 목록에 Texture 와 Material이 포함되어 있었다.

3. Atlas 를 로드 해보자.

당연 하지만 위 소스 중에 _resourcepath 는 실제 AssetBundle 파일이 있는 장소여야 한다. 해당 경로에서 해당 확장자를 가진 ( 확장자를 .dp로 하였기에 해당 확장자를 긁어 모았다 ) 

읽어 들인뒤 로드하였다 이떄 ab.Load() 함수를 사용하였는대 AllLoad()를 사용하게 되면 해당 파일의 어떤 것들이 담겨져 있는지 보이는대 이를 디버깅으로 까보면 확실히 기억은 안나지만 5~6개의 파일들이 담겨져 있던걸로 기억한다.

하지만 우리가 필요한건 Atlas GameObject 이기에 typeof(GameObject)로 골라내어 로드한후 해당 Gameobjcet 의 UIAtlas  객체를 뽑아내어 Atlas 목록에 넣고 있다. 

4. Load  한 Atlas 적용하기.

이제 우리가 마지막으로 원하는건 로드한 Atlas 를 써먹는거다 .

위와 같은 간단한 소스를 만들어서 Sprite 에 넣어주면 해당 Sprite 가 Awake 될때 

에디터상의 세팅된 AtlasKind에 따라 자기 자신의 Atlas 를  세팅하고 Sprite 이미지 까지 

지정된 이름으로 세팅한다.

 - 잡소리

이러한 Atlas 를 외부에서 로드해서 사용하는 것들은 이미지들이 더 추가될 가능성이 낮고 

또한 실제 이런 이미지들을 사용하는 것들이 런타임 도중 동적으로 이미지가 바뀔 가능성이 

낮은 것들을 위주로 하였기에 ( 또한 아틀라스가 로딩 되기전에 보여지는 이미지가 아닌 것들 )

Awake 함수에서 한번 로드된 아틀라스 로 자기 자신의 아틀라스와 이미지를 세팅하고

끝내는 방식으로 하였다

당연히 아틀라스를 로드 하기전에 보여져야 되는 이미지들은 이런식으로 하면안된다

(로고라던지, 로딩 화면이라던지)

또한 이미지가 런타임 도중 계속 바뀌어야 하는 것들 인벤창의 아이템 이라 던지...

이런 것들은 이미지가 추가될 가능성도 높고 이미지들이 바뀌거나 세팅 되거나 하기전에 가장먼저

Atlas가 세팅되어야 하므로 ( 아틀라스가 세팅되기전의 해당 Sprite의 이미지를 바꾸거나 한다면...

Error가 나던가..? 아마 안나긴 할거다 하지만 아무런 이미지도 보이지 않을거다 ) 

신경써야 되는 부분이 더 생길거 같기도 하고 아이템아이콘 같은경우 사용하는 부분이 너무 많아 그런 여러곳을 전부다 찾아가며 테스트 해보기 귀찮아서 

간단하고 바뀔일 없고 이미지는 커서 용량을 많이 차지하는 것들 로 해당 작업을 하였다.

위의 소스들을 그대로 쓴다면 아마 안될거다(Export스크립트 제외 ) 

그러니 안되는건 레퍼런스를 참조해보도록.... 

출처 : http://chocotart.tistory.com/entry/NGUI-Atlas-Assetbundle-%EB%A7%8C%EB%93%A4%EA%B8%B0-%EB%B0%8F-%EB%A1%9C%EB%93%9C-%ED%95%98%EA%B8%B0

[기존 소스에 일부 코드 수정]

스크롤뷰 아이템을 재사용 할 수 있게 해주는 스크립트 입니다.

인터넷에 이미 몇가지 있는 걸로 알지만, 제가 쓰고 있는 것도 공유해 봅니다.

사용법은 간단합니다.

스크립트에 멤버 변수로 CUIListView를 등록하면 다음과 같이 나옵니다. 

Item List - 스크롤뷰가 포함되어 있는 오브젝트.

Item - 리스트로 출력할 프리팹.

Add Row of Column - 0일 경우 View사이즈에 딱 맞게 아이템을 생성해줍니다. 이렇게 되면 아이템 재사용이 제대로 동작하지 않으니, 1이나 2로 지정합니다.

Item Padding - 아이템 사이의 간격입니다. 알아서 다 맞춰주기 때문에 Grid 사용하지 않아도 됩니다.

Scrollbar - 스크롤바가 있을경우 지정해줍시다.

그리고 UIPanel의 offset과 Center 좌표는 0으로 두는게 좋습니다. 패널 위치를 옮기려면 게임오브젝트의 좌표를 움직이는게 좋습니다.

using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public class CListViewTest : MonoBehaviour
{
    public CUIListView m_ListView;

    private List m_ItemList = new List();

    void Start ()
    {
        for(int i = 0; i < 500; ++i)
        {
            m_ItemList.Add(i);
        }

        m_ListView.OnUpdateItem = OnUpdateItem;
        m_ListView.OnGetItemCount = OnGetItemCount;

        m_ListView.Init();
    }

    public void OnUpdateItem(int index, GameObject go)
    {
        CListViewTestItem item = go.GetComponent<CListViewTestItem>();
        item.m_Label.text = index.ToString();
    }

    public int OnGetItemCount()
    {
        return m_ItemList.Count;
    }
}

public class CListViewTestItem : MonoBehaviour
{
    public UILabel m_Label;
}

코드는 위와같이 작성합니다. 

OnUpdateItem - 아이템이 갱신될 때 호출됩니다. 나머지 부분은 직접 구현하시면 됩니다. 

OnGetItemCount - 리스트의 전체 개수가 필요할 때 호출됩니다.

추가로 Refresh와 Reset, SetFocus 함수가 있는데 필요에 따라서 호출하여 쓰시면 될 것 같습니다.

미구현 기능 및 버그

- 스크롤 바를 클릭해서 뷰를 이동하는 기능. 이 기능을 쓸일이 없고 작업하기도 힘들어서 구현하지 않았습니다.

- 아이템이 한페이지 이상 삭제되었을 경우에 Refresh를 호출하면 뷰 이동이 안되는 버그. (이런 경우에는 Reset을 쓰는 걸 추천).

2015. 4. 15 업데이트

아이템이 리스트에 딱 맞게 설정되어 있을 경우에 스크롤이 되는 버그가 있어서 수정하였습니다.

2015. 5. 26 업데이트

아이템의 크기가 뷰사이즈 보다 작을 경우 드래그가 불가능 하도록 스크롤뷰를 disable 시키는 기능 추가.

SetFocus(0); 을 호출 할 경우 0번째 아이템이 화면 중앙에 위치하는 버그 수정.

출처 : http://kheldon.tistory.com/2

참조 : http://blueasa.tistory.com/1777

참조 : http://www.tasharen.com/forum/index.php?topic=10223.0

[파일]

이전에 포토샵의 Overlay와 비슷한 느낌의 Shader가 필요해서 찾아서 올려놨는데 NGUI 패널에서 클리핑이 안돼서

수정 및 추가해서 올려 놓음.

요즘 텔레그램 스티커가 생겼길래

출처 : http://honeycast.kr/bbs/board.php?bo_table=tip&wr_id=326