Just finished watching the stream and wanted to drop in and say my thanks. I like the way [MENTION=2247][/MENTION] can explain some complex stuff using easy to understand examples. Seeing how much awesome stuff there is in UE I understand that not every stream can be about C++ but I sure can’t wait to watch more on the topic.
I think it’s lazy to answer with “it depends” on this topic. There are some bad practices on writing C++ code in Unreal and I feel someone should address these and get rid of them already. I mentioned pointer protection. I saw people talking about isValidLowLevel on Discord and how they use it (also read something in the forum). I think in the end someone replied with “try to only use simple pointer protection if(pointervar) and try to put the critical stuff outside, i.e. if a function needs to be fast, make sure the class who calls it makes all the tests and don’t put these tests inside in the function itself” (I hope you understand, because what I wrote looks even weird to me ^^). But that’s the kind of topic I would love to see. I hope you also saw the ConstructorHelpers::FObjectFinder I wrote in my post. This is simple stuff in C++ and there is just some small coverage on the docs, but I would love to see everything in action, how you use it, when would you do this function instead of that one, but most of the time, we use function yxz. GetWorld, GEngine etc., when does it exist, when am I allowed to call it, is also a topic people want to have more understanding off.
I also don’t believe nativized blueprints on PC can be measured, maybe on mobile, but I never tested it. However, there is no information about that, how is the generated file included in the class, if it’s pasted directly in the class, that would mean there is no difference, but that answer is 2 trivial ;P.
To sum it up, questions about good Unreal C++ habits and how the engine works. And please don’t point to a 3 years old documentation :3. And no, you don’t have to answer these questions just for me. At least looking at Discord, I just feel like this is what wants to see. But hey, I can be completely wrong and Epics focus should be whatever the majority needs <3.
*Also, Paragon runs pretty bad on my rig when I played it like 1 year ago and I’m pretty sure Gears of War is the better game to sell it as “great performance”. Wait, why do even argue about performance gains from nativize on Paragon? Was it CPU bound? Or is the server load smaller than Unreal Tournament or something? This might go offtopic ^^
There certainly are good and bad practices in programming in general, and UE4 (or any other engine) will not eliminate the potential for users to write bad code. There are some practices that are always a bad idea, though, and others that are sometimes bad, sometimes acceptable, and sometimes really good, appropriate answers. I don’t agree that it’s a lazy answer, and I’m sure you can see how even seasoned professionals have varying opinions. I’ve been around enough that my personal opinion is that the context matters a lot, and this isn’t one-size-fits-all, aside from some objectively bad practices.
This is a good example of what I mean when it say it’s highly dependent on the situation.
Objectively, universally good/bad practice: If you need to check two things, and one of them is fast to check, and likely to fail, while the other is slower to check and less likely to fail, always check the fast/likely one first.
Sometimes a good practice: Check outside the function because the function isn’t exposed, is called often, and would make your game slower if the check were inside it. Just be careful that you never pass it a bad parameter.
Sometimes a good practice: Check inside the function because the function is exposed, isn’t called often enough to matter, and thus is better to make robust rather than shaving every possible CPU cycle off of it. Now you don’t need all that outside check code, and if your check functionality changes, you don’t have to worry about fixing it everywhere the function was used.
You can also use things like “check” and conditional “UE_LOG” calls to catch invalid data that might cause your game to behave badly, but not crash. These will be removed when your game is built in Shipping mode, so they won’t affect players at all, but you will get the to see if they’re being hit in your own builds. Either way, the bottom line is that this is a fairly nuanced area. I hope to be able to cover some of this in future streams, so thank you for this input!
“I also don’t believe nativized blueprints on PC can be measured”
The engine comes with performance profiling tools that can do this. I haven’t used them personally very much, but there are people here who are tasked with optimization and use these tools extensively on a daily basis. In the simplest case, you could just build your game with BPs as you prototype, then run it, and note your framerates. Then go back and nativize, and note your framerates. You can then decide if it’s worth the effort to convert those BPs to C++ (and test them all), then see what the framerate from that is, though I would caution you that your gains won’t be very big compared to the effort you’re going to put in. However, you are certainly welcome to squeeze every drop of performance out of the engine if you have the engineering time to do so.
“how is the generated file included in the class, if it’s pasted directly in the class, that would mean there is no difference, but that answer is 2 trivial ;P.”
The generated code is produced while the build is being made and is compiled in with the rest of the C++ code. You can actually find it if you look around in your project directory after packaging. It’s pretty reliable, but it’s not always as well-optimized as code written by a human programmer who understands exactly what’s going on.
I’m really trying to talk about nativized BPs, and I didn’t work on Gears so I can’t say how heavily they use them. I also don’t know your personal machine, and that’s a big factor, so I think it would be fair to judge it by a standardized piece of hardware, like the PS4, where it has been running at a vertical resolution of at least 900 and holding a pretty solid 60 FPS for at least the last six months, maybe even longer. Regardless of how well Paragon plays, my points in bringing it up as an example were:
- Epic itself trusts BP nativization well enough to use it in our own games where performance is very important to us.
- BP nativization is closer (in terms of size and speed) to native code than to regular BPs by a significant margin - I’d estimate (off-hand, not official numbers) you’re getting at least 80% of the way from BP to C++ speed/size levels by clicking that one checkbox in Project Settings.
I give up, I seem to fail to realize which audience you target with these streams. Sorry <3.
Many thanks!!!
Great Livestream!
Thank you guys. Currently, the single biggest hump for Unity developers transitioning to Unreal is the C++.