자체 게임엔진 DevLog - 크기조절 문제 해결

렌더 스레드 작업을 성공적으로 마무리 하기 위해서 남은 문제가 Resize 문제였다.

크기 조절은 매번 그래픽스를 할 때마다 어려운것 같다. 

 

Framebuffer Resize

메인스레드에서는 아무 문제없이 돌아갔는데 렌더링 스레드로 호출했을 때 문제가 터졌다.

 

 

분명히 colorAttahcments size가 _index보다 큰데 out of range 에러가 발생하는게 문제였다.

 

계속 디버깅 해보다가 원인을 알았는데 프레임버퍼를 재생성하는 함수가 원인이었다.

프레임버퍼가 크기가 변했을때 재생성하는 부분을 메인스레드에서 실행했었는데 렌더 스레드 구조를 집어넣으면서 이 부분도 렌더 스레드가 실행하는게 순서가 꼬이지 않을것 같아서 프레임버퍼 재생성도 렌더 스레드에서 호출되도록 변경했었다.

 

그런데 재생성 코드를 보면 이런식으로 기존의 colorAttachments를 clear해버리고 새로 만든다.

 

GetColorAttachmentTexture함수는 이 colorAttachments를 기반으로 동작하고

ImGui::Image같은 함수들이 메인스레드에서 이 함수를 호출하는데

렌더스레드에서 Recreate()함수가 호출되었을 때 기존 Attachments를 clear해버리고

새로 만드는 도중에

메인스레드에서 GetColorAttachmentTexture가 동시에 호출되면

덜 만들어진 colorAttachment에 접근하려고 시도하게 되고 out of range문제가 생기게 되는 것이었음

 

해결방법은 간단하게 해결했는데

clear를 해버리면서 없는 인덱스에 접근하는 경우를 막으면 되기 때문에 clear()하는 코드를 제거해주니 이 문제는 더이상 발생하지 않았따.

어차피 재할당을 통해 원래 새로운 텍스쳐를 할당할 것이기 때문에 clear()가 굳이 필요 없다고 결론지어서 이렇게 고쳤다.

 

처음 변경한 프레임버퍼 크기조절 함수

 

ImGui에서 뷰포트 크기 변화를 감지하면 이 함수가 실행된다.

EnqueuPreFrameCommand는 새로운 프레임이 시작할 때 다른 작업들보다 먼저 실행할 일회성 함수들을 집어넣는 함수로 만들었음ㅁ

 

우선 framebuffer가 가진 width와 height를 바로 재설정해주고, 렌더스레드에는 프레임버퍼를 실제로 재생성하는 명령을 보내는 식으로 구성했다.

 

렌더스레드에서 width와 height까지 변경하게 만들면

Resize가 느리게 끝나는 경우 메인스레드에서 다시 크기 변경이 필요한줄알고 Resize를 한번 더 요청하는 문제가 있어서 이렇게 했는데

막상 실행해보니 메인스레드와 렌더스레드간 경쟁 상태가 발생한 것(?)인지 생성하는 DSV랑 RTV 크기가 달라서 터진다.

 

사실 명확한 원인을 찾지 못했다. AI도 헛소리만 하고 딱히 명확한 원인을 찾지 못해서 Resize 함수가 한번 더 호출되더라도 일단은 스레드에서 width와 height도 일괄적으로 변경하게 두었고 일단은 오류가 발생하지 않음

 

Swapchain Resize

Before

After

스왑체인의 크기조절 방식도 수정했는데

원래 메인 창만 크기 조절을 하게 만들었었지만

이제 WindowManager로 특정 윈도우를 문자열 기반으로 가져올 수 있다.

그래서 크기가 변경된 윈도우의 이름을 가져와서 

윈도우의 포인터를 얻고 그 윈도우의 스왑체인 크기를 변경하게 했다.

 

그리고 ResizeSwapchain함수가 호출되면 swapchain의 isSwapchainResized 플래그를 true로 변경한다.

이런식으로 프레임이 시작할때 isSwapchainResized가 true라면 변경된 크기를 가지고 스왑체인을 새로 만들게 된다.

 

대충 리사이즈도 테스트 해보니까 크게 오류없이 잘되는걸 확인할 수 있었고 

 

다음에 할 건 또 렌더러 리소스 구조 변경 작업이다. 솔직히 재미없어서 새로운 기능이나 이런거 구현해보고 싶은데

현재 구조가 별로인데 지금 안바꾸고 진행하자니 찝찝해서 어쩔 수가 없는듯