Author Topic: Epic Releases Free Version of Unreal Engine  (Read 9450 times)

0 Members and 1 Guest are viewing this topic.

Offline Ghostavo

  • 210
  • Let it be glue!
    • Skype
    • Steam
    • Twitter
Re: Epic Releases Free Version of Unreal Engine
Are you seriously telling me that using say... a 512x512 texture is the same thing speed wise as using a 64x64 one?
"Closing the Box" - a campaign in the making :nervous:

Shrike is a dirty dirty admin, he's the destroyer of souls... oh god, let it be glue...

 

Offline Flipside

  • əp!sd!l£
  • 212
Re: Epic Releases Free Version of Unreal Engine
From a hardware point of view, it's the speed of the pipeline that counts as much as the size of the texture, in fact, using a 64x64 texture can waste processor time on some of the newer cards, because the data is transmitted in blocks, and a smaller texture can introduce redundancies into the data.
« Last Edit: November 08, 2009, 03:50:28 am by Flipside »

 

Offline Ghostavo

  • 210
  • Let it be glue!
    • Skype
    • Steam
    • Twitter
Re: Epic Releases Free Version of Unreal Engine
Those newer cards are fast enough to make the point of engine speed pointless. And besides, if you are using the same textures (a 64x64 and a 512x512) to cover the same area, the 64x64 is going to be faster.

Anyway, if I was making a game with decent graphics, I'd much rather using an engine that was made to render stuff like this instead of one that's usually used to render stuff like this.
« Last Edit: November 08, 2009, 04:15:02 am by Ghostavo »
"Closing the Box" - a campaign in the making :nervous:

Shrike is a dirty dirty admin, he's the destroyer of souls... oh god, let it be glue...

 

Offline Flipside

  • əp!sd!l£
  • 212
Re: Epic Releases Free Version of Unreal Engine
Just because the demo of an Engine doesn't have commercial quality graphics, it does not neccessarily follow that the engine is incapable of handling that level, put those textures into the unreal engine, and you'd get pretty much the same results, only with too much specular.

As for the card itself, from what I understand, the data has to be processed outside the card and transmitted to it in a specific format, usually in 2 Meg chunks (iirc). The difference in time between rendering a 512 texture and a 64 texture is more or less immaterial, whereas the time required to transmit the two textures to the card itself is exactly the same. You might be able to transmit more textures in the 2 Meg chunk if using 64 x 64 but I'm pretty sure there are added complications to that as well.

The thing is, most Graphics cards are optimised for larger textures (256, 512 and 1024) and tend to work best using those sized textures, but it's just possible that the people using Irrlicht are programmers first and can't afford Epic's art department.
« Last Edit: November 08, 2009, 04:48:13 am by Flipside »

 

Offline Ghostavo

  • 210
  • Let it be glue!
    • Skype
    • Steam
    • Twitter
Re: Epic Releases Free Version of Unreal Engine
Just because the demo of an Engine doesn't have commercial quality graphics, it does not neccessarily follow that the engine is incapable of handling that level, put those textures into the unreal engine, and you'd get pretty much the same results, only with too much specular.

(...)but it's just possible that the people using Irrlicht are programmers first and can't afford Epic's art department.

I'm not saying it does, but when someone starts saying engine X is more awesome than engine Y while engine X hasn't been used to the extent engine Y has, it irks me somewhat.


Quote
As for the card itself, from what I understand, the data has to be processed outside the card and transmitted to it in a specific format, usually in 2 Meg chunks (iirc). The difference in time between rendering a 512 texture and a 64 texture is more or less immaterial, whereas the time required to transmit the two textures to the card itself is exactly the same. You might be able to transmit more textures in the 2 Meg chunk if using 64 x 64 but I'm pretty sure there are added complications to that as well.

The thing is, most Graphics cards are optimised for larger textures (256, 512 and 1024) and tend to work best using those sized textures.

It depends on a great deal of many things. The TMUs, the bus, etc...
"Closing the Box" - a campaign in the making :nervous:

Shrike is a dirty dirty admin, he's the destroyer of souls... oh god, let it be glue...

 

Offline blackhole

  • Still not over the rainbow
  • 29
  • Destiny can suck it
    • Black Sphere Studios
Re: Epic Releases Free Version of Unreal Engine
Quote
Those newer cards are fast enough to make the point of engine speed pointless. And besides, if you are using the same textures (a 64x64 and a 512x512) to cover the same area, the 64x64 is going to be faster.

Wrong, wrong, wrongwrongwrongwrongwrongwrong WRONG.

First off, this mindset of "oh computers are so fast we don't have to worry about optimizing our code anymore!" is going to go down in flames once people realize how much power is being wasted on idiotic programming and wasteful resource use. This is best explained with an example that I found in my own efforts to optimize my engine: a month ago, my engine could render 10000 batch rendered images on my desktop at about 40 FPS. A short while later, I realized that I could massively optimize my rendering pipeline using a red-black linked list binary tree, as opposed to a sorted list. After a few other optimizations, the end result was that it can now render 10000 batch rendered images at 80 FPS.

By increasing the speed and efficiency of my engine, I doubled the speed of my rendering. Are you still telling me that engine speed is pointless?

Furthermore, smaller textures do not equate faster drawing. Almost the only thing that matters is how many pixels you are drawing to. If you have a 64x64 writing to the entire screen instead of a 256x256 writing to the entire screen, you have the same number of texture lookups going through a filtering process, which means your only benefit is memory: the lookups will be slightly faster for 64x64 because there's less memory to worry about.

This also,means that Flipside is somewhat mistaken: Large texture sizes are extremely dangerous. Case in point: If you put a 1024x1024 on my laptop, performance drops a significant amount. If you try putting a 2048x2048, it suffers catastrophic performance loss. Anything larger and it can't support it. However, render a 1024x1024 as 4 512x512 chunks, and you'll get a 20-30% performance increase. This same effect can be observed on my desktop, with its newer graphics card, at double that resolution - put in a 4096x4096 and it will start to suffocate. Do the same thing with 1024x1024 chunks and you'll get massive performance increases (in this case the textures have to be scaled back in size so they are all still rendering, otherwise the performance increase is due to culling. Note that the comparison here is between a 25% size 2048x2048 with 25% sized 1024x1024 chunks).

Quote
I'm not saying it does, but when someone starts saying engine X is more awesome than engine Y while engine X hasn't been used to the extent engine Y has, it irks me somewhat.

Windows is used everywhere. Do you think windows is awesome? Linux is only used by 2% of the computer population. That must mean it sucks, right? I don't think i need to really keep going here to point out the glaring flaw in your argument. Take Flash -  Flash is a horrible monstrosity of bloated crapware that is so prevalent across the web because its only competitor is Microsoft's pathetic "silverlight" initiative.  If you don't believe me that flash is crap, it takes the same amount of resources to run unoptimized flash games as it does to run Crysis. If you still don't believe me, flash once managed to crash my friend's computer and corrupt its own update file so that the system BSOD's every time he logged in. He had to go into safe mode and uninstall all adobe-related software just to get the thing functional again. This is the same program that is used on 99% of the websites across the web. Are you still, honest to god, telling me that just because X is used more then Y that Y can't be better then X?

Irrlicht's engine core is the best core I've ever seen. Just because its not focused on making everything pretty for the general public idiots doesn't mean its a piece of crap, it just means it has a different focus - speed. I'm sorry, but not everyone on the planet wants to buy a gaming rig that's the same price as a used car when modern graphics shouldn't be so goddamn bloated in the first place.
« Last Edit: November 08, 2009, 05:35:21 pm by blackhole »

 

Offline headdie

  • i don't use punctuation lol
  • 212
  • Lawful Neutral with a Chaotic outook
    • Minecraft
    • Skype
    • Twitter
    • Headdie on Deviant Art
Re: Epic Releases Free Version of Unreal Engine
I have PC experience dating back to DOS 5 on intel 286 and things haven't changed you always need to run things in as close to optimum way as possible in terms of processor and memory because at the end of the day the potential for software always exceeds hardware capability, also remember in terms of implementation in FSO is that not everyone is running up-to-date kit, for example my machine is a 5-6 year old first gen Athlon 64 on the first mobo to use the nf 3 chipset, 1GB memory and GF 6600 GT, so a performance intensive graphics overlay on some of the inefficiency in FS (eg collision detection) would probably make the game close unplayable
Minister of Interstellar Affairs Sol Union - Retired
quote General Battuta - "FRED is canon!"
Contact me at [email protected]
My Release Thread, Old Release Thread, Celestial Objects Thread, My rubbish attempts at art

 
Re: Epic Releases Free Version of Unreal Engine
There is also other factors included, like bsp spaces and culling that would probably make the unreal engine better than the open source (not that they couldn't they probably don't have the manpower).
That's cool and ....disturbing at the same time o_o  - Vasudan Admiral

"Don't play games with me. You just killed someone I like, that is not a safe place to stand. I'm the Doctor. And you're in the biggest library in the universe. Look me up."

"Quick everyone out of the universe now!"

 

Offline blackhole

  • Still not over the rainbow
  • 29
  • Destiny can suck it
    • Black Sphere Studios
Re: Epic Releases Free Version of Unreal Engine
There is also other factors included, like bsp spaces and culling that would probably make the unreal engine better than the open source (not that they couldn't they probably don't have the manpower).

Yes, but the point here was, which engine would you want to use to implement postprocessing in FS2? Having 1500 dependencies on other engine components isn't going to be much of a help. People look at Unreal and they're like OH YEAH LETS REVERSE ENGINEER THAT SO WE CAN HAVE PRETTY GRAPHICS TOO! The entire point here is that it's a misconception - there are better resources to implement this stuff in that will tell you what you actually need to do without being dependent on a gigantic huge engine library. Looking to a big fat bloated engine to implement features is always a bad idea, regardless of which engine or what features.

 

Offline chief1983

  • Still lacks a custom title
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: Epic Releases Free Version of Unreal Engine
I don't think he meant the prevalence of engine X vs engine Y, I think he meant the extent to which its boundaries have been pushed.  Other than that, good arguments Blackhole.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 
Re: Epic Releases Free Version of Unreal Engine
There is also other factors included, like bsp spaces and culling that would probably make the unreal engine better than the open source (not that they couldn't they probably don't have the manpower).

Yes, but the point here was, which engine would you want to use to implement postprocessing in FS2? Having 1500 dependencies on other engine components isn't going to be much of a help. People look at Unreal and they're like OH YEAH LETS REVERSE ENGINEER THAT SO WE CAN HAVE PRETTY GRAPHICS TOO! The entire point here is that it's a misconception - there are better resources to implement this stuff in that will tell you what you actually need to do without being dependent on a gigantic huge engine library. Looking to a big fat bloated engine to implement features is always a bad idea, regardless of which engine or what features.

FS2 wouldn't be a good use for the unreal engine, and the fs2 engine wouldn't be a good first person engine.
That's cool and ....disturbing at the same time o_o  - Vasudan Admiral

"Don't play games with me. You just killed someone I like, that is not a safe place to stand. I'm the Doctor. And you're in the biggest library in the universe. Look me up."

"Quick everyone out of the universe now!"

 

Offline esarai

  • 29
  • Steathy boi
    • Minecraft
Re: Epic Releases Free Version of Unreal Engine
My school's computer club is going to flip when they find out about this.
<Nuclear>   truth: the good samaritan actually checked for proof of citizenship and health insurance
<Axem>   did anyone catch jesus' birth certificate?
<Nuclear>   and jesus didnt actually give the 5000 their fish...he gave it to the romans and let it trickle down
<Axem>and he was totally pro tax breaks
<Axem>he threw out all those tax collectors at the temple
<Nuclear>   he drove a V8 camel too
<Nuclear>   with a sword rack for his fully-automatic daggers

Esarai: hey gaiz, what's a good improvised, final attack for a ship fighting to buy others time to escape to use?
RangerKarl|AtWork: stick your penis in the warp core
DarthGeek: no don't do that
amki: don't EVER do that

 

Offline Stormkeeper

  • Interviewer Extraordinaire
  • 211
  • Boomz!
Re: Epic Releases Free Version of Unreal Engine
I've gotta go with Blackhole. I can generally tell if the game is running on the Unreal engine the moment I get into gameplay. The graphics have an ... I dunno, an "Unreal" aura.

And he's also right. Smaller textures don't mean faster load times, and optimization will always be necessary. Sure you could run that program just fine on current PCs, no matter how crapsack its programming is. But optimize it, and it'll positively fly.
Ancient-Shivan War|Interview Board

Member of the Scooby Doo Fanclub. And we're not talking a cartoon dog here people!!

 

Offline asyikarea51

  • 210
  • -__-||
Re: Epic Releases Free Version of Unreal Engine
I can generally tell if the game is running on the Unreal engine the moment I get into gameplay. The graphics have an ... I dunno, an "Unreal" aura.

I guess I know I'm not alone now.

Though I'm not always correct in guessing if game X or game Y uses UE3... XD
Inferno plz
The Power of Nightmares
TheHound: "Nice idea, but I have a thing against announcing campaigns before having them already finished."
G5K: "The flipside of that is that if you don't announce your campaign, yet take too long to finish it, other people may independently come up with some of the same ideas."

 

Offline Ghostavo

  • 210
  • Let it be glue!
    • Skype
    • Steam
    • Twitter
Re: Epic Releases Free Version of Unreal Engine
Quote
Those newer cards are fast enough to make the point of engine speed pointless. And besides, if you are using the same textures (a 64x64 and a 512x512) to cover the same area, the 64x64 is going to be faster.

Wrong, wrong, wrongwrongwrongwrongwrongwrong WRONG.

First off, this mindset of "oh computers are so fast we don't have to worry about optimizing our code anymore!" is going to go down in flames once people realize how much power is being wasted on idiotic programming and wasteful resource use. This is best explained with an example that I found in my own efforts to optimize my engine: a month ago, my engine could render 10000 batch rendered images on my desktop at about 40 FPS. A short while later, I realized that I could massively optimize my rendering pipeline using a red-black linked list binary tree, as opposed to a sorted list. After a few other optimizations, the end result was that it can now render 10000 batch rendered images at 80 FPS.

Great, start programming in assembly then. Cause you know, there are a lot of cycles being wasted by compilers. C, C++, JAVA, Python, etc... all these? Wasting cycles by virtue of compilers not being perfect.

Quote
By increasing the speed and efficiency of my engine, I doubled the speed of my rendering. Are you still telling me that engine speed is pointless?

You are taking what I said and applying in a way I didn't mean to. When you have a newer card capable of rendering what the engine tells it at a ludicrous number of FPS, let's say for discussion sake's 300FPS minimum, while another engine only achieves a paultry 250 FPS also minimum. Does engine speed matter any more? Especially seing more screens nowadays can't output more than 60 Hz at their native resolution? When the human eye can't process information beyond 30 FPS? Does it really matter?

Quote
Furthermore, smaller textures do not equate faster drawing. Almost the only thing that matters is how many pixels you are drawing to. If you have a 64x64 writing to the entire screen instead of a 256x256 writing to the entire screen, you have the same number of texture lookups going through a filtering process, which means your only benefit is memory: the lookups will be slightly faster for 64x64 because there's less memory to worry about.

This also,means that Flipside is somewhat mistaken: Large texture sizes are extremely dangerous. Case in point: If you put a 1024x1024 on my laptop, performance drops a significant amount. If you try putting a 2048x2048, it suffers catastrophic performance loss. Anything larger and it can't support it. However, render a 1024x1024 as 4 512x512 chunks, and you'll get a 20-30% performance increase. This same effect can be observed on my desktop, with its newer graphics card, at double that resolution - put in a 4096x4096 and it will start to suffocate. Do the same thing with 1024x1024 chunks and you'll get massive performance increases (in this case the textures have to be scaled back in size so they are all still rendering, otherwise the performance increase is due to culling. Note that the comparison here is between a 25% size 2048x2048 with 25% sized 1024x1024 chunks).

I'm sure it doesn't automatically equate to faster drawing with a few oddball cases out there, but from the gist of things, you seem to agree with me. You only provided cases where the smaller resolutions are faster than larger resolutions.

Quote
Quote
I'm not saying it does, but when someone starts saying engine X is more awesome than engine Y while engine X hasn't been used to the extent engine Y has, it irks me somewhat.

Windows is used everywhere. Do you think windows is awesome? Linux is only used by 2% of the computer population. That must mean it sucks, right? I don't think i need to really keep going here to point out the glaring flaw in your argument. Take Flash -  Flash is a horrible monstrosity of bloated crapware that is so prevalent across the web because its only competitor is Microsoft's pathetic "silverlight" initiative.  If you don't believe me that flash is crap, it takes the same amount of resources to run unoptimized flash games as it does to run Crysis. If you still don't believe me, flash once managed to crash my friend's computer and corrupt its own update file so that the system BSOD's every time he logged in. He had to go into safe mode and uninstall all adobe-related software just to get the thing functional again. This is the same program that is used on 99% of the websites across the web. Are you still, honest to god, telling me that just because X is used more then Y that Y can't be better then X?

Used to the extent != popularity

Used to the extent == taking the engine further to the limit of what it can do.

Quote
Irrlicht's engine core is the best core I've ever seen. Just because its not focused on making everything pretty for the general public idiots doesn't mean its a piece of crap, it just means it has a different focus - speed. I'm sorry, but not everyone on the planet wants to buy a gaming rig that's the same price as a used car when modern graphics shouldn't be so goddamn bloated in the first place.

Maybe if Irrlicht had ways to make it easy to do the things the Unreal engine does easily or automatically, it would have more users. And until you use textures and models on par with the ones the Unreal engine uses, I'm not sure if you can make the assumption it would be faster. Hence my previous "used to the extent" remark. :P

Like the point I made in the beginning, why doesn't anyone but driver programmers and other lowlevel programmers use assembly anymore, despite enabling to waste less cycles?  :P
"Closing the Box" - a campaign in the making :nervous:

Shrike is a dirty dirty admin, he's the destroyer of souls... oh god, let it be glue...

 

Offline Unknown Target

  • Get off my lawn!
  • 212
  • Push.Pull?
Re: Epic Releases Free Version of Unreal Engine
It doesn't matter anyway because if anyone here has actually read the article and license terms, it says that the source is not released with this.

You can, however, make commercial games with it. Epic gets 25% on any profit over $5,000 though.

 

Offline chief1983

  • Still lacks a custom title
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: Epic Releases Free Version of Unreal Engine
Ghostavo, yes engine speed still matters.  You may not notice in the case you described, but when you actually start pushing the limits of the engine one will obviously choke before the other.  Or what if you decide to use the engine to prerender frames?  The faster engine will complete the task faster, significantly faster even.  If you can optimize something with a little effort, it's probably worth it in the long run.  But that's not saying that you should make design decisions that make it harder to maintain for the sake of efficiency, although in some cases that is still necessary (real-time programming for example).
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline Ghostavo

  • 210
  • Let it be glue!
    • Skype
    • Steam
    • Twitter
Re: Epic Releases Free Version of Unreal Engine
What about when the decisions you make start lowering the effective ease of using an engine? Speed only matters if you can use it effectively. If the engine is too difficult to use with "modern graphic settings" (take that as you will) it's not a good engine to use in those cases.
"Closing the Box" - a campaign in the making :nervous:

Shrike is a dirty dirty admin, he's the destroyer of souls... oh god, let it be glue...

 

Offline chief1983

  • Still lacks a custom title
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: Epic Releases Free Version of Unreal Engine
Nobody's saying that either.  Modern computing virtually necessitates some speed sacrifices to be made for ease of use, security, and maintainability of code.  That doesn't excuse sloppy programming or wasting cycles 'because you can'.  Suppose we end up with a model of computing-as-a-service, where you pay for usage of a cloud.  Now let's say you pay for how much load you incur on a cluster.  Obviously the cluster has the power to run any number of engines, but the most efficient one would be the one that costs you the least.  Or when software designed for a certain environment needs to be ported to run on a much weaker infrastructure (say, running JS on a handheld device).  Or, to stay on the Javascript example, look at how much more prevalent Javascript is.  The pure speed of the Javascript engine is now becoming a factor in what browser many people are using nowadays (Apple Webkit/Chrome is kicking everyone's ass btw).  The functionality of JS is the same across browsers, yet IE's engine sucks, Mozilla's is ok and Webkit puts them all to shame.  Because they made an engine that can run it the fastest.  If more energy had been put into a fast JS engine by the Firefox team earlier on they wouldn't be as far behind already as they are now.  And Microsoft should just give up, their current engine probably needs a complete rewrite to stand a chance.  Yet they're all the same ease of use because they're all a standard implementation.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline blackhole

  • Still not over the rainbow
  • 29
  • Destiny can suck it
    • Black Sphere Studios
Re: Epic Releases Free Version of Unreal Engine
Quote from: Ghostave
Great, start programming in assembly then. Cause you know, there are a lot of cycles being wasted by compilers. C, C++, JAVA, Python, etc... all these? Wasting cycles by virtue of compilers not being perfect.

I actually do program my pixel shaders in assembly. The point I'm making here, however, is not that we need to rescue every last cycle that's being wasted by compilers, but to fix the idiotic programming mistakes that waste hundreds of thousands of cycles. The number of wasted cycles caused by imperfect compilers is several orders of magnitude smaller then the wasted cycles caused by stupid and/or lazy programming. THAT'S what I'm getting at here.

Quote from: Ghostave
You are taking what I said and applying in a way I didn't mean to. When you have a newer card capable of rendering what the engine tells it at a ludicrous number of FPS, let's say for discussion sake's 300FPS minimum, while another engine only achieves a paultry 250 FPS also minimum. Does engine speed matter any more? Especially seing more screens nowadays can't output more than 60 Hz at their native resolution? When the human eye can't process information beyond 30 FPS? Does it really matter?

If that's true, you have no argument. No one here is arguing that a 10 year old game will not benefit from code optimizations on modern hardware. That's kind of a "No Duh" kind of thing. The only place that code optimization ever does become relevent is in cutting-edge software or software that takes up a significant amount of system resources. If your game is being rendered at 250 FPS, not only is it not taking up a significant amount of system resources, its actually wasting them, because you don't need to render above 60 FPS, and so you should be giving back the extra CPU cycles you don't need to the system instead of hogging them. For the sake of the rest of this post I will assume we are talking about modern games instead of pac-man.

Quote from: Ghostavo
I'm sure it doesn't automatically equate to faster drawing with a few oddball cases out there, but from the gist of things, you seem to agree with me. You only provided cases where the smaller resolutions are faster than larger resolutions.

Oh I am agreeing with you. Smaller textures do allow for faster rendering... just not by much.

Quote from: Ghostavo
Maybe if Irrlicht had ways to make it easy to do the things the Unreal engine does easily or automatically, it would have more users. And until you use textures and models on par with the ones the Unreal engine uses, I'm not sure if you can make the assumption it would be faster. Hence my previous "used to the extent" remark.

I can't make any argument against this without hard data, and I really don't have time to set up benchmarks just to prove a point, so I'll just leave this one for another day.

Quote
Like the point I made in the beginning, why doesn't anyone but driver programmers and other lowlevel programmers use assembly anymore, despite enabling to waste less cycles?

And like the point I made in the beginning, its not a matter of wasting a few CPU cycles, its a matter of inherently bad and lazy programming that wastes millions of cycles and hundreds of megabytes of memory. As I mentioned before, doing a small optimization like switching from a linked list to an optimized binary tree (which no one even has to code themselves) can result in massive performance increases.

What about when the decisions you make start lowering the effective ease of using an engine? Speed only matters if you can use it effectively. If the engine is too difficult to use with "modern graphic settings" (take that as you will) it's not a good engine to use in those cases.

96% of the time, it is possible to optimize an engine in such a way that its ease of use is not affected. Furthermore, I have a counterexample: My graphics engine does both at the same time. In an effort to make it easier for the programmer, it automatically sorts and optimizes every single image in its rendering pipeline. By doing this through a highly efficient pipeline, it actually improves the average performance of the application because the programmer is no longer required to figure out all possible optimizations anymore - the engine does it instead.

My fundamental point here is that modern applications are bloated and slow and bog down machines when there exist proven examples of programs that do the exact same thing at a fraction of the cost. Lazy programming helps no one.