1. Input && Timer
유니티 스타일로 Input 만듦.
매프레임 마다 키 체크 하는 이유
이렇게 매 프레임마다 키 체크를 하는 이유는
동일한 프레임에서는 키상태가 항상 일정하다고 가정을 해야한다.
동일 프레임에서 한번 확인했을때는 누른 상태였는데 다시 확인하니까 때진 상태라거나 하는게 말이안된다.
그리고 이부분 winAPI인데
::GetAsyncKeyState & 0x8000이랑 비트 연산하면 뭔가 키보드를 눌렸다는 거임.
Timer
설명이 좀 많이 불친절해서 다시 공부겸 정리를 하도록 하자.
-
deltaTime : 이전 프레임에서 현재 프레임까지 경과된 시간
-
fps : frame per second, 매 초마다 평균적으로 몇프레임이 실행됬는지를 나타내주는 부분임. (1초마다 결과물)
초당 렌더링 횟수 : 프레임
https://maxlevel-trace.tistory.com/4
여기 보기바람❗❗
::QueryPerformanceFrequency(reinterpret_cast<LARGE_INTEGER*>(&_frequency));
이 함수는 매개변수에 현재 시스템의 고해상도 타이머의 주파수(1초당 진동수)를 반환한다.
이 값은 시스템 마다 고정값이다.
(현재 프레임 진동수 - 이전 프레임 진동수) / 초당 진동수 => 한프레임에 몇번 진동했는지 알 수 있다.
ex) 현재 진동수 QueryPerformanceCounter 1100이고 이전 QueryPerformanceCounter는 1000이라면은
1100 - 1000은 100이다. 1초당 진동횟수는 1000이라고 가정을 하면은 한프레임동안 100번 진동했다는 거임.
1000번진동할 때 1초이니 100번진동할 때는 0.1초임.
이게 deltaTime이다.
2. Material
잠깐 Input수정
GetKeyboardState 함수를 사용할 것임
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getkeyboardstate
이렇게 수정해주도록 하자.
해주니까 확실히 FPS더 올라감...
그래서 material이라는 것은
우리가
이렇게 mesh : 정점데이터, shader 일감 기술서 : 외주 인력들이 뭐 해야할지 기술
texture : 말그대로 texture인데
이렇게 만들어주는게 부화가 심하고 비용이 많이 들기 때문에 매번마다 새로 만들지 않고, 같은 애들끼리는 공유를 해서사용을 할 수있도록
Material이라는 것을 사용을 한다.
유니티 / 언리얼 둘다 위에서 설명한것처럼 하기 위해서 Material이라는 개념을 사용을 한다.
material이라는 것은 결국 우리가 사용할 shader에다가 이런저런 정보를 또는 어떤 인자를 활용을 할 것인지를 쭉 하나로 딱 묶어준 그런 개념이라고 보면은 된다.
그래서 이 material을 mesh한테 입혀주게되면은 해당 shader와 인자들이 다 묶여가지고 공통적으로 "적용"이 되는 것이다.
코드작성 중간중간
더이상 C-style array사용 안할 것이라서
이부분에서 std::array사용함.
array <int32, MATERAIL_INT_COUNT > 만큼 채우겠다라는 것임.
3. Coponent
유니티는 component기반 방식이고
UE는 상속기반 방식임.
유니티는 빈깡통에서
mesh나 이런저런 부품들을 조합해서 오브젝트를 만든다고 보면은 된다.
Component가 가장 base클래스이고 GameObject랑 순환구조로 만들어야 하기 때문에
shared_ptr이 아니라 weak_ptr로 만듦.
스마트 포인터
자기 자신에 대한 shared_ptr넘겨주고 싶을 경우
endalbe_shared_from_this와 shared_from_this() 를 사용하면 된다.
여기서 이렇게 사용을 하고
AddComponent에서 사용한다.
Monobehaviour
생성자를 보면은 조금? 좆밥이 보기에는 복잡한데
Component를 상속을 받는데
Component의 생성자가 COMPONENT_TYPE type을 인자로 받기 때문에 꼭 넣어주어야 컴파일 에러가 안뜬다.
4. Scene
싱글톤
강의의 첫번째 부분은 안좋은? 싱글톤이다..ㅠ
이버젼 써야됨.
static SceneManager* _instance;
public:
static SceneManager* GetInstance()
{
if (_instance == nullptr)
_instance = new SceneManager;
return _instance;
}이거 사용하면 안됨.
free나 nullptr사용할 경우 망가진 싱글톤이 된다.
(return 받은 _instance에다가 nullptr넣을 경우)
C# for_each?
이 for문 C# for each랑 비슷함.
위랑 아래 완전 똑같은건데
for ( : ) 이게 가독성이 더 좋음.
만약
vector<shared_ptr<GameObject>> _gameObjects;
이런식의 shared_ptr을 가지는 vector가 있고
#################################
1번
for (const shared_ptr<GameObject>& gameObject : _gameObjects)
{
gameObject->Awake();
}
##################################
이렇게 순회 할 경우와
##################################
2번
for (shared_ptr<GameObject> gameObject : _gameObjects)
{
gameObject->Awake();
}
#################################
이렇게 순회 할 경우는 다른데 '&' 로 받으면 ref count 늘어나지 않는다.
1번의 경우에는 ref count가 증가하지 않고
2번의 경우에는 ref count가 증가한다.
GameObject관리
지금은 vector로 GameObject관리를 하는데 하나의 Scene에 Object가 천개정도 있을 경우 Player를 찾을 때는 O(n)이 걸림.
그래서 유니티나 UE에서는 Layer를 놔둠.
그래서 vector를 하나만 만드는게 아니라 vector의 32정도의 배열을 만들어서 관리를 함 => 성능 향상.
정리 ❗
Win32API JumpKing과의 구조가 점점 비슷해진다.
처음에 초기화 부분 정신 나갈거 같았는데 조금씩 내가 상상하던 Frame이랑 비슷해지는 느낌임..
