You don’t always need the raw speed of C++, especially in scripting. Hell, I’m willing to bet that the execution time differences between Unityscript, C# in Unity, and Blueprint are almost nil.
There’s a new BP math node which makes it as simple as that.
Are you sure of it dear? The following situation is very important to me:(AI)
On each frame or particular conditioned moment, an master object/actor will request various properties of at least dozens objects/actor. Then a big decision script will work on each and every object on scene and pass the information to each-other. Then some checker script will check for all objects to make sure all is ok. You see heavy amount of processing. Speed is crucial for me.
Another scenario is certain gesture detection, for inputs.
Yep, that sounds like something you’d want to do in C++ (which would also be faster than C# scripting I imagine).
1 Like
You can write decent performing engines in C# with OpenTK, it’s not C# that’s the issue here.
There’s a reason I specified C# in Unity. It’s kinda a long-standing thing that it’s nowhere near as performant as it should be.
Yeah. But you still have to drag the node into place and connect up the wires etc. In a scripting language when I want to write the next “node” I just press return.
As for speed. It is possible in C# to write “unsafe” blocks which execute very fast. Not sure if you can do that in Unity… but it could if it wanted to.
1 Like
It’s certainly a different workflow, but as with all things, it depends on the task at hand and your own preference. Some tasks will be faster with Blueprints, and some with scripting. Of course, C++ also has a run time speed advantage, which is nice if you simply like to do all your work in code.
C# is not really “scripting”, C# is compiled into CLR bytecode (similar to Java) which is pretty close to native code (in C++) or similar in terms of speed. Same thing for UnityScript and Boo (does anyone even use Boo, anyway?). Of course, that leaves the efficiency of the library out of the consideration, and of course, the same might be true for Blueprint (or it could even be compiled into real native code).
If Unity’s C# is too slow, it’s probably not C#s fault but either that of the Unity libraries or of your code.
Or, you know, Unity’s ancient Mono implementation.
Whoops, good point.
I wondering why certain people are still here and bitching about every aspect in Unity, if they think UE4 is so superior.
If I’d think that Unity sucks for my projects, I’d simply switch and not look back. Simple…
2 Likes
How dare we want long standing issues that have gone years without being fixed be improved instead of migrating to a new engine.
1 Like
No need to get cynical.
Repeating the same stuff over and over again, doesn’t gain you anything in this situation. We told them thousand times now that the prices are too high, that they need to ramp up their development speed, that Unity offers too few compared to UE4.
They should be well aware of that now.
All I see here is simple bitching and cycle jerking, beating a dead horse.
1 Like
Except it’s not just these things.
It’s the outdated version of OpenGL for deployment on non-Windows desktop platforms. It’s the terrain system that’s had an update request sitting in the feedback section for five years, it’s the ancient implementation of Mono that is only seeing any improvement by being replaced on mobile platforms, it’s the fact that Unity can’t handle having a controller unplugged and plugged back in, it’s the lack of properly exposed particle scripting. These aren’t new problems, they’re old problems that are getting ridiculous.
4 Likes
Yes and we mentioned those issues as well. Several times. I just picked some examples.
It’s pretty obvious that UT will announce their news at Unite. You might not like their secretiveness. Me neither. But that’s how they work at the moment.
I’m not a part of their beta. So I don’t know what they’re cooking up. I’m waiting for Unite and form my opinion after I collected the relevant informations about Unity5 and possible price changes.
But repeating the same stuff over and over again doesn’t seem to help anyone. Especially if nobody here really knows what they currently planning, or working on.
It’s not that I didn’t criticize UT and Unity. I did that too. But I think we reached a point where UT gained the infos they needed to actually improve things.
If they don’t, well I’m one of the first people here who jumps ship. On that you can be sure.
But until any official announcement it’s just beating a dead horse in my opinion.
And what happens if Unite comes and goes and nothing changes?
Then…
Ultimately, you vote with your wallet.
I’ve been waiting for improvements since years. And believe me, I’m tired of that and UT’s hollow promises and teasing.
The stuff they have now in the works plus the pressure to deliver something great and work on their prices (thanks to UE4) still gives me some hope.
But in case they fail. “Bye Bye”
I doubt that telling them the stuff, they already know here will change anything.
If they are really that stubborn (which I hope not), I think they need it to learn the hard way (a.k.a losing tons users/customers to UE4).
And get an error (+3 sec)
Blueprint is about 10x slower than C++, that is what the devs themselves say. Which is pretty close to other scripting languages, even faster than some of them. Lua (without luajit) is what, 30 times slower than C++?
Considering Epic used almost all Unrealscript on UT3 (and 100% Unrealscript for UDK utgame), I wouldn’t worry about the performance of it.
In any case, if you got performance issues with the blueprint, you can always move that to C++ and expose it as a single blueprint node, easy and efficient.
1 Like