[1]. Engine 프로젝트의, 부모 클래스인, Level 클래스에도 GameInstance를 추가한다.
[2]. Client 프로젝트 속, Level클래스의 자식 클래스인, Level_Loading 클래스에서 GameInstance가 필요하기 때문에, 부모인 Level 클래스에서 GameInstance를 추가하고, Reference Count 관리를 한다.
[3]. Level_Loading 클래스의 Update 함수 안에, ‘’스페이스 바’’키를 입력하면, 다음 Loading Level 에서 다음 Level 로 넘어가는 동작의 코드를 작성할 것이다. GameInstance에, Level_Manager 클래스의 Open_Level 함수가 있기 때문에, 추가를 했던 것. 부모 클래스 Level 에서, m_pGameInstance 의 AddRef와 Release를 담당하고 있기 때문에, 현재 자식 Level_Loading 클래스에서는, m_pGameInstance 의 관리에 대해 신경 쓸 필요가 없다.
[4]. 간단한 Level 전환을 확인하기 위해, 각각의 Logo , GamePlay 클래스의 Render함수에, SetWindowText 함수를 호출해, 간단하게 텍스트로 Level이 전환되고 있다는 것을 확인한다.
[5]. Logo 클래스에서는, Update 함수에, 엔터키를 눌렀을 때, Logo Level → Loading Level 2 → GamePlay Level 이 될 수 있도록,
두 번 째 Loading 이 완료되면, 현재 Logo Level은 해제가 되고, GaemPlay Level 로 전환이 된다.
[6]. 이제 Loader 클래스에 쓰레드를 마저 완성한다.
[7]. 참고로, 쓰레드를 통한 로딩작업 전에, 호출 하면 좋은 것이, CoInitializeEx 함수로, 쓰레드는 결국 stack영역을 제외한 나머지 메모리 영역을 공유하는데, 그 공유된 메모리에 할당된 COM 객체가 혹여 중복 사용되면 문제가 될 수 있기 때문에, 새로운 쓰레드가 시작되면, 그 COM 객체는 리셋 시켜주는 함수이다. 알아두고 필요할 때 써주면 될 것 같다.
[8]. 현재 프로젝트를 빌드 후, 실행하면, 메모리 누수가 발생하는데, 이는 결국 Level_Manager 가 완벽하게 지워지지 않고 있기 때문이다.
[9]. 더 정확하게, Level_Manager의 GameInstance의 Free함수가 호출되지 않고 있다.
[10]. 가장 먼저 Level_Manager에서, 불리는 Level 클래스의 m_pCurrentLevel 을 해제 함으로서, Reference Count를 감소시킨다.
[11]. 그리고, GameInstance를 지워야만 Free 함수가 호출되고, Free 함수가 호출되어야 GameInstance를 지울 수 있는 역설적인 관계가 나타나기에, 아예 Release_Engine() 이라는 함수를 통해, Device를 포함한 Engine 속, 각종 Manager 클래스들을 해제한다. 이 함수를 Main App의 Free 에서 호출해서, 처음의 역설적인 호출 순서에서, 우선 순위를 지정해 주었다.
[12]. 해제 되는 순서는 결국, MainApp 클래스의 Free 함수 속에,
순으로 호출이 되면서 프로그램은 종료된다.
[13]. Dx11에서는 자체적으로, 프로그램을 실행하고 난 뒤, 메모리 누수 같은 문제점의 원인을 별도로 알려주는데, 이는,