> Bad comparison. While AMD proposed to Khronos their Mantle as a base for OpenGL-next and in general aim to make it open, Apple didn't do any such thing. Apple does Metal precisely out of lock-in mentality.
If you don't think Apple has invested a shit-ton of money into GLES to make it habitable I just don't think you're living in a world inhabited by the rest of us. Apple has spent tons of man-hours and money dealing with the OpenGL process. But no, Snidely fuckin' Whiplash is over here curling his moustache and hissing "yessss, yesss, everything we do by stripping out layers of abstraction and making things faster for obvious and comprehensible reasons is eeeeeeevil."
They still support GLES. They still participate in the process. But they offer a frankly better solution too, one on top of which you can build an agnostic API that can better leverage each platform's better options than OpenGL.
> It's not a "feature" to stagnate hardware for such long periods of time.
Cool. Get normal people to shell out for a new console--you know, that thing that lives in a home theater center that you buy and stop thinking about--every two years. Don't worry, everybody else will definitely wait for the market to prove you right, they won't be over here cooking on what actually works.
Upgrades should not depend on where you place your computer. There is absolutely no logical relation between how often you want to upgrade and the type of gaming it's used for. So who said consoles have to be all locked up and controlled by Sony, MS and Co.? There is no reason to, but they do it in order to control developers. It's all about lock-in and reducing choice, not about anything else.
> If you don't think Apple has invested a shit-ton of money into GLES to make it habitable I just don't think you're living in a world inhabited by the rest of us...
they offer a frankly better solution too
So, where is their proposal to make Metal into OpenGL-next? Until it surfaces, Metal will remain a lock-in attempt.
> Upgrades should not depend on where you place your computer.
They aren't computers. This is the blinkered view of people way too close to their choice of silicon that ignores what people who actually buy hardware want. Normal people don't want computers. Computers suck and are hard to use. They want predictable, turn-key solutions. I'd point to the smoking ruin that is the commercial HTPC market as evidence that, hey, maybe this actually is a thing that works...but I have this sneaking suspicion you'll just say that's definitely not a true Scotsman, no no no.
> So who said consoles have to be all locked up and controlled by Sony, MS and Co.?
Nobody, so don't put words in my mouth.
> So, where is their proposal to make Metal into OpenGL-next? Until it surfaces, Metal will remain a lock-in attempt.
If you would stop extrapolating general-purpose software to to hardware layers for just a tick, the notion might enter your head that Metal is designed around the behaviors of the guts of the A7. It doesn't make sense to generalize it because the generalization of it into "OpenGL-next" takes away the reason to use it! You can bleat 'till you're blue in the face about how terrible it is that people would trade abstractive consistency for performance, but it's what everybody's done in games--and, when you add enough zeroes to a problem, software in general--forever.
Abstractions inevitably fail. Your ideology can attempt to ignore it. It'll fail, too. And the arrogance that you display in this insistence that people have thought about this much much more than you must be acting dishonestly because they disagree with your ideological bent is simply astounding.
Sony and MS did. "Nobody" now is probably Valve who want to disrupt the sickening locked up consoles scene. Time will tell if they'll succeed.
> It doesn't make sense to generalize it
No, it does make sense to provide a generic cross platform API. We aren't in the dark ages of computing anymore. Forcing developers to use hardware specific code is backwards unless we are talking about drivers and assembly like development.
> Abstractions inevitably fail.
Is that Apple's argument for Metal? Abstractions don't fail. They save tons of effort for developers. Otherwise why don't you propose writing programs in machine code like in the olden days? That for sure can produce the most optimized result in theory.
> We aren't in the dark ages of computing anymore. Forcing developers to use hardware specific code is backwards unless we are talking about drivers and assembly like development.
Do you think game development followed the web off the performance-doesn't-matter cliff and went "welp, we're just going to go write everything in Ruby"? What exactly do you think game development is if not intensely performance-critical low-level software development? Do you somehow think they aren't writing whacks of assembly and adding code paths for specific versions of drivers because of reasons X, Y, and Z?
> Otherwise why don't you propose writing programs in machine code like in the olden days?
You literally must be trolling. What do you think game developers do when they run into hot spots in their code? Bunches of AAA games (and every engine vendor, thanks much) have one or more gurus around who eat and sleep the assembly language for every deployable platform. I know a guy--socially, we're not friends, but we've talked about this--whose entire job is rendering optimization for iOS. He owns a big whack of stiff C where every allocation is carefully considered and which has more than a little assembly in there. Because that's what you do when you need to wring performance out of a system. He digs Metal because it makes him better at his job--at making the hardware optimally do what he very badly needs it to do.
Stop trying to conflate web development on future computers from beyond the moon with game development because what you know does not hold. These games are not being written in Node, they are not being written in environments with garbage collection--hell, a lot of the time they don't even use inheritance in C++ because of the cost and complexity of vtables (this is one of the reasons the standard collection libraries in C++ are a template soup, as it happens). It's not the "olden days," it's today, now. That's why these low-level APIs are coming about: because the abstractions you think don't fail don't cut it.
"Abstractions don't fail" is one of the most unintentionally funny things I've read in a very long time and I can literally think of a dozen places just off the top of my head in my very much non-gamedev job where the abstraction layers other people put in place screwed me hard. Quit while you're very far behind.
> Do you think game development followed the web off the performance-doesn't-matter cliff and went "welp, we're just going to go write everything in Ruby"?
Cross platform APIs can be native in C/C++. Ruby or Node have nothing to do with it.
> It's not the "olden days," it's today, now.
Sure, it's today now on consoles which provide low quality generic APIs because no one cared to provide high quality ones. That's not a valid reason to say "fire! we now need machine code to save the gaming industry at large". That's a reason to say that console manufacturers don't care about developers besides locking them into their platforms. Luckily this is going to change. Of course you are free to use low level code still when it's really needed.
> I can literally think of a dozen places just off the top of my head in my very much non-gamedev job
We are talking about gaming. I can think of cases where low level development is needed too. That's irrelevant to the discussion about using cross platform APIs vs using platform locked ones.
If you are seriously going to attempt to reject the parallel between assembly code and low-level platform-specific APIs, I'm utterly done with you.
(And there's x86 and x64 assembly in UE3. For PCs, right now. But don't let that stop you from telling people how to do their jobs. It's a shame @ShitHNSays got canned.)
If you use Metal or similar you'll have to either show users of other platforms to the door or to support N such APIs. Most would prefer to reduce that number not multiply it.
All that cheering for Metal is not sincere. Talk to actual developers who are forced to support many APIs because no one cared to make one cross platform work well. The bottom line, we need less of lock-in APIs promoted as the way to develop games.
In some cases. In other cases engine developers support multiple back ends and for actual game developers this is simplified by using that engine. But in any case if the game wants to be inclusive rather than exclusive the burden of supporting multiple APIs will show up. Either for studio developers themselves or as expense to hire contractors who do the porting or this will fall to engine developers.
If you don't think Apple has invested a shit-ton of money into GLES to make it habitable I just don't think you're living in a world inhabited by the rest of us. Apple has spent tons of man-hours and money dealing with the OpenGL process. But no, Snidely fuckin' Whiplash is over here curling his moustache and hissing "yessss, yesss, everything we do by stripping out layers of abstraction and making things faster for obvious and comprehensible reasons is eeeeeeevil."
They still support GLES. They still participate in the process. But they offer a frankly better solution too, one on top of which you can build an agnostic API that can better leverage each platform's better options than OpenGL.
> It's not a "feature" to stagnate hardware for such long periods of time.
Cool. Get normal people to shell out for a new console--you know, that thing that lives in a home theater center that you buy and stop thinking about--every two years. Don't worry, everybody else will definitely wait for the market to prove you right, they won't be over here cooking on what actually works.