Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Maik Klein

Member Since 14 Feb 2012
Offline Last Active May 14 2015 10:39 AM

Posts I've Made

In Topic: Am I crazy for wanting to switch from Ue4 to Unity?

28 April 2015 - 12:16 PM

 


C++ compile times are necessarily longer than they ought to be (longer than comparably complex code in more modern languages by orders of magnitude). This is unfortunate, but there are steps you can take to reduce compile times

Much of those costs are also the source of the strengths. I don't think it is "longer than they ought to be". Yes, it takes more time, but that is a cost paid for an actual benefit.

 

The performance killers are well documented. Opening up every #include is time consuming, and features like template expansion cause compilation time to grow rapidly. However, the benefits from those compilation costs can be amazing.

 

One of the strongest features of the language is that the compiler digs deeply into every function and searches for things to elide and eliminate, nested calls to inline, code to relocate and merge, and evaluate an enormous number of potential substitutions in order to save a few nanoseconds at runtime. Trying to do the same thing with more modern languages, the deeply-nested call trees that ultimately resolve to a single data read, the logic that in some builds vanishes completely, these are opposite of the modern language functionality.  It is possible to get some of that benefit with JIT compilation and hotspot analysis done at run time, but that moves the cost to a different time that is often unacceptable in games.  Sure it is fine if one of the load-balanced business servers in a server rack slows down for a moment for a hotspot optimization, not so much if the game stutters.

 

The compilation model used by C and C++ and several other older languages include features that are completely at odds with features in more modern languages.  You cannot perform the heavy optimizations, the heavy stripping of dead code, extracting logic from common classes or from deeply-inlined calls, the complete removal of unused logic and functions, while at the same pulling in features like complete reflection of classes. 

 

 

 

So yes, the compilation times can be much faster in modern languages.  For fast iteration that is a good thing.  But since games are still pushing computers to their limits, there are many times when those extra compile times provide major benefits that cannot be recouped in modern languages.

 

It is a tradeoff. Use the right tools.

 

 

The same for switching from ue4 to unity. They are similar tools, but they have differences. If one is a better fit for the project at hand, use that one.

 

This might interest you http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/


In Topic: Am I crazy for wanting to switch from Ue4 to Unity?

25 April 2015 - 03:34 AM

Well I am following Ue4 guidelines. I started with the ShooterGame example which already had around 70 header files.

 

They create a file called something like MyGameClasses.h which contains every header file from your project. Then they put this header file in MyGame.h and MyGame.h needs to be in every file that you create.

 

Note that MyGameClasses.h is auto generated from their build tools. Then they use something called a unity build where they put everything in one file and then hit compile. 

 

I ripped everything apart and I am managing my headers now manually with proper forwarding etc and I turned the unity build off. Also they have a tool that parses every header file to generate the necessary reflection code which also needs some time to run. I have also put most header files in the .cpp files so that I can avoid an additional header parse.

 

Now I am pretty sure I can optimize the build times a bit more because it took me 3 hours to go over every file and fix the dependencies and I probably have done a few mistakes but I don't think that there are any low hanging fruits.

 

For the architecture I don't think I have too much freedom If I want to use unreals gameplay framework. But I still don't know why it has 27 dependencies, at least I can not find that much. I think it has something to do with their build tool and the way they generate the reflection code. I should investigate further.

 

I also do not want to use blueprint, I am not a big fan of visual scripting, also the blueprint system comes with its own problems.

 

I am thinking about integrating D or C# but I am not sure how much work that would require and I really have no experience with this kind of stuff.


In Topic: Am I crazy for wanting to switch from Ue4 to Unity?

24 April 2015 - 07:14 PM

 


A simple change in my Character.h will result in a 100 sec build time.

 

Honestly, 100 seconds is nothing to complain about. Actually 100 seconds for a build is blazing fast compared to the stuff I have to deal with daily. You can barely get up, walk to the kitchen and pour yourself a cup of coffee in that time!

 

If you want to get stuff done stick with the tech you're familiar with. Switching your entire technology base just because you don't like to wait two minutes for a build is just insane.

 

EDIT:

 

Fun fact, while typing this post originally I was actually waiting for a build to complete. I can guarantee you it took longer than 100 seconds ;)

 

Just to be clear, we are talking about incremental builds right? I usually program with some sort of REPL where I hit the compile button several times are minute. I probably have to lose that habit when I code in C++.

 

I've found programs (games) powered by Unreal to be much more responsive and less buggy than comparable games made with Unity.

I could be wrong - just a feeling.

However, as Radikalizm (cool name!) said: 2 minutes is nothing. You are blessed. ;)

Unity's build time is deceptive since you're not really compiling to machine code at all. Not a .NET wizard, but it gets compiled at least once more at runtime.

But it's jit'ed so you won't notice the "second" compile time. And if you do a release build I think Unity converts the the IL code to C++. I think they call it IL2CPP not sure if it is already live though.


In Topic: What XNA really is

25 March 2012 - 05:50 PM

If you want to use XNA just be aware of it's limited deployment options. It's really designed for windows devices ( be it 360, mobile Win devices, or PC running windows ). The main differences between it and other engines is it uses C#. Most engines are written C++ with wrappers for Obj-C or Java but at it's core still C++. A few well known engines support C#, like Unity 3D. C# being one of the more modern languages have benefits for beginners but for professionals, the tradeoff in terms of performance usually isn't deem acceptable.

Good Luck!

-ddn


i only want to develop on windows.

i thought the core of XNA is c++,mhhh.. well i just read it in some forums.

how big is the perfomance tradeoff ?

edit:

what alternatives do i have ?

i made a quick google search and found this => http://www.sfml-dev.org/features.php
its written in c++ but usable with c#, dunno how this works out for game dev.

maybe u can give me a better alternative ?

In Topic: What XNA really is

25 March 2012 - 02:30 PM

okay XNA looks pretty interesting

i think i start with

http://www.3dbuzz.co...uctid=79&ref=12

i would love to read some books / guides around 3d application , like lightning system physics etc.

what would you recommend me to watch / read ?

edit:

http://www.amazon.co...32708061&sr=8-1
http://www.amazon.com/Microsoft-Studio-Creators-Second-Edition/dp/0071614060/ref=sr_1_3?ie=UTF8&qid=1332708061&sr=8-3
these books sound quite interesting

PARTNERS