아이디어이 문제는 예전에 C#으로 풀어본 적이 있는데 어떻게 풀어본지 기억이 안났다. 문제 분류를 안보고 푸는 습관을 최근 들이고 있어서 처음엔 조건문을 여러 개 거치는 그리디 방식으로 접근했다. 나름 빈틈 없이 조건문을 작성했다고 생각했는데도 계속 예외가 나오니 그리디는 아니겠지 싶었다. 그래서 종이에 숫자를 쭉 써놓고 최소 연산 횟수를 적다가 문득 DP배열을 사용해서 풀면 되겠다는 생각이 들었다.1, 2, 3은 각각 0, 1, 1으로 저장하고 시작4 이상의 값 n부터는 n-1, n/2, n/3의 연산 횟수를 확인하고 최소값에 1을 더한 값을 갖는다.입력받은 값까지 반복문을 돌려 해당 인덱스의 값을 불러온다.제한시간이 0.15초로 굉장히 짧은 편이라 통과될지 긴가민가 했지만 무난하게 통과했다. O(n)..

아이디어주어진 수보다 큰 수 중에 팰린드롬 수를 찾아야하니 일단 입력받은 수에 1을 더하고 시작했다. 그렇게 하고는 문자열의 가운데 인덱스부터 시작해서 양쪽으로 넓어지며 숫자를 비교하는 방식. 넓어지며 비교할 때는 다음과 같은 조건분기를 거쳤다.왼쪽 수가 오른쪽 수보다 크면 오른쪽 수는 그냥 왼쪽 수로 바꾼다.왼쪽 수가 오른쪽 수보다 작으면 오른쪽 수부터 끝까지 전부 0으로 바꾸고 오른쪽 수 바로 왼쪽의 수에 1을 더하고 반복문을 다시 시작한다.2번에 걸리지 않았다면 팰린드롬 완성이 방법은 잘 먹혔지만 1번 조건분기에서 문제가 있었다. 오른쪽 수를 왼쪽 수로 바꾼 후 그 오른쪽에 있는 수들도 모두 0으로 바꿔줘야 자릿수 올림이 됐던 것. 이 부분을 간과하고 테스트 케이스만 돌렸다가 몇번 실패했다.#inc..

"> 아이디어사실 접근 자체는 어렵지 않았다. 일단 원점부터 주어진 좌표까지의 거리를 double로 저장해두고 최대한 점프로 거리를 좁힌 후에 특정 범위에 다다랐을 때 조건분기로 걸린 시간을 구해내겠다는, 단순하지만 해답에 거의 가까운 발상이였다. 조건분기로는 세 가지 경우를 고려했다.점프 두 번점프 한 번 + 걸어서그냥 걸어서하지만 이걸 조건문으로 돌리려니 어떻게 조건을 걸어야할지 참 막막했고 그냥 MIN을 써서 최소값을 구하는 방식으로 구현했다. 그리고 빼먹은 경우가 있었는데 바로 점프를 어떻게 사용하던 애초에 걷는 속도보다 느린 경우다. 이걸 나중에 알아내서 조건을 추가해줬다.해답#include using namespace std;int main() { double answer = 0; ..

아이디어주어진 n개의 값들이 들어있는 배열을 거꾸로 탐색하고 2중 for문으로 다시 정방향 탐색하며 비교하는 방식을 사용했다. 미리 찾아둔 오큰수 인덱스와 비교해가며 찾기 때문에 깡으로 정방향 탐색하는 것보다는 시간이 덜 걸릴것 같다는 생각이였다.memset(nge, -1, sizeof(int) * 1000000);for (int i = 0; i > arr[i];for (int i = n - 2; i >= 0; i--) { for (int j = i; j = 0) { if (arr[i] 하지만 시간초과가 났고, 더 이상 아이디어가 떠오르지 않아 문제 분류를 확인했더니 스택이 있었다.해답배열은 정방향으로 탐색한다. 스택을 선언하는데, 여기에는 배열 요소들의 인덱스를 넣는다.배열을 ..

사실 예전부터 백준에서 PS를 해왔었고 나름 재밌는 취미생활로 여겼다. 골드2 까지 찍고나니 그래도 실제 프로젝트에 써먹는 일도 생기고 조금 자신감이 붙었는데 이거저거 한다고 한동안 쉬니까 머리가 또 굳어버렸다. 본격적으로 취업을 위한 포트폴리오 정리와 코테 준비를 시작하니까 이게 정말 확 와닿았다. 그래서 새로운 백준 계정을 만들며 내 나름의 규칙을 정하기로 했다. 1. 하루에 1솔브 이상2. 고생해서 풀었던 알고리즘 분야, 또는 문제는 포스팅 하며 복기하기3. 이미 풀었던 문제도 생각날 때 포스팅하기 뭐.. 나름의 자기 자신에 대한 포부를 다지고자 호들갑좀 떨어볼겸 적어봤다..

여러가지 기능을 구현하면서 오브젝트들을 여러개 꺼내 테스트해보니 그림자가 없어서 물체들의 거리감이 느껴지지가 않았다. 게임은 비주얼적인 부분이 아주 중요하다고 생각하기 때문에 내가 불편하다 느끼면 바로 고쳐야 직성이 풀린다. 조금 우여곡절이 있긴 했지만 섀도우맵은 구현해냈다. 골격을 사용하는 모델의 경우에도 잘 적용되도록 Skinned Mesh에 대한 확장성도 고려해서 쉐이더를 작성해줬다. 문제는 여기서부터다. 안그래도 예전부터 애니메이션이 적용된 테스트 모델을 불러올 때면 프레임이 기하급수적으로 떨어졌다. 뭐 별거 하는거도 없는데 평균 130 중반정도. 거기에 더해 모델의 움직임을 구현하면 10프레임정도 더 떨어졌다. 움직이면 프레임이 추가적으로 더 떨어지는걸 보고 당연히 Transform의 갱신과 ..

엔진 개발이 나름 순조롭게 진행이 되서 이제는 이전에 미뤄뒀었던 물리엔진쪽을 건드리고 있다. 자연스럽게 충돌 감지를 위한 콜라이더 구현을 하게 됐고, 이에 따른 테스트 및 디버깅이 계속 수행되는 중이다. 박스형태의 콜라이더를 먼저 구현하는 중인데 범용성을 위해 AABB 방식은 완전히 배제하고 OBB 방식만을 고려해서 구현 중인데, 문제는 얘네가 진짜 충돌하고 있는건지 시스템이 뱉는 로그나 값만 보고 판단 가능하다는 것이였다. 지금이야 그냥 박스 오브젝트끼리 충돌시키니까 콜라이더와 오브젝트의 크기가 딱 들어맞지만, 복잡한 메시를 가진 오브젝트에 콜라이더를 적용시킨 경우라면 충돌을 잘못 감지하고 있는건지 내가 알 길이 없기 때문에 실제 충돌 감지 범위를 보여주는 별도의 렌더링이 필요해진 상황이다. 콜라이더는..

모델 애니메이션 구현 작업을 하던 도중 Position, Rotation, Scale 세 가지 요소들의 키프레임 갯수 중 가장 많은게 무엇인지 알아내야하는 상황이 생겼다. c++ 11 이상부터 algorithm 라이브러리를 참조할 시 std::max({ v1, v2, v3... }) 의 형태로 간단하게 최대값을 알아내는게 가능하다. 본인의 엔진 개발은 c++ 20의 환경에서 진행되고 있으므로 전혀 문제가 되지 않을 것임에도 불구하고 컴파일러는 에러를 뱉어냈다. 혹시 c++ 20에서 중괄호를 작성하지 않는 것으로 바뀐건가 싶어 중괄호를 지워보니 작동은 됐지만 첫번째, 두번째 인자만 비교하고 그 이후의 인자에 대한 비교는 이루어지지 않았다. 원인은 window 라이브러리에 포함된 minwindef.h 에 ..

엔진을 개발하다보니 여러 정보를 GUI를 통해 제어해야할 필요가 생겼다. MFC같은 고전적인 방법도 있겠지만 가장 처음 DirectX11을 접했을 때 들었던 강의 커리큘럼을 참고해서 ImGUI를 사용하기로 했다. 코드상으로 보기에 GUI를 구현하는 것이 굉장히 간단해보였는데 한국어로 기술된 자료가 적다는것 빼고는 이렇다할 단점을 찾지 못해 안쓸 이유가 없었다. 심지어 Valve, Nvidia, Ubisoft와 같은 회사들에서 지원을 받아 개발중이라고 하니 더 안심이 되기도 한다. https://github.com/ocornut/imgui GitHub - ocornut/imgui: Dear ImGui: Bloat-free Graphical User interface for C++ with minimal d..

여태까지 개발한 엔진에서 메시에 할당되는 머터리얼의 정보는 메시 자체에 저장되도록 설계되어있었다. 조금 더 자세히 말하자면 전체 메시에서 서브메시들에 대해 각각 머터리얼 인덱스를 할당해주는 방식이었다. 애초에 셰이더 코드와 관련된 부분이나 텍스쳐 정보도 전부 머터리얼이 들고있으니 문제가 없을 것이라고 생각했다. 무엇보다 서브메시 각각이 Draw Call을 하는 것이 오버헤드를 발생시킨다고 생각했기 때문에 나중에 최적화 작업을 하게 된다면 서브메시를 하나의 버퍼에 묶어서 한 번의 Draw Call로 모든 메시를 렌더링 한다는 원대한 계획도 갖고 있었다.  문제가 발생한건 Skybox를 구현하려고 하면서 부터였다. 일단 엔진에서 기본적으로 생성해둔 구 메시 데이터를 불러와서 Skybox 텍스쳐를 입혀주면 되..