>We're there again: take 3 lines of JavaScript and you're drawing an image[...]
I think Carmack wasn't referring to how more abstractions could make his life easier. I've never had the time to dig deeply into id Software's sources (which get open sourced after a couple of years, in case someone didn't know), but what I've often heard him complain about were the abstractions themselves! This is basically about how we wrap a couple of layers around the drivers these days - drivers which have become increasingly complex.
See, abstractions are a good thing. General purpose abstractions might be a good thing for a lot of applications. For some, like graphics engines, they're not. Suppose you're working on a cutting edge 3D engine and you want to squeeze the last bit of performance from the machine. What you end up doing is talking to the graphics card as directly as possible, with the least amount of "layers of crap", as Carmack called them, inbetween you and the hardware.
General-purpose abstractions are loaded with stuff you don't necessarily need and come with quite a bit of overhead. Suppose you have 10 layers between you and the hardware, then everything you try to tell the hardware has to go through all those layers and possibly back to you. That's quite a drawback.
Since drivers have become rather complex themselves as GFX hardware has become more powerful in the last 2 decades you need quite a lot of code to talk to it properly.
The same thing goes for setting up the screen for rendering. Windows wants you to be quite verbose about what you're going to do (obviously). That's why you need 200 lines of code to do so.
The only way round that is using libraries that abstract those things away from you, but they do so at additional cost. Obviously it's possible to do the same thing in just one line of <insert your favourite language here> in the same way that it's possible to do the same thing in just a couple of lines of low level code as long as you have a library doing it for you.
However, as pointed out, in an AAA game engine, that's not what you want to do. There's a reason why the "highest common denominator" is usually D3D here. It's because D3D is still reasonably quick (although not as quick as OpenGL) and does enough things for you.
> It's because D3D is still reasonably quick (although not as quick as OpenGL)
While I believe that OpenGL is better for everyone if only because it's an open standard, I think that one article noting a difference between the two APIs should not lead to the conclusion that "OpenGL is faster than D3D, full stop".
Your reasoning is definately correct. I haven't made enough measurements myself to justify the statement, but the couple of times I did, OpenGL was usually a tad quicker. However that's more anecdotal evidence than anything else.
I think Carmack wasn't referring to how more abstractions could make his life easier. I've never had the time to dig deeply into id Software's sources (which get open sourced after a couple of years, in case someone didn't know), but what I've often heard him complain about were the abstractions themselves! This is basically about how we wrap a couple of layers around the drivers these days - drivers which have become increasingly complex.
See, abstractions are a good thing. General purpose abstractions might be a good thing for a lot of applications. For some, like graphics engines, they're not. Suppose you're working on a cutting edge 3D engine and you want to squeeze the last bit of performance from the machine. What you end up doing is talking to the graphics card as directly as possible, with the least amount of "layers of crap", as Carmack called them, inbetween you and the hardware.
General-purpose abstractions are loaded with stuff you don't necessarily need and come with quite a bit of overhead. Suppose you have 10 layers between you and the hardware, then everything you try to tell the hardware has to go through all those layers and possibly back to you. That's quite a drawback.
Since drivers have become rather complex themselves as GFX hardware has become more powerful in the last 2 decades you need quite a lot of code to talk to it properly.
The same thing goes for setting up the screen for rendering. Windows wants you to be quite verbose about what you're going to do (obviously). That's why you need 200 lines of code to do so.
The only way round that is using libraries that abstract those things away from you, but they do so at additional cost. Obviously it's possible to do the same thing in just one line of <insert your favourite language here> in the same way that it's possible to do the same thing in just a couple of lines of low level code as long as you have a library doing it for you.
However, as pointed out, in an AAA game engine, that's not what you want to do. There's a reason why the "highest common denominator" is usually D3D here. It's because D3D is still reasonably quick (although not as quick as OpenGL) and does enough things for you.