User Tag List

Page 2 of 2 FirstFirst 12
Results 41 to 48 of 48

Thread: Training Livestream - Getting Started with C++ in UE4 - April 18 - Live at Epic HQ

  1. #41
    0
    Unreal Engine Developer
    Join Date
    Mar 2014
    Posts
    76
    Quote Originally Posted by Ninjin View Post
    I think you totally forgot to give an argument why Blueprints are good for ANY good project. I'm not trying to avoid them, I just don't see why they make a tutorial about this well documented stuff instead of basic stuff that is long overdue. I'm reading #programming on Discord and I'm fascinated that even the pros I look up to suddenly get confused with basic stuff and argue about code they are writing everyday.
    I'll get to "why are BPs good for any project" at the bottom of this post, but yes, that's how it often is. There are a lot of different ways to solve the same problem in C++ (or other languages). Sometimes you'll find a better/worse difference. Sometimes it just depends on your personality, or the way your teammates think, or the particular restrictions of your game.

    Quote Originally Posted by Ninjin View Post
    I know the ups of Blueprints, but if you are working alone on a mobile title, you can ignore all of them and write your whole game in C++ (yes, such people are the minority, I know, but you could technically add every other guy who works alone to this). ... To be fair, I prototype a lot in Blueprints, they got their place but in the end I convert everything into C++. I don't need any nativize Blueprints to see how my game actually performs and my executable stays as small as possible.
    I personally do use some BPs, with nativize, when working on my own. But if I have so much as one designer or artist, I use more BPs. In any case, if a tool is useful to you at some times but not others, then definitely use it only where it helps.

    Quote Originally Posted by YasuoCodes View Post
    This, what Ninjin has said.
    I do the same convert everything to C++, no nativized Blueprints. I could careless for Blueprints. The reason I chose Unreal Engine 4 is because of C++ and not Blueprints. They are nice to handle the GUI framework for C++, but I could do without them.
    Hand-converting BPs to C++ may result in slightly faster/smaller code than nativizing BPs, but the nativization process as it stands gets most of the performance back, and I'm talking "good enough for high-performance AAA games" here. For example, Paragon uses nativized BPs, and running a game like that - highly complex visuals, ten players, hundreds of AIs - at the framerates it hits leaves little room for slack. However, if you really prefer C++ exclusively, it's fine to use it. For a long time, that was my personal preference, and I learned to expose things to data-driven, editor-based sources only because I had non-programming team members. In other words, it was something I did for others, not for myself. I've noticed that my output in small, personal projects looks better if I use BPs for some things. Usually it's just minor stuff like custom things I want to put in only one or two places in my game, or special events that happen in just one level, but overall, I find that the freedom to hook up "art" type stuff just somehow comes out better when BPs are used. But overall, "not everyone on the team is a C++ programmer of the caliber we want writing code in our game" is a great reason, and you should use the tool that works best for your situation on a case-by-case basis.

  2. #42
    0
    Just finished watching the stream and wanted to drop in and say my thanks. I like the way @Richard Hinckley 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.

  3. #43
    1
    Quote Originally Posted by Richard Hinckley View Post
    Hand-converting BPs to C++ may result in slightly faster/smaller code than nativizing BPs, but the nativization process as it stands gets most of the performance back, and I'm talking "good enough for high-performance AAA games" here. For example, Paragon uses nativized BPs, and running a game like that - highly complex visuals, ten players, hundreds of AIs - at the framerates it hits leaves little room for slack. However, if you really prefer C++ exclusively, it's fine to use it. For a long time, that was my personal preference, and I learned to expose things to data-driven, editor-based sources only because I had non-programming team members. In other words, it was something I did for others, not for myself. I've noticed that my output in small, personal projects looks better if I use BPs for some things. Usually it's just minor stuff like custom things I want to put in only one or two places in my game, or special events that happen in just one level, but overall, I find that the freedom to hook up "art" type stuff just somehow comes out better when BPs are used. But overall, "not everyone on the team is a C++ programmer of the caliber we want writing code in our game" is a great reason, and you should use the tool that works best for your situation on a case-by-case basis.
    @Richard Hinckley:

    Interesting read especially about Paragon, thanks for sharing. (Waiting for yest steam to hit YT)...
    Has there ever been discussion about adding BP node right-click -> view source / go to source?
    While Kismet didn't have this either it was easy to locate nodes as source was always installed.

    Learning about implications / usage of BP nodes from looking at the docs is really hit and miss.
    I feel that's why some devs automatically jump to C++ along with the obvious flexibility gained.
    But not all devs who even use C++ in their day job want that when creating small Indie games...

  4. #44
    0
    Samaritan
    Join Date
    May 2015
    Posts
    133
    Quote Originally Posted by Richard Hinckley View Post
    I'll get to "why are BPs good for any project" at the bottom of this post, but yes, that's how it often is. There are a lot of different ways to solve the same problem in C++ (or other languages). Sometimes you'll find a better/worse difference. Sometimes it just depends on your personality, or the way your teammates think, or the particular restrictions of your game.
    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 everyone 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 ^^
    Last edited by Ninjin; 04-19-2017 at 03:56 PM.
    "The possibility of victory is only 0% when all the players give up. I refuse to make it 0% myself" - Kuroko

  5. #45
    0
    Unreal Engine Developer
    Join Date
    Mar 2014
    Posts
    76
    Quote Originally Posted by Ninjin View Post
    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.
    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.

    Quote Originally Posted by Ninjin View Post
    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"
    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 chance 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.

    Quote Originally Posted by Ninjin View Post
    *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"
    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:
    1. Epic itself trusts BP nativization well enough to use it in our own games where performance is very important to us.
    2. 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.
    Last edited by Richard Hinckley; 04-24-2017 at 09:18 AM.

  6. #46
    0
    Samaritan
    Join Date
    May 2015
    Posts
    133
    I give up, I seem to fail to realize which audience you target with these streams. Sorry <3.
    "The possibility of victory is only 0% when all the players give up. I refuse to make it 0% myself" - Kuroko

  7. #47
    0
    Quote Originally Posted by Nagoshi View Post
    Anyone looking for the recorded stream can catch it on Twitch: https://www.twitch.tv/videos/136474763
    Many thanks!!!

  8. #48
    0
    Great Livestream!

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •