FuJi Graphics

[#9] Draw call and RendererAPI, RenderCommand

목표 DrawCall(드로우 콜) 기능 구현 DrawCall(드로우 콜)은 '이런 정보를 주었으니, 이런 방식으로 렌더링 해라'라고 커맨드 큐와 같은 컨테이너에 명령을 제출하고 그래픽카드에게 렌더링 명령을 내리는 것을 의미합니다. Renderer Architecture 화면에 렌더링을 해주는 특정 기능들의 집합, 렌더러의 목적과 기능, 설계 방식을 의미합니다. Render Command Queue 렌더링이 완료된 Scene들을 렌더러에 의한 요청에 의해 순차적으로 처리해주는 커맨드 큐 RendererAPI 렌더 과정이 아닌 렌더러가 사용하는 API들의 집합(일종의 래퍼 클래스) 드로우 콜과 렌더러의 관계 드로우 콜이란 우리가 화면에 어떤 기하학 형상을 그리기 위해 관련 정보를 렌더러에게 제공해주는 과정을..

[#8] Vertex Array 및 test code

- 작성한 코드 OpenGL에서 Vertex Buffer와 Index Buffer를 관리하는 Vertex Array 기능을 추상화. 두 개의 Vertex Array를 이용한 test code 작성 Vertex Array // Vertex Array std::shared_ptr m_VertexArray.reset( VertexArray::Create() ); VertexArray는 OpenGL VertexArray의 기능에 초점을 맞춰서 추상화되었습니다. VertexArray는 각각의 VertexBuffer 묶음과 IndexBuffer를 가리키는 포인터를 소유하고 있는 클래스입니다. Normal Engine에서는 모든 리소스에 대한 개수를 관리하기 위해서 shared_ptr을 사용합니다. 위에처럼 Stat..

[#7] 렌더러 API 추상화 및 코드 컨벤션 수정

Normal Render API Normal Engine이 추구하는 장기적인 목표는 멀티플랫폼에서 동작하는 엔진입니다. 그러므로 각각의 그래픽 API에 종속되지 않도록 자체적인 렌더링 API를 구현해야 합니다. 이 솔루션의 장점은 특정 그래픽 API에 의존적이지 않다는 장점이 있습니다. 하지만 그래픽 API를 직접 하드코딩해서 작성하는 것보다는 추상화 단계가 하나 더 늘어나기 때문에, 속도가 아무래도 더 느릴 수 밖에 없습니다. 저는 차후에 API가 변경될 가능성이 있기 때문에, 특별히 API를 변경해도 코어 내부의 코드가 동작하는데 문제가 없도록 하드코딩을 최대한 지양하는 방향으로 진행하려고 합니다. Vertex Buffer 및 Index Buffer 코드는 프로젝트를 진행함에 따라서 앞으로 구조가 바..

[#6] docking 시스템 추가, LevelContainer 수정, Log 편의 기능

도킹 시스템 구현했습니다. 사실 ImGui에서 만들어져있는거 전에 그대로 포팅한 걸 ImGui 도킹 브랜치 버전으로 세팅하고 다시 포팅했습니다. 버튼추가나 기능 넣는데 편하게 될 것 같네요. 컨테이너가 관리하는 각 레벨 계층마다 UI를 자기가 넣을 수 있게끔 창 렌더링이 개별적으로 동작합니다 로그 편의기능도 좀 손봤습니다. 각 생성자마다 NR_CORE_INFO_CTOR or DTOR 매크로 붙여주면 알아서 로그 출력해주는 기능입니다 다만 처음에는 클라이언트 진입 포인트(일종의 int main)에서 직접 Log 관련 클래스를 초기화(init)해주고 사용하는 방식을 사용 했었는데, 일부 static 클래스들이랑 런타임시 외부 참조 에러가 나서, 그냥 Log 클래스를 전역 싱글톤으로 리팩토링 했습니다. 참고로..

[#5] Imgui example renderer 연동 테스트

https://github.com/ocornut/imgui/blob/master/examples/example_glfw_opengl3/main.cpp 이 예제 대충 엔진에 포팅해서 구동시켜보려고 렌더러 클래스 따로 만들었는데 링크 순서 꼬이고 솔루션 디렉터리 설정 꼬이고 죽는 줄 알았습니다.. 그래도 어찌되었던 성공해서 다행이네요 위 예제를 클래스로 포팅한 코드입니다 대충 프레임 기능 짜맞춰서 애플리케이션 레벨에서 렌더링 + 업데이트 같이 시켜서 돌렸습니다. // 테스트용 코드들 이제 렌더러 연동 확인했으니 렌더러 만들어야 하는데 vulkan예제 테스트도 마저 해보고 vulkan부터 만들어서 엔진에 연동할 예정입니다

[#4] Keyboard, Mouse InputManager, LevelContainer

반복 횟수는 아직 구현을 못했네요. 잘 동작하는 것 같습니다. glfw로 윈도우에 들어오는 이벤트에 대해서 콜백 함수를 등록합니다. 그리고 작성된 키보드 매니저에서 콜백 함수 OnEvent가 호출되면 GLFW에서 설정된 액션에 맞게 IsPressed, IsReleased 함수를 호출합니다. BIND_EVENT_FUNC는 std::bind를 통해서 함수포인터에 템플릿 타입에 대해서 바인딩해주는 매크로입니다. 해당 매크로를 통해 각 버튼에 대해서 호출이 될 수 있도록 함수를 바인딩해줍니다. 그리고 NR_SET_NAME은 디버그 모드에서만 클래스들이 이름을 가질 수 있도록 설정해둔 매크로입니다. 저번에 만든 로그 기능에서 직접 해당 변수를 대입하는 대신 NR_GET_NAME 를 사용하면 디버그 모드랑 릴리즈 ..

[#3] Log, Event 시스템

로깅 시스템 로그 시스템은 spdlog 라이브러리를 랩핑해서 사용합니다. spdlog 라이브러리 사용법은 https://github.com/gabime/spdlog 이곳을 참고하면 됩니다. setPattern은 아래와 같은 매크로를 통해 애플리케이션 레이어와 코어 레이어에서 로그 호출을 구분하기 위해 정의해두었습니다. SPD_LOGGER_CALL은 spdlog 내부에서 호출 위험 레벨에 대해 직접 할당하던 매크로 입니다. 저는 메세지만 입력하고 로거 호출은 자동으로 해줄 수 있도록 다시 매크로로 랩핑해서 사용했습니다. 이벤트 시스템 이벤트 시스템은 실제 헤이즐 엔진에서 사용되던 코드를 가져왔습니다. EVENT_CLASS_TYPE은 매크로 구문을 통해 상속된 클래스마다 함수를 재정의해주는 방식입니다. Ev..

[#2] 게임 엔진 베이스 코드

- 엔진 요소의 기본 구성 Normal Engine의 기초 구성은 크게 4가지로 구성합니다. (Entry Point) 엔진 코어 시스템 (DLL) 애플리케이션 레이어 (exe) 2D/3D 렌더러 창 시스템 엔진 시스템 엔진 코어 시스템의 기본 목적은 사용자가 애플리케이션에서 로직을 구성할 때 필요로 하는 적절한 프레임워크나 도구를 제공하고, 게임 로직과 명확하게 계층을 구분해 시스템 관리를 용이하게 하기 위함입니다. 일반적으로 동적 링크(DLL) 형태로 애플리케이션과 상호작용하며, 기존 프레임워크나 도구들이 DLL 형태로 애플리케이션에 제공되도록 솔루션을 구분해서 작성합니다. 위 사진처럼 EntryPoint.h 코드의 구성 요소를 보면 엔트리 포인트로 애플리케이션 레이어와 엔진 코어가 상호작용 하도록 분..