UE4 With Casey - My C++ Workflow
ฝัง
- เผยแพร่เมื่อ 28 ก.ย. 2024
- Today I ramble about how I work C++ into my games. Personally, I use it as a performance tool at the end of my game cycle. Here, I show you how easy it is to work C++ into your own games.
I love all your videos man, they are so well made and clear. Keep it up!
Thank you for sharing your workflow! Awesome explanation!
People underestimate how easy C++ is, putting this turret code in C++ would literally be only a few lines of code plus its so much easier to read when you extend it and make it more complex, blueprints are great but C++ actually teaches you good coding practices, how to really use unreal engine at a low level. Makes life easier in the long run, more of an investment in yourself.
The same thing I learned. I understand blueprints even better after deciding to learn c++ along it.
Yeah, c++ is easy, the compilator and linker are true evil here :D
thanks man very useful info.
Thank you for providing a simple explanation for us noobs!
Great ifno, keep on going you deserve lot of followers!
Great info. Many thanks!
Wow
What about built-in blueprint function nodes? Do they directly call C++ code or do they in turn call other blueprint nodes (like your custom "FindClosest" function)? Should you convert built-in function nodes into C++ and how would that work (For example, converting your "MultiSphereTraceForObjects" into C++)?
User made functions written in blueprints only call blueprint nodes, that isn't converting to c++. However, there are some functions included in the base unreal math library that does some of what I'm describing. Like the node "find look at rotation" is a single call from blueprints down to c++, however in c++ its doing several calculations before returning a value.
Moving the traces over to c++ is actually something I dealt with a few days ago for one of my games. It turned out that its very frustrating to get them to work in C++ and that most people recommended doing the traces in blueprints and then sending the hit results to c++ instead.
I would look at it this way, if I use the built in trace function in unreal I'm making a single call from blueprints to C++. If I rewrite that trace by itself in c++ and then call it in blueprints I'm still making a single call from blueprints to c++ to trace. There's no performance gained. The idea is that we want to group up a collection of calls or math calculations that we are doing in blueprints and group them into a single function in c++ so that there is a single call. A good example of that is how I showed we can move the find closest calculation over and it doesn't have a larger effect on the blueprint workflow.
The more we can group together the better, but there is definitely a limit.
Okay... so built-in function nodes such as "MultiSphereTraceForObjects" or "SetWorldRotation" do only a single call and thus are unneccesary to do in C++... have I understood this correctly? Does this apply for ALL built-in nodes (including all math nodes)?
How do you know exactly how many calls a non-user made (built-in) function makes? Sorry if it's a stupid question but I really have no idea...
The time when you would want to move something like "setworldrotation" over to c++ is when you can group that node with several others that will always need to be ran together. If you know every time you run "setworldrotation" you are also doing things like math, some branches, and maybe settings some variable values then it could be worth grouping all of them into one c++ function. By itself its not worth moving, but when it can be grouped that's when we can save some performance.
I'm not 100% sure, but I do believe it applies to all built-in nodes. I don't think the answer is in the documentation and it has been awhile since I heard the answer in one of Epic's talks.
A built in function should only make one call. That is because the all the code inside the function exists in c++.
Ok gotcha! Thanks! :)
Great video! What is your opinion on BP Nativization?
Great when it works, but I've had serious issues in the past getting it to work. One of the biggest issues (at least at the time) was that any blueprint with a blueprint defined struct couldn't nativize. Along with that, I believe any blueprint that referenced a blueprint that had that same struct also couldn't. This was probably back in ~4.15 though.
For me, the time wasted trying to clear every nativization error isn't worth when I could spend less time just rewriting in c++ and get more performance.
@@ue4withcasey391 Gotcha! Thanks! I'll have to do more research into if they have made any improvements with nativization. My project also is heavily reliant on structs so that wouldn't be good.
@@ue4withcasey391 1 year later, and now it's working awesome.
It would be nice if u show some numbers profiling the same code in blueprints and cpp.
I didn't make this but here is an example th-cam.com/video/V707r4bkJOY/w-d-xo.html
However that video isn't a perfect example it seems, read the top comment for more info.