Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by Shadowriver View Post
    maybe will be able to code even with QBASIC on UE4
    OMG! That would be sweet.

    10 PRINT "UE4 Rocks!"
    20 GOTO 10

    Comment


      Originally posted by timconwell View Post
      OMG! That would be sweet.

      10 PRINT "UE4 Rocks!"
      20 GOTO 10
      Man...that means we are old...but wasn't that?

      Begin:
      Print "UE4 Rocks!"
      Goto Begin

      Comment


        Applesoft BASIC didn't have labels, so GOTO and GOSUB used line numbers. Named labels were really nice. Applesoft BASIC also only allowed two digit variable names, so AA, AB, AC, etc until you ran out.

        Comment


          Haha! Yeah, probably does mean we are old, or past the point of being young at least. Feel like I ought to brush up on my basic now. The pranks we used to play in the computer lab plus teachers who barely knew how this stuff worked. Good times.

          Comment


            Originally posted by gmpreussner View Post
            I'll repeat what I said during the West Coast DevCon: All programming languages suck. They just suck in different ways

            Yup. Basically this. The interesting thing about programming is that the languages are simply tools to use for a job. I mean you can argue that a steak knife could cut steak better then a butter knife but in the end does it make it easier? Depends on the job (And how much memory you have to work with!) and the tools you're comfortable with using.

            Now having said that... I really love pointers, ha.
            Third Person Camera Zoom Tutorial, Click Me!

            Comment


              Originally posted by Master Kyp View Post
              Yup. Basically this. The interesting thing about programming is that the languages are simply tools to use for a job. I mean you can argue that a steak knife could cut steak better then a butter knife but in the end does it make it easier? Depends on the job (And how much memory you have to work with!) and the tools you're comfortable with using.

              Now having said that... I really love pointers, ha.
              Yes to the above, but having said that, the whole point is which language is better suited for the job not which language sucks more.

              It also depends on, what you are planning to prepare for your users. Will it be some "beefy" experience or just ordinary, every-day, bread and butter sandwich.

              In my opinion (and I believe most of professional AAA developers) C++ is your man.

              Gaming industry speaks C++.
              Last edited by smallB; 09-13-2014, 05:52 AM.

              Comment


                Originally posted by Shadowriver View Post
                But things already being solved, there script plugin that let you implement any scripting people like, once marketplace will be open for plugins you will maybe will be able to code even with QBASIC on UE4
                And good luck with that...

                Comment


                  "a steak knife could cut steak better then a butter knife but in the end does it make it easier?"

                  I believe a steak knife does cut up steak easier.

                  Finally! Something I know something about! Bam!

                  Comment


                    Here is an interesting talk about what is horrible in C++, by one of the top leading figure in the C++ world - Scott Meyers :

                    Comment


                      Then, this is kind of off-topic here, but some people are going to find this interesting - it's a take on game-programming from an experienced 'AAA' games developer and game-designer:



                      There is an initiative that is developing for defining a spec for a new programming-language that is 'kinda' domain-specific for games, the same way Go is 'kinda' domain-specific - this is for actual game-engine code, not scripting, so it's not about UE4 - it's more about the future of programming in games in general.
                      He goes over many interesting topics, and touches on Go, D, and Rust, what's good about them to take inspiration from and what's not.

                      Comment


                        Originally posted by EruArnold View Post
                        Then, this is kind of off-topic here, but some people are going to find this interesting - it's a take on game-programming from an experienced 'AAA' games developer and game-designer:

                        There is an initiative that is developing for defining a spec for a new programming-language that is 'kinda' domain-specific for games, the same way Go is 'kinda' domain-specific - this is for actual game-engine code, not scripting, so it's not about UE4 - it's more about the future of programming in games in general.
                        He goes over many interesting topics, and touches on Go, D, and Rust, what's good about them to take inspiration from and what's not.
                        1.) Jonathan Blow is an indie developer, not a AAA developer. He's notable for developing Braid.
                        2.) I watched the talk, I wouldn't call it a developing initiative yet. It's a week of thinking of some ways to write a better language, turned into a two hour talk.

                        That said, thanks for the link, it was a very interesting talk. I agree with most of his frustrations regarding C++, though I'm not sure he's put enough thought into his suggestions yet. In fact I think that's what the talk was, it was a kind of request for discussion on those ideas. I appreciate how often he tried to make it clear when he pulled things out of thin air.

                        Favorite part of the talk though, was the part where he mentioned wanting to stay away not only from languages built to support an ideology, but from doing that with this proposed language. That's incredibly important.

                        The 85% > 100% as a design tenet is a good way to approach this, and he did a good job at not sounding elitist when saying it shouldn't be built explicitly for newbies.

                        But whether these things just sound good or actually turn into a decent alternative to C++ for games is still way up in the air, and right now it's closer to just sounding good. Several of those suggestions sound great in theory, but I'm worried about his throwing around the word "trivial" so much in regards to creating a new language. He doesn't speak as though he has experience in language design outside of (2+ decade old) college courses on writing compilers, so if he heads this up I expect some severe growing pains.

                        Comment


                          It is very easy to come up with "great ideas" for great language. Much harder to actually see it through. That's the first point.
                          "In theory practice is simple" as somebody once said.

                          Second point - nobody ever claimed that C++ has no faults. So does C#, Java, python etc... All languages suck in some respect as one of the Epic's guys pointed out. One of most horrible things in C# or Java? Its slowness, lame template system, decompiling is as easy as compiling etc, etc. The point is that all languages have their faults.

                          Main point is that as the current state of affairs is, C++ is the best and really only vital choice when AAA game programming is concerned. There is simply no way around it.

                          And I am really tired of hearing guys coming here and claiming that performance doesn't matter - especially when game development is concerned.

                          It does matter, it always did and it always will.

                          AAA Gaming industry speaks C++.
                          Last edited by smallB; 09-26-2014, 03:58 AM.

                          Comment


                            There is one languague that solved C++ annoyances. It's called D.

                            How many people are using it ? Oh .. How many of you heard about it ?

                            While designing new language is certainly not very easy, it's also not terribly complex.
                            What is really hard:
                            1. Getting people to use it.
                            2. Build tools, to make using language easier.

                            If you don't have ecosystem around your language or you are not big enough to make that ecosystem happen (like Microsoft did with C#), then it's just academic or fun activity to make new programming language, that is better.

                            At this point, I would bet more on native compiled C#, than anything else.
                            https://github.com/iniside/ActionRPGGame - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.

                            Comment


                              Originally posted by iniside View Post
                              There is one languague that solved C++ annoyances. It's called D.

                              How many people are using it ? Oh .. How many of you heard about it ?

                              While designing new language is certainly not very easy, it's also not terribly complex.
                              What is really hard:
                              1. Getting people to use it.
                              2. Build tools, to make using language easier.

                              If you don't have ecosystem around your language or you are not big enough to make that ecosystem happen (like Microsoft did with C#), then it's just academic or fun activity to make new programming language, that is better.
                              ^^^ Agreed, agreed, agreed.
                              Last edited by smallB; 09-26-2014, 10:46 AM.

                              Comment


                                I think he makes some valid points in his talk - I don't think he is going to write any programming language himself - he even says so - so I wouldn't worry about his ability or background for being able to personally do it.

                                I think his main goal at this point is just to raise awareness of the possibility of such a project, and of the potential net-gain that can be made if/when such a thing would ever exist.

                                As for performance, smallB, it is pretty obvious from your reaction that you didn't watch the talk at all.
                                He aims for such a new language to not only be faster then C++, but possibly even faster then C.
                                Granted, this is no small aspiration, but I agree with him that it is not impossible.
                                If you take into consideration the amount of bloat, cruft and general 'legacy'/'backward-compatibility'-related encumbrances that muti-decades-old languages like C and C++ carry with them, you should be able to build a case for the viability of possibly writing a new spec from scratch that does't suffer from such evolutionary-baggage, and thus be potentially faster. He doesn't suggest another "managed-language" (like C# or Java), in fact, he flat-out dismisses the inclusion of any sort of garbage-collector as a 'non-starter', which is the main reason he dismisses Go, for example...

                                I liked how he practically dismisses the whole 'smart-pointers' story of C++11/14 as being 'impractical', due to the cost of heap-allocation(s) and the need to consolidate them for any kind of real-world viability in terms of performance. This falls flat in the face of anyone claiming that C++11 'changes the game' so to speak when it comes to memory-safety. It theory, yes it does. In practice, nope...
                                Same goes for standard-library templates for 'containers' and 'algorithms' - they may be at the point of being "affordable", in terms of 'programmer-productivity' (thanks to the addition of 'Lambdas' and 'auto'), as well as 'run-time-performance' (mainly thanks to r-value references, 'Move-Semantics', perfect-forwarding, variadic-templates, etc.) - but all of this is not 'free', and incurres a cost at 'compile-time' - which makes them ultimately 'un-affordable' in the grand-scheme... (at least for large-projects, due to the accumulative compile-time-cost).

                                I am not sure this is a solvable-problem in a new language, but let's think about it:
                                Let's say a new language is designed, do the default-behaviors are the ones that are actually being used ~80% of the times in C++ anyways:
                                1. Variables are 'immutable' (const) by default, and you have to explicitly define them as mutable using a key-word (Rust does this).
                                2. Ownership is 'Moved' by default, and you have to explicitly state you want to 'Share' (Rust does this, sorta...)
                                3. Arguments and assignment-operators are 'pass-by-reference' by default, and you have to explicitly say you want a 'copy' in case you do.
                                4. Memory-Allocations of members (for structs/classes) are optimized in the compiler to be done 'in-bulk' by default, as well as guaranteed to be layed-out sequentially (which prevents the whole 'memory-block-member' workaround shown in the video, and known very well by game-developers).
                                5. Pointers are unique by default (using a standard-notation, built-in to the language, not a template in a library that needs to be compiled...).
                                6. Shared-pointers have their own notation (say, re-purposing the '&' for this semantics, given No.2 + No.3 makes C++ style references redundant).
                                7. Arrays are implemented built-in as the C++ Vectors are, and not as a compiled-template.
                                8. All other containers as built-ins instead of templates (Maps, List, Queue, Set, etc.).
                                9. Algorithms as built-in-functions instead of templates (Sort, find, etc).
                                10. A decent 'Modules' architecture (no more pre-processor compilation of headers for inclusions/imports)
                                ...

                                I can go on, but you get the picture...
                                There is A LOT of room for improvement from what C++11/14 offers, just by taking a look at patterns that are already being done for decades now, and switching-up the default-behaviors to represent the +80% use-cases, as well as turning templates into built-ins - all of which can dramatically improve code-readability, expressiveness AND performance, memory-efficiency and safety, and all long before one even begins to talk about game-domain-specific optimizations...

                                So yeah, would it be difficult? Probably. Yes. Is it impossible? Definitely no. Is there a strong case for it? HELL YEAH!!!
                                Last edited by EruArnold; 09-26-2014, 01:55 PM.

                                Comment

                                Working...
                                X