일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- UnrealEngine4
- directx
- C
- 백준
- algorithm
- Unreal Engine5
- RootMotion
- 언리얼엔진5
- DeferredRendering
- 티스토리챌린지
- Programmers
- GeeksForGeeks
- RVO
- 2294
- baekjoon
- 프로그래머스
- DirectX11
- 팰린드롬 만들기
- 오블완
- winapi
- NRVO
- const
- C++
- UE5
- 1563
- 줄 세우기
- Frustum
- IFileDialog
- softeer
- UnrealEngine5
- Today
- Total
목록UnrealEngine5 (31)
Game Develop
이런 enum class의 상태들이 있을 때, 이것들의 순서를 변경했다면 반드시 행동트리에서도 관련된것들을 다시 체크해줘야 한다.나같은 경우 순서를 바꿨었는데, 그럴경우 행동트리에서 데코레이터노드의 값들이 변경되거나 아예 값이 설정이 안되어있기도 했다. State Is Equal To Chase라고 지금은 잘 되어있긴 한데, 뭣모르고 바꾼다음에 몬스터AI가 이상하게 수행되었었다.그러다가 자세히 보니 값들이 풀려있거나 다른것으로 설정되어있던것을 확인할 수 있었다.혹시 갑자기 행동트리가 멋대로 작동한다면, 이 부분을 확인해볼것.
const UEnum* enumPtr = FindObject(ANY_PACKAGE, TEXT("EMainPlayerSkillStates"), true);if (enumPtr != nullptr){ for (int i = 0; i NumEnums(); ++i) { EMainPlayerSkillStates enumState = (EMainPlayerSkillStates)(enumPtr->GetValueByIndex(i)); //UE_LOG(LogTemp, Log, TEXT("> %s"), *enumPtr->GetNameByIndex(i).ToString()); }} 구글링 시, 언리얼4버전에서는 FindObject할 때 꺽쇠로 캐스팅할 클래스명시 안하는걸로 되어있는데, ..
프로젝트의 TMap컨테이너를 사용해야하는데 Key값으로 FName을 사용하거나 주소값 (AActor*라던가 등)을 사용하곤 한다. 이 때 FName을 Key값으로 사용할 시, 성능이 괜찮은지 궁금해서 구글링하던 결과 괜찮은 글을 찾았다.근데 이건 6년전 글이라 UnrealEngine4 버전 기준이다.성능이 빠르다는것은 5버전이더라도 유효할것이고, 이유도 비슷할거라서 일단 포스팅했다.5내에서의 원리는 추후... 언젠가 조금이라도 분석해보겠다. https://www.reddit.com/r/unrealengine/comments/828neo/questionfname_performance_in_a_database_tmap/?rdt=45138 From the unrealengine community on Red..
필요없는 잡소리를 듣고싶지 않다면 https://forums.unrealengine.com/t/when-is-the-constructor-called/480067 When is the Constructor called?Hey guys, first of all, i am sorry for my English. So i need to say that i am in the beginning of GameDev. I know the basics of c++, and so on, and therefore i wanted to look into Unreal Engine. My Problem is something like this: why is it not possible toforums.unrealengine.c..
UPROPERTY를 당연히 쓰긴 써왔지만, 사실 각프로퍼티에 대해 좀 헷갈렸었다. 설명은 많지만 아키타입이 뭔지도 헷갈리고, 그냥 적용범위가 넓은 프로퍼티를 써서 되게만 해왔던 것 같다. 하지만 const처럼, 읽기전용으로 할것을 굳이 Edit관련 프로퍼티를 넣을필요가 없기에 한번 싹 정리를 했다. 공식문서등에 나오는 아키타입이란 것은, 우리가 어떤 액터를 만들고 해당 액터를 상속받는 블루프린트클래스파일을 만들경우 이 블루프린트파일이 아키타입이라 생각하면 된다. 유니티의 프리팹이랑 매우 비슷한 개념이라고 하며, UPROPERTY에서 아키타입에 관해 Edit이라던가 Visible관한 설명이 나오면 이 블루프린트파일내에서 디테일패널에 표시할건지, 수정까지할건지 등에 대한 속성을 결정하는거라 보면 된다. 위의..
다른부분에 대해서 구글링하다가, 우연히 접하게 되었다. 이름에서 알 수 있듯이, C++의 inline과 비슷한데 좀 더 강력한 강제성을 지녔다고 한다. 애초에 c++에서의 inline같은 경우는 명시하더라도 컴파일러가 임의로 인라인화를 안시킬수도 있으며 inline을 명시 안했더라도 인라인화를 시켜버리기도 한다. 예를들어 헤더에서 함수정의까지 할 경우 인라인화를 시키는 경우가 있다. 그에반해 언리얼 FORCEINLINE은 좀 더 강제성을 띈다고 한다. 다만 당연히 무조건 좋은건 아니고 공식문서에도 좀 더 보수적으로 사용하라고 되어있다. 어떤곳에 사용하지않는게 좋은지는 알아갈때마다 이 글에 추가해봐야겠다. 일단 현재는 Getter 함수에다가는 전부 선언해줬다.
ActorPool로 관리할 액터들에게 PoolableActor라는 인터페이스를 상속시켰었다. 해당 인터페이스에는 m_bIsActive, 즉 활성화여부를 따지는 bool변수 딱 하나만 있었다. 아무생각없이 그렇게 하다가, 인터페이스 관련 글을 보다보니 원래 객체지향설계에서 인터페이스에는 멤버변수가 없는게 정설이라고들 하더라... 원시타입인 bool 하나라서 괜찮지 않을까? 싶다가도, 후에 특정 액터클래스에도 같은 변수명이 있을수도 있는, 즉 겹칠수도 있는 상황이 있을수도 있단다. 생각해보니 말이 된다. 물론, 현제 내가 아는 영역에서는 활성화여부란 액터풀에 관련된 활성화여부밖에 없지만, 그건 취준생의 생각일 뿐이다. 그래서 언리얼 인터페이스가 아니라 그냥 추상클래스로 바꾸려고 여러 시도를 했다. 거의 인터..
튜토리얼?이라던가 그런것들 보면 보통 생성자에서 부착해서 쓰고들 한다. 그래서 생성자에서만 호출 가능한 로드함수들을 사용하고는 한다. CreateDefaultSubobject라던가 ConstructorHelpers::FClassFinder (혹은 FObjectFinder 등) 같은 걸 쓴다. 일단 기존의 생성자에서 호출하는 코드. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 UWidgetComponent* widgetComponent = CreateDefaultSubobject(*assetPath); widgetComponent->SetupAttachment(mesh); widgetComponent->SetRelativeLocation(relativeLocation); wi..