유니티 (Unity) 2D 모바일 게임 최적화 팁 & 체크리스트

업데이트:

  • 2017/12/13 가독성 개선
  • 2017/6/26 레퍼런스 추가
    • 로깅/ GC, 필수 작업/ 퀄리티 세팅 추가
  • 2017/5/26 유니티 5.6에 맞추어 갱신

레퍼런스

  • https://divillysausages.com/2016/01/21/performance-tips-for-unity-2d-mobile/ (필수 작업, GC, 로그, 퀄리티 설정)

이 팁들은 모바일이나 PC 에서 60프레임을 안정적으로 지키기 위한 팁입니다.

코드에서는 디자인 패턴과 관련된 부분은 제외하고, 빌드전 체크해야 될 옵션과 팁에 대한 사항들 입니다.
유니티 5.6 이상의 2D 게임, 안드로이드를 기준으로 했지만, 다른 버전과 플랫폼에도 일반적으로 적용할 수 있는 내용입니다.

당연한 작업들

당연한 이야기라 굳이 설명할 필요 없이 바로 해두시면 됩니다.

  1. Application.targetFrameRate 를 60으로 설정합니다. 모바일에서는 30이 기본으로 설정되어 있습니다.
  2. 경우에 따라 vSyncCount 를 Quality 설정에서 켤 수 있습니다. 몇몇 안드로이드 기기에서는 60fps 이상 랜더링 될때가 있습니다.
    • 이렇게 너무 프레임이 높게 랜더링 되는 경우, 과열되어 장치가 응답하지 않게 될 수도 있습니다.
  3. 클라우드 테스트와, 안드로이드 실제 기기 테스트를 둘다 애용 합시다.
    • 쓸만한 무료 클라우드 테스트로는 구글 플레이 콘솔에서 지원하는 “출시전 보고서” 기능이 있습니다.
    • 즉시 사용 가능한 유료 클라우드 테스트는, 아마존 디바이스팜과 파이어베이스 테스트 랩이 있습니다.
  4. 오브젝트 풀을 반드시 사용하세요.
  5. 써드파티 텍스쳐 패커를 사용해서, Dynamic Batching 이 이루어지게 하세요.
  6. 컴포넌트에서 비어있는 유니티 메세지 함수들은 지우세요. 함수 내부가 비어있어도, 호출은 됩니다.
  7. GameObject.Find() 같은 함수를 사용하지 마세요. 특히 Update/FixedUpdate 에서는 절대 안됩니다.
  8. 사용하지 않는 게임 오브젝트나 컴포는트를 비활성화 하세요. Update/FixedUpdate 는 하는 일이 없더라도 실행됩니다.

 

가비지 콜렉터를 제어하기

게임 도중에 GC 가 발동된다면 게임이 뚝뚝 끊길수 있습니다.

GC 는 어플리케이션이 메모리를 추가로 요구할때 발동됩니다.
즉 필요한 것들을 미리 게임 초반에 인스턴스화 하여 메모리를 점유하고, 게임 플레이 도중에 더이상 요구하지 않는 다면 GC 문제를 겪지 않습니다.

즉 오브젝트 풀링을 사용하세요.

다른 문제로는, 눈치 채기 힘든 메모리 할당 들입니다.
안쓰기는 힘듭니다. 하지만 그래도 알고 쓰는게 최적화에 도움이 됩니다.

  1. foreach 를 사용하면 enumerator 를 위해 32B 메모리를 할당합니다. 이게 작아보여도, Update 와 FixedUpdate 안에 몇개 넣어두고 반복적으로 돌리면 퍼포먼스에 영향을 줍니다.
  2. delegate 에 콜백을 추가하거나 삭제하는 것은 104B 메모리를 할당합니다.
  3. string 은 생성하는 만큼 할당됩니다.
    “Hello” + “World” 같이 연결하는 부분을 주의하세요. 이 경우 실제로는 3개의 string 을 할당합니다.
    Debug.Log() 로 string을 많이 출력하는 것도 비슷한 맥락입니다.

    • StringBuilder 나 String.Format() 을 사용하세요.
  4. class 와 struct 의 차이점을 고려하세요.

클래스는 힙 영역에 생성되나,  struct 는 Pass by Value 로 동작합니다.

값을 전달할때 class 는 레퍼런스가 할당되고, struct 는 복제본을 전달합니다.

단순 데이터 컨테이터용으로 50개의 struct를 사용해서, A->B->C 로 전달하면, 150 개의 struct 가 생성되게 됩니다. 하지만 구조체는 스택에 할당되고, 자신을 호출한 함수가 종료되면 즉시 사라지기 때문에, GC를 유발하지 않고 빠르게 동작합니다.

결론적으로, struct는 메모리를 많이 사용하지만 레퍼런스와 관련된 처리가 없므로 속도는 더 빠를 수 있습니다.

하지만 단일 struct 오브젝트의 크기가 크면, 매번 복사하는 시간 때문에 class 형보다 처리 시간이 더 길어질 수 있습니다.

  • 변수가 2~3개 뿐인 단순한 데이터 컨테이너라면 struct 를 사용하는게 빠릅니다.
  • 일반적인 경우에는 class 를 쓰세요.

저는 그리드형 게임에서 2차원 좌표용으로 struct를 사용합니다.

struct Coord { int x; int y;}

프로파일러를 사용합시다

  1. 유니티 프로파일러로 병목 지점을 확인하세요
  2. CPU Usage 란에서, GC Alloc 기준으로 정렬하면, 누가 할당을 언제 시도하는지 볼 수 있습니다. 할당을 최대한 줄이고 몰아서 하면, 게임이 부드러워집니다. physics.engine 할당 같은 것은 제어할 수 없지만, 그 정도는 괜찮죠.
  3. Memory Area 에서는, 현재 메모리 상태의 스냅샷을 찍을 수 있습니다. 어디에서 메모리 누수가 발생하는지 파악가능합니다.

System.GC.Collect() 로 GC를 원하는 시점에 발동시킬 수도 있습니다.

컷신이 끝난 직후나, 다음 플레이어의 조작이 활성화 되기 전이라던지, 그런 시점에서 쓸수 있습니다.

먼저 GC를 해둠으로서, 예상치 못한 시점에 발동될 확률을 낮추는 거죠.

로그 남기기

string 에 대한 이야기에서말했듯이, Debug.Log() 등의 호출을 가능한 지우는 것이 좋습니다.

  • LogStringToConsole() – 메세지를 호출하는 이 함수는, 콘솔창이 없는 빌드된 게임에서도 동작합니다. 그리고 좀 느립니다.

이걸 체감하려면, 프로파일링 할때,  Development Build 를 선택하고 프로파일링 해보면 됩니다. 로그 메세지가 스택 트레이스에 잡힐때 게임이 느려집니다. 프로파일링에서 메세지가 띄어질때 마다 차트가 요동치는 것을 확인 할 수 있습니다.

  • 입력에 string 을 합쳐서 전달하는 방식은, 메모리를 더욱더 많이 요구합니다. 거기에  ToString 을 사용하면 더 심합니다.
    • Debug.Log( “Player ” + player + ” is doing something in game ” + game );

Debug.Log() 를 랩핑한 함수를 만드는 방법을 쓸수도 있습니다.

하지만 이 경우에도  빈 함수가 string 입력을 받기 위해서 메모리 할당은 여전히 이루어집니다.

해결책

세가지 해결책이 있는데, C# 조건 속성을 강력히 추천합니다. 다만 C# 조건 속성을 사용하면, 유니티 콘솔창에서 로그를 더블 클릭하면, 오류가 난 지점이 아닌 디버그를 랩핑한 코드로 이동하는 사소한 불편은 있습니다.

  1. 모든 Debug.Log 를 전처리기로 감싸놓습니다. 그래서 출시용 빌드에는 코드가 존재하지 않게 합니다.
  2. 빌드하기 전에 에디터의 Find and Replace 기능이나, 셸 스크립트를 돌려서 모든 디버그 함수를 주석 처리합니다.
  3. C# 조건 속성을 사용합니다. https://msdn.microsoft.com/en-us/library/4xssyw96(v=vs.90).aspx 깔끔하고 우아한 방법입니다.
    • 클래스 내부에 Conditional 속성이 지정된 static void 함수를 추가합니다.
    • 만약 Conditional 에 따라오는 심볼이 정의됬다면 static 함수는 존재합니다.
    • 중요한것은 static 함수 뿐만이 아니라, 그것을 호출하는 부분 까지 모조리 빌드에서 빠져나가므로 매우 간편합니다.
    • 즉 처음부터 존재하지도 않은 것이 됩니다.

글로벌 일루미네이션 제거

  • 만약 라이팅을 가지고 노는 일이 전혀 없는 게임이라면, Precomputed Realtime GI, Based GI, Fog 등을 전부 끄세요.

Quality Setting 트윅

  1. default 보다 높은 프로필은 모두 해제하세요. (모바일이라면 Simple)
  2. 사용하지 않는다면, Pixel Light Count 를 0으로 하세요.
  3. Texture Quality 를 가능한 낮게 잡으세요. Half Res 일때도 모바일에서는 눈치채기 힘든 경우가 많은데 75%나 메모리를 절약해줍니다.
  4. 텍스쳐에 확대 축소를 사용하지 않는다면, minmaps 를 해제하세요. 33% 메모리를 절약해줍니다.
  5. 비스듬한 각도에서 텍스쳐를 봐야하는 일이 없다면, Anisotropic Textures 를 해제합니다.
  6. Anti Aliasing 을 끄거나 2 passes 로 설정하세요. 그정도만 해도 지글거림을 해결해줍니다. LineRenderer 를 사용한다면 눈에 거슬릴순 있습니다.
  7. Soft Particle을 끕니다. 메쉬들을 적절히 섞어주는 역할을 하지만, 3D 상에서의 문제입니다.
  8. Shadow 를 끕니다.

여기서 가장 눈에 띄는 효과를 가진 것은, 텍스쳐 설정과 안티 얼라이언싱 입니다.

텍스쳐 퀄리티는 메모리에 직접적인 타격을 가하고 GPU 에 이미지를 보내는데 얼마나 시간을 먹을지 결정합니다.

안티얼라이언싱은 전체 화면에 적용되므로 해상도가 커짐에 따라 비용이 가파르게 증가합니다.

 

Unity 3D & 2D 공용

오디오 (사운드)

오디오 설정

  1. 모바일에서 스트레오는 큰 의미를 가지지 않습니다. Force To Mono 를 사용합시다.
  2. Preload Audio Data는 기본 옵션입니다. 미리 오디오 데이터를 로드하므로, 씬 로드에 조금 부담을 줍니다.
    하지만 이것을 사용안하면, 오디오를 재생하는 순간에 오디오를 로드 합니다.
    즉 게임 도중에 약간의 오버헤드가 생길 수 있습니다.
  3. Load in Background는 엄격하게 재생 타이밍을 맞춰야 하는 경우가 아니라면 체크해도 됩니다.엄격하게 로드 타이밍을 지키지 않고, 느긋하게 백그라운드에서 로드 합니다.
    씬이 시작되자 마자 재생을 시도할때, 조금의 지연시간이 지난 다음에야 재생되게 됩니다. 그래도 로딩 속도를 적게나마 향상시킬 수 있습니다.
  4. 로드 타입 (메모리 많이 먹고 빠릿함 vs 메모리 적게 먹고 오버헤드)
    • Decompress On Load 는 미리 압축을 해제해서 메모리에 적재하기에, 플레이 하는 순간에 오버헤드가 생기지 않습니다.적은 용량의 효과음에 사용합시다. 압축을 미리 메모리에 풀기 때문에 메모리를 많이 먹기 때문입니다.
    • Compress On Memory 는 메모리에 로드할때는 압축되어 있다가 재생시 압축을 해제합니다.플레이하는 순간에 압축을 푸는 과정이 생기기에, 오버헤드가 생길 수 있습니다. 메모리에 그대로 적재하기는 힘든 큰 용량의 배경 음악에 사용합시다.
  5. 오디오 매니저에서 스트레오 사운드가 필요없으면 스피커 모드를 Mono나 Raw로 합시다.

오디오 압축 포맷 (Compression Format)

오디오 압축은 기본적으로 아래의 사항에서 적절한 중간 지점을 선택하는 과정입니다.

높은 품질 + 많은 메모리 사용 + 적은 오버헤드 vs
낮은 품질 + 적은 메모리 사용 + 많은 오버헤드

얻는게 있으면 잃는게 있는법이죠.

압축률이 낮을수록 품질도 높고 오버헤드도 적으나, 빌드 용량과 메모리를 많이 먹습니다.

압축률이 높으면 빌드 용량과 메모리를 적게 먹으나, 압축을 푸는 과정에서 재생이 지연될 수 있습니다.

중요: 유니티에 임포트하기전에 미리 손실 압축을 거는 것은 의미 없습니다!

  • PCM
    • 품질이 제일 높습니다. 무압축 입니다.
    • 압축을 푸는 과정이 없어서 오버헤드가 없고, 재생이 지연 되지도 않습니다.
    • 빌드 용량과 메모리를 제일 많이 차지합니다.
    • 즉시 재생해야 하는 매우 짧은 효과음에 씁시다.
  • ADPCM
    • PCM 과 Vorbis/MP3 중간의 퀄리티와 압축률을 가집니다.
    • PCM 과 비교해서: 높은 압축률, 낮은 품질, 높은 오버헤드
    • Vorbis/Mp3 와 비교해서: 낮은 압축률, 높은 품질, 낮은 오버헤드
    • 어디까지나 사실상 무압축인 PCM 보다 용량이 낮고,  품질이 나쁘다는 얘기입니다.
      일반적인 손실 압축에 비해 품질 유지가 뛰어나고 CPU 오버헤드도 크지 않죠.
    • PCM 보다는 지연과 오버헤드가 존재하지만, Vorbis/MP3 와 비교할시 지연과 오버헤드 없이 즉시 재생됩니다.
    • 총격 소리와 같이 무압축에 가까운 품질 까지는 필요없지만, 지연시간 없이 자주 반복 재생 되야 하는 경우 적절합니다.
  • Vorbis/MP3
    • 가장 높은 압축률을 가집니다.
    • 당연히 품질이 제일 안좋습니다. 하지만 용량을 제일 덜 먹어요.
    • 로드 혹은 재생시 압축을 풀기 때문에 지연 재생될 수 있습니다.
    • 무압축으로 할시 용량을 감당할수 없고, 지연 재생 되어도 무방한 일반적인 배경음에 씁시다.

Unity 2D 기준

이미지 (텍스쳐)

중요! TinyPNG 같은거 쓰지맙시다. 알아서 유니티가 손실/무손실 압축합니다. 임포트 하기전에 손실 압축 하는 것은 의미가 없어요.

이미지(텍스쳐) 설정

  1. Generate Mil Maps 해제: 카메라와의 거리를 실시간으로 조정하는 게임이 아닌 이상 필요 없습니다.
  2. 특정 플랫폼에 무관하게 압축을 설정할시 압축 설정 (Override 를 사용하지 않고 일괄 적용할시)
    • 압축 옵션의 포맷은 알파값이 있다면 Truecolor 아니면 Compressed 옵션을 추천 합니다.
    • 알파값이 있는 이미지는, Compressed 옵션으로 아낀 용량에 비해, 품질 손상이 좀 많이 심합니다.
    • 반대로 알파값이 없는 경우, 큰 용량 절감 효과를 보여주고 상대적으로 알파값이 있는 경우보다 품질 손상도 적습니다.
      • 다만 알파값이 없는데 알파값이 있는 이미지로서 인식됬다면 Advanced에서 RGBA가 아닌 RGB 압축 포맷으로 지정해줍시다.
  • 필터링
    • 도트형 레트로 스타일의 게임은 필터를 사용하면 안됩니다.
      필터를 적용하지 않는 Point 로 적용 합시다.
      도트형 그래픽의 외곽선을 부드럽게 꺽어 왜곡하여 비주얼상 더 난잡해 보일 수 있어요.

이미지 아틀라스 (스프라이트 팩킹 Sprite Packing)

  1. 사용해야 하는 이유
    • 이미지는 2의 배수의 정사각형으로 메모리에 적재됩니다.
      하나의 이미지에 대해서 많은 여백이 남게되죠.
      이 여백을 낭비하지 말고 다른 이미지로 채워서 메모리를 아낍니다.
    • 자주 사용되는 이미지 끼리 하나의 파일로 뭉쳐 한번에 호출하면, 호출을 개별로 여러번 할 필요가 없어서 성능이 절약됩니다.
    • 즉 메모리와 성능이 절약됩니다.
  2. Packing Tag 를 팩킹할 이미지 끼리 같은 이름으로 지정해주면 유니티가 알아서 팩킹해줍니다. 
  3. 그외 옵션은 이곳을 참고할수 있습니다. http://lhh3520.tistory.com/350
  4. Resources 폴더의 텍스쳐는 엔진 구조상의 문제로 유니티 기능만으로는 팩킹 불가능합니다.

이미지 압축 (Compression) 고려 사항 (안드로이드 기준)

압축 포맷이 빌드 타켓 플랫폼과 호환되는지 확인하세요!

호환되지 않는 포맷은 해당 플랫폼에서 무압축으로 변환되어 사용됩니다.

그리고 압축된 포맷을 무압축으로 해제하는 과정에 오버헤드가 발생합니다.
즉 처음부터 무압축으로 올렸을 때 보다 오버헤드가 더 생깁니다.

압축 설정

  1. 알파 값이 없는 이미지라면, 알파값을 지원하지 않는 압축 포맷을 사용해서, 품질은 유지하면서도 용량은 줄일 수 있습니다.
  2. ETC2 vs ETC1
    • 안드로이드의 메이저한 압축 포맷은 ETC2 와 ETC1 입니다.
      • ETC2 는 더 나은 성능과 품질을 제공하지만 OpenGL ES3.0 에서 지원됩니다.
        • 즉 안드로이드 4.4 버전 이하에서는 제대로 동작하지 않는 경우가 많습니다.
      • ETC1 은 OpenGL ES2.0 에서 지원되나, 알파 (투명도) 를 지원하지 않습니다.
        • ETC1 을 설정할 경우 Spilt Alpha Channel 옵션을 통해 알파를 분리한 또다른 파일을 생성하여 알파를 지원하는 꼼수가 있습니다.
          • 다만 이 옵션은 버그인지, UGUI 에서 사용할시 비정상적으로 표현됩니다. (유니티 5.6.1 기준)
    • 하여간 ECT1 지원폰도 ETC2 호환이 된다고는 하는데… 사용 가능하다는 것이지, 사용시 무압축으로 올려버려서 메모리가 터집니다.
    • 무엇을 선택할 것인가 에 대한 딱 떨어지는 답이 없어요.
      • ETC2 가 대세긴 하지만 아직도 ETC1 만 지원하는 석기시대 안드로이드 폰의 점유율이 작지 않기 때문에, 타겟을 잘 고려해야 합니다.


ES2.0 점유율.. 미친 진짜 징하다… 물론 안드로이드 고유의 파편화 때문에 조금 걸러 볼 필요가 있습니다. 예를 들어, 대시보드에서 ES2.0 이라고 나와도 ES3.0 을 제한적으로 지원하는 경우도 많으니까요.

이외의 압축 포맷

  1.  RGBA32
    • 무압축 입니다. 가장 높은 품질을 가집니다. 메모리를 많이 먹지만, 품질을 높게 유지해야 하는 경우 추천 합니다.
    • 특히 유저가 매우 자주 보게 될 UI 에서는 이 옵션을 사용합시다.
  2. RGBA16
    • 알파 품질이 조악합니다.
    • 제한된 16비트에 RGB 는 물론 A 채널까지 포함하니 품질이 나쁠 수 밖에 없죠.
  3. RGB16
    • 쓸만한 압축률과 좋은 컬러 품질을 보여 줍니다.
    • RGBA 와 달리 16비트를 온전히 RGB에 다 쓰기 때문이죠. 물론 알파 값은 지원 못합니다.
  4. RGB24
    • RGBA32 와 동등한 품질을 보여줍니다. 단 알파값을 지원 못합니다.

기타 설정

  1. 압축시 2의 제곱수를 변길이로 가진 정사각형으로 이미지를 사용합니다. 그러니 여백을 활용하기 위해 정사각형에 가깝게 이미지를 제작하는 걸 고려할 수 있겠네요.
    • 예를 들면 900×1600의 해상도를 가진 물체라면 1024×1024와 2048×2048 중에 maxSize를 고민하게 됩니다. 전자는 화질이 손상되고 후자는 낭비니까요.
    • Sprite Packing 기능으로 묶어서 여백을 활용해도 되고요.
  2. Compress Quality 를 통해 손실 압축 포맷들은 압축의 품질을 결정할 수 있습니다. 당연히 Best 에 가까울수록 동일 품질에 대한 압축률이 좋아지겠지만, 유니티 에디터 상에서 최초 압축 및 팩킹시 매우 많은 시간을 소비합니다.
    • 즉시 빌드를 해야할때, 긴 압축시간으로 피볼수도 있습니다.

UGUI 오버헤드 관리

하나의 캔버스에 모든 UI 요소를 넣는 것이 꼭 좋은것은 아닙니다.

  1. 캔버스에서 어떤 UI 요소의 스프라이트가 동적으로 변할때, 캔버스에 있는 전체 요소들도 동시에 갱신됩니다. 즉 하나가 변하면, 같은 캔버스에 다른 친구들도 같이 갱신됩니다.
    한 UI 오브젝트가 변해도, 갱신 비용은 같은 캔버스 밑에 모든 UI 오브젝트 만큼 드는 거죠.
  2. 즉 서로 같은 타이밍에 내용이 (텍스트나 이미지가) 바뀌는 오브젝트 끼리 같은 캔버스로 묶으면 성능에 좋습니다.
  3.  그러나 개발자가 직관적으로 편집하기 좋게 하이라키에 배치하는 것도 고려해야 하니, 어디까지나 케이스 바이 케이스. 

폰트

  1. 완성형 한글의 모든 글자를 메모리에 집어넣는 메모리 빌런이 되고 싶지 않다면 Dynamic을 사용합시다. 폰트를 임포트할때 기본값으로 Dynamic 이 지정됩니다.
  2. 만약 해당 폰트를 꼭 써야하는게 아니라면 Incl. Font Data를 해제해도 됩니다. 해당 폰트가 시스템에 존재하면 사용하고, 없으면 시스템 폰트를 가져다 쓸것입니다. 빌드 사이즈가 줄어듭니다.
    다만 의도한 디자인을 유지하기 힘들어서, 이 방법을 추천하진 않네요.

물리 설정

  1. 물리, 레이캐스팅을 사용하지 않는 형태의 게임이라면 충돌 레이어 설정을 해제해도 됩니다. 프로젝트 세팅 중 Physics 에서 Collision 레이어 항목 체크를 해제하면 되죠.
  2. FixedUpdate는 랜더와 상관없이 물리를 위해 독립적으로 일정 간격 호출되는 함수입니다.
    리기드 바디 등을 사용하지 않는 게임이라면, 물리 체크를 자주 할 필요가 없겠죠. 필요에 따라 호출 간격을 길게 해서 성능을 아낄수 있습니다.

기타 & 빌드시 세팅

  1. 절대 Keystore 파일 잃어 먹지 마세요. (미아앱 되기 싫으면 클라우드 저장소에 백업 좀 하셈)
  2. 유니티가 빌드시 알아서 사용되지 않는 애셋은 제외합니다.
    • 하지만 스크립트 파일은 사용되든 사용되지 않든, Editor 폴더에 있지 않는한, 모두 포함되서 빌드됩니다.
  3. Resource 폴더는 안쓸수 있다면 최대한 쓰지 맙시다.
    • 여기 들어가는 요소들은 실제 사용되든 사용되지 않든 빌드에 무조건 포함되고 메모리에 적재됩니다.
  4. 안드로이드 빌드시 세팅
    • x86(데스크탑 안드로이드) 를 사용하는 기기는 거의 없습니다.
    • FAT 은 x86과 ARM 을 모두 빌드하므로 용량이 커집니다.
      • FAT을 하지 말고 ARM 대상으로만 빌드합시다.
      • 혹은 x86 과 ARM 을 따로 빌드해서 구글 플레이 콘솔에 멀티 APK 로 올려도 됩니다.
    • Stripping Level의 경우 가능한 높은 수준을 추천합니다. 다만, micro nmscorlib이나 byte code 세팅이 프로그램을 크래쉬할 수 있으니 테스트는 해봅시다.
    • 32비트의 컬러 품질이 필요한지 비교후, 그렇지 않다면 체크 해제합니다.
    • 호환에 문제가 없다면 빌드 용량을 줄이기 위해 기본값인 .NET 2.0 Subset 을 사용합니다.

계속 갱신중.

유니티 (Unity) 2D 모바일 게임 최적화 팁 & 체크리스트”의 8개의 생각

  1. 안녕하세요

    제가

    ETC1과 ASTC의 퍼포먼스 차이를 분석하거 있는데요…

    ASTC가 ETC1과 비교해서 별차이없는 품질에 메모리 사용량은 절반인데

    딱 메모리 사용량말고는 퍼포먼스차이가 거의없는거 같은데 어떻게 분석해야할까요…

    1. 그거야 ASTC 가 차세대 포맷이니까 모든면에서 좋은게 당연하져 ㅋ
      문제는 언제나 플랫폼이 지원하냐는 거지만 ㅠㅠ

      참고로 저도 그런거 딱히 거창하게 비교하는게 아니라 “로드 속도” “메모리” “퀄리티” 딱 세개만 무식하게 돌려서 비교해요ㅋㅋ;;
      메모리는 그냥 프로파일러로 확인하고,
      로드 속도는 아무것도 없는 씬에서, 서로 다른 이미지 한 100장 쌓아놓고 스프라이트 랜더러를 붙인 100개의 오브젝트들이 있는 씬을 비동기로 호출하면서 씬로드 끝나는 타이밍까지 시간 재서 로그로 찍고,
      퀄리티는 그라데이션 들어간 이미지를 압축별로 캡쳐해서 눈으로 확인하는 정도 ㅋ

답글 남기기

이메일은 공개되지 않습니다.