Hey man, all do respect, but when you run into issues with C++ you should try googling why things are that way. C++ is still pretty well on the cutting edge of programming languages provided you’re using near the latest version. You’re really comparing apples and oranges comparing compiled languages (C++) to JIT languages (C#). Your example from earlier (header files being useless), really shows your lack of understanding. Header files exist to separate implementation from definition, essentially like a glossary for the compiler. In C# because it’s compiling to MIL it stores that data in the metadata generated beforehand that the JIT compiler can use at runtime. C++ compiling would be hell without the separation.
You don’t need to use header files in C++, it’s just not really in your best interest to avoid them.
Unreal’s UObject system is already a system for intermingling managed and unmanaged code. You’re asking for a that already exists in the engine.
No, I’m not interested to avoid them. Because now, although I’m not a programming language designer, I think like one. And when I see something that can be done better. I want to improve it. If not sooner, then at least later.
I did. And it seems I learned more than you did. Headers do exist because of C. It is a simple a lack of compiler features. Well, at least that’s what Micro$oft said on YouTube and in their proposal for their module system for the C++ standard (I didn’t read all the versions, though). Yes there is more. If I recall, mentioned that at least if UE4 wanted to make full use of a module system, that C++ may require additional syntax for its own exported dependencies.
Yes, additional syntax again… This is the very reason why I think that C++ may be beyond saving in the first place. Built-in features do have the means of making things a lot slicker. And we already know what to build in, too.
No, I’m not asking for that. I’m saying that a hybrid programming language maybe be able to do this better, without a Stitches++ feel to it. UObject is about Attributes, UClass, UProperty, etc… This is why hot plugging works in C++, too, .Net does the compiling via editor/engine code (Actually I’m guessing. But I did something like that with C# files on top of my own C# console program). Though, these C++ Attributes look more like a typical C++ hack via macros, because language features are missing. You know there is a language that can do reflection very well, and does have built-in attributes…
And, this is not just about UE4. This is also about other game engines and software types (especially new ones). A hybrid language wouldn’t be just optimized with it syntax, it also could allow the very fast refactoring of managed or native code. You wouldn’t need to make a new native or managed V$ project and than move your code, but instead, change the source file type and then let the IDE refactor any declaration and member access to native or managed identifiers. You would need extra coding if you moved from managed to native(obviously). But at least you can do it this way a lot faster already. With a hybrid language, it would be a mere choice of what language you want to use, depending on what you even need, instead of choosing between two languages and start all over again.
There are programmers who complain that .Net likes to eat away a LOT of more memory than a native code would. Well, if M$ had a good hybrid language the effort of fixing this could be reduced. And keep in mind, Unity supports C#, but it still needs an extra V$ add-on for debugging. A hybrid should support full debugging right out of the box.
That’s a gross oversimplification on headers. They’re a holdover from C, but they’re still a pretty core part of how the C++ compiler works. These days it has about as much to do with C as anything in C# has to do with Java. If they wanted to make header files optional they certainly could (and in some ways they are especially if you’re using tools to automatically generate headers/C++ files from unified files), the language specification changes every couple of years.
The is already there in unreal though. Whether or not it already exists in a different language is irrelevant, because it is already supported in the language the editor is written in. I don’t think it’s really worth the time to implement a new language to support features that are already supported.
There have been hybrid languages before. Even you mentioned managed C++. Few people use them because the performance is generally sub-par or the syntax is often even worse than dedicated languages (jack of all trades, of none), so using 2 languages for the parts of your application that benefit from the languages’ strong points is almost always better.
But with 2 languages you will have the boundary between native and managed again. Making calls to native costs extra performance. And debugging. How is even the debugging experience with a C# and UE4? The download link for UE4 C# 4.5 is dead. I can’t try it for myself.
Good thing that M$ bought that Unity plugin (you can’t debug without this plugin at all), too… And is making a module system for C++…
I understand that under the hood, C++ is different than C#. But boy, first impressions are powerful. So I came to C++ and guess what? Dose attributes they are in like four locations (generated include, [projectname]_API, UCLASS, Generaded_Body). Because actually they are macro hacks and not even actual attributes. You think I don’t like that? Well, ask IntelliSense what it thinks about this hack. Still headers… IntelliSense like to take its time… At least V$ doesn’t spit entirely at C++ and is kind enough to auto add the semicolon after the closing bracket of a class. And what’s wrong with the definitions of the declarations?
See, the declaration in the header is this: static FString GetDateAndTime(float playedTime, FLoreTime start, FLoreTime format);
But, the definition is .cpp file is this: FString UcLoreTime::GetDateAndTime(float YourMom, FLoreTime ShowsItOnPronHub, FLoreTime AndThatForFree)
And this actually compiles and executes only because the name and signature is correct… Some first impressions…
If you add many small things together, you get one big thing… And I just started to learn C++. How much more non-sense will I find? 0.o
Which is actually just a cast to use a standard structure in one of the mandatory render methods.
It’s actually not that difficult, once you actually get it. Good luck getting it though, since you need to dig under tens of includes to actually see what is the actual type of the damned thing.
Not to mention the raw pointer C stuff underneath.
**** Adobe.
Unreal is kinda easy after that mess.
EDIT: this is coming from a guy who has extensive scripting experience but has just started c++ (actually got convinced by @ in a pm)
Which is actually just a cast to use a standard structure in one of the mandatory render methods.
It’s actually not that difficult, once you actually get it. Good luck getting it though, since you need to dig under tens of includes to actually see what is the actual type of the damned thing.
Not to mention the raw pointer C stuff underneath.
**** Adobe.
Unreal is kinda easy after that mess.
EDIT: this is coming from a guy who has extensive scripting experience but has just started c++ (actually got convinced by @ in a pm)
[/QUOTE]
Now that you mentioned pointers. How many of the C++ programmers do even know that C# does have pointers, too? Inside an /unsafe code of C#, the modifier “unsafe” disables GC and boundary checks on declarations. Object pooling can improve GC performance.
The city builder Cities: Skylines was made with Unity. Sadly I can’t tell if they used a C++ plugin, too, or not. But one could use a plugin with Unreal. Oh, what? You don’t like Unreal plugins? It’s a pain? Hey, you wanted to be a “C++ programmer” after all… No, please don’t mention the performance of ARK: Low FPS Evolved. But, on the bright side, it’s actually not C#'s fault (obviously).
My question about this C# on top of a C++ core is of mere principle* nature (I’m too intelligent for fangirlism). Unity devs can end up too often having to write their own code in C# to make up for the short comings of Unity. In general, this should be less the case with UE4. This means a C# layer on top of UE4 would be a tiny bit thinner than that of a Unity game.
It ain’t just principle though. It is also about trolling. Think of it. If it turned out that a C# on top of a C++ is an actual “professional” approach, and all the C++ fangirls are wrong. Then I could say things like this: Oh, look. It’s Epic Games. Those noobs, hackers, they don’t use C#! Trolololololo! The CryEngine (CE# Framework) does have C#. Even that god **** Unity thing does have C#! EPIC NOOBS! Trolololo! (It’s OK. I’m a PC gamer. This behavior kinda natural… :))
What it looks like to me is that you’re taking this thing waaaay to personally and seriously.
C# is just another language. There’s tons of them, really, no point in arguing this much.
Bottom line, if you want people to listen to you, you need to ask “I would love a proper scripting language implemented in unreal”.
That may gather more following than an argument about merits and demerits of c# (which I frankly don’t like as much as I don’t like C++).
Hell, I’d like to see python implemented! But turns out there’s no actual need.
Why?
That’s why. You already have not just one scripting language, but three current projects (more if you count older stuff), one of which is production proven and commercial grade (sookum).
And then there’s the blueprint system.
Fact is, if you use them as a scripting tool languages are just different in syntax (well mostly).
For every that is directly missing in one specific language there could be not just one but a lot of workarounds to get to the results you need.
And even if there’s no workaround there’s probably a different way to do what you want using a different approach that takes into account the used language.
What i don’t really understand is this fixation on C# when there’s a ton of languages out there that satisfy the same criteria.
Which is scripting. Anything system related should stick to the source language, so C++. Good luck if you use any other engine though, since you don’t have the source available.
And also, never forget that you need to have a permissive license to make a language work with unreal, otherwise it would only be supported by third parties. As Epic stated before, Xamarin charges for licenses and their respective eulas clash with one another.
So, can you tell me again, what’s the deal with your request?
Do you REALLY need C# or just a scripting language?
This is mission control to delete button, do you copy? This is mission control to delete button, do you copy? Houston, we lost contact to delete button. That’s what you get for sending it to MARS! **** it NASA. Don’t you know that there is a portal to hell on it?
Unless cryengine is an exposed scripting language in unreal you just showed you didn’t really read my post very well
The problem with this is just syntax. Provided that for your use case C# and C++11 in the UNREAL SDK are at parity level, the only real barrier are semantics and syntax, which seems to me you don’t want to learn.
Eight or fifty lines of code difference to code something is not strong enough of a point to expose another language at system level in a codebase as large as unreal’s.
There are so many bugs and gotchas already with the source available, another language on top of this would just create exponentially more bugs and slower releases.
Why not use C++ for system optimization and another scripting language i listed before to do gameplay stuff? Is it because C++ is difficult? Well, yes, but so is game programming in general, and like any other craft it takes time to learn well.
I’m not saying you don’t know how to, but selecting tools that are suitable to one’s knowledge at a given point in time should be a reasonable advice.
And that would mean to use a C# engine since you seem much more well versed in it instead of c++. After all, an engine is just a tool.
So i fail to see what is this all about, really. And i don’t particularly care about competitors, so please stop referring to cryengine just to prove your point. If you want to be heard you need to provide actual points of discussion that are relevant to unreal programming. Competitors and business strategies are not the point , and should not be discussed since Epic is a privately owned company. Unless you actually own stakes of the company.
CryEngine 5 not a “Game Editor”. Cities SKylines performance and C# modding
No… Crysis 3 is not made with the CryEngine V… bad joke…
However, it is never a good sign when I quote myself. So, the CryEngine V isn’t even an actual “Game Editor”. Yes, I had a look at it. It’s just a bunch of smaller editors slapped together into one huge, that has its own launcher just like Unreal with marketplace and assets. There is not even a content browser. It seems that CryTech is either not trying to make an actual “Game Editor”, or they don’t get the concept of this idea. Yeah, it is still in “beta”…
Long story, short. I don’t think CryEngine V is a competition to Unreal, so not an alternative for those who would like to use C#. Actually, if one wanted a “Game Editor”, it is not even a competition to Unity. You would be surprised what people can do with Unity who know enough about the engine.
Regarding the game Cities: Skylines that is based on the Unity engine. I found a file with the name ColossalNative.dll, in the plugins folder. Neither the internet nor the forum could tell me so far if that is an actual C++ plugin with game code, or just something generated like for getting rid of the JustInTime compiler to use AOT instead. It is 13MB large!
I ran a benchmark on this very demanding game (CPU wise). Rig was:
i5 6600
GTX 970 @ 1920x1080
8GB RAM
And with a population of 100K, which is very large. Though there are also cites with 300K already. The performance was this:
**VSync On @ 60Hz (1920x1080) Settings - Distance: Very Far
~ CPU 75% at normal game speed
~ GPU 50% (Fail…)
~ RAM 2.5 GB (C++ ?)
~ 30 FPS up close.
~ 40 FPS further away.
~ 45 FPS in the middle.
~ 37 FPS furthest distance.**
In Cities: Skylines there are tons of people and cars on the streets. AI/Path Finding stuff can get performance critical. So I guess the ColossalNative.dll ain’t just generated native code for AOT. Though there certainly still a layer of C# on top of the C++. The modding goes over C#. This game comes with a C# compiler.
Ok then,
having a list of objects composed by name (string) value (float), filter for the ones that contains “hello” in the name, filter again by value where %2=0, order them descending by name, sum the values of the first 5.
do it in C++ and let’s see how does it compare against linq.
And what would you compare? Raw speed is the only objective data , other things are too subjective?
Besides, what’s the point in this? I’m merely stating that you CAN use what’s available now. Or are you suggesting that this particular operation is NOT doable in c++?
I was thinking about the TITLE of the thread but ok, let’s compare it with raw speed. I choose assembler.
PRODUCTIVITY is the only objective data, paying 2 months of works or 1 month of works is not the same.
I’m saying that in C# is that trivial that anyone would write it as an answer,
but nobody would actually try to write it in C++ , cause you know that it will take forever.
Aha so you actually prove my point .
It’s a hassle, yes, so is learning C++ syntax and semantics. And I’m not writing a console program doing that because i’m lazy
It really is an hassle, but as someone suggested before in the thread, it’s just a one time hassle. If you need to do that, you just write helper functions one time and reuse. Obviously you can do it in C# too.
Problem is, Epic will not ever implement C#, and neither M$ nor Xamarin will probably do it too.
So you’re kind of stuck with C++. Yes it’s a real hassle (i’m not hiding , i hate c++ as much as i hate c#) but it’s a doable hassle if you account for everything you can find in Unreal that actually lets you code less.
IF you just need code speed, well Unity lets you have it your way and the new updates are quite good even in the gfx department (which i use unreal for).
No it is a called linq, and insisting on calling it “syntax and semantics” just shows how much you shouldn’t even be in this post in the first place, cause you have no idea on what you are talking about.
Good, tell me when you finished rewriting the entire .net framework.
It’s not, it’s EXPENSIVE.
I get payed for every hour of my work, if it takes twice to do the same thing, I do cost twice.
EXACTLY, it takes an effort for you to write that code, you even need the console program cause of course is not simple enough to do it in pseudocode in C++.
Now, writing that piece of code in C# with linq require the same exact effort than writing this answer, actually even less cause I would have intellisense.
Easy man, no need being childish. You don’t even know who is who, calling names is not going to prove you right. And in any case, my voice counts as much as yours or anyone’s .
Just a quick search. Again, it will probably be a hassle to merge into your project, but there are solutions. Which you wouldn’t probably consider anyway since they are C++.
Again, semantics and syntax. Strings are array of chars in C. Crazy if you ask me, but this didn’t stop countless programmers doing string operations.
Asserting that you CANNOT do something in C++ because of a lack of modern features is kind of crazy if you ask me.
Do you actually need the whole framework?
Very true. Though I fail to see why your particular working condition should either apply for everyone or should be considered as a problem by Epic.
Problem is, you are requesting something to Epic. And you need to be realistic in what you ask for. C# is not realistic in Epic’s perspective, and they already made it clear. Not just once if I may add.
Choose one. and please do not just google “solution 1”, choose from all those links one and I will tell you why is nonsense.
btw, do even one of those links would currently works in ue4? -.- what’s your point? showing me that there are even C++ features that could be added? I already knew that thanks, that’s part of my point.
Then do it in assembler, after all it’s just a different syntax, and asserting that you CANNOT do something in assembler because of a lack of modern features is kind of crazy if you ask me.
Cause it does apply to every programmer and we are Epic customers?
good, so nothing involving you right? after all you don’t know nothing about C# and you are not Epic, so why did you choose this thread instead of another one?
Do anyone even read the first post of threads anymore???
So no problem then. And most probably yes, if it works in C++ it could (theoretically) be made to work in UE4. How much hassle it would be, well, that i don’t know. Maybe some other person will chime in.
You see, I’m not really pro C++. From my standpoint it’s an effin nightmare. but that’s what we got now.
No way I’m gonna do it again uahahahaha I coded in it so many years ago on a pentium 1 on turbopascal for a high school assignment and i spent like 1 month just doing a **** blit for an isometric engine. No way in hell i’m gonna do it. I still have nightmares.
It applies to every programmer who is not well versed in C++.
Which I am too (actually i don’t really know how to do stuff from scratch, i just code plugins for compositing applications using C++), so we are on the same side in this.
But some programmers I worked with on Unreal projects pumped off C++ code like there was no tomorrow, and they didn’t really have any productivity problems (Are you reading this Daniele? :)).
Also, until you actually start paying royalties you’re just using their engine: you’re not an actual customer, just a potential one.
2 reasons:
1- Because I hate when people ask forcefully things without considering others or the bigger picture. It’s just me.
2- Because I’d rather have Epic fix rendering, stability and usability issues than to add another layer of complexity on top.
I so much want dynamic GI. Waiting ages for a production lightmass bake is killing my productivity a lot. I personally use unreal as a rendering engine. It’s not just bake, it’s iterate and iterate and iterate again. Hours thrown to the wind. So i use VXGI. Which is a completely broken thing, not very usable, it overdarkens and so on.
Do you see me spamming in every thread for dynamic GI support? nope. I just wrote a thread once. Then I read what wrote. It’s shelved. Bummer. I still have to do stuff. I do stuff less productively if I have time, if not I stick to my older offline guns. This means not using unreal if i’m in production, only for lookdev. Which is halving my POTENTIAL productivity, but it’s not in my hands anymore.
Yes. And extending without rewriting is still A LOT of work, which i’d love Epic to put into other things. Like not having the editor crashing. Or features working consistently from version to version (see the skylight broken thread).
Again, even if I’m not actually programming a lot in unreal, my voice counts as much as yours, since we both use the engine in a way or another.
What i’m writing now would be very different if Epic would just open to C# in some statement (heck, i would be VERY happy to have an alternative to c++), but they already said no.
It would be easier if some dev would comment on this before the flames spread, but they cannot do it each and every time, and it’s also reasonable to think that people should remember what has been said already before writing.
Why not?
“semantics and syntax. Asserting that you CANNOT do something in Assembler because of a lack of modern features is kind of crazy if you ask me.”
Then have them join this conversation, give them the algoritm that I told you before and ask them how long does it takes to be written in C++, then choose another random person from another forum in C# and ask the same.
Again, what’s the point for you in joining in this conversation? you don’t know C# and you are not “well versed” in C++.
First of all, even if a product is free I would still be a customer, that doesn’t change the definition of customer.
I get payed to work, and I work for people that eventually will pays royalties.
You DON’T have any picture, you don’t have any part in this, you are not epic, this is not your picture, you don’t know C#, and barely know C++.
So are you gonna spam in every single thread that is not related to fixing/stability/usability requests on this forum?
THEN MAKE ANOTHER THREAD!!!
Read the TITLE, it isn’t “[feedback request] dynamic GI” if you want something else, YOU ARE NOT IN THE RIGHT PLACE.
Do you see spamming about C# in your dynamic GI thread? nope. But according to you, I should.
it would be even better if no one flames, what about that anyone can’t talk about something they don’t know nothing of?
I’m not even gonna quote your stuff since it’s too much work to just ease a child, and you seem to love patially quoting just to display incorrect info to prove your point.
No i don’t know C#. never said i did. I read a lot of code snippets around, and I don’t like the syntax, but if need arises (namely a new api on my dcc apps) I’ll learn as much as i need to get the work done.
Yes i do know C++, even if i’m not that good at it: afterall it’s not my primary job. Yes I also knew a bit of assembly (like 18 years ago), and frankly you cannot compare it to C++ like we were doing with C#. C’mon.
What I know a lot of is, python, javascript, mel, and any scripting api for any program I use. Even if it’s just scripting, it’s programming nonetheless.
But most of all, why the flying **** are you angry about? I said a number of times that i’m not a fan of C++, and even if i don’t like C# syntax it’s not really worth the hate. So what’s going on between your ears?
What i’m saying to you NOW is that Epic will not do Mono in the foreseeable future. THEY SAID IT.
I’m just reminding you since in between your smug comments you failed to remember it, and because since I started reading this thread (which was interesting before you heated things up) you were the only one to be rude while the others (OP included, well mostly :)) were trying to get on and actually talk.
If you read my first comment you’ll see it was just a joke.
I shouldn’t have answered you the first time, it’s just feeding trolls. My bad.
