슬비의 개발일지

스크립트 컴포넌트 -> 기능이 정해지지 않은 컴포넌트, 사용자가 구현하고 싶은 컴포넌트(엔진에서 제공되지 않음) 스크립트 컴포넌트를 상속시켜 여러 스크립트들을 제작한다. 스크립트들은 final tick 을 하면 안된다. -> 스크립트를 제외한 일반적인 컴포넌트가 기본적인 위치나 이동이 끝나고 gpu에 데이터를 전달하기전에 마무리하기 위해 만들어놓은 틱이기 때문이다. 스크립트는 논리적인 로직을 구현하는 파트이기 때문에 틱에서 구현을 마무리 해야한다. 그래서 스크립트 컴포넌트에서 finaltick() final {}; 을 붙여서 그 밑의 자식 스크립트들이 구현할 수 없게 막아놓는다. 스크립트 컴포넌트나 자식 스크립트 컴포넌트들의 타입은 다 스크립트로 분류가 된다. 게임오브젝트에 에드컴포넌트에 들어왔을때 기존..

sampler는 샘플러 레지스터에 고정으로 항상 셋팅을 해둘 것이다. (s0, s1) 샘플러 종류 2개 -> Anisotropic(이방성, 두종류의 방향으로 향하는 성질), Point 1. Anisotropic (s0) AddressU -> address_mode::texture_address_wrap AddressV -> address_mode::texture_address_wrap AddressW(게임에선 3차원 텍스쳐는 잘 사용안해서 없다고 생각하면됨) 필터링 방식 -> 이방성필터링 옵션 filter_anisotropic 2. Point (s1) 필터링 방식 -> filter_min_mag_mip_point 샘플러는 버텍스쉐이더에만 필요한게 아니라 전 쉐이더에 다 필요하다. 두 샘플러의 차이 ? 이..

파일로 존재하는 이미지 파일을 압축포맷이 다양하기 때문에 메모리에 로딩하는 과정에서 포맷에 맞게 역으로 디코딩을 해야한다. 리소스들은 무조건 로드라는 함수가 있어야한다. 직접적으로 리소스를 로딩할 수 없고 리소스매니저에 있는 크리에이트 함수를 이용해야한다. ex) 아무데서나 CTexture* pTex = new CTexture; pTex->Load(); 이게 안된다. 리소스매니저에 전혀 등록이 안되기 때문이다. 그래서 항상 로딩은 리소스매니저를 통해서 해야한다. ex) CResMgr::GetInst()->Load("키값", 경로"); 텍스쳐를 로딩하려면 다이렉트텍스 라이브러리 함수를 사용해야 한다. 먼저 라이브러리를 인크루드 한다. 1. 텍스쳐 ScratchImage(다이렉트 텍스에서 제공해주는 클래스)..

1. 게임오브젝트 (엔터티 상속) 컴포넌트 기반 설계 좌표 데이터도 컴포넌트로 뺄 예정이다. 어떤 컴포넌트를 사용할 것인지에 대한 컴포넌트 배열만 가질 예정이다. 게임 오브젝트 랜더링할 때에는 랜더링기능을 랜더링컴포넌트에 요청을 한다. -> 매쉬랜더 매쉬랜더 컴포넌트가 없을 수도 있다 -> 화면에 굳이 그려지지 않아도 되는 연산만 하면 되는? 특정 영역 근처에 플레이어가 가까이 오면 몬스터 스폰하는.. 로직만 작동하면 되는 것들 2. 컴포넌트 1) transform-> 오브젝트의 위치이동 담당 컴포넌트 render 2) meshrender 게임 오브젝트는 본인이 소유하고 있는 컴포넌트를 인덱스로 접근 가능하게 하고, 모두 다 컴포넌트를 상속받았기 때문에 부모 포인트 하나로 관리를 할 것이다. 그래서 배열..

그룹별로 리소스를 나눠서 맵을 별도로 구현을 할 것이다. 그래서 맵을 배열로 가져온다. typeid 를 이용해서 T 타입이 어떤 타입인지 확인할 수 있다. 셰이더는 크게 두 종류로 나뉜다. 1. 그래픽스 쉐이더 (랜더링용) 2. 컴퓨트 세이더 리소스를 상속받아서 중간 부모에 쉐이더를 놓고 이중으로 파생시켜서 그래픽스와 컴퓨트로 나눈다. 쉐이더에는 private 로 ErrBlob을 만든다. 쉐이더는 리소스를 상속받았기 때문에 자신이 무슨 타입인지 명시를 해야한다. 근데 그래픽스인지 컴퓨트인지 모르기 때문에 받아온걸 넣어주도록 설정한다. 1. 그래픽스 쉐이더 (VS, HS, DS, GS, PS) 파이프라인 단계에서 사용할 쉐이더를 고르고, IA 단계에서 사용할 매쉬 모양을 고르고 이 모양을 이 쉐이더로 랜더..

같은 위치의 정점을 여러번 넣는건 비효율적이어서, 정점 수를 필요한 만큼만 넣고 인덱스를 활용한다. 정점 수를 줄인다고 버텍스 쉐이더 호출 수가 줄어드는건 아니다. 8 인덱스 버퍼 -> 인덱스를 저장하는 버퍼, 겹치는 자리에 정점을 안주려고 사용한다. 사각형을 그릴 때, 정점이 6개 필요했지만 인덱스버퍼가 있으면 정점이 4개만 있어도 된다. 인덱스 버퍼는 6개 필요하다 .. 상수버퍼는 디바이스에서 관리한다.. 상수버퍼마다 용도가 따로 있다. Transform -> 캐릭터의 위치 정보 Material -> 재질정보 * ComPtr은 기본 인터페이스 포인터의 참조 개수를 자동으로 관리하여 참조 횟수가 0이 되면 인터페이스를 릴리스한다. enum 으로 하면 캐스팅 없어도 정수로 변환이 자유롭다. 파이프라인을 ..

삼각형 움직인 원리 gpu에 VB 설정을 하고 system 메모리 쪽에도 동일하게 유지되는 전역변수로 벡터 정점 3개 짜리를 주었다. 키보드를 움직이면 system 메모리 쪽에 있는 배열이 수정되는 것이다. map, unmap 이라는 함수를 통해 system 메모리 쪽에서 gpu VB로 보낸다. 버텍스버퍼에 정점을 찍은 이유 -> 현재 삼각형 모형으로 정점을 찍었다. 애초에 NDC 좌표를 기준으로 해서 삼각형 모형이 될 수 있도록.. VB를 훼손시키지 않으면서 정점들을 이동시키려면, VB는 그대로 IA에서 입력을 받고, 버텍스 쉐이더에서 몬스터 위치값을 받아서 한번에 이동을 시키고 레스터라이저에게 주면된다. (이동량을 별도로 따로 받음) Constant Buffer (상수버퍼) -> 자잘한 상수값을 전달..

레이아웃은 정점의 정보를 표현한다. 레이아웃 -> 버텍스쉐이더가 입력으로 받을 시멘틱과 버텍스가 어떻게 구성되어 있는지 시멘틱으로 정보를 알려주는 객체 정점을 사용하는 것은 버텍스 쉐이더이다. 하나의 정점에 하나의 버텍스 쉐이더가 호출된다. 버텍스쉐이더는 어떻게 정점이 구성되어있는지는 모르지만 하나의 정점안에 포지션이랑 컬러 시멘틱이 있어야 하고 입력을 받아오겠다는 것이기 때문에 둘이 연결을 시켜주어야한다. 그래서 레이아웃보다 버텍스쉐이더가 먼저 만들어져야 한다. HLSL으로 작성한 걸 읽어들여서 기계어로 바꾼걸 빌드할건데, 빌드된 코드를 저장하는게 ID3DBlob 이라는 객체이다. ID3DBlob -> 컴파일 된 코드를 저장~ 코드만을 저장하진 않고 문자열 데이터 or 바이너리화된 코드를 저장하는 메모..

좌표데이터 -> 컴포넌트 게임오브젝트는 어떤 컴포넌트를 사용할건지 컴포넌트 배열만 가지고 있을 것이다. 컴포넌트 종류 transform -> 위치 이동 담당 meshrender -> 랜더링 관련 컴포넌트(굉장히 다양함 현재는 이것만) 컴포넌트도 자신을 소유한 오브젝트가 누군지 알아야함. transform -> 상대적인 위치, 크기, 회전 값을 가지고 있어야한다. 트랜스폼 업데이트데이터에서 위치정보를 상수버퍼에 전달시킨다. 그리고 상수버퍼값을 VS에 업데이트 시킨다. 연산만하고 랜더링이 없어도 되는 오브젝트도 존재한다

그래픽스 파이프라인 -> 물체 하나가 그려지는 과정 (GPU로 연산) 우선은 아래와 같이 간소하게 사용함 Input-Assenbler (IA) -> 화면에 그리기 위해서 필요한 데이터를 입력받는 단계 Vertex Shader -> 버텍스버퍼에 만들어진 정점 정보를 IA 단계가 받고, 버텍스 쉐이더에서 Rasterizer로 정점정보를 넘긴다. 정점 하나당 버텍스스테이지를 병렬로 수행한다. Rasterizer -> 받은 정점 세개를 정규화된 좌표(NDC, NormarizedDeviceCordinate)로 변환된 걸 받는다. *NDC 좌표계 -> 중심이 0,0 이고 화면의 전체 영역을 -1 ~ 1 범위로 잡은 좌표계이다. 정규화 한다는 것은 비율을 적용해서 값을 -1 ~ 1 사이의 값으로 변환하는 것이다. Z..