슬비의 개발일지

기본 옵션이 레스라서 1보다는 가까워야한다 처음에 뎁스스텐실텍스처를 1로 초기화한다. 그래서 1보다 낮아야 통과를 한다 가장 멀리 있는걸로 셋팅하려면 0.99 이런 느낌으로 그리드는 사실 순서에 상관없이 언제 그려지더라도 본인이 가장 멀리있는 깊이로 판정이 된다. 간격은 스크립트를 통해 조절 가능하다. 추가하거나 삭제되는 것은 바로바로 진행되는게 아니라 다음번 프레임부터 적용되어야한다. ==> 지연처리 이벤트매니저 만들고 이걸로 처리한다. DWORD_PTR을 쓴 이유? 플랫폼에 따른 가변 자료형이기 때문에 파라미터의 주소값이 들어갈 경우를 대비해서 사용한 것 미사일 생성 본인의 위치정보를 트랜스폼에서 RelativePos를 받아와서 y값을 위로 올릴거니까 스피드값을 이용해서 올릴 것이다.

부모에 영향받지 않고 자식이 원하는 사이즈로 있고 싶다면 어떻게? (부모크기를 일일이 확인하는게 번거로움) 부모의 회전이나 자식의 이동값이 부모로부터의 상대적인 개념은 맞는데, 부모의 크기까지 영향을 받게되면 실제 원하는 위치에 자식을 달아줄 때 너무 불편하다. 그래서 크기 행렬은 부모의 영향을 무시할 수 있게 만들어야 한다. 트랜스폼에 bool 변수로 부모의 스케일 정보를 무시할 수 있는 옵션을 준다. 자식 오브젝트 트렌스폼에서 스케일 영향을 주는걸 해제해놓는다면 누군가의 자식오브젝트가 되더라도 부모의 스케일에 더이상 영향을 받지 않게 된다. ==> 내가 원하는 포지션이나 스케일을 설정하더라도 부모에 영향을 받지 않고 직관적으로 셋팅할 수 있다. 부모의 행렬을 무작정 아무렇게나 누적을 해서 곱하면 안된..

SetLayerMaskZero -> 모든 레벨(레이어)을 다 찍는 것 SetLayerMask -> 원하는 레이어인덱스를 넣으면 비트값 체크해서 그린다. 해당 카메라에 랜더를 주는 이유 ? 카메라마다 월드상의 위치가 다르다 -> 그 카메라가 중심이 되어야 하기 때문에 뷰행렬&투영법이 다 다르다. ==>> 행렬 세팅하는 부분이 랜더하기 직전으로 옮겨야함.. 투영행렬이나 뷰행렬 변환행렬이 이 카메라껄로 셋팅이 되어야하기 때문 셋팅해놓고 랜더링을 돌려야 물체들 입장에서는 자기 트랜스폼에서 월드행렬을 집어넣으면 뷰프로젝션(나를 찍는 카메라)으로 투영되고 이동변환을해서 최종적인 쉐이더 단계에서 해당카메라 시점기준으로 위치가 정해진다. 월드뷰프로젝션변환 계산을 미리 해두면 쉐이더에서 더 편하게 사용할 수 있다. ma..

쉐이더마다 특징이 있는데, 특징에 맞는 그룹군을 모아서 랜더링 순서를 정할 것이다. *도메인 쉐이더할 때의 도메인이 아님! *비트연산할게 아니니까 enum class *도메인 -> 자신의 주영역, 메인 영역 enum class SHADER_DOMAIN -> 쉐이더마다의 영역! 투명도가 없는 애들이 제일 먼저 그려져야한다. 반투명하다 -> 기존에 그려져 있는 거랑 색상이 반쯤 섞이는 것이다. 불투명한 애들이 먼저 그려져 있어야 반투명한 애들이 그려질 때 이미 그려진 애랑 본인이 출력할 색상을 섞은 색상으로 값을 계산할 수 있다. 불투명한 애들이 먼저 다 그려지고 나면 반투명한 애들과 영역이 겹치는게 있을 시 사이사이에 껴들어간다. 물체들의 실체 위치와 상관없이 불투명하냐 반투명하냐에 따라 랜더링 시점을 다..

레스터라이저 스테이트 타입 cull_back -> 아무것도 설정하지 않으면 뒷면을 컬링 (디폴트 옵션) // 뒷면 기준 -> 레스터라이저에게 전달된 면의 정점 접근하는 순서가 반시계방향으로 접근 cull_front -> 시계방향을 안 그리고 반시계를 그린다. cull_none -> 컬링을 안함 앞면이든 뒷면이든 상관없이 무조건 그림 wire_frame -> topololy를 다 무시하고 정점과 정점을 잇는 라인만 그리도록 한다 (안에가 안채워짐) 레스터라이저 문제점 디바이스에 단계별로 어떤 레스터라이저 옵션을 사용할 것인지 한 번 셋팅을 해놓으면, 다음 쉐이더가 다른 옵션으로 바꾸지 않으면 계속 동일한 옵션을 사용하게 된다. 그래서 디폴트 옵션인 cull back으로 다시 돌려두려면 이미 셋팅해두었던 레..

뷰행렬 월드에서 뷰변환을 한다는 얘기는 기준이 카메라로 바뀐다는 얘기이다. 카메라를 항상 월드에 있던 월드 원점의 기준이 아니라 월드상에 카메라도 같ㅇ ㅣ존재하고 있는데 카메라를 원점으로 보고 카메라가 전방으로 자기가 보고 있는 방향을 z축이라고 했을 때의 본인들의 좌표를 다시 계산해야되는 것이다. 월드에서 뷰로 넘어가기 위해서 곱해주는게 뷰행렬인데 뷰행렬 안에는 카메라가 원점이고 카메라가 보는 방향을 z축이라고 했을 때의 좌표를 계산할 수 있게 해주는 변환행렬 정보들이 들어있다. 월드에 있던 좌표들이 뷰행렬을 곱하고 나면 뷰 좌표계로 바뀌는 것이다. 그렇게 하기 위해 뷰행렬에는 4행파트에 카메라 본인의 월드포지션을 음수로 해서 들고 있다. 카메라가 원점이 된다는 이야기는 결국 카메라가 월드에 있던 좌표..

우리가 보고있는 곳은 게임 월드 찍고 있는 카메라가 월드의 원점에 있는 것이다. 우리가 보고있는 정면 방향이 z축 평행한 방향 물체의 상태값은 해당 물체의 트랜스폼에 저장되어있다. 확대는 먼저 확대하고 이동을 시킴 회전은 ? 회전도 로컬스페이스에서 회전을 먼저 시켜놓고 이동해야한다. 최종 월드 행렬 = 크기행렬 x 회전행렬 x 이동행렬 순서로 해야한다. 행렬 4 by 4 행렬이기 때문에 z축 회전 -> z 가 그대로니까 cosa sina 0 0 -sina cosa 0 0 0 0 1 0 0 0 0 1 x축 회전 -> x 가 그대로니까 1 0 0 0 0 cosa sina 0 0 -sina cosa 0 0 0 0 1 y축 회전 -> y 가 그대로니까 cosa 0 -sina 0 0 1 0 0 sina 0 cos..

XMMatrixIdentity -> 단위행렬 XMMatrixScaling(x값 크기, y값 크기, z값 크기) -> 넣어주면 사선으로 x y z 1 생기고 나머지 0 XMMatrixTranslation(x값 이동, y값 이동, z값 이동) -> 이동행렬 월드 행렬 = 크기 * 이동 들어온 것은 로컬스페이스 좌표인데 행렬 안에 이동값이 들어가 있다. 이동파트가 4행에 들어와있다. 네번째 동차좌표를 1로 확장시켜 곱해주면 행렬 안에 들어있는 4행성분의 이동량만큼 이동을 하게 된다. 즉, 로컬스페이스는 동일한 좌표가 들어오는데 각 오브젝트별로 자기의 월드 행렬값을 전달시켜 랜더링 하기 전에 자기의 월드상태를 보내놓으면 로컬스페이스에 있는 것을 월드행렬을 적용시켜 거기에 기록되어 있는 이동값이 영향을 받아 이동..

오브젝트들은 어떤 재질을 사용할지를 미리 골라놓고 시작된다. 플레이 하는 도중에 마스터 매태리얼을 모두 참조하고 있으니까 각 재질별로 종류별로 대표격인 리소스 하나씩만 존재한다. 혼자만 좀 달라져야하면 마스터매태리얼이랑 똑같은 재질하나를 복사시켜서 다이나믹 매태리얼로 바꿔서 사용했다가 다시 공유재질인 마스터매태리얼로 돌아간다. 쉐어드 매태리얼에는 마스터 매태리얼들만 가리킬 수 있는 포인터만 들어간다. 플레이 도중에 다이나믹 매태리얼을 달라고 한다는 것은 원본 매태리얼의 복사본을 생성시켜 그거를 쓰는 상태로 만들어 놓는다는 의미이다. 레벨이 종료되고 나면 모든 오브젝트들은 사라지거나 또는 원래 상태로 복구될 때 다이나믹 매태리얼들은 다 지워진다. 그래서 리소스 매니저에 등록조차 안한다. 게임 플레이하다가 ..

리소스매니저가 지워지고 레벨매니저가 지워지게 되면 레벨 매니저에 있는 물체들이 지워질 때 스마트포인터가 자기들이 소멸될 때 자기가 가리키고 있는 리소스가 살아있다고 생각하고 release를 한다. 근데 리소스 매니저가 이미 지워졌기 때문에 레벨의 오브젝트들이 지워진 주소를 들고 있게 된다. 그래서 삭제된 메모리에 접근을 해서 기능을 호출하는 거기 때문에 문제가 된다. 힙손상이 발생할 수 있다. 재질로 상수는 전달할 수 있는데 아직 텍스쳐는 불가능하다.. 이젠 텍스쳐도 인덱스에 맞춰서 해당 레지스터에 바인딩을 해놔야한다. 재질은 리소스다. 같은 재질을 공유하다보면 재질 안에는 해당 재질을 사용하는 물체들이 랜더링 하기 직전에 전달시킬 상수데이터와 택스쳐를 들고 있다. 예를들어 애니메이션을 한다면 플레이어가..