[Ghostavo]

Are you seriously telling me that using say... a 512x512 texture is the same thing speed wise as using a 64x64 one?

[Flipside]

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.

[Ghostavo]

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.

[Flipside]

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.

[Ghostavo]

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.

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...

[blackhole]

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).

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.

[headdie]

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

[Scooby_Doo]

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).

[blackhole]

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.

[chief1983]

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.

[Scooby_Doo]

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.

[esarai]

My school's computer club is going to flip when they find out about this.

[Stormkeeper]

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.

[asyikarea51]

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

[Ghostavo]

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.

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?

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.

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.

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.

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? 

[Unknown Target]

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.

[chief1983]

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).

[Ghostavo]

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.

[chief1983]

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.

[blackhole]

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.

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.

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.

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.

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.