SubCamera3/canvas world로 한 이유?
world -> screen변경
이유가 있는게 아니라면 UI로 할것 (sprite + ui 동일 hierarchy 아래에?, 구조파악 및 유지보수 하기 힘듦)
추가로, UI끼리는 SpriteAtlas 등으로 배칭이 되나 SpriteRenderer는 UI와 배칭이 되지 않음
Washer UI Canvas/Panel Scale,Rotation 잡은 이유?
-> 이유없으면 Scale과 Rotation은 가급적 1,1,1/0,0,0 으로 잡고, Height, Width, pivot, offset 등을 통해 잡기
카메라 4개 다 활성화, Display만 바꿔서 렌더링하는 이유?
-> 렌더링 퍼포먼스잡아먹으니 필요하지 않으면(단순 포지션 용 이라면) 카메라를 사용하지말자 (Editing의 용이성을 위함이라면, 에디팅용 FakeCamera의 개념으로 런타임에서 비활성화 시켜주는 등의 방법이 필요)
LocalizedTextComponent Update 안에서 + 연산자, Tostring() 사용 중
-> 둘다 gc발생 시키므로 구조를 고민해서 업데이트 이벤트 발생 시에만 호출되도록 하는 편이 좋음
-> Update 안에서 지속적으로 GC를 발생하는 경우는 최소화
DetergentInsertClick Update에서 Getcomponent()를 지속적으로 호출
-> Update 안에서 GetComponent 류 함수는 지양할 것
오브젝트들의 Update문이 대부분 WasherDoorClick.CheckNumber의 변화값을 캐치하기 위함이라면
WahserDoor.onCheckNumberChanged를 정의 해놓고, WasherDoorClick.CheckNumber는 Property로 수정한 후
Setter에서 값의 변화에 따라 이벤트를 호출하는 게 낫다
Update, LateUpdate 등의 매직 함수는 일반 함수보다 호출 비용이 높다.(MonoBehaviour의 함수 호출 가능 여부를 체크하는 오버헤드 발생)
(ex: 10000개 오브젝트의 컴포넌트에서 Update구현해서 호출해보기 vs 1개의 매니저 클래스에서 10000개 오브젝트의 일반 함수 호출하기)
wall instancing (Material/EnableGPUInstancing 체크)
-> 동일한 메쉬에 동일한 마테리얼을 쓰는 오브젝트는 배칭이 되어 그래픽카드에서 한번에 그릴 수 있다
버그 수정 용 Branch 만들 때 는 어떤 버그에 대한 Branch인지 기술하고 머지된 브랜치는 delete 하기 (가급적 하나의 브랜치에서 하나의 기능 수정 및 추가가 적용 되도록)
MinBall
commented
1 year ago
SubCamera3/canvas world로 한 이유? world -> screen변경 이유가 있는게 아니라면 UI로 할것 (sprite + ui 동일 hierarchy 아래에?, 구조파악 및 유지보수 하기 힘듦) 추가로, UI끼리는 SpriteAtlas 등으로 배칭이 되나 SpriteRenderer는 UI와 배칭이 되지 않음
Washer UI Canvas/Panel Scale,Rotation 잡은 이유? -> 이유없으면 Scale과 Rotation은 가급적 1,1,1/0,0,0 으로 잡고, Height, Width, pivot, offset 등을 통해 잡기
카메라 4개 다 활성화, Display만 바꿔서 렌더링하는 이유? -> 렌더링 퍼포먼스잡아먹으니 필요하지 않으면(단순 포지션 용 이라면) 카메라를 사용하지말자 (Editing의 용이성을 위함이라면, 에디팅용 FakeCamera의 개념으로 런타임에서 비활성화 시켜주는 등의 방법이 필요)
LocalizedTextComponent Update 안에서 + 연산자, Tostring() 사용 중 -> 둘다 gc발생 시키므로 구조를 고민해서 업데이트 이벤트 발생 시에만 호출되도록 하는 편이 좋음 -> Update 안에서 지속적으로 GC를 발생하는 경우는 최소화
DetergentInsertClick Update에서 Getcomponent()를 지속적으로 호출 -> Update 안에서 GetComponent 류 함수는 지양할 것
오브젝트들의 Update문이 대부분 WasherDoorClick.CheckNumber의 변화값을 캐치하기 위함이라면 WahserDoor.onCheckNumberChanged를 정의 해놓고, WasherDoorClick.CheckNumber는 Property로 수정한 후 Setter에서 값의 변화에 따라 이벤트를 호출하는 게 낫다 Update, LateUpdate 등의 매직 함수는 일반 함수보다 호출 비용이 높다.(MonoBehaviour의 함수 호출 가능 여부를 체크하는 오버헤드 발생) (ex: 10000개 오브젝트의 컴포넌트에서 Update구현해서 호출해보기 vs 1개의 매니저 클래스에서 10000개 오브젝트의 일반 함수 호출하기)
wall instancing (Material/EnableGPUInstancing 체크) -> 동일한 메쉬에 동일한 마테리얼을 쓰는 오브젝트는 배칭이 되어 그래픽카드에서 한번에 그릴 수 있다
버그 수정 용 Branch 만들 때 는 어떤 버그에 대한 Branch인지 기술하고 머지된 브랜치는 delete 하기 (가급적 하나의 브랜치에서 하나의 기능 수정 및 추가가 적용 되도록)
Profiler / FrameDebugger 사용 하기