Unreal Engine has more resources behind it's development so it is better suited for different environments since it doesn't put as many layers between the engine and the hardware. Not to mention they could afford to pay nVidia/ATI to make their drivers work better with that engine.

As for the engine not communicating directly to the hardware and being developed for a specific OS, you are correct, I was talking in the concept of optimization. The more specific it is, the better the optimization. Always taking into account that you have capable devs, of course... It is not just the tool, but what you do with it. Still, the principal applies: Unity puts a middle-man between the engine and the api. You simply cannot expect the same code to work on x86, x86-64, ARM (including recent Apple variants), and on top of that have a completely different environment (OS) with different drivers, memory management, space allocation, etc..., and expect it to be optimized... except with lots of resources from Fortnite I guess.

Unreal Engine is not AS optimized as it seems, though it is better than Unity, that's for sure.

For one thing, it's missing basic functionality that's still not solved.
Like choosing a different resolution than standard desktop or monitor native.

https://forum.unity.com/threads/playerprefs-for-screen-resolution-ignored-in-windows-builds.11749/

In some Unity games this can be solved by either editing the registry or adding -window-mode exclusive command line argument. But this will not always work and if it does sometimes it will reset every time you start the game.

As for gpu load, yeah Unity can be taxing but more often than not Unreal engine games are way worse in my experience.
Unless like the above mentioned issue where it ignores the player prefered resolution (in my case 1080p) and outputs monitor native (4k) which will fry your pc for sure.

VSync doesn't solve the problem that he's been talking about. I always have VSync on, and it does nothing at all to stop Unity games from from making my GPU's fans sound like a vacuum cleaner.

It's not possible to have a frame rate higher than the display's refresh rate when enabled. So either vsync is not actually enabled or your GPU has problems. Fans running is not really a problem.

Hello Ancient-Red-Dragon!

Indeed, my experience with Unity-based games is that the developers rarely implement a functioning frame limiter, and that VSync neither ingame (where available) nor driver-forced works properly!

Hence, I have to resort to take advantage of external frame limiting programs--currently, I am using Dxtory (a capture program) in the background to limit the frames in Unity-Engine games. (Unfortunately, the free trial version automatically tries to open their site in my standard browser upon closing the application. For me not an issue, because I am basically playing offline anyway.)

Really annoying is, that some games will not even start/launch when the frames are externally hard-limited.
In such cases, I have to launch the game first, often have to start or load the actual gameplay/save (main menu is not sufficient), then using ALT+TAB to return to my desktop in order to now launch the frame limiting program in the background.

Four particular offenders for my system are "Haven Park" (whose very few graphics settings seem to have barely any impact, and which refuse to start with less than 60 fps), "Anodyne 2: Return to Dust" (where the initial loadup of the 3D world outside of the main menu is somehow crashing when the frames are limitted externally already), "Race the Sun" (with its super simple geometry and only shaded textures), and "Terra Lander" (the first one, which uses very basic vector graphics, but heats up my system the most)!

Another game, the modern submarine simulation "Cold Waters", got significantly less demanding on my machine when I started to apply a small modification, reducing the visibility in the water (now looking more similar to the underwater feel of the Silent Hunter series (e.g. Silent Hunter II & III).

Kind regards,
foxgog

Cause people lacking LOGIC & REASONING stay away from C#, C++ like a Vampire off Garlic.
Java & Unity are failures in 4GLs for single platform game programming.

While I critize and question when I see inconsistencies, I will also give praise and have good heart to companies that do well when they do.

I've got the opportunity to play the game GRIME (Albeit not the GOG version of it, but the Amazon Games version which was given away) and as far as I noticed, the game is made in Unity.

It is amazingly optmized with a ton of graphic settings options for customization. (Even screen shake amount, a necessity for games like this I'd say.)

So, congratulations to the devs of Clover Bite studio for such a well optmized game.
And to Akupara Games for publishing it.

The problem of 4th & 5th GL platforms is they try to do everything for everyone and they suck at all.
Go back to separating PCs from Heatboxes from Handheld Atoms & Android "Devices".
A PC is a monster performer, like Godzilla vs. Grizzly Bear. NOT A "DEVICE".

From what I understand, Java and C# are similar languages, and therefore I would expect them to have comparable performance to each other. Also worth noting that Unity uses C#.

For comparison, C++ is a lower level language, and therefore code written in it will run faster and more deterministically. (In particular, you don't get random garbage collections happening, potentially at bad times, in C++.) C and Rust are comparable languages in this regard. (Still higher level than assembly language.)

On the other hand, Python is slow, so a game written entirely in Python may have poor performance. Fortunately, it's quite possible to take a program written in Python and re-write performance critical parts of the program in a lower level language like C. GDScript (Godot's scripting language) and JavaScript are similar high-level langauges (though note that a lot of work has gone into optimizing JavaScript interpreters simply because of the amount of JavaScript code on the web).
This reminds me of what I have heard about Electron. Generally, Electron apps have a reputation for being slow and poorly optimized, but one particular popular Electron app, Visual Studio Code, is apparently actually well optimized.

(By the way, games can be made in Electron. While I don't have any examples off the top of my head, I note that CrossCode apparently uses something similar.)

Not really. They have a very similar structure and syntax, but the one is basically a interface for DotNet, the other one one runs on a virtual machine written in C++. It's two very different approaches - technology wise.

Yes, native C and C++ code will always run faster than both of them, that much is true.

Script languages like Python or JavaScript or TypeScript are out of competition of course. Their purpose is not 3D rendering or UIs in general. While it is possible to create a UI with Python, it's absolutely not performant in any way. These script languages are just not designed for that and their speed also relies on the engine that runs them. For example JavaScript can be run in many engines, two of them being Nashorn and GraalVM.

Many games use a mix of different languages. A fast core engine written in C++, then a scripting language for simple tasks like moving platforms or cut scenes in general. There is no gain in hard coding these.
In the past games had their own scripting languages (starting with Scumm up to games like Jedi Knight), now most often standard languages are used.

Java can do 3D ok, but not great (The performance of Minecraft was ok, or was it?). There are several 3D engines for Java, which in background run natively, Java relies on Standard interfaces. No one sane would ever try to write a hardware driver in Java, since that driver would require to run the JVM and that's just stupid. The question is not if Java is faster or not does not even come up.

Unity is not written in C#. It's written in C/C++, like all other engines. But it offers a DotNet API to access it's functions, which can be accessed through C# for example. Direct C access should work just as well.

My understanding is that .net is a VM similar to the JVM.

What do you think the difference is? Just like Java, .NET also runs a virtual machine, with JIT.

https://en.wikipedia.org/wiki/Common_Language_Runtime

After your posts I had to look up something and turns out I had the wrong impression about how DotNet works. I always had in mind that there's another layer under it to start with.

Thank you all for the insights too.

I remember starting to go through Unity development, or at least the tutorials. Something that stood out to me, is they have different filters and visual effects that are tablet/phone and others that are for the computer. It wouldn't be a surprise that an overtly bad number of visual filters and effects that require a lot of complex computational work are left in the 'game' assuming everyone is running on the best hardware, rather than going with the much lighter and simpler options and only turning a handful on when really needed.

One of the things it also went into, was bounds and collision checking. A complex visual model by default is the same model used for bounds checking, but you really want 2 models, a very simplified check (and is suggested to even just use a pill shape).

But these are just the immediate ones that come to mind, without reading every single post in this thread so far.

I played Oni and the blind forest, good game, and it uses Unity. But it made my graphics card hum with how much the video processor was heating up, and i'd wished i could turn off a bunch of background graphical effects that were literally the background and had zero effect on the events in the game. So another problem is that the devs aren't putting the graphical options needed to turn off the high-end needed effects. Maybe it's too much effort, i don't know.