Game Develop

두가지 방법이 있다. 첫번째방법은 상당히 오래전부터 사용한 방법이고, 두번째 방법은 윈도우비스타 이후부터 권장되어진 방법이다. https://docs.microsoft.com/en-us/windows/win32/api/commdlg/nf-commdlg-getopenfilenamea GetOpenFileNameA function (commdlg.h) - Win32 apps Creates an Open dialog box that lets the user specify the drive, directory, and the name of a file or set of files to be opened. docs.microsoft.com MSDN에서 직접 언급했다. 샘플코드같은것들도 들어가서 조금만 뒤지면 나오..

사실 아직도 도저히 이해가 안가는 일이긴 하다. 씬에서 직접 fbx파일을 추출해서 Asset창에 보여주고 렌더시키는 툴을 만드는 중인데 fbx파일 선택을 위해 공용대화상자를 여는 winapi를 찾게 되었다. 먼저 사용한건 commdlg.h에 있는 GetOepnFileName()이라는 함수를 이용해서 파일대화상자(FileDialog)를 여는건데, 비교적 사용법은 쉬웠다. (사용법에 대해선 따로 정리해놨다) 근데 이상하게, 저 대화상자를 열고 파일 선택하고 확인을 누른 다음에 ModelExporter을 실행하면 도통 파일을 읽어오질 못한다. 이것저것 시도하다 하루를 날렸는데 멘탈이 조금 깨졌었다. 그냥 한창 구현만 하면 되는 작업이였어서 딱히 막히는일이 없을줄알았는데 생각치도못한곳에서 작업이 멈추니까 짜증도..

string path = "C:\\Users\\JYP\\Desktop\\p\\resource\\spam\\*.*"; // 맨끝에 *대신 특정 확장자를 입력하면 그 확장자만 읽어올 수 있다. struct _finddata_t fd; intptr_t handle; if ((handle = _findfirst(path.c_str(), &fd)) == -1L) { cout

fxc.exe가 종료되었습니다.(CODE 1) => FXC는 셰이더 컴파일도구종류중 하나인거같은데, 갑자기 잘되던게 이 에러뜨면서 빌드가 안된다. 이건 좀 사연이 길다 사실 잘되던건 아니고, UV피킹 구현중에 DEVICE설정 좀 건드리느라 혹-시나(전혀 걱정할필요없지만) 기존 컴퓨트피킹에 뭐 영향이 갔나 싶어서 컴퓨트피킹으로 바꿔놓고 빌드했는데 피킹이 갑자기 잘 안된다. 정말로 많이 당황했다. 셰이더파일 설정같은거 뭐 건드렸나싶어서 다 살펴보고했지만 아무리생각해봐도 전혀 뭘 건드린게 없었다. 이걸로 하루넘게 날렸다. 뭐 UV피킹 구현하는걸로 시간을 쓴것도아니고, 기존에 잘 되던게 갑자기 안되버리니 미치는줄알았다. 결국 원인을 찾았는데, cbuffer 레지스터 등록이나 구조체,함수 선언을 따로 Heaer에..

디퍼드렌더링이 뭔지에 대한 자세한 글이 아니라 실제 코드에서 전체적인 자원이동 흐름이 어떤건지 정말 간략하게 정리해놓은 글이다. 디퍼드렌더링이 뭔지는 대충 검색하면 많이 나오지만, 실제 코드로써 자원정의와 흐름을 모르면 써먹을 수 없기 때문에 예제 보면서 코드 한줄한줄 이해했다. 개인적으로 RenderTarget부분을 제대로 공부안했어서 시간이 좀 걸렸었는데 어쨋든 이기회에 많이 공부해서 다행이다. cpp코드로 hlsl코드 보면서 메모장으로 막 정리한거라 다른사람이 보기에는 많이 불편할것같다. 디퍼드렌더링은 기존의 포워드렌더링의 라이트계산을 압도적으로 줄여놓은 라이팅 최적화기법이다. 포워드렌더링같은 경우 N*M의 라이트계산을 해야한다. 하나하나 일일이 해줘야한다는것. 디퍼드렌더링은 각 오브젝트들의 디퓨즈..

Person(Person&& other) : m_ptr(other.m_ptr) { other.m_ptr = NULL; // 소멸자호출 방지하기위함. } ~Person() { delete m_ptr; } 복사생성자는 아예 새로 할당받는거고, 이동생성자는 호출된 인스턴스가 가지고있는 포인터변수의 주소값을 그대로 옮기는(이동)것이기 때문에 임시객체를 만들필요가없다. 그래서 더 빠르다. 생성자부분에서 other.m_ptr = NULL값을 넣어주는이유는, 안넣어주면은 other인스턴스가 소멸될 때 다른곳으로 이전된 m_ptr이 delete 되버리기 때문이다. 다른곳에서 쓰이고있는데 해제시켜버리면 안됨.

현재 작업중인 프레임워크는 학원에서 배우고 사용했던 프레임워크를 기반으로 내 포트폴리오에 맞춰서 최적화시킬수 있는건 최적화하고 기능 추가하고 하는중이였는데 터레인에디터부분에서 최적화가 많이 필요한걸 느꼈다. 일단 터레인맵의 크기가 클수록 프레임이 기하급수적으로 떨어졌다. 피킹을 하면 터레인크기가 클수록 프레임이 더 떨어지는건 정상이긴하지만 좀 많이 떨어졌다. 떨어졌던 원인 2가지는 아래와 같다. 1. 터레인피킹 2. 터레인피킹으로 좌표를 받아와서 좌표주변의 버텍스 y값 조절을 통해 지형을 수정하는 과정. 피킹자체는 학원에서 배울 때 컴퓨트쉐이더를 이용해서 gpu쪽연산으로 돌렸기 때문에 최적화가 됐다. 그러나 렌더함수쪽에서 피킹으로 값받아오는 연산이 프레임단위로 수행되고 있었기 때문에 터레인크기를 늘리자마..

그냥 어느정도의 영역만큼 컬링하는지 표현하려고 해봤다. 혹시 크기를 알아내는게 복잡한가? 싶어서 투영행렬 유도식까지 공부하고 정리했는데 굳이 필요는 없었다. 물론 공부자체는 매우 유익했는데 절두체크기 구하는건 단순히 탄젠트공식 하나만 알면 되는 부분이긴했다. 절두체크기 구하는 부분에 대해선 다른 카테고리에 포스팅했으니 참고할사람은 했으면 좋겠다. 결과물은 아래와 같다.